linux router iptables probleem

[ShaneV]

Omdat ik het beu ben te werken met prefab images alla pfsense, smoothwall, ipcop, etc... die teveel bieden dan ik nodig heb, wil ik een simpel linux routertje opzetten die alle inkomende verbindingen blokkeert en alle uitgaande toestaat (ik weet dat het nog beter zou zijn om manueel te zeggen welke poorten naar buiten mogen) maar, dat is voor een later stadium.

Het probleem: verkeer naar buiten werkt niet. Ik mis ergens een regel, iemand enig idee?

ter info: ETH0 ==> WAN , ETH1 ==> LAN
OS: Laatste debian versie

Ik heb tot nu toe:

code:

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/tcp_syncookies


        #Flush table's
        iptables -F INPUT
        iptables -F OUTPUT
        iptables -F FORWARD
        iptables -t nat -F

        #Drop traffic
        iptables -P FORWARD DROP
        iptables -P INPUT DROP
        iptables -P OUTPUT DROP

    #verkeer naar buiten toe laten en nat aanzetten
        iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
        iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
        iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

        #RDP forward voor windows servers
        iptables -t nat -A PREROUTING -p tcp --dport 3389 -i eth0 -j DNAT --to destination 192.168.2.10
        iptables -t nat -A PREROUTING -p tcp --dport 3340 -i eth0 -j DNAT --to destination 192.168.2.12

        #toestaan SSH verkeer
        iptables -t nat -A PREROUTING -p tcp --dport 22 -i eth0 -j DNAT --to destination 192.168.2.1
        iptables -t nat -A PREROUTING -p udp --dport 22 -i eth0 -j DNAT --to destination 192.168.2.1

    #toestaan verkeer loopback
    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT

    #toestaan lokaal netwerk
    iptables -A OUTPUT -o eth1 -j ACCEPT
    iptables -A INPUT -i eth1 -j ACCEPT
    iptables -A INPUT --match state --state RELATED,ESTABLISHED -j ACCEPT

ifconfig eth1 192.168.2.1/24
ifconfig eth0 XXXXXXXX
ifconfig eth0 up
ifconfig eth1 up
route add default gw XXXXXX

[Seth4Chaos]

In je startpost zeg je dat eth0 je WAN is, in de config staat eth0 = 192.168.2.1. dan lijkt me eth0 LAN en eth1 WAN.

verder zou ik deze

code:

        iptables -P OUTPUT DROP

naar accept zetten. Hiermee zeg je dat je server zelf niets naar buiten mag sturen.
Het is opzich een goede regel maar dan moet je een hoop uitzonderingen eronder zetten (en die heb je niet), dus doe makkelijk en zet hem op accept.

[ Voor 208% gewijzigd door Seth4Chaos op 22-01-2010 11:39 ]

[ShaneV]

Seth4Chaos schreef op vrijdag 22 januari 2010 @ 11:31:
In je startpost zeg je dat eth0 je WAN is, in de config staat eth0 = 192.168.2.1. dan lijkt me eth0 LAN en eth1 WAN.

Juist, das een foutje die al aangepast was. Mijn excuses! Snel even men start post updaten

[Seth4Chaos]

ShaneV schreef op vrijdag 22 januari 2010 @ 11:38:
[...]


Juist, das een foutje die al aangepast was. Mijn excuses! Snel even men start post updaten

Als je startpost goed was zit je probleem hier:

code:

    #verkeer naar buiten toe laten en nat aanzetten
        iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
        iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
        iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

dit heb je precies omgedraait.
Je staat alles van het WAN toe en van het LAN alleen wat established is.
Verder moet je masq. op je WAN poort doen.

Overigens als je wilt dat dit gaat werken:

code:

#toestaan SSH verkeer
        iptables -t nat -A PREROUTING -p tcp --dport 22 -i eth0 -j DNAT --to destination 192.168.2.1
        iptables -t nat -A PREROUTING -p udp --dport 22 -i eth0 -j DNAT --to destination 192.168.2.1

dan zal je hier ook een ACCEPT rule in je FORWARD table moeten opnemen.

[ Voor 20% gewijzigd door Seth4Chaos op 22-01-2010 11:42 ]

[ShaneV]

Seth4Chaos schreef op vrijdag 22 januari 2010 @ 11:40:
[...]

Als je startpost goed was zit je probleem hier:

code:

    #verkeer naar buiten toe laten en nat aanzetten
        iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
        iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
        iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

dit heb je precies omgedraait.
Je staat alles van het WAN toe en van het LAN alleen wat established is.
Verder moet je masq. op je WAN poort doen.

Overigens als je wilt dat dit gaat werken:

code:

