Iptables block/allow

[Dacuuu]

Ik heb hier een DNS servertje, die ik beschikbaar wil maken via WAN.
Dnsmasq op de server stuurt alles door naar 8.8.8.8
Nu kan iedereen met kennis van het ip adres mijn server gebruiken als DNS server en dat wil ik niet.

De logische manier is om al het verkeer op poort 53 te blocken, en alleen de IP adressen whitelisten die ik specifiek instel. Het droppen werkt wel, maar het accepteren van de ingestelde IP adressen werkt gewoon niet. Ik heb de volgende 2 varianten geprobeerd. Waar gaat het mis?

code:

sudo iptables -A INPUT -p udp --dport 53 -j DROP
sudo iptables -A INPUT -p udp --dport 53 -s [interneipvadresvanpc] -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -s [mijnexterneipadres] -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -s 8.8.8.8 -j ACCEPT

code:

sudo iptables -A INPUT -p udp --dport 53 -j DROP
sudo iptables -A INPUT -p udp -s [interneipvadresvanpc] --dport 53 -j ACCEPT
sudo iptables -A INPUT -p udp -s [mijnexterneipadres] --dport 53 -j ACCEPT
sudo iptables -A INPUT -p udp -s 8.8.8.8 --dport 53 -j ACCEPT

[Sendy]

De eerste regel die matcht wordt gevolgd. Dus alles wordt gedropt.

[GlowMouse]

Sendy schreef op dinsdag 29 oktober 2013 @ 12:05:
De eerste regel die matcht wordt gevolgd. Dus alles wordt gedropt.

Wat hij zegt. Dit had je ook zo gezien via iptables -L -nvx.

[Dacuuu]

ik heb de drop regel ook als laatst gebruikt. Dus eerst 3 x accept regel en dan de drop regel. Maar zonder succes.

[Hero of Time]

Houd je ook rekening mee met het type van je data? Dus dat NEW, RELATED en ESTABLISHED accept worden? Als je alleen NEW accepteert, wordt de rest alsnog weggegooid.

Enne, zit je DNS server achter een NAT? Want dan ziet-ie mogelijk alle inkomende data van je router komen, ipv de werkelijke externe IP die verbinding maakt.

[Osiris]

Hero of Time schreef op dinsdag 29 oktober 2013 @ 12:38:
Enne, zit je DNS server achter een NAT? Want dan ziet-ie mogelijk alle inkomende data van je router komen, ipv de werkelijke externe IP die verbinding maakt.

Wat voor achterlijke NAT-box heb je dán? Naar mijn weten gebeurt dat nevernooitniet vanaf buitenaf hoor.. Hooguit bij NAT loopback van binnenuit.

[ Voor 6% gewijzigd door Osiris op 29-10-2013 12:40 ]

[Dacuuu]

Eigen fout.

had alles een beetje door elkaar gehaald.
Had gelezen op het grote boze internet dat ik eerst moest droppen, en dan moest whitelisten.
Maar waarschijnlijk had ik niet eerst alle rules verwijderd om vervolgens opnieuw te proberen.

Het volgende werkt tot nu toe

code:

sudo iptables -A INPUT -p udp --dport 53 -s [interneipvanpc] -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -s [serverip] -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -j DROP

[Osiris]

Je kunt ook wel éérst droppen qua invoer op je command line interface.. Maar dan moet je niet `-A` gebruiken, maar `-I <rulenumber>` (hoofdletter -i). Op die manier kun je de plek waar de regel komt beïnvloeden. Hij moet namelijk wel altijd ónder je ACCEPT-rules idd..

Uiteraard ook RELATED en ESTABLISHED accepten (zoals eerder gezegd) en ook natuurlijk altijd kijken of je `iptables -L INPUT -n --line-numbers` er goed uitziet.

[ Voor 22% gewijzigd door Osiris op 29-10-2013 12:49 ]

[Dacuuu]

Osiris schreef op dinsdag 29 oktober 2013 @ 12:48:
Je kunt ook wel éérst droppen qua invoer op je command line interface.. Maar dan moet je niet `-A` gebruiken, maar `-I <rulenumber>` (hoofdletter -i). Op die manier kun je de plek waar de regel komt beïnvloeden. Hij moet namelijk wel altijd ónder je ACCEPT-rules idd..

