[Debian 3.0] Ipchains, udp wel, tcp verkeer niet

[Verwijderd]

Op mijn stage plaats hebben we op dit moment een windows gebasseerde isdn router. Deze geeft de computers in het lan internet toegang en stuurt de mail door naar een Mdaemon mailserver op het lan. Dit doormiddel van bsmtp.

Omdat we niet tevreden zijn over deze oplossing ben ik al enkele maanden bezig met een Linux oplossing. Dit vindt ik wel een uitdaging omdat ik verder nooit in de gelegenheid ben gesteld om zo'n project uit te voeren.

Ik ben begonnen met de IP masquerade howto te lezen. Ook heb ik het boek Linux firewall's als goede hulp.

Ik heb Debian 3.0 op een pc met isdnkaart geinstalleerd en 1 netwerkkaart voor het interne lan geinstalleerd. Ik heb Kernel 2.2.23 gecompileerd en geinstalleerd op deze machine.

Ik kan gewoon inbellen naar de service provider. Daarna heb ik geprobeerd de Simple internet deel methode die beschreven staat in de ipmasqarding howto werkend te krijgen. Als ik dat doe krijg ik internet goed aan de praat.

Daarna heb ik met behulp van Linux Firewalls een sterker firewall script geschreven. Ook heb ik in /etc/network/options spoofprotect ip_forward en syncookies op yes gezet.

Ik heb het script in /etc/init.d/ip-up.d heb gezet.
firewall script . En als de verbinding wordt gestart wordt dit schript ook op de achtergrond uitgevoerd. ipchains -L uitvoer

Nu kan ik zowel op de server zelf als op een machine in het Lan geen TCP verbindingen meer maken. Als ik een ping naar www.tweakers.net vanuit het lan of op de server doe dan krijg ik wel gewoon een reactie terug. Maar alle TCP verbindingen worden geblockt en ik kan niet achterhalen waarom.

Als ik bijvoorbeeld op een Windows 2000 pro machine de website www.tweakers.net probeer krijg ik in beeld het ipadress en bezig met het maken van een connectie naar <vul ip adres in>, daarna wil hij naar de msn site voor een foute pagina en daarna krijg ik: kan de zoekpagina niet openen. Als ik in een command.com scherm netstat -n intik krijg ik alleen:

code:

Proto           Lokaal adres           Extern adres               status
TCP               192.168.0.6           213.239.154.35:80     Syn_sent

Ik denk dat het in de syn ack vlaggen van mijn regels zit. Maar als ik de tabellen met de verbindings opbouw van mijn Linux Firewalls boek van de verschillende diensten bekijk kan ik niks vreemds aan mijn regels ontdekken. Ook in syslog of messages kan ik niks vreemds ontdekken.

ifconfig:

Uitvoer van ifconfig

route -n:
uitvoer van route

Op de het lan probeer ik het met een win2k pro client.
ipadress 192.168.0.6
netmask 255.255.225.0
gateway 192.168.0.2
dns: 213.227.141.10

Niet alleen http verbindingen mislukken op beide machines ook Ftp en telnet verbindingen. Wat doe ik fout.

[Verwijderd]

hoi,

ik heb het vermoeden dat het probleem in het volgende zit:
# Lan toegang tot Internet: IP doorsturen (Forwarding) en maskeren
$IPCHAINS -A forward -i $EXTERNAL_INTERFACE -s $LAN_1 -j MASQ

Ik weet het niet helemaal zeker maar ik denk dat de interface niet helemaal goed beschreven is.
Wat ik altijd doe om het probleem te zoeken is zo min mogelijk opties in een regel te zetten.
Begin bijvoorbeeld eens met:
$IPCHAINS -A forward -s $LAN_1 -j MASQ
Op die manier heb je minder kans dat een optie je in de weg zit, later kun je dit altijd uitbreiden tbv. de veiligheid ed.

[zeik] Daarom is iptables zo mooi die kan zowel een interface als een "outerface" beschrijven. [/zeik]

[Verwijderd]

of gebruik pmFireWall, is een handig script om alles in te stellen, aan de hand van een aantal vragen.
In ieder geval de moeite waard om te bekijken.

[_JGC_]

Vraagje: waarom nog ipchains en een 2.2 kernel?

[Jordi]

Dat lijkt me niet echt relevant (ik draai ook 2.2 en met een goede reden).

[Verwijderd]

Even twee aanmerkingen, eerst over je methode: je hebt veel gedaan, veel gezocht e.d., maar je debugging methode is nogal vreemd. Wat ik zou doen is gewoon vanaf point zero (je werkende verbinding plus "$IPCHAINS -F && for chain in input output forward; do $IPCHAINS -P $chain ACCEPT; done") proberen een firewall uit te bouwen, eerst met NAT/ipmasq functionaliteit, en daarna met firewall (blocking) functionaliteit. Gewoon een script schrijven en dan zeggen "oh, hij doet het niet" is niet erg handig. Als ik software schrijf, dan begin ik vaak ook vanuit point zero, en steeds als ik iets toevoeg (al was het slechts een scherm met 1 knopje wat er nu twee zijn, bij wijze van), dan test ik het weer, zodatals er iets niet goed gaat, ik meteen weet waar het aan ligt. Dus het punt: bij elke toevoeging even snel opnieuw testen - dan weet je waar het fout gaat. Bv. eerst NAT functionaliteit, dan UDP blocken behalve de DNS en evt. wat anderen dingen (default input op reject/deny zetten, en een -p tcp -j ALLOW doen), dan TCP blocken (default input op reject/dney houden, -p tcp -j ALLOW weghalen), etc. Dus: houdt het simpel!

