[debian] Dedicated server + iptables

[Martink]

Hoi

Ik heb sinds gisteren een dedicated server in amsterdam erg leuk maar moet dus ook zelf firewall instellen, ben beetje naar het kijken geweest naar scrips maar dat spreekt me niet zo aan. dus ben nu zelf simpel scriptje aanhet maken zie hieronder.
Heb een beetje van wat ik thuis gebruikt gepakt en beetje van forum en beetje van andere pagina's
Maar is het script zo een beetje veilig?

code:

# Flush
iptables -F
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -F -t mangle

# Set default policies
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

# Loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow SSH
iptables -A INPUT -p tcp -i eth0 --dport 22 -j ACCEPT

# Allow FTP
iptables -A INPUT -p tcp -i eth0 --dport 21 -j ACCEPT
# Non-Passive FTP
iptables -A INPUT -p tcp -i eth0 --dport 20 -j ACCEPT

# Allow HTTP
iptables -A INPUT -p tcp -i eth0 --dport 80 -j ACCEPT

# Allow DNS
iptables -A INPUT -p tcp -i eth0 --dport 53 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --dport 53 -j ACCEPT

# Allow icmp
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

Er moeten straks nog meer porten open zoals pop3, unreal 2004 server, maargoed dat komt later wel

Ik heb wel een klein probleempje met ftp, het verbinden duurt langer als ik de firewall aanzet. kan dit ook opgelost worden? ftp programma blijft langer op "Connected to x.x.x.x" staan voordat hij uiteindelijk gaat inloggen.

[Verwijderd]

Ik zie geen regels voor connection tracking staan. Dit kan de preformance aanzienlijk benadelen.

code:

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

Dan krijg je verder regels zoals.

code:

# Allow remote clients access to you Local SSH server (tcp 22)
iptables -A INPUT -i $INTERFACE  -p tcp \
     -d $IPADDR --sport $UNPRIVPORTS \
     --dport 22 -m state --state NEW -j ACCEPT

En draai je ook een dns server op die machine voor je domein? Anders zou ik binnenkomende verbindingen op poort 53 niet toestaan. Maar alleen uitgaande met behulp van connection tracking.

Martink schreef op zaterdag 06 augustus 2005 @ 17:32:

Ik heb wel een klein probleempje met ftp, het verbinden duurt langer als ik de firewall aanzet. kan dit ook opgelost worden? ftp programma blijft langer op "Connected to x.x.x.x" staan voordat hij uiteindelijk gaat inloggen.

Het je de ip_conntrack_ftp module geladen?

[deadinspace]

Zonder die connection tracking kun je volgensmij niet eens uitgaande connecties vanaf je server maken (bijvoorbeeld iets downloaden met een ftp client, of ergens anders heen ssh-en).

Daarnaast nog twee dingen:

De poorten die niet geACCEPT worden DROP je. Dat kan onhandig zijn, aangezien iemand die probeert op zo'n poort te verbinden moet wachten op de timeout ipv dat hij gewoon "connection refused" krijgt.

Daarnaast vraag ik me af of het niet handiger is alle services die je niet van buitenaf nodig hebt uit te zetten, dan is een firewall ook niet nodig.

[CyBeR]

deadinspace schreef op zaterdag 06 augustus 2005 @ 20:48:
De poorten die niet geACCEPT worden DROP je. Dat kan onhandig zijn, aangezien iemand die probeert op zo'n poort te verbinden moet wachten op de timeout ipv dat hij gewoon "connection refused" krijgt.

Dat is nou het laatste waar ik me zorgen over zou maken bij het dichtgooien van poorten tegen indringers

[eth0]

en je hebt poort 22 voor de werlend open staan, is opzich geen probleem, maar je zou deze natuurlijk nog op ip kunnen afschermen. Scheelt heel wat aanvallen. Ik krijg dagelijks brute force aan vallen op poort 22.

Als poort 22 wel voor de wereld moet open staan dan kan ik je het volgende aam raden:

code:

#ssh
${IPTABLE} -A in -p tcp --dport 22 --dst $ETH0 -i eth0 -m state --state NEW -m recent --set
${IPTABLE} -A in -p tcp --dport 22 --dst $ETH0 -i eth0 -m state --state NEW -m recent --update --seconds 120 --hitcount 4 -j DROP
${IPTABLE} -A in -p tcp --dport 22 --dst $ETH0 -i eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Hier mee mag je vanaf 1 ip maar 4 connects maken binnen 2 minuten. Daarna word je gedropt. Handig voor al die brute force hacks op poort 22

[Ajunne]

CyBeR schreef op zaterdag 06 augustus 2005 @ 20:53:
[...]


Dat is nou het laatste waar ik me zorgen over zou maken bij het dichtgooien van poorten tegen indringers

Helaas is dit wel de verkeerde mentaliteit. De hele bedoeling achter het principe is dat mensen die je computer beginnen te portscannen lang moeten wachten eer ze doorkrijgen dat een bepaalde poort gesloten is. Als ze meteen een "connection refused" message krijgen, kunnen ze makkelijk verder doen door de volgende poort te scannen. Als ze echte moeten wachten tot de boel timedout duurt het poortscannen veel langer en wordt de boel sneller afgesloten en een volgend slachtoffer gezocht.

[Martink]

deadinspace schreef op zaterdag 06 augustus 2005 @ 20:48:
Zonder die connection tracking kun je volgensmij niet eens uitgaande connecties vanaf je server maken (bijvoorbeeld iets downloaden met een ftp client, of ergens anders heen ssh-en).

Daarnaast nog twee dingen:

De poorten die niet geACCEPT worden DROP je. Dat kan onhandig zijn, aangezien iemand die probeert op zo'n poort te verbinden moet wachten op de timeout ipv dat hij gewoon "connection refused" krijgt.

Daarnaast vraag ik me af of het niet handiger is alle services die je niet van buitenaf nodig hebt uit te zetten, dan is een firewall ook niet nodig.

Aha dus eigenlijk is firewall beetje overdreven, en alleen dingen die ik intern nodig heb zoals mysql via firewall dichtgooien of binden aan localhost.

Ik draai momenteel nog geen domeinen op de dns maar dat gaat wel gebeuren. moet alleen nog even uitzoeken hoe ik alles moet configen, mail en dns voor de domeinen, ftp en apache weet ik wel

ssh is wel makelijk als ik die vanaf elke hostname kan berijken. als ik ergens anders zit dat ik ook dingen kan instellen.

[CyBeR]

Ajunne schreef op zaterdag 06 augustus 2005 @ 21:39:
[...]


Helaas is dit wel de verkeerde mentaliteit. De hele bedoeling achter het principe is dat mensen die je computer beginnen te portscannen lang moeten wachten eer ze doorkrijgen dat een bepaalde poort gesloten is. Als ze meteen een "connection refused" message krijgen, kunnen ze makkelijk verder doen door de volgende poort te scannen. Als ze echte moeten wachten tot de boel timedout duurt het poortscannen veel langer en wordt de boel sneller afgesloten en een volgend slachtoffer gezocht.

Probeer je me nou tegen te spreken of niet? Dat kan ik niet echt opmaken uit je verhaal.. Je zegt namelijk dingen die ik ook wel weet maar die niet van toepassing waren op mijn eerder gemaakte opmerking...

[benoni]

Ajunne schreef op zaterdag 06 augustus 2005 @ 21:39:
[...]Helaas is dit wel de verkeerde mentaliteit.[...]

Zijn understatements-interpreter had blijkbaar een bug, maar de rest van de uitvoer was correct

[vanaalten]

eth0 schreef op zaterdag 06 augustus 2005 @ 21:31:Als poort 22 wel voor de wereld moet open staan dan kan ik je het volgende aam raden:

code:

#ssh
${IPTABLE} -A in -p tcp --dport 22 --dst $ETH0 -i eth0 -m state --state NEW -m recent --set
${IPTABLE} -A in -p tcp --dport 22 --dst $ETH0 -i eth0 -m state --state NEW -m recent --update --seconds 120 --hitcount 4 -j DROP
${IPTABLE} -A in -p tcp --dport 22 --dst $ETH0 -i eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Hier mee mag je vanaf 1 ip maar 4 connects maken binnen 2 minuten. Daarna word je gedropt. Handig voor al die brute force hacks op poort 22