#toestaan SSH verkeer
        iptables -t nat -A PREROUTING -p tcp --dport 22 -i eth0 -j DNAT --to destination 192.168.2.1
        iptables -t nat -A PREROUTING -p udp --dport 22 -i eth0 -j DNAT --to destination 192.168.2.1

dan zal je hier ook een ACCEPT rule in je FORWARD table moeten opnemen.

Ok, als ik je redenering volg heb ik dus nodig (en ook totaal logisch, niet normaal dat ik dat gemist kan hebben!) :

code:

iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Ik heb eveneens nog een regel aangepast en 1 toegevoegd:

code:

aangepast: iptables -A INPUT -i eth0 --match state --state RELATED,ESTABLISHED, -j ACCEPT
toegevoegd: iptables -A OUTPUT -o eth0 -j ACCEPT

Zonder die laatste output op eth0 ging het nog niet. Nu heb ik met succes internet verkeer Is er een reden waarom iptables klaagt bij men prerouting regels over --to destination? ik moet hem zo maken: --to 192.168.2.1, dus zonder die destination.

Wbt die forward regel voor ssh/rdp bedoel je dan: iptables -A FORWARD -p tcp --dport 22 -j ACCEPT?

Alvast bedankt!

[Seth4Chaos]

ShaneV schreef op vrijdag 22 januari 2010 @ 11:58:
[...]
Is er een reden waarom iptables klaagt bij men prerouting regels over --to destination? ik moet hem zo maken: --to 192.168.2.1, dus zonder die destination.

Mischien moet je even de exacte output posten, volgens de man-page van iptables is "--to-destination" valide.

Wbt die forward regel voor ssh/rdp bedoel je dan: iptables -A FORWARD -p tcp --dport 22 -j ACCEPT?

Yeps, anders wordt het pakketje wel herschreven in de prerouting maar niet doorgelaten in de forward.

[ShaneV]

Seth4Chaos schreef op vrijdag 22 januari 2010 @ 12:06:
[...]

Mischien moet je even de exacte output posten, volgens de man-page van iptables is "--to-destination" valide.

[...]

Yeps, anders wordt het pakketje wel herschreven in de prerouting maar niet doorgelaten in de forward.

Hij zegt met de regel: iptables -t nat -A PREROUTING -p tcp --dport 22 -i eth0 -j DNAT --to destination 192.168.2.1

iptables v1.4.2: Bad IP address "destination"

Try "iptables -h" blablalbal...

hah.... ik zie men probleem... staat geen - tussen to en destination....

[Orion84]

- Je kan ook --to gebruiken en dan gevolgd door IPADRES:PORT dan kan --dport weg
- Verder zou ik FORWARD gewoon de policy op ACCEPT zetten, er wordt vanwege NAT toch niks geforward anders dan wat er bij een NAT rule of bestaande verbinding hoort voor zover ik weet.
- Voor OUTPUT ook gewoon de policy op ACCEPT zetten, zodat je server over al z'n interfaces gewoon de mogelijkheid heeft om pakketjes uit te sturen. Nu heb je een policy op DROP en ga je per interface alsnog een complete ACCEPT invoegen, dat is vrij nutteloos

En geef nog even je hele script, want met die aanpassingen en toevoegingen wordt het een beetje onoverzichtelijk om te zien of het klopt

Zelf heb ik het (afgezien van een lijst portmappings en expliciete accepts op externe INPUT) als volgt opgezet (eveneens eth0 extern, eth1 intern):

code:

# flush all existing rules: start clean :)
iptables -F
iptables -F -t nat

# set the default policy
iptables -P OUTPUT  ACCEPT
iptables -P INPUT   DROP

# forwarding is beschermd door NAT, dus accept all zodat er niet per port-forward nog een accept regel nodig is
iptables -P FORWARD ACCEPT

# enable NAT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#echo 1 > /proc/sys/net/ipv4/ip_forward
#ip_forwarding is taken care of in /etc/sysctl.conf

# op het lokale netwerk staan we alles toe 
iptables -A INPUT   -i eth1 -j ACCEPT

# local host vertrouwen we ook
iptables -A INPUT -d 127.0.0.1 -j ACCEPT

# allow incoming ICMP ping pong stuff
iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT

# eth0 mag ook vanaf buiten beschikbaar zijn op een paar poorten
...

#port forwarders
...

# Accept 'established' traffic
iptables -A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT

[ Voor 3% gewijzigd door Orion84 op 22-01-2010 12:15 ]

[ShaneV]

Dit is tot nu toe wat ik heb, inclusief je aanpassingen