Uiteraard ook RELATED en ESTABLISHED accepten (zoals eerder gezegd) en ook natuurlijk altijd kijken of je `iptables -L INPUT -n --line-numbers` er goed uitziet.

Bedankt, met sudo iptables -h kreeg ik al meer info.met het -F commando alles clearen en overnieuw beginnen was voor mij het beste

[CyBeR]

Hero of Time schreef op dinsdag 29 oktober 2013 @ 12:38:
Houd je ook rekening mee met het type van je data? Dus dat NEW, RELATED en ESTABLISHED accept worden? Als je alleen NEW accepteert, wordt de rest alsnog weggegooid.

Aangezien 'ie geen -m state gebruikt is dat niet van toepassing.

[Wolfboy]

Hero of Time schreef op dinsdag 29 oktober 2013 @ 12:38:
Houd je ook rekening mee met het type van je data? Dus dat NEW, RELATED en ESTABLISHED accept worden? Als je alleen NEW accepteert, wordt de rest alsnog weggegooid.

UDP is stateless, dus dat is sowieso irrelevant
Blijkbaar houd iptables zelf nog de state bij voor related verbindingen, ook bij udp... nevermind

TS: weet je zeker dat je geen andere regels hebt staan?

Probeer dit eens (zorg er wel voor dat je alle regels eerst backupt, als er andere regels zijn)

sudo iptables -F INPUT
sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -s [interneipvadresvanpc] -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -s [mijnexterneipadres] -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -s 8.8.8.8 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -j LOG
sudo iptables -A INPUT -p udp --dport 53 -j DROP

Dan zie je direct in je syslog wat er nog mist kwa regels

[ Voor 55% gewijzigd door Wolfboy op 29-10-2013 13:44 ]

[Osiris]

CyBeR schreef op dinsdag 29 oktober 2013 @ 13:13:
[...]


Aangezien 'ie geen -m state gebruikt is dat niet van toepassing.

Jawel toch?

Aangezien een return-packet als SOURCE-port 53 heeft en als DESTINATION-IP het lokale IP, zeg maar, alles wat nu omgedraaid staat.

Kortom, dan stuurt iemand een UDP-pakketje naar dnsmasq, maar vervolgens weigert de server zichzelf om een pakketje terug te sturen.

Gevoelsmatig, heb bovenstaande niet getest

[ Voor 4% gewijzigd door Osiris op 29-10-2013 13:41 ]

[Wolfboy]

Osiris: yes... volgens mij heb je gelijk, iptables houd zelf de state bij. Established is niet van toepassing bij UDP maar related nog steeds wel om de terugverbinding te accepteren.

[CyBeR]

Osiris schreef op dinsdag 29 oktober 2013 @ 13:39:
[...]

Jawel toch?

Aangezien een return-packet als SOURCE-port 53 heeft en als DESTINATION-IP het lokale IP, zeg maar, alles wat nu omgedraaid staat.

Kortom, dan stuurt iemand een UDP-pakketje naar dnsmasq, maar vervolgens weigert de server zichzelf om een pakketje terug te sturen.

Gevoelsmatig, heb bovenstaande niet getest

Dat klopt allemaal (voor een dns server overigens, niet voor een client die packets stuurt) maar heeft niks te maken met state TS selecteert gewoon op basiseigenschappen zonder state mee te tellen.

[Osiris]

CyBeR schreef op dinsdag 29 oktober 2013 @ 13:46:
[...]


Dat klopt allemaal (voor een dns server overigens, niet voor een client die packets stuurt) maar heeft niks te maken met state TS selecteert gewoon op basiseigenschappen zonder state mee te tellen.

Dan zou 'ie ook --sport moeten gebruiken i.p.v. --dport, right?

[CyBeR]

Osiris schreef op dinsdag 29 oktober 2013 @ 13:50:
[...]

Dan zou 'ie ook --sport moeten gebruiken i.p.v. --dport, right?

Nee want hij wil zorgen dat zijn DNS server, welke op poort 53 draait, niet gebruikt kan worden door onbekenden. Of de laatste regel klopt ligt aan dnsmasq overigens; ik weet niet zeker of die ook queries vanaf poort 53 stuurt.

[ Voor 15% gewijzigd door CyBeR op 29-10-2013 13:53 ]

[Osiris]

CyBeR schreef op dinsdag 29 oktober 2013 @ 13:52:
[...]