Okee, nu over je firewall zelf, want hij bestaat schijnbaar al. Ik kan niet zeggen waarom het niet werkt, omdat ik het niet kan testen voor je, ik kan wel aanmerkingen geven.

code:

$IPCHAINS -P input DENY
$IPCHAINS -P output REJECT
$IPCHAINS -P forward REJECT

Waarom output/forward op REJECT? Output gaat bij standaard firewalls op ACCEPT, omdat je dan verbindingen naar buiten kan opbouwen. Dit gebeurt alleen als je uitgaand verkeerd ook streng wilt controleren (en dus niet enkele services buitensluiten, maar "slechts enkele services toestaan").

code:

# Negeer de door het IANA gereserveerde adressen
...

Wat is daar het nut van? Ze worden toch als extern adres geinterpreteerd en zouden toch nooit meer dan de standaard toegang krijgen via de firewall. Dus: waarom?

code:

OPENWINDWOS_PORT="2000"             # (TCP) Open Windows
$IPCHAINS -A output -i $EXTERNAL_INTERFACE -p tcp -y \
                    -s $IPADDR \
                    -d $ANYWHERE $OPENWINDOWS_PORT -j REJECT

Hier moet je uitkijken. Een TCP verbinding verloopt niet over diezelfde poort als over welke ze geinitialiseerd is. Dus je moet hier alleen REJECT doen als de SYN TCP flag geset is. Zie de manual over hoe je dat kan checken. Maar dit geldt dus voor alle TCP verbindingen!

code:

NAMESERVER="213.227.141.10"
.. doe dingen hiermee

Je hebt meerdere nameservers, gebruik een for lus:

code:

for NAMESERVER in 213.227.141.10 213.227.141.11 213.227.141.12 [etc]; do
        .. doe dingen met $NAMESERVER
        done

code:

$IPCHAINS -A input -i $EXTERNAL_INTERFACE -p tcp \
                   -s $ANYWHERE $UNPRIVPORTS \
                   -d $IPADDR 113 -j ACCEPT

$IPCHAINS -A output -i $EXTERNAL_INTERFACE -p tcp ! -y \
                    -s $IPADDR 113 \
                    -d $ANYWHERE $UNPRIVPORTS -j ACCEPT

Oe, dit lijkt echt fout. Sorry, maar ik gooi dit even gemakzuchtig onder de noemer "teveel willen doen". Aan de server kant worden de verbindingen namelijk ook naar een private port gegooid aangezien de verbinding TCP is. allow gewoon uitgaande connecties naar poort 113 met de SYN bit geset (-y/--syn -> gebruik trouwens GNU-style --long-options, dat is leesbaarder!), en laat inkomend TCP verkeerd en uitgaand TCP verkeer zonder de SYN bit geset (! -y) per definitie toe, over elke poort. Als de packet fake is, dan zal de kernel dat al afhandelen (aangezien je geen verbinding kan hebben als deze niet eerst is opgezet). Oftewel: je maakt het jezelf hier ontzettend moeilijk zonder dat daar reden toe is, imho. Dit doe je ook op meerdere plekken, niet alleen hier. Zou best kunnen dat je hierdoor geen TCP verbindingen kan opzetten.

code:

# Passieve modus FTP datakanalen toestaan
$IPCHAINS -A output -i $EXTERNAL_INTERFACE -p tcp \
                    -s $IPADDR $UNPRIVPORTS \
                    -d $ANYWHERE $UNPRIVPORTS -j ACCEPT

$IPCHAINS -A input -i $EXTERNAL_INTERFACE -p tcp \
                   -s $ANYWHERE $UNPRIVPORTS \
                   -d $IPADDR $UNPRIVPORTS -j ACCEPT

Besef je dat je je halve server hiermee opengooit? Allow alle non-SYN packages en allow specifieke SYN packages over poort 21 hiervoor. Bovenstaand is niet echt handig...

Nouja, ik kijk nogal kritisch, trek je je daar niet te veel van aan, maar ik hoop dat je iets aan de aanmerkingen hebt. Firewalls als deze (hand-gemaakt) is echt iets wat niet voor iedereen geschikt is, daar zit veel pijn&moeite in en het kost gewoon ontzettend veel tijd. Gevolg is wel dat je werkelijk alle mogelijkheden hebt die er maar zijn. Maargoed, probeer iets te doen met bovenstaande kritische aanmerkingen voor zover ze nuttig zijn! suc6!

[Verwijderd]

