---

Min bror har bedt mig om hjælp til at gøre en Cisco 761M lidt mindre
pivåben. Jeg har kigget lidt i manualen og har strikket følgende
sammen:

Tillad alt fra lokalt net (netmask 255.255.255.0):
SET IP FILTER IN SOURCE = ip.på.lokalt.net/24 ACCEPT

Tillad derudover udefra:

Tcp-pakker, som ikke forsøger at skabe en ny forbindelse:
SET IP FILTER tcpxsyn IN ACCEPT

Udp-pakker, som kommer fra "kendte" dns- og ntp-servere:
SET IP FILTER udp IN SOURCE = ip.på.dns.server1/32:53 ACCEPT
SET IP FILTER udp IN SOURCE = ip.på.dns.server2/32:53 ACCEPT
SET IP FILTER udp IN SOURCE = ip.på.dns.server3/32:53 ACCEPT
SET IP FILTER udp IN SOURCE = ip.på.ntp.server1/32:123 ACCEPT
SET IP FILTER udp IN SOURCE = ip.på.ntp.server2/32:123 ACCEPT
SET IP FILTER udp IN SOURCE = ip.på.ntp.server3/32:123 ACCEPT

Icmp-pakker, bortset fra icmp redirect:
SET IP FILTER icmpxrd IN ACCEPT
(Egentlig ville jeg også gerne have lukket for icmp
address-mask-request, hvad den så end gør, samt icmp echo-request,
men kan jeg mon det?)


Ser det fornuftigt ud?

Alternativt, findes der noget sted på nettet et forslag til sikker
opsætning? Jeg ledte hos www.cisco.com uden held.


--
Allan Olesen, Lunderskov
Hvorfor er det kun Nej-sigerne, der må køre 55 i byen?

---

Hej Allan Olesen <aolesen@post3.tele.dk>

>Tcp-pakker, som ikke forsøger at skabe en ny forbindelse:
>SET IP FILTER tcpxsyn IN ACCEPT

>Icmp-pakker, bortset fra icmp redirect:
>SET IP FILTER icmpxrd IN ACCEPT
>(Egentlig ville jeg også gerne have lukket for icmp
>address-mask-request, hvad den så end gør, samt icmp echo-request,
>men kan jeg mon det?)

Nej, tror ikke 700-serien kan differenciere ICMP typer andet end de
prædefinerede types under ip filter.

>Ser det fornuftigt ud?

Ser udmærket ud, jeg ville endvidere lægge et filter så ingen fra WAN
interfacet får lov til at adressere routeren direkte, med men der er
tale om port-forwarding/pat eller lign.

>Alternativt, findes der noget sted på nettet et forslag til sikker
>opsætning? Jeg ledte hos www.cisco.com uden held.

Det meste om 700 serien handler om dial cookbooks, du kan prøve at se
om der er noget interessant her:

http://www.cisco.com/warp/public/700/configaccess.html

og jeg går ud fra du har læst:

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_fix/750/700cr44/700crip.htm#xtocid554939

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund <larskim@mail.com> wrote:

>Ser udmærket ud,

Tak.

>jeg ville endvidere lægge et filter så ingen fra WAN
>interfacet får lov til at adressere routeren direkte,

Det troede jeg egentlig, at jeg havde gjort med ovenstående, i det
omfang, det var muligt?

Men du tænker måske på noget i retning af:

SET IP FILTER IN SOURCE = NOT ip.på.lokalt.net/24 DESTINATION =
ip.på.router BLOCK

Men vil det ikke også spærre for pakker, som skal videre tilbage på
det lokale net vha. nat/pat/masquerading/whatever?

Eller er den intelligent nok til at kende forskel?

(Jeg har ikke selv en router at afprøve det på. Ellers ville jeg ikke
stille et så dumt spørgsmål.)

>med men der er tale om port-forwarding/pat eller lign.

Du snakker sort lige nu, gør du ikke?

Jeg er forresten kommet til at tænke på, at man vel næsten med
sikkerhed får problemer med ikke-passiv ftp med mit regelsæt. Er der
en vej uden om det?