Hee, handig, meteen overgenomen!
Overigens ook even getest. Het is maar een detail, maar je mag vanaf 1 ip maar 3 connects maken binnen 2 minuten, de vierde wordt al gedropt!

[eth0]

mm, klopt ja, de hitcount van vier houd in dat hij de 4de dropt. Dus je mag idd 3 connects maken vanaf 1 ip.

[Kippenijzer]

Zou er ook een "eenvoudige" manier zijn om die recent match uit te breiden dat hij de "oude matches" langer en nog stricter "bewaart" voor de komende langere tijd?
Uitleg in beschrijving van wat ik bedoel:

IP A probeert in 120 seconden 4 keer in te loggen, en wordt dus geblockt voor de volgende (of rest van de?) 120 seconden, maar zodra dit ip in de opeenvolgende 10 minuten weerd probeert wil ik hem maar 1 kans geven, en anders direct weer blokken, maar ik zie zou niet hoe/of dat zo ook kan?

[edit] En weet iemand toevallig hoe het zit met de "vervaltijd" van de recent regels? Hij zet ze in /proc, dus in ram, maar zou je daarmee in theorie geen dDos kunnen creeren door vanaf tig veschillende IP's deze recent lijst te vullen? Of zit er aan standaard FIFO achtig verval in recent, danwel iptables, danwel proc?

[ Voor 28% gewijzigd door Kippenijzer op 21-08-2005 11:43 ]

[Tomsworld]

Ik probeer dit ook enigsinds te implementeren.

code:

$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
$IPT -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_
force "
$IPT -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

code:

ACCEPT  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp dpt:22 state NEW recent: SET name: SSH side: source
iptables: No chain/target/match by that name
LOG  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp dpt:22 recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source LOG flags 0 level 4 prefix `SSH_brute_force '
iptables: No chain/target/match by that name
DROP  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp dpt:22 recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source
iptables: No chain/target/match by that name

Ik heb al talloze variaties geprobeerd niets werkt.

[ Voor 8% gewijzigd door Tomsworld op 22-08-2005 10:32 ]

[Kippenijzer]

Je moet bij de --update regels alsnog wel statefull matchen btw (-m state --state NEW), daarbij zou ik in de -j LOG regel voor --rcheck kiezen (anders updaten de twee regels de teller 2x)

Verder de vraag wat je "exacte" commando is waarna je de uitvoer uit het 2e code venster krijgt? Want op deze manier zie ik het niet echt (die output is niet "standaard", muv de error,en als hij chain INPUT niet kent heb je een probleem

[Tomsworld]

Kippenijzer schreef op maandag 22 augustus 2005 @ 10:57:
Je moet bij de --update regels alsnog wel statefull matchen btw (-m state --state NEW), daarbij zou ik in de -j LOG regel voor --rcheck kiezen (anders updaten de twee regels de teller 2x)

Verder de vraag wat je "exacte" commando is waarna je de uitvoer uit het 2e code venster krijgt? Want op deze manier zie ik het niet echt (die output is niet "standaard", muv de error,en als hij chain INPUT niet kent heb je een probleem

Ik heb nog eens het stukje van hierboven erin gegooid.

code:

echo "ssh"

$IPT -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --set
$IPT -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --update --seconds 120 --hitcount 4 -j DROP
$IPT -A INPUT -p tcp --dport 22 -i eth1 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

echo "done."


geeft

ssh
  tcp opt -- in eth1 out *  0.0.0.0/0  -> 0.0.0.0/0  tcp dpt:22 state NEW recent: SET name: DEFAULT side: source
iptables: No chain/target/match by that name
DROP  tcp opt -- in eth1 out *  0.0.0.0/0  -> 0.0.0.0/0  tcp dpt:22 state NEW recent: UPDATE seconds: 120 hit_count: 4 name: DEFAULT side: source
iptables: No chain/target/match by that name
ACCEPT  tcp opt -- in eth1 out *  0.0.0.0/0  -> 0.0.0.0/0  tcp dpt:22 state NEW,RELATED,ESTABLISHED
done.

Table INPUT bestaat.
eth1 = wan interface.

[Jaap-Jan]

Ajunne schreef op zaterdag 06 augustus 2005 @ 21:39:
[...]


Helaas is dit wel de verkeerde mentaliteit. De hele bedoeling achter het principe is dat mensen die je computer beginnen te portscannen lang moeten wachten eer ze doorkrijgen dat een bepaalde poort gesloten is. Als ze meteen een "connection refused" message krijgen, kunnen ze makkelijk verder doen door de volgende poort te scannen. Als ze echte moeten wachten tot de boel timedout duurt het poortscannen veel langer en wordt de boel sneller afgesloten en een volgend slachtoffer gezocht.

Even voor de duidelijkheid: deadinspace vond dat je een 'connection refused' moest krijgen op een geblokkeerde poort. Dit wordt gedaan met REJECT. CyBeR vond dat DROP beter was, zodat portscanners moeten wachten op time- outs en dan weten ze nog niets.

Waarschijnlijk ben je het juist eens met CyBeR, in plaats van hem tegen te spreken .

[Tomsworld]

Ondertussen heb ik nog een leuke insteek gevonden.

http://cert.uni-stuttgart...ity/2005/02/msg00025.html

I use a two-level approach like this:
#
# special handling for SSH (to dwarf SSH dictionary attacks)
#
$IPTABLES -N SSH
$IPTABLES -N SSH-evil
$IPTABLES -A SSH-evil -m recent --name badSSH --set -j LOG --log-level DEBUG --log-prefix "evil SSH user: "
$IPTABLES -A SSH-evil -j REJECT

$IPTABLES -A SSH -p TCP ! --syn -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A SSH -p TCP --syn -m recent --name badSSH --rcheck --seconds 600 -j REJECT
$IPTABLES -A SSH -p TCP --syn -m recent --name sshconn --rcheck --seconds 60 --hitcount 5 -j SSH-evil
$IPTABLES -A SSH -p TCP --syn -m recent --name sshconn --set
$IPTABLES -A SSH -p TCP --syn -j ACCEPT


It first checks for already established connections and let's em pass. Then it checks for the badSSH flag and rejects the bad guy for 10 minutes. Otherwise it is a new SSH connection and checks if we've seen 5 in 60 seconds, if so, jump to SSH-Evil where the badSSH marker gets added. Otherwise just set the connSSH marker which is harmless unless you get 5 in 60 seconds.

Echter werkt dit ook niet

code:

iptables -v -N SSH
iptables -v -N SSH-evil
iptables -v -A SSH-evil -m recent --name badSSH --set -j LOG --log-level DEBUG --log-prefix "evil SSH user: "
iptables -v -A SSH-evil -j REJECT
LOG  all opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  recent: SET name: badSSH side: source LOG flags 0 level 7 prefix `evil SSH user: '