Nee want hij wil zorgen dat zijn DNS server, welke op poort 53 draait, niet gebruikt kan worden door onbekenden.

Ja, daarvoor is --dport icm de lokale IP's als source. Dat bedoelde ik niet.

CyBeR schreef op dinsdag 29 oktober 2013 @ 13:52:
Of de laatste regel klopt ligt aan dnsmasq overigens; ik weet niet zeker of die ook queries vanaf poort 53 stuurt.

Als ik 't DNS-protocol goed herinner, zou dat wel moeten AFAIK. Met als --dport () het random gekozen poort-nummer wat de client heeft gekozen. (Of dát bij DNS ook zo was, I dunno meer..) Vandaar dat --dport 53 sowieso verkeerd is AFAIK. Lijkt me sterk dat je een UDP-pakketje hebt die van 53 naar 53 gaat?

[Dacuuu]

Ik heb al jullie berichtjes nog gelezen, sommigen delen snap ik nog niet erg.

Eerst was het zo, zodra ik de -DROP regel deed, ik zelf geen connectie meer kon maken, -F commando om alles leeg te maken en ik had direct weer verbinding.

Nu met de regels uit mijn laatste post hier, kan ik zelf nog normaal verbinding maken. Ik hoop snel het echt extern te kunnen testen vanaf een pc buiten mijn eigen netwerk.

[CyBeR]

Osiris schreef op dinsdag 29 oktober 2013 @ 14:04:
[...]

Als ik 't DNS-protocol goed herinner, zou dat wel moeten AFAIK. Met als --dport () het random gekozen poort-nummer wat de client heeft gekozen. (Of dát bij DNS ook zo was, I dunno meer..) Vandaar dat --dport 53 sowieso verkeerd is AFAIK. Lijkt me sterk dat je een UDP-pakketje hebt die van 53 naar 53 gaat?

Dat kan prima. Als je een DNS server hebt die een recursive query doet, kan die vanaf poort 53 komen. Moet niet, mag wel.

De server die een client antwoordt zal inderdaad van poort 53 naar de random gekozen poort van de client gaan.

Dacuuu schreef op dinsdag 29 oktober 2013 @ 14:57:
Ik heb al jullie berichtjes nog gelezen, sommigen delen snap ik nog niet erg.

Eerst was het zo, zodra ik de -DROP regel deed, ik zelf geen connectie meer kon maken, -F commando om alles leeg te maken en ik had direct weer verbinding.

Nu met de regels uit mijn laatste post hier, kan ik zelf nog normaal verbinding maken. Ik hoop snel het echt extern te kunnen testen vanaf een pc buiten mijn eigen netwerk.

Je moet waarschijnlijk bij je laatste regel, aangaande 8.8.8.8, even --dport veranderen naar --sport. Niet waar want je blockt alleen --dport 53 op input dus die regel mag überhaubt weg.

[ Voor 35% gewijzigd door CyBeR op 29-10-2013 15:45 ]

[Osiris]

CyBeR schreef op dinsdag 29 oktober 2013 @ 15:39:
[...]


Dat kan prima. Als je een DNS server hebt die een recursive query doet, kan die vanaf poort 53 komen. Moet niet, mag wel.

De server die een client antwoordt zal inderdaad van poort 53 naar de random gekozen poort van de client gaan.

Ergo: destination port 53, destination IP 'lokale IP'. Of gewoon RELATED toestaan..

[ Voor 70% gewijzigd door Osiris op 29-10-2013 15:40 ]

[Dacuuu]

Net getest op een pc van een maatje van me via teamviewer.
Eerst kon ik geen verbinding maken met mijn eigen dns server, na het adden van mijn maatje's IP adres in de iptables. lukte het direct. Alles werkt!

Met deze rule-opzet

code:

sudo iptables -A INPUT -p udp --dport 53 -s [interneipvanpc] -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -s [serverip] -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -j DROP

En uiteraard had ik poort 53 in de router geopend.

[ Voor 7% gewijzigd door Dacuuu op 29-10-2013 15:46 ]

[Rainmaker]

Wat ik meestal makkelijker vind bij iptables editten is trouwens iptables-persistent installeren (voor het init script) en hierna in /etc/iptables/rules.v4 en /etc/iptables/rules.v6 de regels aanpassen.

Na aanpassen service restarten, en klaar.

Geen "geklooi" met -I, -L etc.