[LINUX] Iptables commentaar*

[Nimoleda]

Ik ben vandaag bezig geweest met het maken van een iptable, zouden jullie commentaar kunnen geven op mijn script? En eventueel dingen kunnen toevoegen etc.

Ik vraag me ook af waarvoor de volgende regel staat:

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

Als ik deze regel weg haal, wordt alles geblocked

Ik heb google en de search van tweakers al raadgepleegd.

Alvast bedankt

PHP:

# Firewall configuration written by iptable
# Manual customization of this file is not recommended.

*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
:OUTPUT ACCEPT [0:0]

-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


#***********SERVER PORTS************#
# Port 21              VSFTPD       #
# Port 22              SSHDeamon    #
# Port 80              Apache       #
# Port 25              Send Mail    #
# Port 10000           Webmin       #
#***********************************#
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 22 --state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 80 --state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 21 --state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 25 --state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 10000 --state NEW -j ACCEPT
#***********************************#


#***********Blocked IP's************#
#           SSH PORT 22             #
#***********************************#
-I INPUT -s 222.235.64.140 -j DROP
-I INPUT -s 84.16.225.105 -j DROP
-I INPUT -s 209.59.11.5 -j DROP
-I INPUT -s 216.54.111.44 -j DROP
-I INPUT -s 61.132.74.9 -j DROP
-I INPUT -s 63.193.254.66 -j DROP
-I INPUT -s 218.188.252.3 -j DROP
-I INPUT -s 195.136.50.169 -j DROP
-I INPUT -s 219.133.170.114 -j DROP
-I INPUT -s 217.172.186.91 -j DROP
-I INPUT -s 212.82.212.107 -j DROP
-I INPUT -s 81.74.233.45 -j DROP
-I INPUT -s 84.14.109.37 -j DROP
-I INPUT -s 66.221.179.136 -j DROP
-I INPUT -s 66.15.145.131 -j DROP
-I INPUT -s 194.143.150.172 -j DROP
-I INPUT -s 83.18.146.102 -j DROP
-I INPUT -s 84.114.170.176 -j DROP
-I INPUT -s 211.119.136.170 -j DROP
#***********************************#

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

COMMIT

[Nitroglycerine]

Je vergeet de OUTPUT regels, zie onderstaand voorbeeld:

#iptables -A INPUT tcp --dport 21 -j ACCEPT
#iptables -A OUTPUT tcp --sport 21 -j ACCEPT


Ten aanzien van je vraag over de specifieke regel:

quote:
REJECT
This is used to send back an error packet in response to the matched
packet: otherwise it is equivalent to DROP so it is a terminating TAR-
GET, ending rule traversal. This target is only valid in the INPUT,
FORWARD and OUTPUT chains, and user-defined chains which are only
called from those chains. The following option controls the nature of
the error packet returned:

--reject-with type
The type given can be icmp-net-unreachable, icmp-host-unreach-
able, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-
prohibited or icmp-host-prohibited, which return the appropriate
ICMP error message (port-unreachable is the default). The
option tcp-reset can be used on rules which only match the TCP
protocol: this causes a TCP RST packet to be sent back. This is
mainly useful for blocking ident (113/tcp) probes which fre-
quently occur when sending mail to broken mail hosts (which
wonât accept your mail otherwise).
unquote
Die regel die zorgt ervoor dat alle pakketten die niet geaccepteerd worden, teruggestuurd worden met een foutmelding.

Output is nodig om de uitgaande stroom van de server te kunnen regelen. Indien je niet vanaf de server een ssh verbinding of ftp connectie op moet zetten, dan zijn de output regels niet nodig.

Een andere melding tav je iptables regels: vrij standaard is dat je alles eerst blokkeerd, en dan de uitzonderingen erop maakt. Jouw aanpak is anders: er wordt in de beginne niets geblokkeerd, alleen alle inkomende verzoeken die niet voldoen aan de opgegeven poorten worden als laatste geblokkeerd.

Als voorbeeld mijn iptables tabel. Deze firewall wordt gebruikt om enerzijds mijn firewall te beschermen, en om het verkeer van mijn LAN naar buiten te routeren, en mijn LAN te beschermen voor de buitenwereld.