iptables -v -A SSH -p TCP ! --syn -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables: No chain/target/match by that name
iptables -v -A SSH-evil -j REJECT
iptables -v -A SSH -p TCP --syn -m recent --name badSSH --rcheck --seconds 600 -j REJECT
iptables -v -A SSH -p TCP --syn -m recent --name sshconn --rcheck --seconds 60 --hitcount 5 -j SSH-evil
REJECT  all opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  reject-with icmp-port-unreachable
iptables -v -A SSH -p TCP ! --syn -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -v -A SSH -p TCP --syn -m recent --name sshconn --set
iptables -v -A SSH -p TCP --syn -j ACCEPTACCEPT  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp flags:!0x16/0x02 state RELATED,ESTABLISHED
iptables -v -A SSH -p TCP --syn -m recent --name badSSH --rcheck --seconds 600 -j REJECT
REJECT  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp flags:0x16/0x02 recent: CHECK seconds: 600 name: badSSH side: source reject-with icmp-port-unreachable
iptables: No chain/target/match by that name
iptables -v -A SSH -p TCP --syn -m recent --name sshconn --rcheck --seconds 60 --hitcount 5 -j SSH-evil
SSH-evil  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp flags:0x16/0x02 recent: CHECK seconds: 60 hit_count: 5 name: sshconn side: source
iptables: No chain/target/match by that name
iptables -v -A SSH -p TCP --syn -m recent --name sshconn --set
  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp flags:0x16/0x02 recent: SET name: sshconn side: source