(Hvis det var en Linux-maskine, ville jeg bare indlæse det
kernel-modul, som router ftp, men det her ligner godt nok ikke Linux,
selv om der er en kommandoprompt.)

>Det meste om 700 serien handler om dial cookbooks, du kan prøve at se
>om der er noget interessant her:

>http://www.cisco.com/warp/public/700/configaccess.html

Jo, tak. Der har jeg været uden held.

>og jeg går ud fra du har læst:
>
>http://www.cisco.com/univercd/cc/td/doc/product/access/acs_fix/750/700cr44/700crip.htm#xtocid554939

Det er vist et udsnit af den manual, som min bror mailede mig, da jeg
blev træt af at hjælpe ham over telefonen[1] uden manual, men hvad er
det, der gør lige præcis "show ip filter" interessant?


[1]: Jeg har engang lært ham at binde slips med dobbeltknude over
telefonen, så vi er ellers vant til at kunne komme langt ad den vej.


--
Allan Olesen, Lunderskov
Hvorfor er det kun Nej-sigerne, der må køre 55 i byen?

---

Hej Allan Olesen <aolesen@post3.tele.dk>

>>jeg ville endvidere lægge et filter så ingen fra WAN
>>interfacet får lov til at adressere routeren direkte,
>
>Det troede jeg egentlig, at jeg havde gjort med ovenstående, i det
>omfang, det var muligt?

Jeg gennemskuede ikke om du sendte hele filtret eller udsnit - og jeg
har arbejdet alt for lidt med 7xx filtre til at jeg udfra et par
kommandoer kan se hvordan det virker i praksis, andet end det
overordnede, som jo står mere eller mindre i "klar tekst".

Jeg har faktisk arbejdet en del med 7xx, men kun i beskyttede miljøer,
hvor filtrering ikke er relevant.

>Men du tænker måske på noget i retning af:
>
>SET IP FILTER IN SOURCE = NOT ip.på.lokalt.net/24 DESTINATION =
>ip.på.router BLOCK

Ja, noget i den stil.

>Men vil det ikke også spærre for pakker, som skal videre tilbage på
>det lokale net vha. nat/pat/masquerading/whatever?

Du kan nøjes med at filtrere de services som routeren har, snmp,
telnet etc.

>Eller er den intelligent nok til at kende forskel?

Jeg kan ikke huske opbygningen af 7xx filtre, men normalt er den
hierarkisk og dropper ud ved første match. Det er uvist om der er
implicit deny any, men det står sikkert i manualen. Dvs.

Accept X -> A
Accept Y -> B
Accept Z -> C
Block any

Det vil sige tillad X, Y og Z og drop resten.

>>med men der er tale om port-forwarding/pat eller lign.
>Du snakker sort lige nu, gør du ikke?

Det var faktisk det du selv kom ind på, hvis du blocker alt til
routeren, så mister du mulighed for at oversætte og forwarde.

Altså router-ip port XX -> intern-IP port YY

>Jeg er forresten kommet til at tænke på, at man vel næsten med
>sikkerhed får problemer med ikke-passiv ftp med mit regelsæt. Er der
>en vej uden om det?

Hmm, så vidt jeg husker FTP's natur vil serveren lave en session
tilbage med sourceport 20/tcp (ftp-data), dvs. at du burde kunne lave
en regel i stil med

Accept udefra syn hvis sourceport = 20/tcp
Block udefra syn (dvs. alt andet)

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund <larskim@mail.com> wrote:

>Jeg kan ikke huske opbygningen af 7xx filtre, men normalt er den
>hierarkisk og dropper ud ved første match. Det er uvist om der er
>implicit deny any, men det står sikkert i manualen. Dvs.

OK. Nu forstår jeg hvorfor du mener, der ikke er spærret for adgang
til routeren. Jo, den fungerer sådan, at bare een af filterreglerne er
ACCEPT, vil default policy være BLOCK. Derfor har jeg ikke eet eneste
BLOCK-filter.