code:

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

        #Flush table's
        iptables -F INPUT
        iptables -F OUTPUT
        iptables -F FORWARD
        iptables -t nat -F

        #Drop traffic
        iptables -P FORWARD ACCEPT
        iptables -P OUTPUT ACCEPT
    iptables -P INPUT DROP

    #verkeer naar buiten toe laten en nat aanzetten
        #iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
        #iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
        iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

        #RDP forward voor windows servers
        iptables -t nat -A PREROUTING -p tcp -i eth0 -j DNAT --to 192.168.2.10:3389
        iptables -t nat -A PREROUTING -p tcp -i eth0 -j DNAT --to 192.168.2.12:3340

        #toestaan SSH verkeer
        iptables -t nat -A PREROUTING -p tcp -i eth0 -j DNAT --to 192.168.2.1:22
        iptables -t nat -A PREROUTING -p udp -i eth0 -j DNAT --to 192.168.2.1:22

    #toestaan verkeer loopback
    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT

    # allow incoming ICMP ping pong stuff
    iptables -A INPUT -p icmp -j ACCEPT
    iptables -A OUTPUT -p icmp -j ACCEPT

    #toestaan lokaal netwerk
    iptables -A INPUT -i eth1 -j ACCEPT
    iptables -A INPUT --match state --state RELATED,ESTABLISHED -j ACCEPT

ifconfig eth1 192.168.2.1/24
ifconfig eth0 XXXXX
ifconfig eth0 up
ifconfig eth1 up
route add default gw XXXXX

[Seth4Chaos]

#toestaan SSH verkeer
iptables -t nat -A PREROUTING -p tcp --dport 22 -i eth0 -j DNAT --to destination 192.168.2.1
iptables -t nat -A PREROUTING -p udp --dport 22 -i eth0 -j DNAT --to destination 192.168.2.1

#toestaan verkeer loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# allow incoming ICMP ping pong stuff
iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT

#toestaan lokaal netwerk
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT --match state --state RELATED,ESTABLISHED -j ACCEPT

---

vier aanpassingen:
1e: SSH werkt alleen op TCP.
De 2e en 3e zijn zinloos aangezien je bovenin de output al globaal op accept heb gezet.
De 4e is zinloos aangezien je dat al in de regel erboven gedaan hebt.

Mischien nog iets om aan het einde toe te voegen om te loggen wat/wie toegang tot je systeem probeert te krijgen:

code:

        # Log het einde van de EXT_IFACE
        ${IPTABLES} -A FORWARD -i ${EXT_IFACE} -j LOG --log-prefix="iptables: REST-FOR-inet! " 
        ${IPTABLES} -A INPUT -i ${EXT_IFACE} -j LOG --log-prefix="iptables: REST-IN-inet! "

[ Voor 17% gewijzigd door Seth4Chaos op 22-01-2010 12:32 . Reden: 4e moet wel, thx Orion ]

[Orion84]

Regels 16 en 17 kunnen natuurlijk weg, als je de FORWARD policy al op accept hebt staan

En regel 38 heeft niks met lokaal netwerk te maken. Dat heeft betrekking op pakketjes die binnenkomen op eth0 (eth1 is immers al ACCEPT). Die regel zorgt er voor dat als je vanaf de server (dus niet vanaf LAN) een verbinding opzet, dat de reacties van de gesprekspartner ook geaccepteerd worden. Die regel heb je dus wel nodig, maar hoort niet onder dat stukje commentaar

En de expliciete OUTPUT accepts kunnen idd ook nog weg ja

Seth4Chaos schreef op vrijdag 22 januari 2010 @ 12:28:
vier aanpassingen:
1e: SSH werkt alleen op TCP.
De 2e en 3e zijn zinloos aangezien je bovenin de output al globaal op accept heb gezet.
De 4e is zinloos aangezien je dat al in de regel erboven gedaan hebt.

Helemaal mee eens, behalve dat laatste, je hebt die regel nodig voor eth0, anders kan de firewall machine zelf geen verbindingen naar het Internet opzetten (respons wordt gedropt) en dat lijkt me niet handig

[ Voor 39% gewijzigd door Orion84 op 22-01-2010 12:31 ]

[ShaneV]

Alrighty, dit zou het dan moeten zijn Ik bedank jullie dan ook beiden om me wat bij te scholen wbt connecties en iptables

