[Iptables] UDP wel zichtbaar, maar toch dicht?

[Erhnam]

Ik ben bezig om mijn server/router te beveiligen met een iptables firewallscript, omdat mijn provider binnenkort alle porten t/m 1023 opengooit (voorheen allemaal dicht) Maar iets is mij niet geheel duidelijk....

Omdat ik nu niet goed op mijn externe interface kan testen (alles staat nog dicht) moet ik dus maar doen met mijn interne interface en ik val mijn server dus intern aan om zo te testen wat er wel en niet doorkomt.

Na het dichtzetten van een zooi poorten:
iptables -A INPUT -p tcp --dport 111:1023 -i eth0 -j DROP
iptables -A INPUT -p udp --dport 111:1023 -i eth0 -j DROP


Kwam ik het volgende tot ontdekking:



Goed is te zien met het sript dat alle tcp porten dicht zijn. UDP heb ik op precies dezelfde manier gedaan, maar zoals in de bovenstaande screenshot is nog steeds geheel duidelijk te zien welke services er achter de bepaalde poorten zitten.

Nu vraag ik mij af: Zijn deze poorten daadwerkelijk gesloten, omdat ze toch gewoon zichtbaar zijn? Is beveiligen met tcp inkomend op mijn externe interface genoeg, of moet udp ook dicht, of zie ik nu totaal iets fout ?

Bedankt voor alle reacties!

[deadinspace]

Erhnam schreef op 28 november 2002 @ 19:35:
Goed is te zien met het sript dat alle tcp porten dicht zijn. UDP heb ik op precies dezelfde manier gedaan, maar zoals in de bovenstaande screenshot is nog steeds geheel duidelijk te zien welke services er achter de bepaalde poorten zitten.
Nu vraag ik mij af: Zijn deze poorten daadwerkelijk gesloten, omdat ze toch gewoon zichtbaar zijn?

TCP is een connection-based protocol: client vraagt aan server of hij mag connecten, en de server stuurt dan een TCP ACK, waarop de client moet zeggen "ok, dan hebben we een connectie", en dan pas kan er data gezonden worden.
UDP is connectionless, wat erop neerkomt dat je je packets maar naar een poort stuurt, en of het dan aankomt, er iets mee gedaan wordt of wat terugkrijgt boeit dan niet.

Omdat voor TCP de ontvangende host met ACK (of SYN) antwoordt als de poort open is, met RST antwoordt als de poort closed is en niet antwoordt als je het verkeer DROPped is voor TCP heel makkelijk te bepalen in welke staat een poort verkeert.

Voor UDP is dit veel lastiger, omdat UDP connectionless is. Een stukje uit de nmap manpage:

code:

       -sU    UDP scans: This method is used  to  determine  which  UDP  (User
              Datagram Protocol, RFC 768) ports are open on a host.  The tech-
              nique is to send 0 byte udp packets to each port on  the  target
              machine.   If  we receive an ICMP port unreachable message, then
              the port is closed.  Otherwise we assume it is open.

"Otherwise we assume it's open". Als dat prog van jou dezelfde methode gebruikt dan krijg je inderdaad te zien dat poorten open zijn als je ze DROPped.
Dat lijkt mij dus het geval, want ik vind het sowieso een grote waslijst UDP services die die scanner vindt, ik neem aan dat je dat niet allemaal draait.

Een doorgaans verstandigere aanpak mbt firewalling is btw om alleen datgene door te laten wat je door wilt hebben en de rest te blokkeren, dus bv iptables -A INPUT -i eth0 -p tcp --dport ssh -j ACCEPT; iptables -A INPUT -i eth0 -p tcp -j DROP laat ssh toe en blokkeert de rest.
Je zult dan alleen nog wat met stateful firewalling moeten doen, want anders worden antwoorden op requests die je zelf gestuurd hebt ook gedropt