>Hmm, så vidt jeg husker FTP's natur vil serveren lave en session
>tilbage med sourceport 20/tcp (ftp-data), dvs. at du burde kunne lave
>en regel i stil med
>
>Accept udefra syn hvis sourceport = 20/tcp
>Block udefra syn (dvs. alt andet)

Så må han hellere klare sig med passiv ftp. Jeg tør vædde på, at den
løsning er så udbredt, at mange hackere vil finde ud af at bruge port
20 som source-port.

Tak for hjælpen.
--
Allan Olesen, Lunderskov
P/N 1391407 1991-05-13

---

Hej Allan Olesen <aolesen@post3.tele.dk>

>>Jeg kan ikke huske opbygningen af 7xx filtre, men normalt er den
>>hierarkisk og dropper ud ved første match. Det er uvist om der er
>>implicit deny any, men det står sikkert i manualen. Dvs.
>
>OK. Nu forstår jeg hvorfor du mener, der ikke er spærret for adgang
>til routeren. Jo, den fungerer sådan, at bare een af filterreglerne er
>ACCEPT, vil default policy være BLOCK. Derfor har jeg ikke eet eneste
>BLOCK-filter.

Altså en hvid-liste, det er også det mest normale. Hvis man laver
sort-lister skal man huske en accept any til sidst, men det siger jo
sig selv.

>>Accept udefra syn hvis sourceport = 20/tcp
>>Block udefra syn (dvs. alt andet)
>
>Så må han hellere klare sig med passiv ftp. Jeg tør vædde på, at den
>løsning er så udbredt, at mange hackere vil finde ud af at bruge port
>20 som source-port.

Hvis de er tilstrækkelig intelligente og interesserede. Størsteparten
er dog scriptkiddies der bare fyrer et par port-scans af og mister
interessen hvis der ikke sker noget.

Tænk på biltyve, de tager de lette biler på en parkeringsplads (f.eks.
dem uden startspærre).

Jeg er tæt på at mene at hvis ambitionsniveauet er så højt burde man
kigge på noget rigtig stateful inspection.

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund <larskim@mail.com> wrote:

>Altså en hvid-liste, det er også det mest normale. Hvis man laver
>sort-lister skal man huske en accept any til sidst, men det siger jo
>sig selv.

Hvid-lister er lidt af en kæphest for mig. Hvis jeg skal lave
sort-lister, skal jeg jo kende alt det, jeg skal beskytte mig mod.
Hvis jeg skal lave hvid-lister, skal jeg (næsten) kun kende det, jeg
har brug for at anvende.

>Hvis de er tilstrækkelig intelligente og interesserede. Størsteparten
>er dog scriptkiddies der bare fyrer et par port-scans af og mister
>interessen hvis der ikke sker noget.

Hedder de ikke script-kiddies, fordi de downloader færdige scripts og
programmer, som kan udføre en bestemt hacker-opgave? Så er det jo
programmørens intelligens, man skal frygte, og jeg kan forestille mig,
at port 20 og 53 er populære valg blandt disse programmører.

>Tænk på biltyve, de tager de lette biler på en parkeringsplads (f.eks.
>dem uden startspærre).

Enig.

>Jeg er tæt på at mene at hvis ambitionsniveauet er så højt burde man
>kigge på noget rigtig stateful inspection.

Ambitionsniveauet er nok noget lavere. Man kunne jo sige:
"Den bedst mulige sikkerhed med det givne udstyr og trafikbehov."

Altså at lukke mest muligt, og kun udsætte sig for risikoen ved at
åbne noget, hvis det er nødvendigt for at dække et specifikt behov for
adgang. Så hvis det viser sig, at de i firmaet ikke har brug for at gå
ind på ftp-sites, der ikke tillader passiv ftp, kan man lige så godt
bruge den mere paranoide opsætning.