code:

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/tcp_syncookies


        #Flush table's
        iptables -F INPUT
        iptables -F OUTPUT
        iptables -F FORWARD
        iptables -t nat -F

        #Drop traffic & Accept traffic
    iptables -P INPUT DROP
        iptables -P FORWARD ACCEPT
        iptables -P OUTPUT ACCEPT

    #Nat aanzetten
        #iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
        #iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
        iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

        #RDP forward voor windows servers
        iptables -t nat -A PREROUTING -p tcp -i eth0 -j DNAT --to 192.168.2.10:3389
        iptables -t nat -A PREROUTING -p tcp -i eth0 -j DNAT --to 192.168.2.12:3340

        #toestaan SSH verkeer
        iptables -t nat -A PREROUTING -p tcp -i eth0 -j DNAT --to 192.168.2.1:22

    #toestaan verkeer loopback
    iptables -A INPUT -i lo -j ACCEPT

    # allow incoming ICMP ping pong stuff
    iptables -A INPUT -p icmp -j ACCEPT

    #toestaan lokaal netwerk
    iptables -A INPUT -i eth1 -j ACCEPT
    
    #Firewall traffic toestaan
    iptables -A INPUT --match state --state RELATED,ESTABLISHED -j ACCEPT

    #logging
    iptables -A FORWARD -i eth0 -j LOG --log-prefix="iptables: REST-FORWARD-inet! "
    iptables -A INPUT -i eth0 -j LOG --log-prefix="iptables: REST-INPUT-inet! "
    

ifconfig eth1 192.168.2.1/24
ifconfig eth0 XXXXXX
ifconfig eth0 up
ifconfig eth1 up
route add default gw XXXX

[ Voor 5% gewijzigd door ShaneV op 22-01-2010 12:49 ]

[swbr]

ShaneV schreef op vrijdag 22 januari 2010 @ 12:46:

code:

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Even een kleine zijsprong, maar door de volgende regels in /etc/sysctl.conf toe te voegen (of te uncommenten) worden die parameters gezet tijdens het booten.

code:

net.ipv4.ip_forward=1
net.ipv4.tcp_syncookies=1

[ShaneV]

Antaresje schreef op vrijdag 22 januari 2010 @ 12:56:
[...]


Even een kleine zijsprong, maar door de volgende regels in /etc/sysctl.conf toe te voegen (of te uncommenten) worden die parameters gezet tijdens het booten.

code:

net.ipv4.ip_forward=1
net.ipv4.tcp_syncookies=1

Dat weet ik maar, ik wou een script hebben die ingeval van crash, snel op een andere machine opgezet kan worden en met dat het dan snel moet gaan, zou ik wel eens die sysctl.conf kunnen vergeten aan te passen

[Orion84]

Dat is opzich nog wel een interessant punt.

Als je het in het firewall script zet, wordt het ongeveer tegelijk actief met de firewall regels, als het in sysctl staat, kan er een gat zitten tussen forwarding actief en firewall actief.

Op zich voor een IPV4/NAT oplossing nog niet zo heel spannend, maar met IPV6 waar de LAN hosts zonder portforwards te bereiken zijn wel. Al valt natuurlijk te betwisten in hoeverre dit in de praktijk echt uitmaakt. Net als het pas up brengen van je interfaces in het firewall script, ipv. elders.

* Orion84 heeft het trouwens wel in sysctl staan, en ook het aanzwengelen van de interfaces gebeurt elders.

@ShaneV: Denk je er wel nog even aan dat als je vanaf extern bijvoorbeeld via SSH je firewall wilt kunnen beheren dat je daar ook nog even een INPUT ACCEPT rule voor moet bakken?

PS: Heb je zoveel last van (D)DOS aanvallen dat je die syncookies nodig hebt?

[ Voor 4% gewijzigd door Orion84 op 22-01-2010 13:18 ]

[ShaneV]

Orion84 schreef op vrijdag 22 januari 2010 @ 13:12:
Dat is opzich nog wel een interessant punt.

Als je het in het firewall script zet, wordt het ongeveer tegelijk actief met de firewall regels, als het in sysctl staat, kan er een gat zitten tussen forwarding actief en firewall actief.

Op zich voor een IPV4/NAT oplossing nog niet zo heel spannend, maar met IPV6 waar de LAN hosts zonder portforwards te bereiken zijn wel. Al valt natuurlijk te betwisten in hoeverre dit in de praktijk echt uitmaakt. Net als het pas up brengen van je interfaces in het firewall script, ipv. elders.

* Orion84 heeft het trouwens wel in sysctl staan, en ook het aanzwengelen van de interfaces gebeurt elders.

@ShaneV: Denk je er wel nog even aan dat als je vanaf extern bijvoorbeeld via SSH je firewall wilt kunnen beheren dat je daar ook nog even een INPUT ACCEPT rule voor moet bakken?

PS: Heb je zoveel last van (D)DOS aanvallen dat je die syncookies nodig hebt?

Nee hoor, maar het zit erin, kan nooit kwaad om het preventief aan te zetten

Met die forward accept staan blijkbaar al men poorten open naar het internet toe. Wanneer ik terug val op men oude manier, zijn ze allemaal gesloten. Oude manier:

#iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
#iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