code:

#!/bin/bash

INT_DEV="eth1"
EXT_DEV="eth0"

EXT_IP=$(ifconfig ${EXT_DEV} | grep "inet" | awk '{print $2}' | awk -F: '{print $2}')
#echo -e External IP ${EXT_IP} 
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

#Regels om de firewall middels ssh bereikbaar te maken, is nodig om na het laden van de regels remote verbinding met de firewall te kunnen maken, en niet alles op de console te hoeven doen
iptables -A INPUT tcp --dport 22 -j ACCEPT
iptables -A OUTPUT tcp --sport 22 -j ACCEPT

#Voorbeeldregels, in dit geval regels om ftp-verkeer naar de firewall toe toe te staan
#iptables -A INPUT tcp --dport 21 -j ACCEPT
#iptables -A OUTPUT tcp --sport 21 -j ACCEPT
#iptables -A INPUT tcp --dport 20 -j ACCEPT
#iptables -A OUTPUT tcp --sport 20 -j ACCEPT

#Accepteer alles wat vanaf het interne netwerk komt, en sluis dat door naar buiten
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A OUTPUT -o eth1 -j ACCEPT
iptables -A FORWARD -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -j ACCEPT

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

[ Voor 92% gewijzigd door Nitroglycerine op 29-11-2005 09:35 ]

[Nimoleda]

Nitroglycerine schreef op dinsdag 29 november 2005 @ 09:11:
Je vergeet de OUTPUT regels, zie onderstaand voorbeeld:

#iptables -A INPUT tcp --dport 21 -j ACCEPT
#iptables -A OUTPUT tcp --sport 21 -j ACCEPT

is het de bedoeling dan het dan zo wordt:

PHP:

-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 22 --state NEW -j ACCEPT
-A OUTPUT tcp --sport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 80 --state NEW -j ACCEPT
-A OUTPUT tcp --sport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 21 --state NEW -j ACCEPT
-A OUTPUT tcp --sport 21 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 25 --state NEW -j ACCEPT
-A OUTPUT tcp --sport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 10000 --state NEW -j ACCEPT
-A OUTPUT tcp --sport 10000 -j ACCEPT

en waarom moet de output er eigenlijk staan? het werkt nu namelijk gewoon?

thx

[Nimoleda]

bedankt voor je uitleg!

dus eigenlijk hoeft het alleen bij ftp,

en als ik het niet doe maakt het mijn server niet onveilger?

en welke regel zou ik er dan in moeten zetten om alles te blokkern?

maar wel dat de poorten 22 25 10000 en 80 het wel nog gewoon doen?

zou ik dan dit er in moeten zetten (in het begin dan )

$IPTABLES -F
$IPTABLES -N block
$IPTABLES -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A block -m state --state NEW -i ! eth0 -j ACCEPT

[ Voor 66% gewijzigd door Nimoleda op 29-11-2005 10:32 ]

[Nimoleda]

een klein schopje

[zomertje]

Het is niet de bedoeling om je eigen topic binnen een dag omhoog te schoppen

Verder is het gebruikelijk om in je firewall eerst alles dicht te zetten en daarna de dingen die je nodig hebt open te zetten.

[Mitch]

toch niet echt heel ingewikkeld ?
http://www.google.com/search?q=iptables%20howto

toen ik pas begon met firewalling heb ik het script uit de ip-masquerading howto gebruikt (strict), daarna met de verschillende howto's aangepast tot ik tevreden was / ben.
Als je het één keertje zelf helemaal uitzoekt zijn aanpassingen daarna supersimpel.

[Nimoleda]

zomertje schreef op dinsdag 29 november 2005 @ 13:58:
Het is niet de bedoeling om je eigen topic binnen een dag omhoog te schoppen

Verder is het gebruikelijk om in je firewall eerst alles dicht te zetten en daarna de dingen die je nodig hebt open te zetten.

ah ok,

ik heb nu alles op drop zitten

nu moet toch alles dichtzitten? op de poorten na die ik zelf heb opengezet

PHP:

# Firewall configuration written by iptable
# Manual customization of this file is not recommended.

*filter
#Drop alles
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]