Uanset ambitionsniveau var udgangspunktet nærmest katastrofalt. Han
ringede og fortalte, at han havde købt en router til firmaet og havde
fået Pro@ccess ISDN. Nu ville han gerne lige have mig til at checke,
at der ikke var adgang udefra. En hurtig portscanning viste, at
telnet-porten stod åben. Så telnettede jeg til routeren, kom ind uden
password og gav mig til at ændre hans opsætning - så meget man nu kan,
når man aldrig før har snakket med en Cisco.

Jeg fatter simpelthen ikke, at man sælger routere, der pr. default
accepterer telnet login fra Internettet. Det er sådan noget, man kan
åbne, hvis man har brug for det. Jeg har før brokket mig over min
Dlink, men jeg troede dengang, at Dlink var nogle helt enestående
fjolser. Nu viser det sig så, at de bare deler tankegang med Cisco.


--
Allan Olesen, Lunderskov
Hvorfor er det kun Nej-sigerne, der må køre 55 i byen?

---

Hej Allan Olesen <aolesen@post3.tele.dk>

>>Altså en hvid-liste, det er også det mest normale. Hvis man laver
>>sort-lister skal man huske en accept any til sidst, men det siger jo
>>sig selv.
>
>Hvid-lister er lidt af en kæphest for mig. Hvis jeg skal lave
>sort-lister, skal jeg jo kende alt det, jeg skal beskytte mig mod.
>Hvis jeg skal lave hvid-lister, skal jeg (næsten) kun kende det, jeg
>har brug for at anvende.

Det mest normale er at benytte hvid-lister når det drejer sig om
sikkerhed, men nu bruges access-lister til andet end sikkerhed, og der
er mange tilfælde hvor sort-lister er anvendelige.

Så alt til sin tid.

>Uanset ambitionsniveau var udgangspunktet nærmest katastrofalt. Han
>ringede og fortalte, at han havde købt en router til firmaet og havde
>fået Pro@ccess ISDN. Nu ville han gerne lige have mig til at checke,
>at der ikke var adgang udefra. En hurtig portscanning viste, at
>telnet-porten stod åben. Så telnettede jeg til routeren, kom ind uden
>password og gav mig til at ændre hans opsætning - så meget man nu kan,
>når man aldrig før har snakket med en Cisco.

Det viser også at det er en SOHO-ting, stort set alle andre
Cisco-bokse tillader ikke remote login hvis ikke password er
defineret.

>Jeg fatter simpelthen ikke, at man sælger routere, der pr. default
>accepterer telnet login fra Internettet. Det er sådan noget, man kan
>åbne, hvis man har brug for det. Jeg har før brokket mig over min
>Dlink, men jeg troede dengang, at Dlink var nogle helt enestående
>fjolser. Nu viser det sig så, at de bare deler tankegang med Cisco.

Cisco 7xx og måske 6xx (har aldrig brugt dem), alt andet jeg har mødt,
det være sig IOS routere, switche ol. har som sagt ikke tilladt login
med mindre password var sat.

En anden "sjov" ting er at meget er web-enablet, endnu en ting, der
kan exploites, og der har faktisk været software fra Cisco, hvor netop
web-adgangen kunne komprimitteres. Så med mindre man har brug for det
så bør man disable den eller i det mindste sørge for at kun kendte
adresser kan benytte den, tilsvarende (og egentlig i højere grad)
gælder SNMP, hvis man gætter write community så har man FULD kontrol
over boksen,

--
Lars Kim Lund
http://www.net-faq.dk/

---

On Sat, 24 Feb 2001 20:41:20 GMT, Lars Kim Lund
<larskim@mail.com> wrote:

> Det viser også at det er en SOHO-ting, stort set alle andre
> Cisco-bokse tillader ikke remote login hvis ikke password er
> defineret.

Crescendo IOS.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.org/networking/
FAQ : http://www.net-faq.dk/

---

Hej Asbjorn Hojmark <Asbjorn@Hojmark.ORG>

>> Det viser også at det er en SOHO-ting, stort set alle andre
>> Cisco-bokse tillader ikke remote login hvis ikke password er
>> defineret.
>
>Crescendo IOS.

Uhm, ja, du har ret.

--
Lars Kim Lund
http://www.net-faq.dk/