Vanaf ik dan iptables -A FORWARD -p tcp --dport 3389 -j ACCEPT doe, staat weer alles open. Iemand enige idee waarom?

[ Voor 5% gewijzigd door ShaneV op 22-01-2010 15:04 ]

[Orion84]

Wat bedoel je met "al men poorten open naar het internet toe"? Althans, hoe test je dat?

Voor zover ik kan zien is je constructie nagenoeg gelijk aan de mijne en als ik bijvoorbeeld op grc.com een test run dan zie ik alleen die poorten als open staan die ik expliciet open heb gezet, de rest wordt aangemerkt als stealth.

[ Voor 57% gewijzigd door Orion84 op 22-01-2010 15:10 ]

[ShaneV]

Orion84 schreef op vrijdag 22 januari 2010 @ 15:08:
Wat bedoel je met "al men poorten open naar het internet toe"? Althans, hoe test je dat?

Voor zover ik kan zien is je constructie nagenoeg gelijk aan de mijne en als ik bijvoorbeeld op grc.com een test run dan zie ik alleen die poorten als open staan die ik expliciet open heb gezet, de rest wordt aangemerkt als stealth.

Ok, het is bovengekomen. Omdat ik zei: "iptables -t nat -A PREROUTING -p tcp -i eth0 -j DNAT --to 192.168.2.10:3389"

Stuurde hij alle data gewoon naar daar door..... mits ik mis --dport 3389! DOH!! DOH DOH DOH DOH!

Nvm foutje van mijn kant

[Orion84]

uhh, ja, sorry dat was dus mijn fout, omdat ik had gezegd dat als je --to HOST:PORT gebruikte dat --dport dan weg kon, wat inderdaad niet waar is. De --dport is de destination van het oorspronkelijke pakketje, de --to is het doel na portmapping

[H!GHGuY]

Het kan dan arrogant overkomen, maar RTFM hier:
http://www.frozentux.net/...al/iptables-tutorial.html

Deze legt haarfijn uit hoe iptables werkt, zie ook volgend diagram:


Als je deze tutorial volgt, kom je ongetwijfeld op je fouten uit.

[Verwijderd]

Als je default policy voor Forward accept is,

code:

iptables -P FORWARD ACCEPT

dan is de volgende regel voor logging toch overbodig?

code:

iptables -A FORWARD -i eth0 -j LOG --log-prefix="iptables: REST-FORWARD-inet! "

Hij komt hier toch nooit meer?

[ShaneV]

Orion84 schreef op vrijdag 22 januari 2010 @ 15:18:
uhh, ja, sorry dat was dus mijn fout, omdat ik had gezegd dat als je --to HOST:PORT gebruikte dat --dport dan weg kon, wat inderdaad niet waar is. De --dport is de destination van het oorspronkelijke pakketje, de --to is het doel na portmapping

Fouten maken we allemaal had er ook glans overgelezen. Nu stuurde ik gewoon alle TCP data door naar die server Lek is gedicht en alleen de 3 poortjes die ik open wil, staan open

In tussen tijd ook een pak bijgeleerd over iptables

@H!GHGuY: dat ding heb ik al doorgelezen, helaas staat daar teveel informatie in voor mij. Ik leer een product door ermee te werken en domme dingen zoals zonet tegen te komen. Persoonlijk vindt ik dat nog steeds de beste methode

[ Voor 14% gewijzigd door ShaneV op 22-01-2010 15:26 ]

[Seth4Chaos]

Verwijderd schreef op vrijdag 22 januari 2010 @ 15:22:
Als je default policy voor Forward accept is,

code:

iptables -P FORWARD ACCEPT

dan is de volgende regel voor logging toch overbodig?

code:

iptables -A FORWARD -i eth0 -j LOG --log-prefix="iptables: REST-FORWARD-inet! "

Hij komt hier toch nooit meer?

klopt, was een standard copy uit mijn firewall (die niet op accept staat).

[Ultraman]

Ik draai ook al tijden op een Linux router met een eigen gemaakte iptables set.
Ook ooit met wat documentatie en wat kleine simpele guides een scriptje gemaakt.

Later heb ik een leuk artikel gevonden, link staat in script, wat ik heb gekopieërt en aangepast voor eigen gebruik. Ik dacht ik plaats het even
Misschien heb jij er wat aan en mogelijk ontdekken we ook nog wel fouten die ik over het hoofd heb gezien.
Het draait hier al sinds 12 juli 2009 op de stable box (sol).
Wat persoonsgegevens er uit gewipt

code:

#!/bin/sh
# ---
# Firewall Config Script v0.3
# for lymos (testing) & sol (stable)
# -
# Courtesy of : http://www.bit-tech.net/bits/2008/06/27/build-your-own-router/
# Edited for personal use by Stefan "Ultraman" *** <***@***.***>
# Last update: 12 Jul 2009
# ---