iptables: No chain/target/match by that name
iptables -v -A SSH -p TCP --syn -j ACCEPT
ACCEPT  tcp opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  tcp flags:0x16/0x02
root@andromeda:/etc/firewall#

* Tomsworld zal straks maar es firewall netjes maken en een topic starten.

@Kippenijzer ik ga denk ik een ander topic starten zodat dit beperkt blijft het probleem brute force ssh attacks.

[ Voor 60% gewijzigd door Tomsworld op 22-08-2005 12:40 ]

[Kippenijzer]

TNX Alot tomsworld, deze had ik toen je dit topic starte toevallig gezine, maar kon hem eergisteren niet meer terugvinden mbv google.

Btw, je output is onvolledig en redelijk onleesbaar, stop ajb voor even met overal de -v flag aan mee te geven, daarvan wordt het leesbaardaar. Ook het ene regel met, andere zonder prompt ervoor is erg irri.

[ Voor 45% gewijzigd door Kippenijzer op 22-08-2005 11:57 ]

[Tomsworld]

Toch nog een poging in dit topic aangezien alle rest blijft werken.

Mijn firewall zonder ips / poorten

eth0 = local lan
eth1 = internet

code:

#!/bin/bash

echo -n "Setting up Iptables... "

################################################################################
#   Vars                                                                       #

IPT="/sbin/iptables"
INT="eth0"
EXT="eth1"
ANYWHERE="0.0.0.0/0"        # elk ip adres valt hierbinnen
LOOPBACK="127.0.0.1"        # ip adres van localhost
CLASS_A="10.0.0.0/8"        # klasse A prive netwerk
CLASS_B="172.16.0.0/12"     # klasse B prive netwerk
CLASS_C="192.168.0.0/24"    # klasse C prive netwerk

BLOCK_LIST=""

NR_IP="1 2 3 4 5 6 7 8"
IP1="aaa.bbb.ccc.1"
IP2="aaa.bbb.ccc.2"
IP3="aaa.bbb.ccc.3"
IP4="aaa.bbb.ccc.4"
IP5="aaa.bbb.ccc.5"
IP6="aaa.bbb.ccc.6"
IP7="aaa.bbb.ccc.7"
IP8="aaa.bbb.ccc.8"

TCP_ALL="21 22 25 53 80 110 113 119 143 443"
UDP_ALL="53"

IP1_TCP="587 2525 5100"
IP1_UDP=""
IP2_TCP="3000 61234"
IP2_UDP=""
IP3_TCP="8000 8001 8002 8003 8004 8005 8006 8007 8008 8009 8010 8011 8012 8013 8014 8015 8016 8017 8018 8019 8020 8021 8022 8023 8024 8025 8026 8027 8028 8029 8030 8031 8032 8033 8034 8035 8036 8037 8038 8039 8040 8041 8042 8043 8044 8045 8046 8047 8048 8049 8050 "
IP3_UDP=""
IP4_TCP=""
IP4_UDP=""
IP5_TCP=""
IP5_UDP=""
IP6_TCP="4000 4950 4960 4990 4100 4101 4200 4300 5000 6666 6667 6668 6669 6670 6767"
IP6_UDP=""
IP7_TCP="31457 1433 1434"
IP7_UDP=""
IP8_TCP="28000"
IP8_UDP=""

################################################################################

# Remove any existing rules from all chains
# Flush
$IPT -F
$IPT -F INPUT
$IPT -F OUTPUT
$IPT -F FORWARD
$IPT -F -t mangle

# Accept everything on the loopback and internal interfaces
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
$IPT -A INPUT -i eth0 -j ACCEPT
$IPT -A OUTPUT -o eth0 -j ACCEPT

# Set the default policy to DROP
$IPT --policy INPUT DROP
$IPT --policy FORWARD DROP

# Default Output Policies
$IPT -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPT -A OUTPUT -p icmp -d 0/0 -o $EXT -j ACCEPT
$IPT -A OUTPUT -j ACCEPT

# DO NOT MODIFY THESE!
#
# If you set these to DROP, you will be locked out of your server.
#
$IPT -t nat --policy PREROUTING ACCEPT
$IPT -t nat --policy OUTPUT ACCEPT
$IPT -t nat --policy POSTROUTING ACCEPT
$IPT -t mangle --policy PREROUTING ACCEPT
$IPT -t mangle --policy OUTPUT ACCEPT