Is beveiligen met tcp inkomend op mijn externe interface genoeg, of moet udp ook dicht, of zie ik nu totaal iets fout ?

Nee, UDP moet je zeker ook meenemen in je firewall (het is nogal eens een vergeten kindje, maar niet ongevaarlijk), want er zijn best services die op UDP luisteren (bind bijvoorbeeld).

[Erhnam]

Okee bedankt voor uitbundige reactie... Enige probleem is dat er veel spelletjes gespeeld worden op het interen netwerk..

Ik denk dat ik dan geproberen op jouw manier.. door eerst bv ssh etc open te zetten en daarna alles te droppen..

Verder klopt het inderdaad dat achter lang niet alles een service zit.. vreemd dat die daar mee toch op de proppen komt..

[ Voor 21% gewijzigd door Erhnam op 29-11-2002 13:49 ]

[ProZa|IA]

Dat is niet zo vreemd. Bij een service hoort een poort. bv. DNS en poort 53. Ziet dat progje nu poort 53 open dan zal hij om het jou wat makkelijker te maken vertellen dat daar een dns server achter zit. Hij hoeft dat dus helemaal niet echt te zien.
IMHO is de enige goede manier om een firewall te bouwen dat wat "deadinspace" al zei namelijk alles dicht en dan pas open gaan zetten wat je open wilt hebben. Vergeet udp en icmp niet !
Als je je blocks laat loggen kan je precies zien wat waarvandaan geblockt wordt en kan je de rules zo aanpassen dat dat verkeer wel doorgelaten wordt.
Het is veel werk en veel logs doorbladeren maar het wordt imho wel een betere firewall.

[Verwijderd]

Erhnam schreef op 28 November 2002 @ 19:35:
Na het dichtzetten van een zooi poorten:
iptables -A INPUT -p tcp --dport 111:1023 -i eth0 -j DROP
iptables -A INPUT -p udp --dport 111:1023 -i eth0 -j DROP

Op je plaatje zag ik dat je 192.168.0.1 scande.... is dat dan ook je eth0 ?

[Erhnam]

mja 192.168.0.1 op eth0 is mijn ip lokaal.. had ik dat er boven ook al niet verteld...

[deadinspace]

Erhnam schreef op 29 november 2002 @ 13:48:
Okee bedankt voor uitbundige reactie... Enige probleem is dat er veel spelletjes gespeeld worden op het interen netwerk..

Mja, lees een iptables HOWTO (bv Rusty Russels HOWTO, die vind ik wel aardig) en lees dan vooral de stukjes over state matching.

Verder klopt het inderdaad dat achter lang niet alles een service zit.. vreemd dat die daar mee toch op de proppen komt..

Mja, zie het stukje over UDP poort detectie dat ik quootte... Als de scanner geen RST terugkrijgt neemt hij aan dat de poort open is (maar als je DROP doet stuurt het OS ook niks terug dus denken scanners die die techniek gebruiken onterecht dat de poort open is).

[Erhnam]

Nu heb ik nog een vraagje.. Met de volgende regels wil ik mijn externe interface geveiligen, maar nadat ik dat heb gedaan werken sommige diensten niet meer (irc, browsen etc bv) weet iemand wat je hier tegen moet doen ? ident dns staan nl gewoon open.

code:

# ssh, ftp, http, ident, pop dns voor de buitenwereld open.

iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp --dport 110 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp --dport 113 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p udp --dport 113 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp --dport 1030 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp --dport 3456 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p udp --dport 53 -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp -j DROP
iptables -A INPUT -i $EXTERNAL_INTERFACE -p udp -j DROP

[ Voor 45% gewijzigd door Erhnam op 30-11-2002 22:31 ]

[terrapin]