# Determine interfaces

EXTIF="eth1"
INTIF="eth0"


# Loop device/localhost

LPDIF="lo"
LPDIP="127.0.0.1"
LPDMSK="255.0.0.0"
LPDNET="$LPDIP/$LPDMSK"


# Text tools paths

IFC="/sbin/ifconfig"
G="/bin/grep"
SED="/bin/sed"
AWK="/bin/awk"
ECHO="/bin/echo"
export LC_ALL="en"


# Setting up external interface environment variables

EXTIP="`$IFC $EXTIF|$AWK /$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`"
EXTBC="`$IFC $EXTIF|$AWK /$EXTIF/'{next}//{split($0,a,":");split(a[3],a," ");print a[1];exit}'`"
EXTMSK="`$IFC $EXTIF|$AWK /$EXTIF/'{next}//{split($0,a,":");split(a[4],a," ");print a[1];exit}'`"
EXTNET="$EXTIP/$EXTMSK"


# Setting up internal interface environment variables

INTIP="`$IFC $INTIF|$AWK /$INTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`"
INTBC="`$IFC $INTIF|$AWK /$INTIF/'{next}//{split($0,a,":");split(a[3],a," ");print a[1];exit}'`"
INTMSK="`$IFC $INTIF|$AWK /$INTIF/'{next}//{split($0,a,":");split(a[4],a," ");print a[1];exit}'`"
INTNET="$INTIP/$INTMSK"


#-----------------------------------------------------------------
# Initialisation of iptables
#-----------------------------------------------------------------

# Load Kernel modules

modprobe nf_conntrack
modprobe nf_nat
modprobe nf_conntrack_ftp
modprobe nf_nat_ftp
modprobe nf_conntrack_irc
modprobe nf_nat_irc


# Enable forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward


# Tighten timeouts etc

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

#echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_intvl


# Flush all existing chains

CHAINS=`cat /proc/net/ip_tables_names 2>/dev/null`

for i in $CHAINS
do
    iptables -t $i -F
    iptables -t $i -Z
    iptables -t $i -X
done


# set default policy

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP


# Enable Anti DDOS & Block NEW without SYN

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

iptables -A INPUT -i $EXTIF -p tcp ! --syn -m state --state NEW -j DROP


#-----------------------------------------------------------------
# Filling the chains with rules
#-----------------------------------------------------------------

#--------------------------------------------------------------
# rules for table filter chain PREROUTING
#--------------------------------------------------------------

# For accessing SSH over the internet on port 2222
iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport 2222 -j REDIRECT --to-ports 22
# And marking those trying to access SSH port 22 from the WAN for later DROPping
iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport 22 -j MARK --set-mark 0x10

# Port-forward for (Hamachi) traffic to Korlash (DISABLED)
#iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport 51000 -m state --state NEW,ESTABLISHED,RELATED -j DNAT --to-destination 192.168.0.3
#iptables -t nat -A PREROUTING -i $EXTIF -p udp --dport 51000 -m state --state NEW,ESTABLISHED,RELATED -j DNAT --to-destination 192.168.0.3

#--------------------------------------------------------------
# rules for table filter chain FORWARD (DROP)
#--------------------------------------------------------------

# User initiated and related traffic
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# Internet access from subnets
iptables -A FORWARD -i $INTIF -s $INTNET -m state --state NEW -j ACCEPT


# Port-forward for (Hamachi) traffic to Korlash (DISABLED)
#iptables -A FORWARD -i $EXTIF -o $INTIF -d 192.168.0.3 -p tcp --dport 51000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
#iptables -A FORWARD -i $EXTIF -o $INTIF -d 192.168.0.3 -p udp --dport 51000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT


#--------------------------------------------------------------
# rules for table filter chain INPUT (DROP)
#--------------------------------------------------------------

# allow known connections

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


# Deny SSH Access from WAN port 22 MARKed by PREROUTING table
iptables -A INPUT -m mark --mark 0x10 -j DROP


# Anti-spoofing rules

iptables -A INPUT -i $EXTIF -s $EXTIP -j DROP
iptables -A INPUT -i $EXTIF -s 127.0.0.0/8 -j DROP
iptables -A INPUT -i $EXTIF -s $INTNET -j DROP


# Block fragments and Xmas tree as well as SYN,FIN and SYN,RST

iptables -A INPUT -i $EXTIF -p ip -f -j DROP
iptables -A INPUT -i $EXTIF -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
iptables -A INPUT -i $EXTIF -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -i $EXTIF -p tcp --tcp-flags SYN,RST SYN,RST -j DROP


# Allow traffic from the LAN
iptables -A INPUT -i $INTIF -j ACCEPT

