Gå til innhold

Merkelig(?) ferdiggenerert iptables


Anbefalte innlegg

Må innrømme at jeg ikke er noen ekspert på iptables, men jeg har nå alltid klart å sette opp en simpel firewall med noen linjer kode. Pleier å begynne med å sperre alt, også gradvis åpne det jeg ønsker.

 

Nå ble jeg dog ganske forvirra etter å ha testa Suse 8.2 sin egen firewall-løsning. Var egentlig bare litt nysgjerring på hva den kom til å generere, og jeg ba om å sperre alle innkommende connections unntatt ping/traceroute (og selvsagt relatert trafikk).

 

Hele iptables-oppsettet ble så omfattende at jeg ikke kan skrive det ut her så jeg nøyer meg med INPUT-chainen:

 


skrotburken:~ # iptables -L INPUT

Chain INPUT (policy DROP)

target     prot opt source               destination

ACCEPT     all  --  anywhere             anywhere

LOG        all  --  loopback/8           anywhere           LOG level warning tcp-options ip-options prefix `SuSE-FW-DROP-ANTI-SPOOFING '

LOG        all  --  anywhere             loopback/8         LOG level warning tcp-options ip-options prefix `SuSE-FW-DROP-ANTI-SPOOFING '

DROP       all  --  loopback/8           anywhere

DROP       all  --  anywhere             loopback/8

LOG        all  --  80.111.24.150        anywhere           LOG level warning tcp-options ip-options prefix `SuSE-FW-DROP-ANTI-SPOOFING '

DROP       all  --  80.111.24.150        anywhere

input_ext  all  --  anywhere             80.111.24.150

DROP       all  --  anywhere             ow8pqo1.cm.chello.no

DROP       all  --  anywhere             255.255.255.255

LOG        all  --  anywhere             anywhere           LOG level warning tcp-options ip-options prefix `SuSE-FW-ILLEGAL-TARGET '

DROP       all  --  anywhere             anywhere

skrotburken:~ # 

 

Nå kommer altså mitt problem:

 

Med mitt begrensede intellekt virker det som at første linje slipper all trafikk igjennom :shrug:

 

Iptables begynner jo fra toppen, og går nedover til den finner en passende regel. Hvis ingen passer bruker den chain-policy'en (i dette tilfelle DROP)

 

Det står jo at den skal akseptere alle protokoller fra alle source-addresser.

 

Please enlighten me...[/code]

Lenke til kommentar
Videoannonse
Annonse
Iptables begynner jo fra toppen, og går nedover til den finner en passende regel. Hvis ingen passer bruker den chain-policy'en (i dette tilfelle DROP)

 

Dei fleste program begynner å lese på toppen når det gjeld config-filer, men der får og den siste konfigurasjonen som gjelder eit visst punkt prioritet. Så dersom du først definerer at alt skal slippe gjennom, og seinare definerer at nettet ikkje skal ha tilgang til port 80, så vil brannmuren i teorien sleppe igjennom kva som helst utanom port 80. Ikkje det at eg seier at det nødvendigvis er løysinga her, men eg finn det rart at eit såpass bra laga program som iptables held seg til det som må seiast å rekna som standard.

Lenke til kommentar
Dei fleste program begynner å lese på toppen når det gjeld config-filer, men der får og den siste konfigurasjonen som gjelder eit visst punkt prioritet. Så dersom du først definerer at alt skal slippe gjennom, og seinare definerer at nettet ikkje skal ha tilgang til port 80, så vil brannmuren i teorien sleppe igjennom kva som helst utanom port 80.

Nå er det jo ikke akkurat snakk om config-filer her, men regler som er punchet inn i iptables.

 

Utdrag fra man-filen:

 

A firewall rule specifies criteria for a packet, and a

target. If the packet does not match, the next rule in

the chain is the examined; if it does match, then the next

rule is specified by the value of the target, which can be

the name of a user-defined chain or one of the special

values ACCEPT, DROP, QUEUE, or RETURN.

 

 

Har lest opp og ned i man-filen men er fortsatt like klok :shrug:

Lenke til kommentar
Hvis du slenger med en -v parameter til iptables -L så vil du se hvilken interface regelen gjelder for. Da vil du nok se at den ref'er til intern-beinet. 8)

Det var saker :)

 

skrotburken:~ # iptables -v -L INPUT

Chain INPUT (policy DROP 0 packets, 0 bytes)

pkts bytes target     prot opt in     out     source               destination

 130  8476 ACCEPT     all  --  lo     any     anywhere             anywhere

   0     0 LOG        all  --  any    any     loopback/8           anywhere           LOG level warning tcp-options ip-options prefix `SuSE-FW-DROP-ANTI-SPOOFING '

   0     0 LOG        all  --  any    any     anywhere             loopback/8         LOG level warning tcp-options ip-options prefix `SuSE-FW-DROP-ANTI-SPOOFING '

   0     0 DROP       all  --  any    any     loopback/8           anywhere

   0     0 DROP       all  --  any    any     anywhere             loopback/8

   0     0 LOG        all  --  any    any     80.111.24.150        anywhere           LOG level warning tcp-options ip-options prefix `SuSE-FW-DROP-ANTI-SPOOFING '

   0     0 DROP       all  --  any    any     80.111.24.150        anywhere

75009  106M input_ext  all  --  eth0   any     anywhere             80.111.24.150

   0     0 DROP       all  --  eth0   any     anywhere             ow8pqo1.cm.chello.no

   0     0 DROP       all  --  eth0   any     anywhere             255.255.255.255

 162  5184 LOG        all  --  any    any     anywhere             anywhere           LOG level warning tcp-options ip-options prefix `SuSE-FW-ILLEGAL-TARGET '

 162  5184 DROP       all  --  any    any     anywhere             anywhere

skrotburken:~ #

 

Første linja gjaldt bare for loopback. Så det var en naturlig forklaring likevel.

 

Tusen takk!

Lenke til kommentar
Iptables begynner jo fra toppen, og går nedover til den finner en passende regel. Hvis ingen passer bruker den chain-policy'en (i dette tilfelle DROP)

 

Dei fleste program begynner å lese på toppen når det gjeld config-filer, men der får og den siste konfigurasjonen som gjelder eit visst punkt prioritet. Så dersom du først definerer at alt skal slippe gjennom, og seinare definerer at nettet ikkje skal ha tilgang til port 80, så vil brannmuren i teorien sleppe igjennom kva som helst utanom port 80. Ikkje det at eg seier at det nødvendigvis er løysinga her, men eg finn det rart at eit såpass bra laga program som iptables held seg til det som må seiast å rekna som standard.

 

Ser han har pastet det som sto i man sidene, men på godt norsk blir det;

ved første match, ettersom den traverserer tabellene, blir den gjeldende regelen.

I motsetting til andre os's ipfiltrering (blandt annet openbsd's) som leser hele lista, for så og ta en handling, vil tux'en gjøre sin handling på første match.

 

-Dante

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...