Bekijk Volledige Versie : Iptables inkomend blokkeren, maar uitgaand WEL toestaan
Ramon Fincken
17/05/17, 10:02
Ik doe iets niet lekker geloof ik
als de variabele: $thisip het IP adres waarvan ik ENKEL wil dat inkomende verbindingen niet moeten, maar dus uitgaand vanaf deze server wel ..
dan lijkt het alsof als ik dit doe:
iptables -I INPUT -s $thisip -j DROP
niet alleen de inkomende, maar ook uitgaande verbindingen blokkeren. Wat doe ik mis?
Laat je related/established ook toe?
Ramon Fincken
17/05/17, 10:11
Dit is alles qua commandos om te blokkeren, iptables zelf is zo leeg als maar kan na (bijvoorbeeld) iptables -F
Maar hoe weet je dat het niet werkt? Want bijvoorbeeld ICMP zal je alleen kunnen testen door een tcpdump op de dst host te doen (want return pakketten mogen niet).
Ramon Fincken
17/05/17, 12:57
concreet is dit een web proxy server
iptables blokkeert malafide aanroepen met die regel code
Probleem echter is dat er een backend server (los van excludes) zichzelf VIA de proxy aanroept en geblokkeerd wordt.
Dat is niet erg als het nu enkel om inkomende verbindingen voor web op de proxy ging.
Maar de proxy kan dan zelf ook niet meer bij die backend server komen waardoor alle sites offline gaan.
Ik doe iets niet lekker geloof ik
als de variabele: $thisip het IP adres waarvan ik ENKEL wil dat inkomende verbindingen niet moeten, maar dus uitgaand vanaf deze server wel ..
dan lijkt het alsof als ik dit doe:
iptables -I INPUT -s $thisip -j DROP
niet alleen de inkomende, maar ook uitgaande verbindingen blokkeren. Wat doe ik mis?
(Zoals SF-Jeroen ook schreef )
Je bent je ervan bewust dat een verbinding twee-weg verkeer is ? Het antwoord verkeer op je _uitgaande_ sessie is voor jou weer _inkomend_ verkeer .
Dat is verkeer dat je (voor de drop) moet doorlaten - bv omdat het 'ESTABLISHED' is .
Als je (met iptables -nvxL ) kijkt naar de hitcounters op de iptables regels zul je waarschijnlijk hits zien oplopen op die input regel op moment dat je een uitgaande sessie opzet.
Ramon Fincken
18/05/17, 12:11
ja, maar ik ben net niet goed genoeg into IPtables om die 1 en 1 als 2 te zien ;)
Ik zal hier naar (laten) kijken, thanks!
systemdeveloper
18/05/17, 13:12
# blokkeer alle inkomende/forwarding zooi als policy
iptables -P INPUT DROP
iptables -P FORWARD DROP
# accepteer wel uitgaand
iptables -P OUTPUT ACCEPT
# Ook wel handig voor local if
ptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# accepteer wel established en related zooi
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Dan zul je wel op de console moet inloggen om iets te doen of je moet ssh er nog aan toevoegen.
En running als scriptje anders is de lol ver over na de eerste regel tenzij je op de console zit.
Of de poorten boven de 32000 toestaan, daar komt het verkeer normaal op terug op Linux.
Of de poorten boven de 32000 toestaan, daar komt het verkeer normaal op terug op Linux.
Dat is een slecht advies.
Het is beslist niet waar dat de uitgaande source poort altijd >32000 op "linux" - en dat retour verkeer dus altijd terugkomt op >32000 .
Het blindeling (zonder source ip of state ESTABLISHED) accepteren van verkeer naar 'hoge' poorten kan betekenen dat er ook inkomend verkeer naar luisterende daemons op hoge poorten binnenkomt.
De keuze voor de uitgaande port is instelbaar (door distributie of admin) via net.ipv4.ip_local_port_range (cat /proc/sys/net/ipv4/ip_local_port_range ) . Verder kan een applicatie zelf eventueel ook een source port kiezen bij het opzetten van een connectie.
Ik vond wat links die suggereren dat Redhat 6 bijvoorbeeld 1024-4999 als ephemeral port range instelt.
Ik zie wel dat je 'verkeer normaal op Linux terug' schrijft, maar iemand die geen benul heeft van iptables heeft nog minder benul van waar te kijken om te zien of zijn 'linux' server in dit opzicht 'normaal' is . Of wanneer een "linux" server "niet normaal" is .
Genoeg redenen dat een kaal advies "retour verkeer op port >32000" een behoorlijke kans heeft om niet van toepassing te zijn op een "linux" server.
Maar hoe weet je dat het niet werkt? Want bijvoorbeeld ICMP zal je alleen kunnen testen door een tcpdump op de dst host te doen (want return pakketten mogen niet).
Let op dat tcpdump verkeer erg direct vanaf de netwerk kaart ziet - en 'voor' iptables zit - verkeer wat je met tcpdump ziet binnenkomen kan daarna door iptables gedropt worden en dus niet meer aankomen bij de applicatie.
Dat kan verwarrend zijn als je aan het troubleshooten bent waarom een applicatie niet werkt terwijl het verkeer 'goed binnenkomt' .
(En andersom :een applicatie als dhcpd [de server daemon] bijvoorbeeld haalt verkeer ook via een 'RAW Socket' binnen en zit daarmee voor netfilter - als je dat niet weet ben je lang aan het zoeken waarom dhcpd blijft werken ondanks een drop rule.