# Fix loopback settings

iptables -A INPUT -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT


# TCP ---------------------------------------------------------

# SSH Access
# Creates SSH_CHECK chain
# Condition := No more than 3 SSH connection attempts within a 60 sec window
# When condition is met: Drop all packets from the source
# After 60 seconds of quiet time, source IP is allowed to try again
iptables -N SSH_CHECK
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHECK
iptables -A SSH_CHECK -m recent --set --name SSH
iptables -A SSH_CHECK -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP

# Allow access to SSH on port 22, while WAN which gets redirected here from external port 2222)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Drop other traffic on priveliged ports
iptables -A INPUT -p TCP ! -i $INTIF -d 0/0 --dport 0:1023 -j DROP

# Allow BitTorrent traffic on 58881-58889 TCP ports
iptables -A INPUT -p TCP -i $EXTIF --dport 58881:58889 -j ACCEPT

# UDP ---------------------------------------------------------

# Reject service-requests from outside
iptables -A INPUT -p UDP --dport bootps ! -i $INTIF -j REJECT
iptables -A INPUT -p UDP --dport domain ! -i $INTIF -j REJECT

# Drop traffic on priviliged ports
iptables -A INPUT -p UDP ! -i $INTIF -d 0/0 --dport 0:1023 -j DROP

# Allow BitTorrent DHT traffic on 58889 UDP port
iptables -A INPUT -p UDP -i $EXTIF --dport 58889 -j ACCEPT


# ICMP --------------------------------------------------------

# Allow all ICMP Traffic IN
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT


#--------------------------------------------------------------
# rules for table filter chain OUTPUT (DROP)
#--------------------------------------------------------------

# Allow known connections

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


# Allow outgoing traffic from the firewall

iptables -A OUTPUT -m state --state NEW -j ACCEPT



#--------------------------------------------------------------
# rules for table nat chain POSTROUTING
#--------------------------------------------------------------

# Enable NAT translation (MASQUERADE)

iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

Dus met wat zaakjes aangepast her en der.
Zitten ook wat grapjes in voor een andere externe SSH poort, maar toch intern wel 22 gebruiken. Externe oproepen die toch op 22 komen worden geMARKed en dan gedropped. Nooit eigenlijk goed kunnen testen alleen...

Ik ga over naar een nieuwe verbinding en een nieuw Linux router boxje, maar ik zat te denken om het script mee te nemen aangezien het zijn werk goed doet (of dat lijkt te doen). Mocht iemand hier dus leuke gaten in vinden, laat maar horen. En als je kunt verbeteren, voel je vrij

[Orion84]

Uiteindelijk redelijk vergelijkbaar met de setup van TS en van mijzelf zo te zien. Wat extra shizzle tegen een aantal aanvallen, wat me voor thuisgebruik een tikkeltje overbodig lijkt, maar als je er geen performance verslechtering door ervaart kan het geen kwaad natuurlijk.

SSH heb ik zelf dichtgetimmerd met behulp van fail2ban, die na te veel foutieve logins een firewall regel toevoegd voor een uur waarmee de afzender geblokkeerd wordt.

Verder zie ik dat bij jou OUTPUT op DROP staat, maar je vervolgens zowel established, related, als new traffic toelaat. Ik ben niet op de hoogte van de details, maar kan je dan niet net zo goed OUTPUT gewoon op ACCEPT zetten?

Een naam aan die interfaces en zo hangen is op zich wel netjes, mocht je daar dan ooit wat aan wijzigen, dan kan je dat makkelijk op een plek fixen. Maar goed, ook dat is voor thuisgebruik lichtelijk overkill. Met die paar regels aan firewall die je effectief hebt zie je niet heel snel dingen over het hoofd. Ik heb ook wel eens firewall scripts gezien in meer bedrijfsmatige omgeving en dan komen dergelijke constructies wel heel erg van pas. Bijvoorbeeld om sets van hosts te definiëren die dan in verschillende regels terugkomen etc.

Al met al ziet het er op zich wel netjes uit en wat mij betreft leuk dat je het even post, altijd leerzaam om te zien hoe anderen het hebben opgezet. Je kan het ook wel zelf allemaal tot in de puntjes gaan uitzoeken, maar zeker voor thuisgebruik heb ik al snel zoiets van goed is goed en dan ga je je er verder niet al te veel in verdiepen. Zo'n kijkje in andermans keuken is dan een mooie manier om ook je eigen aanpak weer even tegen het licht te houden

[ Voor 13% gewijzigd door Orion84 op 22-01-2010 23:09 ]

[Ultraman]