# Remove any pre-existing user-defined chains
$IPT --delete-chain
$IPT -t nat --delete-chain
$IPT -t mangle --delete-chain


################################################################################
# initialiseren van de kernel
 ## Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
 ## Enable IP-spoofing beveiliging
for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do
    echo 1 > $f
done
 ## Disable ICMP redirect acceptatie
for f in /proc/sys/net/ipv4/conf/*/accept_redirects ; do
    echo 0 > $f
done
 ## Disable ICMP send_redirects
for f in /proc/sys/net/ipv4/conf/*/send_redirects ; do
    echo 0 > $f
done
 ## Source routed pakketten niet accepteren
for f in /proc/sys/net/ipv4/conf/*/accept_source_route ; do
    echo 0 > $f
done
 ## Log spoofed pakketten, source routed pakketten en redirected pakketten
for f in /proc/sys/net/ipv4/conf/*/log_martians ; do
    echo 1 > $f
done
 ## Enable TCP SYN cookie beveiliging
 #echo 1 > /proc/sys/net/ipv4/tcp_syncookies
 ## Enable ICMP broadcasting protection
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
 ## Enable ICMP dead error message protection
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
 ## Enable dynamic TCP/IP address hacking
echo 1 > /proc/sys/net/ipv4/ip_dynaddr

################################################################################
# sommige pakketten resoluut weigeren

## Weiger (en log) alle gefragmenteerde pakketten
$IPT -A INPUT -i $EXT -f -j LOG --log-prefix "FRAGMENT! "
$IPT -A INPUT -i $EXT -f -j DROP

## Weiger (en log) alles van privenetwerken op externe iface
$IPT -A INPUT -i $EXT -s $LOOPBACK -j LOG --log-prefix "SPOOFING! "
$IPT -A INPUT -i $EXT -s $CLASS_A  -j LOG --log-prefix "CLASS A ADDRESS! "
$IPT -A INPUT -i $EXT -s $CLASS_B  -j LOG --log-prefix "CLASS B ADDRESS! "
$IPT -A INPUT -i $EXT -s $CLASS_C  -j LOG --log-prefix "CLASS C ADDRESS! "
$IPT -A INPUT -i $EXT -s $LOOPBACK -j DROP
$IPT -A INPUT -i $EXT -s $CLASS_A  -j DROP
$IPT -A INPUT -i $EXT -s $CLASS_B  -j DROP
$IPT -A INPUT -i $EXT -s $CLASS_C  -j DROP

# accepteer bepaalde ICMP pakketten
## Een aantal typen ICMP pakketten accepteren 
$IPT -A INPUT -i $EXT -p icmp --icmp-type 0 -m limit --limit 200/s -j ACCEPT
$IPT -A INPUT -i $EXT -p icmp --icmp-type 3 -m limit --limit 200/s -j ACCEPT
$IPT -A INPUT -i $EXT -p icmp --icmp-type 5 -m limit --limit 200/s -j ACCEPT
$IPT -A INPUT -i $EXT -p icmp --icmp-type 8 -m limit --limit 200/s -j ACCEPT
$IPT -A INPUT -i $EXT -p icmp --icmp-type 11 -m limit --limit 400/s -j ACCEPT
$IPT -A INPUT -p icmp -j DROP

################################################################################
# Silently Drop Stealth Scans
# All of the bits are cleared
$IPT -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# SYN and FIN are both set
$IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
# SYN and RST are both set
$IPT -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
# FIN and RST are both set
$IPT -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
# FIN is the only bit set, without the expected accompanying ACK
$IPT -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
# PSH is the only bit set, without the expected accompanying ACK
$IPT -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
# URG is the only bit set, without the expected accompanying ACK
$IPT -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP
################################################################################
# BLOCK_LIST
#
for blocked_ip in $BLOCK_LIST; do
    # Lock him out:
    $IPT -A INPUT  -s $blocked_ip -j DROP
    # Make sure that he never hears from us again:
    $IPT -A OUTPUT -d $blocked_ip -j DROP