Bedank voor je kritische kantekening Beelzebubu: Ja ik heb het script in een keer geschreven zonder tussentijds te testen. Dit is gebeurt omdat ik niet in de omstandigheid was om iedere wijziging te testen. Dat je je daarmee in de vingers snijdt blijkt nu wel. Ik zal ook zeker zorgen dat ik die mogelijkheid de volgende keer wel heb. Ik weet dat een zelf geschreven firewall een complex gebeuren is. Zo zie ik nu ook pas dat FTP Datakanalen fout is.

En nu kan ik heel moeilijk fouten opsporen in de firewall. Ik heb het wel geprobeert met Ipchains -C en dat bevestigd mijn vermoeden over het blocken van TCP verbindingen. Want alles wat ik probeer met TCP wordt zowel in de input als output chains geblockt. De ipchains -C optie met forward lukt wel. Het zit dus echt in de input en output chains. Maar ik kan niet meer achterhalen waar het nu in zit. En als ik verder ga proberen dan wordt ook udp geblockt. Dan kom je er natuurlijk niet meer achter wat er mis is.

Ik heb dus besloten om opnieuw te beginnen zoals je zei. Als het werkt steeds weer alles testen.

[Buffy]

Tips voor het debuggen van je firewall script:

Voeg overeenkomstige regels samen in een sub chain. Je hebt bv heleboel regels in de vorm:

code:

# Uitgaande AUTH aanvragen toestaan
$IPCHAINS -A output -i $EXTERNAL_INTERFACE -p tcp \
            -s $IPADDR $UNPRIVPORTS \
            -d $ANYWHERE 113 -j ACCEPT
            
$IPCHAINS -A input -i $EXTERNAL_INTERFACE -p tcp ! -y \
           -s $ANYWHERE 113 \
           -d $IPADDR $UNPRIVPORTS -j ACCEPT
           
# Inkomende AUTH aanvragen toestaan
$IPCHAINS -A input -i $EXTERNAL_INTERFACE -p tcp \
           -s $ANYWHERE $UNPRIVPORTS \
           -d $IPADDR 113 -j ACCEPT
           
$IPCHAINS -A output -i $EXTERNAL_INTERFACE -p tcp ! -y \
            -s $IPADDR 113 \
            -d $ANYWHERE $UNPRIVPORTS -j ACCEPT

Die zou je kunnen vervangen door:

code:

$IPCHAINS -A input -i $EXTERNAL_INTERFACE -p tcp \
            -d $IPADDR -s $ANYWHERE -j ex_input

$IPCHAINS -A output -i $EXTERNAL_INTERFACE -p tcp\
            -s $IPADDR -d $ANYWHERE -j ex_output

# Uitgaande AUTH aanvragen toestaan
$IPCHAINS -A ex_output --sport $UNPRIVPORTS --dport 113 -j ACCEPT
$IPCHAINS -A ex_input  --dport $UNPRIVPORTS --sport 113 -j ACCEPT ! --sync

# Inkomende AUTH aanvragen toestaan
$IPCHAINS -A ex_input  --sport $UNPRIVPORTS --dport 113 -j ACCEPT
$IPCHAINS -A ex_output --dport $UNPRIVPORTS --sport 113 -j ACCEPT ! --sync

Dat maakt het opsporen van (type) fouten wat makkelijker.

Tevens is het handig in elke REJECT/DENY regel '$DEBUG' op te nemen die als je gaat debuggen gevuld kan worden met bv '-l' aan het begin van het script zodat je kan zien welke pakketjes door welke regels worden geblokeerd.

Ook is het handig tijdens het debuggen aan het einde van elke chain (input, forward en output) met policy REJECT of DENY een catch-all log regel toe te voegen zodat je kan zien welke (belangrijke) pakketjes niet gematched worden door de regels in die chain.

Jotti schreef op 11 January 2003 @ 00:07:
Dat lijkt me niet echt relevant (ik draai ook 2.2 en met een goede reden).

Heee Noach, is je ark al af?

[Jordi]

Grappenmakert

[Verwijderd]

Vraagje over het ipchains -C commando. Daarin kan je de -y optie gebruiken en niet ! -y. Als je nu een bericht wilt testen waarin de ACK vlag moet zijn gezet.

Moet je dan helemaal geen vlag invullen? bijvoorbeeld:

code:

ipchains -C input -i ippp0 -p tcp -s 62.100.30.165 80 -d 213.227.142.10 5000

Hierop krijg ik als antwoord accepted. Als ik straks opnieuw beginnen met het schrijven van een script waarin ik:
input DENY
output REJECT
forward REJECT

zet en alleen DNS en standaard http verkeer doorlaat is dit dan een goede manier om testen of een respons van een webserver goed wordt doorgelaten?

Is het uberhaupt goed om op deze manier te beginnen met het schrijven van een firewall?

[Verwijderd]

Zorg sowieso dat packages zonder de SYN bit (! --syn) sowieso worden toegelaten, dan heb je al meer kans dat het goed gaat. .

[Verwijderd]

Ik ben weer overnieuw begonnen dit keer met een veel simpelere configuratie.
En nu werkt het wel. Ik moet het een en ander nog goed testen maar dit bericht typ ik achter de router dus dat geeft hoop

Bedank iedereen voor de reply's.