Orion84 schreef op vrijdag 22 januari 2010 @ 23:07:
Uiteindelijk redelijk vergelijkbaar met de setup van TS en van mijzelf zo te zien. Wat extra shizzle tegen een aantal aanvallen, wat me voor thuisgebruik een tikkeltje overbodig lijkt, maar als je er geen performance verslechtering door ervaart kan het geen kwaad natuurlijk.

Het is inderdaad vrij vergelijkbaar. Het is immers opgezet voor hetzelfde doel, het routeren van verkeer tussen internet en netwerk.

SSH heb ik zelf dichtgetimmerd met behulp van fail2ban, die na te veel foutieve logins een firewall regel toevoegd voor een uur waarmee de afzender geblokkeerd wordt.

Dat is ook een goede oplossing. Ik heb dat een tijd lang op een lijstje gehad om mee te gaan spelen, maar nooit aan toe gekomen. Nu ik met een nieuwe box bezig ben zet ik het gelijk weer even er op.

Verder zie ik dat bij jou OUTPUT op DROP staat, maar je vervolgens zowel established, related, als new traffic toelaat. Ik ben niet op de hoogte van de details, maar kan je dan niet net zo goed OUTPUT gewoon op ACCEPT zetten?

OUTPUT op ACCEPT zetten kan idd best. Het is echter niet equivalent met mijn opstelling. Er is ook nog een state INVALID, en die loopt nu tegen de DROP aan.
Het nut daarvan kun je meer op de stapel "probably the right thing to do" gooien. Noodzakelijk is het zeker niet.

Een naam aan die interfaces en zo hangen is op zich wel netjes, mocht je daar dan ooit wat aan wijzigen, dan kan je dat makkelijk op een plek fixen. Maar goed, ook dat is voor thuisgebruik lichtelijk overkill. Met die paar regels aan firewall die je effectief hebt zie je niet heel snel dingen over het hoofd. Ik heb ook wel eens firewall scripts gezien in meer bedrijfsmatige omgeving en dan komen dergelijke constructies wel heel erg van pas. Bijvoorbeeld om sets van hosts te definiëren die dan in verschillende regels terugkomen etc.

Hij is zo lekker portable en ik hoef ook niet extra goed op te letten met de device namen op deze manier als ik een nieuwe regel toevoeg bijvoorbeeld.
Mijn oude script was eerst ook zo als de scripts die boven mijn vorige posts staan en die werken ook prima. Ik ben er alleen toen wel een keer voor gaan zitten om een "nettere" oplossing te maken en dat is toen dit geworden. Voornamelijk handigheidje vind ik het, tegenwoordig doe ik het met wel meer scripts om zaken makkelijk te kunnen aanpassen. En in dit geval komt het van pas omdat ik het script nu simpelweg over kan huizen naar de nieuwe box, waarbij ik alleen bovenin wat zaken aan hoef te passen.
Zit te denken om er nog wat bij te maken voor IPs en poorten trouwens.

Al met al ziet het er op zich wel netjes uit en wat mij betreft leuk dat je het even post, altijd leerzaam om te zien hoe anderen het hebben opgezet. Je kan het ook wel zelf allemaal tot in de puntjes gaan uitzoeken, maar zeker voor thuisgebruik heb ik al snel zoiets van goed is goed en dan ga je je er verder niet al te veel in verdiepen. Zo'n kijkje in andermans keuken is dan een mooie manier om ook je eigen aanpak weer even tegen het licht te houden

Daarom inderdaad gepost. Ik vind het ook interessant om te kijken wat anderen doen. En als ik in dit geval iemand kan helpen of op ideeën kan brengen met wat ik heb gedaan ben ik daar blij mee
En fijn om lezen dat je het script netjes vind.

[Ultraman]

<knip dubbel>

[ Voor 99% gewijzigd door Ultraman op 23-01-2010 00:06 ]

[Seth4Chaos]

Orion84 schreef op vrijdag 22 januari 2010 @ 23:07:
Een naam aan die interfaces en zo hangen is op zich wel netjes, mocht je daar dan ooit wat aan wijzigen, dan kan je dat makkelijk op een plek fixen. Maar goed, ook dat is voor thuisgebruik lichtelijk overkill. Met die paar regels aan firewall die je effectief hebt zie je niet heel snel dingen over het hoofd. Ik heb ook wel eens firewall scripts gezien in meer bedrijfsmatige omgeving en dan komen dergelijke constructies wel heel erg van pas. Bijvoorbeeld om sets van hosts te definiëren die dan in verschillende regels terugkomen etc.

Een naam aan de interface hangen is ook in thuis situaties erg handig. Als je de eerste paar posts leest zie je dat de TS zijn LAN en WAN interface door elkaar haalde. Had die het geschreven met LAN en WAN dan had die het zelf (mischien?) ook gezien dat het verkeerd om stond.