#***********Allowed SERVER PORTS*************#
# Port 21                          VSFTPD    #
# Port 22                          SSHDeamon #
# Port 80                          Apache    #
# Port 25                          Send Mail #
# Port 10000                       Webmin    #
#********************************************#

#SSH Server
-A INPUT -p tcp --dport 22 -j ACCEPT
-A OUTPUT -p tcp --sport 22 -j ACCEPT

#Web Server
-A INPUT -p tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp --sport 80 -j ACCEPT

#FTP Server
-A INPUT -p tcp --dport 21 -j ACCEPT
-A OUTPUT -p tcp --sport 21 -j ACCEPT

#Webmin
-A INPUT -p tcp --dport 10000  -j ACCEPT
-A OUTPUT -p tcp --sport 10000 -j ACCEPT

#Send Mail
-A INPUT -p tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp --sport 25 -j ACCEPT

#********************************************#

COMMIT

[ Voor 43% gewijzigd door Nimoleda op 29-11-2005 14:29 ]

[webfreakz.nl]

"Nu moet alles toch dicht zitten?"

Ik zou zeggen: Open een browser en laad die een pagina, dan zit het niet dicht genoeg

[Nimoleda]

webfreakz.nl schreef op dinsdag 29 november 2005 @ 14:18:
"Nu moet alles toch dicht zitten?"

Ik zou zeggen: Open een browser en laad die een pagina, dan zit het niet dicht genoeg

hahah

maar nu ff serieus

[ Voor 69% gewijzigd door Nimoleda op 29-11-2005 14:23 ]

[Nitroglycerine]

Oh ehm, effe over de beginvraag, die iptables regel:

NIET DOEN!

Tenzij je wilt dat je aan iedereen die je pc probeert te benaderen aangeeft dat je er bent. Dit is niet het veiligst: stealth (dus niet antwoorden op dingen die niet geaccepteerd kunnen worden) is het veligist.

[Mitch]

dat is toch serieus ?
Gewoon testen, gebruik ook eens de log-functie van iptables, dan kun je zien wat er gebeurt.
Verder is shields-up van http://www.grc.com handig om te kijken wat er open / dicht staat (als je pc direct aant internet hangt).

[Nimoleda]

Nitroglycerine schreef op dinsdag 29 november 2005 @ 14:28:
Oh ehm, effe over de beginvraag, die iptables regel:

NIET DOEN!

Tenzij je wilt dat je aan iedereen die je pc probeert te benaderen aangeeft dat je er bent. Dit is niet het veiligst: stealth (dus niet antwoorden op dingen die niet geaccepteerd kunnen worden) is het veligist.

je bedoelt deze regel?

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

die heb ik er nu uitgehaald, zie een post hierboven...

zo moet hij goed draaien he?

[Joghert]

Ik ben zelf de laatste tijd ook nogal geinteresseerd in iptables en dergelijke, nu viel het volgende mij op:

aj viasco schreef op dinsdag 29 november 2005 @ 09:06:
--snip--

code:

...
#***********Blocked IP's************#
#           SSH PORT 22             #
#***********************************#
-I INPUT -s 222.235.64.140 -j DROP
-I INPUT -s 84.16.225.105 -j DROP
-I INPUT -s 209.59.11.5 -j DROP
-I INPUT -s 216.54.111.44 -j DROP
-I INPUT -s 61.132.74.9 -j DROP
-I INPUT -s 63.193.254.66 -j DROP
-I INPUT -s 218.188.252.3 -j DROP
-I INPUT -s 195.136.50.169 -j DROP
-I INPUT -s 219.133.170.114 -j DROP
-I INPUT -s 217.172.186.91 -j DROP
-I INPUT -s 212.82.212.107 -j DROP
-I INPUT -s 81.74.233.45 -j DROP
-I INPUT -s 84.14.109.37 -j DROP
-I INPUT -s 66.221.179.136 -j DROP
-I INPUT -s 66.15.145.131 -j DROP
-I INPUT -s 194.143.150.172 -j DROP
-I INPUT -s 83.18.146.102 -j DROP
-I INPUT -s 84.114.170.176 -j DROP
-I INPUT -s 211.119.136.170 -j DROP
#***********************************# 
...