Je denied alle packets van buiten, behalve diegene die naar een van de services gaan die jij hebt toegestaan. Dus alleen packages op de porten die je boven hebt vermeld mogen naar binnen.
Probleem echter is, dat bij bijvoorbeeld het browsen vanaf je pc, je browser een andere port gebruikt, bijvoorbeeld 32345. De replies van een andere webser, die op die port binnenkomen, worden echter door jouw regels gedropt.
Netfilter bevat echter, gelukkig, een speciaal systeem genaamd connection tracking om die packets wel te accepteren. Het beste kan je de howto's en andere documentatie op http://www.netfilter.org eens goed doorlezen..

[Verwijderd]

Netfilter (iptables) maakt onderscheid tussen verkeer wat door je computer heen gaat (als wanneer je computer als gateway voor je lan dient) en verkeer wat hij zelf genereerd. De INPUT en OUTPUT chains zijn van zichzelf de FORWARD chain gaat over het verkeer wat 'door' je machine heen gaat. Als je dus:

iptables -A INPUT -p tcp --dport 80 -j REJECT

zou doen, dan zou het interne netwerk nog steeds gewoon op internet kunnen (je moet dan wel een vorm van nat toepassen (MASQUERADE / SNAT).

Een simpele vorm van een firewalling script zou zijn:

iptables -P INPUT REJECT
iptables -P OUTPUT REJECT
iptables -P FORWARD REJECT

Hier maak je de 'default policy' REJECT. Alle pakketjes die binnen komen, naar buiten gaan of de machine doorkruizen word afgewezen. (een pakketje met RST flag bij TCP en een ICMP destination port unreachable bij UDP).


function addopenport {
iptables -A INPUT -i $3 -p $1 --dport $2 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $3 -p $1 --sport $2 -m state --state RELATED,ESTABLISHED -j ACCEPT
}


Met behulp van deze functie:


addopenport <protocol> <port> <interface>


Sta je verkeer van en/naar een bepaalde port toe (dit geld niet voor doorkruisend verkeer). de 'NEW' state komt alleen voor bij inkomend verkeer omdat er geen verkeer geiniteerd word vanuit poorten < 1024 (in het algemeen).


iptables -t nat -A POSTROUTING -o <internet interface> -j MASQUERADE


zorgt er voor dat al het verkeer wat door je routes <internet interface> uit word gestuurt geMASQUERADE word. Dit wil zeggen dat hij de connecties vanuit je interne netwerk "proxy'ed" (in tegenstelling tot SNAT, wat alleen het source address veranderd).

op http://www.linuxguruz.org/ staan veel voorbeelden, kijk daar eens.

Groeten, joep

p.s. vergeet niet udp/53 toe te staan vanuit binnenuit (om www.mooievrouwen.nl te kunnen resolven naar een ip)

iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT

(Het aangeven van een state heeft geen zin omdat UDP een connectie loos protocol is)

[ Voor 3% gewijzigd door Verwijderd op 01-12-2002 23:21 ]

[Verwijderd]

Verwijderd schreef op 01 december 2002 @ 23:20:
(Het aangeven van een state heeft geen zin omdat UDP een connectie loos protocol is)

Het klopt dat UDP in principe stateless is, maar het is niet gelijk nutteloos om state matching bij UDP te gebruiken. Lees deze link maar: http://www.sns.ias.edu/~j...s/iptables_conntrack.html Dan zul je zien dat iptables UDP connecties wel degelijk in zijn state tabel kan opnemen en onder hoge load zelfs verschillend kan reageren op UDP streams of UNREPLIED UDP pakketten.

[ Voor 7% gewijzigd door Verwijderd op 02-12-2002 00:06 ]

[Verwijderd]

Interressant, dank :)!

[Erhnam]

Bedankt voor de info allemaal.. Ben goed aan de slag gegaan.
Vooral deze site: http://www.nedlinux.nl/~bart/?page=9 is echt een aanrader.. Veel uitleg en voorbeelden, zeer duidelijk en dta zelfs in het NL.. waar kom je dat nog tegen.. Verder stond er onderaan een zeer goed voorbeeld script!