done
################################################################################
# Use Connection State to Bypass Rule Checking
#
# By accepting established and related connections, we don't need to explicitly
# set various input and output rules. For example, by accepting an established
# and related output connection, we don't need to specify that the firewall
# needs to open a hole back out to client when the client requests SSH access.
#
$IPT -A INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A INPUT  -m state --state INVALID -j DROP
$IPT -A OUTPUT -m state --state INVALID -j DROP


################################################################################
# INPUT - PORTS
################################################################################

#TCP op alle ips
 for tcp_port in $TCP_ALL; do
    $IPT -A INPUT -i eth1 -m state --state NEW -p tcp --dport $tcp_port -j ACCEPT
 done
#UDP op alle ips
 for udp_port in $UDP_ALL; do
    $IPT -A INPUT -i eth1 -p udp --dport $udp_port -j ACCEPT
 done

for j in $NR_IP; do
     eval IPADDR=\${IP$j}
     eval TCP=\${IP$j\_TCP}
     eval UDP=\${IP$j\_UDP}
  #TCP op IPx
  for tcp_port in $TCP; do
     $IPT -A INPUT -i eth1 -d $IPADDR -m state --state NEW -p tcp --dport $tcp_port -j ACCEPT
  done
  #UDP op IPx
  for udp_port in $UDP; do
     $IPT -A INPUT -i eth1 -d $IPADDR -p udp --dport $udp_port -j ACCEPT
  done
done

#dns
#$IPT -A INPUT -i eth1 -p udp --dport 53 -j ACCEPT
#$IPT -A INPUT -i eth1 -p tcp --dport 53 -j ACCEPT

################################################################################
# Beetje inet in colo voor laptopje
################################################################################

## Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# And NAT everything from the local subnet(s) going out of eth1
#$IPT -t nat -A POSTROUTING -s eth0 -o eth1 -j MASQUERADE
$IPT -A POSTROUTING -t nat -o eth1 -j MASQUERADE

################################################################################
# trash opvangen

# alles dat nu nog wordt opgevangen loggen
LOG=no
if [ $LOG = yes ] ; then
  $IPT -A INPUT   -j LOG --log-prefix "filtered on INPUT "
  $IPT -A OUTPUT  -j LOG --log-prefix "filtered on OUTPUT "
  $IPT -A FORWARD -j LOG --log-prefix "filtered on FORWARD "
fi

#Portforwarding dat smtp ook draait op tcp/587 en tcp/2525
$IPT -t nat -A PREROUTING -s 0/0 -d 1.2.3.4 -p tcp --dport 2525 -j DNAT --to 1.2.3.4:25
$IPT -t nat -A PREROUTING -s 0/0 -d 1.2.3.4 -p tcp --dport 587 -j DNAT --to 1.2.3.4:25

#ssh
$IPT -A INPUT -m tcp -p tcp -s 5.6.7.8 --dport 22 -j ACCEPT
$IPT -A INPUT -m tcp -p tcp -s 1.2.3.0/24 --dport 22 -j ACCEPT

echo "ssh"

$IPT -N SSH
$IPT -N SSH-evil
$IPT -A SSH-evil -m recent --name badSSH --set -j LOG --log-level DEBUG --log-prefix "evil SSH user: "
$IPT -A SSH-evil -j REJECT

$IPT -A SSH -p TCP ! --syn -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A SSH -p TCP --syn -m recent --name badSSH --rcheck --seconds 600 -j REJECT
$IPT -A SSH -p TCP --syn -m recent --name sshconn --rcheck --seconds 60 --hitcount 5 -j SSH-evil
$IPT -A SSH -p TCP --syn -m recent --name sshconn --set
$IPT -A SSH -p TCP --syn -j ACCEPT


echo "done."

Als je dat niet verbose runned heb je een probleem op het laatste stukje:

code:

ssh
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
done.

Het enige andere probleempje met deze firewall is wanneer je vanbinnen naar buiten traced. Timeouts, dus waarschijnlijk limit ik ook nog iets teveel in icmp.

[Kippenijzer]