--snip--

Nou snap ik prima dat als je last hebt van externe inlog/hack pogingen dat je dat graag wil blokkeren.
Maar naar mijn mening is het volslagen zinloos om klakkeloos ip's te blokkeren, het helpt natuurlijk wel tegen _die ene_ aanval, maar als het een serieuzere poging is dan zal het niet bij een ip blijven.
Plus dat je nu mischien onschuldige onwetende bijstanders de toegang tot de gehele machine ontzegt.

Wat ik tegenkwam en zelf mooier vind is de "port knocking" methode.
Normaal gesproken moet dit via omslachtige extra software, maar het kan ook doormiddel van een paar aanpassingen in je firewall in combinatie met de recent module. (ook heel interesant voor allerlei andere voodoo) Deze zit overigens al een tijdje standaard in iptables.

Op deze manier kun je zelf altijd toegang krijgen door met een willekeurig programma (telnet, browser, etc.) een verbinding te maken naar een door jouw gespecificeerde port.

code:

...

# port knocking SSH
iptables -A INPUT -i eth0 -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name ALLOWEDLIST -j ACCEPT
iptables -A INPUT -i eth0 -m state --state NEW -m tcp -p tcp --dport 22 -m recent --set -j DROP

# port knocking poorten open zetten & sluiten
iptables -A INPUT -i eth0 -m state --state NEW -m tcp -p tcp --dport 1599 -m recent --name ALLOWEDLIST --remove -j DROP
iptables -A INPUT -i eth0 -m state --state NEW -m tcp -p tcp --dport 1600 -m recent --name ALLOWEDLIST --set -j DROP
iptables -A INPUT -i eth0 -m state --state NEW -m tcp -p tcp --dport 1601 -m recent --name ALLOWEDLIST --remove -j DROP

...

In het eerste deel wordt port 22 standaard voor iedereen dichtgezet behalve als ze in de "ALLOWEDLIST" voorkomen.

In het tweede deel wordt iedereen die _alleen_ op port 1600 traffic maakt in de "ALLOWEDLIST" gezet en iedereen die de poort daarnaast raakt er weer uitgehaald, oftewel niet toegelaten.(dit is een bescherming tegen portscanning, dat ie niet perongeluk getriggerd wordt)


En voila nu staat port 22 veilig dicht behalve voor de mensen die weten hoe ze moeten kloppen. Zo kun je in principe nu elke port open en dicht gooien waar je iets achter wilt draaien waar niet iedereen standaard bij moet kunnen.


!! de gebruikte ports zijn natuurlijk voorbeelden, het heeft totaal geen nut meer als _iedereen_ straks port 1600 als knock port gaat gebruiken

[sPENKMAN]

Joghert schreef op woensdag 30 november 2005 @ 01:54:
-knip-
En voila nu staat port 22 veilig dicht behalve voor de mensen die weten hoe ze moeten kloppen. Zo kun je in principe nu elke port open en dicht gooien waar je iets achter wilt draaien waar niet iedereen standaard bij moet kunnen.


!! de gebruikte ports zijn natuurlijk voorbeelden, het heeft totaal geen nut meer als _iedereen_ straks port 1600 als knock port gaat gebruiken

Dit is zeker iets wat ik ga toevoegen, ik heb nu sinds 3 weken een servertje draaien hier thuis en er zit een gestaagt stijgende lijn in het aantal login pogingen met niet bestaande gebruikers. (er is slechts 1 user toegestaan om van buiten te verbinden)

Ik vraag me alleen af, als je de "port knocking" methode gebruikt, dit niet enigsinds onpraktisch is als je veel van verschillende lokaties connect. Hoe werk jij hiermee in de praktijk? Ik neem aan dat je gebruikt maakt van een uitvoerbaar bestandje welke een "port knock" triggert voordat je connect met je ssh client?

[Nimoleda]

oke harstikke bedankt!, dat ga ik er wel inzeten!

Ik heb gister alles op drop gezet, en alleen poort 25 22 21 80 en 10000 opengezet. Alleen ontvang ik sinds ik dat heb aangepast geen logwatch meer in mijn gmail? iemand enig idee waar dat aan kan liggen?

#Drop alles
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]