owkee, dan stel ik het anders, run het eens niet als script. Copy 1 voor 1 elke regel achter je command line, en voer die uit, en paste dan het geheel (commando's plus replies) hier. Al dat "echo ssh" boeit dus niet, even voor het debuggen geen script gebruiken aub.

[Tomsworld]

Kippenijzer schreef op maandag 22 augustus 2005 @ 13:38:
owkee, dan stel ik het anders, run het eens niet als script. Copy 1 voor 1 elke regel achter je command line, en voer die uit, en paste dan het geheel (commando's plus replies) hier. Al dat "echo ssh" boeit dus niet, even voor het debuggen geen script gebruiken aub.

Owkee

Ik neem mijn basis script tot het punt dat ik ssh wil blokken. (Eerst alles flushen en basis laden).

De lijnen met # zijn mijn command lines die zonder prefix het antwoord van het systeem.

De probleem regels:

1)

# iptables -A SSH-evil -m recent --name badSSH --set -j LOG --log-level DEBUG --log-prefix "evil SSH user: "
iptables: No chain/target/match by that name

2)

# iptables -A SSH -p TCP --syn -m recent --name badSSH --rcheck --seconds 600 -j REJECT
iptables: No chain/target/match by that name

3)

# iptables -A SSH -p TCP --syn -m recent --name sshconn --rcheck --seconds 60 --hitcount 5 -j SSH-evil
iptables: No chain/target/match by that name

4)

# iptables -A SSH -p TCP --syn -m recent --name sshconn --set
iptables: No chain/target/match by that name


Meer output krijg ik er niet uit

Als ik heel mijn firewall flush en alleen dat het ssh stukje uitvoer krijg ik ook deze fout. Ik zie alleen niet in welke chain ik zou ontbreken ?

[Kippenijzer]

En als je :

iptables -N SSH
iptables -L SSH doet

wat voor output geeft dat?

[it0]

MIsschien is http://www.nighttiger.ca/data/ iets voor in combinatie met http://www.nighttiger.ca/data/intruder wat automatische mensen banned voor een in te stellen periode die vervelend tegen je server doen. Hij checked ook je apache logs..

[Tomsworld]

Kippenijzer schreef op maandag 22 augustus 2005 @ 14:11:
En als je :

iptables -N SSH
iptables -L SSH doet

wat voor output geeft dat?

Na enkel het basisscript:

code:

# iptables -N SSH
# iptables -L SSH
Chain SSH (0 references)
target     prot opt source               destination

en met alles:

code:

# iptables -N SSH
iptables: Chain already exists
# iptables -L SSH
Chain SSH (0 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp flags:!SYN,RST,ACK/SYN state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            tcp flags:SYN,RST,ACK/SYN

[Kippenijzer]

Dan vrees ik eigenlijk tcoh dat "gewoon" je ipt_recent ontbreekt. Danwel niet geladen als module, of misschien geheel niet actief in je kernel. Welke kernel draai je btw?

[Tomsworld]

Owkee bedankt al ik zal het straks eens controleren. Het is nog een kernel in de 2.4.xx branch.

[Seth4Chaos]

Kippenijzer schreef op maandag 22 augustus 2005 @ 14:34:
Dan vrees ik eigenlijk tcoh dat "gewoon" je ipt_recent ontbreekt. Danwel niet geladen als module, of misschien geheel niet actief in je kernel.

hierop volgend: bestaat deze directory "/proc/net/ipt_recent" ?

of

staat deze regel in je kernel-config file

code:

CONFIG_IP_NF_MATCH_RECENT=y

die foutmeldingen klinken echt naar dat ipt_recent niet in je kernel zitten.

[Kippenijzer]

Lol, daar zeg je wat, zowaar dat ik die file gisteren nog heb gebruikt, hmm, niet aan gedacht dus

[Tomsworld]

Inderdaad ik had dus echt alle netfilter opties in mijn kernel behalve (ipt_recent.o) nu ff als module gecompiled en het werkt.

Waarschijnlijk is die optie recenter dan mijn oorspronkelijke kernel en heb ik altijd maar die config overgenomen.

Kortom het start nu zonder errors, hopelijk werkt het, de foutmelding van iptables zou wel een stuk duidelijker mogen.

Met dat script hier uit enkele posts hoger lijkt weinig te gebeuren, ga ff het 1e proberen.

Het werkt wel dat was op een niet comon poort.

[ Voor 18% gewijzigd door Tomsworld op 22-08-2005 21:39 ]