[iptables] SSH irritante wachttijd na reboot

[vanaalten]

Enige tijd geleden heb ik op m'n Debian (Sarge) linux server de ssh toegang wat beter beveiligd door maar een beperkt aantal connecties per minuut toe te staan. Gebruikte iptables regels:

code:

iptables -A INPUT --dst $LAN_IP -i $INTERFACE -m state --state NEW -p tcp --dport 22 -m recent --set
iptables -A INPUT --dst $LAN_IP -i $INTERFACE -m state --state NEW -p tcp --dport 22 -m recent --update --seconds 120 --hitco$
iptables -A INPUT --dst $LAN_IP -i $INTERFACE -m state --state NEW,ESTABLISHED,RELATED -p tcp --dport 22 -j ACCEPT

Dit werkt prima, maar heeft een nadeel: zo af en toe rommel ik wel eens wat met de server en is een reboot noodzakelijk (andere kernel, of zoals net, per ongeluk de stekker er uit getrokken). De server start dan wel goed op, alle services zijn volgens mij dan wel beschikbaar (IMAP en HTTP(S) doen het in elk geval), echter ssh-toegang is niet mogelijk. Ik gebruik PuTTY vanaf een windows-XP machine en die geeft een 'connection timed out' foutmelding. Pas na vijf a tien minuten kan ik voor het eerst weer via ssh naar binnen - en vanaf dan loopt het gewoon probleemloos.

Bijzonder irritant, want net na zo'n reboot wil je even via ssh wat dingen regelen en controleren.

Als ik er een 'gewone' iptables regel van maak heb ik hier geen last van:

code:

iptables -A INPUT -i $INTERFACE -m state --state NEW -p tcp --dport 22 -j ACCEPT

Mijn iptables kennis is beperkt, maar van wat ik in de documentatie heb doorgelezen lijkt het gewoon goed zoals ik het hierboven had beschreven. Via google hier niets over kunnen vinden (maar ik kon ook niet echt goede zoektermen bedenken).

Is dit irritante gedrag te voorkomen?

[Insanergy]

I don't have a solution... but I do admire the problem.

Misschien kan je een andere beveiliging nemen tegen die ssh attacks ?
Fail2Ban of DenyHosts

[marko77]

ik zou je ssh daemon sowieso niet op port 22 zetten, dan heb je al een _stuk_ minder pogingen van derden tot inloggen e.d. Users beperken die in mogen loggen is ook aan te raden.

Of je bovenstaande al hebt gedaan kan ik niet opmaken uit je TS maar ik denk dat het al een stuk beter is dan alleen de max. connecties in een bepaalde periode die jij hanteert helemaal omdat je er toch ook wat problemen mee hebt.

[ Voor 7% gewijzigd door marko77 op 16-04-2006 22:27 ]

[Badger]

right, security by obscurity?

Toegang per user/group restricten
Toegang restrictie per IP
Geen root toegang etc etc.

Nog meer ideeen tegen brute force attempts:
http://forums.gentoo.org/...light-ssh+bruteforce.html

Uit de wiki waarnaar gelinked wordt vanuit de start post:

I tried iptables' --hitcount option too ( read here (http://www.debian-administration.org/articles/187) on how to use it) - but it just doesn't work properly. I get unknown delays using that method for IP addresses not exeeding that limit. It would be a good solution to prevent a DoS attack.

[ Voor 44% gewijzigd door Badger op 16-04-2006 22:56 ]

[Guru Evi]

Probeer eens het volgende:

code:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -p tcp --dport 22 -j ACCEPT
#Eerst het Established, Related traffic afhandelen, moet ie niet door alle rules heen
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
#Dan zien we dat elk pakkettje gemarkeerd wordt
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 120 --hitcount 2 -j REJECT --reject-with icmp-port-unreachable
#2/120s is de rate limit. 
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
#Accept wat doorgekomen is

Een andere oplossing (proper) is een nieuwe chain te gebruiken, zodanig moet niet voor elk pakketje nagekeken worden of de regel kan toegepast wordt:

code:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -p tcp --dport 22 -j ACCEPT
#Eerst het Established, Related traffic afhandelen, moet ie niet door alle rules heen
iptables -N mylimit
#Definieer de chain 
 iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j mylimit 
#Laat alle nieuwe pakketjes door de chain gaan
 iptables -A mylimit -m recent --update --seconds 120 --name floods --rsource -j REJECT --reject-with icmp-port-unreachable 
#Reject wat reeds in de lijst staat
 iptables -A mylimit -m limit --limit 2/min --limit-burst 3 -j RETURN
#Laat 2/min toe en een burst van 3
 iptables -A mylimit -m recent --set --name floods --rsource -j REJECT --reject-with icmp-port-unreachable 
#Reject wat nog doorgelopen is

Zoals je ziet gebruik ik geen interface of ip-addressen. De reden hiervoor is: gelijk waar het vandaan komt, elk verkeer voor poort 22 is gevaarlijk en je kunt geen enkele host vertrouwen als het op root-access aankomt. Daarnaast heb ik al eens meegemaakt dat sommigen IP-addressen veranderen, interfaces wisselen en nog zo van die leuke (waardoor intern opeens extern wordt volgens de regels) en vergeten de firewallrules aan te passen waardoor het opeens allemaal geblokkeerd wordt of helemaal niet meer beveiligd is.

[Olaf van der Spek]

Sir_Floppy schreef op zondag 16 april 2006 @ 22:39:
Geen root toegang etc etc.

Dat is toch ook security by obscurity?
Gewoon met SSH keys in plaats van passwords inloggen lijkt me veilig genoeg.

[ Voor 18% gewijzigd door Olaf van der Spek op 17-04-2006 16:58 ]

[Wirehead]

OlafvdSpek schreef op maandag 17 april 2006 @ 16:55:
[...]

Dat is toch ook security by obscurity?

Nee, da's gewoon een harde lock erop Zo ben je al veel minder gevoelig voor zulke attacks. Natuurlijk moet je dan geen usernames met simpele passes gebruiken.

[B-Man]

Hmmm, ik gebruik deze methode ook, in combinatie met het enkel kunnen inloggen met SSH keys. Ik heb echter nog nooit last gehad van timeouts of vertragingen.

Welke iptables en SSH server/client draai je?

[vanaalten]

Even wat reacties beantwoorden:

• natuurlijk kan ik op een andere tcp-poort zitten, daar gaat het even niet om;
• rate-limiten vind ik zelf een fraai systeem om te gebruiken;
• zoiets als 'fail2ban' en dergelijke voelt voor mij wat minder fraai aan; iets dat logfiles doorspit en iptables regels toevoegt voelt aan als 'ballast'. Nu weet ik precies wat en hoeveel iptables regels ik heb en dat vind ik wel een prettig idee.
• Overigens hebben we het hier over een hobby-systeempje met slechts 1 user waar weinig waardevols te halen valt. Het systeem kent geen website met bezoekers dus ik heb hooguit te maken met incidentele bots. Even snel teruggekeken in de logfiles: sinds 19 maart heb ik *geen* ssh login pogingen van onbekenden gezien, daarvoor heb ik geen logfiles van. Laten we security dus vooral niet overdrijven.
• Root login van buitenaf sowieso al niet toegestaan; verder geen ssh toegang met passwords, alleen public/private key access. Qua veiligheid zit het hier denk ik wel goed, vind het gewoon leuk om met dit soort dingen bezig te zijn en te snappen.

@Guru Evi: ik heb je iptables regels (eerste voorbeeld) overgenomen; ik snap je redenering waarom een interface of ip-adres specificeren niet verstandig is. Echter heb ik ook hierbij het effect dat na een reboot het een aantal minuten duurt voor ik weer kan inloggen.
Het tweede voorbeeld heb ik niet geprobeerd - het aantal keren inloggen per dag is zo weinig dat een extra chain aanmaken mij niet de moeite waard lijkt.

Nogmaals wat documentatie doorgelezen en m'n oog viel op de volgende optie:

code:

iptables -Z INPUT

voor het resetten van de counters van de INPUT chain. Helaas, geen effect.

@B-man: Debian Sarge, kernel 2.6.8-16sarge2, OpenSSH_3.8.1p1. Ik heb het zowel met PuTTY als met een RedHat Linux ssh-commando vanaf m'n werk.

Het lijkt er vooralsnog dus op alsof ik niets fout doe en er gewoon mee zal moeten leren leven. Paar minuten geduld hebben na een reboot dus...

[daft_dutch]

ssh op een andere poort wat een dome reactie.
doe eens telnet 127.0.0.1 22
dan zie je dood leuk een text van ssh.
Een beetje aanvaller/worm heeft echt wel een portscanner

[Guru Evi]

Doe eens "iptables --version", "uname -a", "lsmod" en "iptables -nvxL" en post de resultaten eens. Ik heb ook nog nooit gehoord van een vertraging door iptables, staat er iets in je logfiles (/var/log/messages, dmesg)?

Daarnaast: doet het probleem zich alleen voor als je gereboot hebt, of iedere keer je iptables rules opnieuw geladen worden?

code:

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F
iptables -X
iptables -Z
/etc/init.d/iptables restart #zie je distro docu voor de locatie van je script

Daarnaast heb ik het volgende in mijn iptables scripts staan (Debian) welke alles opkuist en een iets snellere doorvoer van mijn pakketjes geeft:

code:

echo "Cleaning up..."
ipt -F
ipt -Z
ipt -X
ipt -F -t nat
ipt -Z -t nat
ipt -X -t nat
ipt -F -t mangle
ipt -Z -t mangle
ipt -X -t mangle

echo "Starting..."
ipt -P INPUT DROP
ipt -P FORWARD DROP
ipt -P OUTPUT DROP
ipt -t nat -P PREROUTING ACCEPT
ipt -t nat -P POSTROUTING ACCEPT
ipt -t nat -P OUTPUT ACCEPT
ipt -t mangle -P PREROUTING ACCEPT
ipt -t mangle -P OUTPUT ACCEPT
ipt -t mangle -P INPUT ACCEPT
ipt -t mangle -P FORWARD ACCEPT
ipt -t mangle -P POSTROUTING ACCEPT

echo "Activating loopback traffic..."
ipt -A INPUT -i lo -s 127.0.0.0/8 -j ACCEPT
ipt -A OUTPUT -o lo -d 127.0.0.0/8 -j ACCEPT
echo "Reconfiguring TCP/IP stack..."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
echo "0" > /proc/sys/net/ipv4/tcp_timestamps
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects
echo "0" > /proc/sys/net/ipv4/tcp_ecn
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
echo "0" > /proc/sys/net/ipv4/conf/all/secure_redirects
# Recommended:
# 128 MB of RAM -> 8192 possible entries, 256 MB of RAM --> 16376 possible entries
# Change if necessary
echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo "10" > /proc/sys/net/ipv4/tcp_fin_timeout
echo "1800" > /proc/sys/net/ipv4/tcp_keepalive_time
echo "0" > /proc/sys/net/ipv4/tcp_window_scaling
echo "0" > /proc/sys/net/ipv4/tcp_sack
echo "15" > /proc/sys/net/ipv4/ipfrag_time
echo "2048" > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo "32768 61000" > /proc/sys/net/ipv4/ip_local_port_range
echo "2" > /proc/sys/net/ipv4/tcp_synack_retries
# Increase the amount of memory associated with input and output socket buffers
echo "262144" > /proc/sys/net/core/rmem_default
echo "262144" > /proc/sys/net/core/rmem_max
echo "262144" > /proc/sys/net/core/wmem_default
echo "262144" > /proc/sys/net/core/wmem_max

echo "Blocking traffic with weird TCP flags..."
ipt -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
ipt -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
ipt -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
ipt -A INPUT -p tcp --tcp-flags ALL FIN -j DROP
ipt -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
ipt -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
ipt -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
ipt -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
ipt -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
ipt -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP
ipt -A INPUT -p tcp --tcp-option 64 -j DROP
ipt -A INPUT -p tcp --tcp-option 128 -j DROP

ipt -t nat -A POSTROUTING -o $EXTIFACE -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ipt -t nat -A POSTROUTING -o $EXTIFACE -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128

En deze zijn de modules die ik laad:

ip_tables iptable_filter iptable_mangle iptable_nat ipt_TOS ip_nat_irc ip_nat_ftp ip_conntrack_ftp ip_conntrack_irc ipt_limit ipt_state ipt_LOG ipt_MASQUERADE

[ Voor 139% gewijzigd door Guru Evi op 18-04-2006 00:30 ]

[B-Man]

Hmmm, ik draai op iptables v1.2.9, OpenSSH_3.9p1, en kernel 2.6.9, alles zelf gecompileerd.

De van toepassing zijnde delen uit mijn firewall script:

code:

#!/bin/sh
# Begin /etc/init.d/firewall
#

# source /etc/init.d/functions

# Set up some global vars
FWVER=1.0
EXTIF="eth0"
IPTABLES=/usr/sbin/iptables
GREP=/bin/grep
AWK=/bin/awk
UNIVERSE="0.0.0.0/0"

# Process user input
case "$1" in
        start)

#
# Start the firewall
#
        echo "Starting Firewall v$FWVER ..."

        echo " > setting default policy to DROP..."
        $IPTABLES -P INPUT DROP
        $IPTABLES -P OUTPUT DROP
        $IPTABLES -P FORWARD DROP
        echo " > flushing all rulesets..."
        $IPTABLES -F INPUT
        $IPTABLES -F OUTPUT
        $IPTABLES -F FORWARD
        if [ -n "`$IPTABLES -L | $GREP drop-and-log-it`" ]; then
           $IPTABLES -F drop-and-log-it
        fi

        echo " > flush all user chains..."
        $IPTABLES -X
        echo " > reset all counters..."
        $IPTABLES -Z
*knip*
        $IPTABLES -A INPUT -i $EXTIF -p tcp --dport 22 -m state --state NEW -m recent --set
        $IPTABLES -A INPUT -i $EXTIF -p tcp --dport 22 -m state --state NEW -m recent --update \
                --seconds 300 --hitcount 3 -j DROP
        $IPTABLES -A INPUT -i $EXTIF -p tcp --dport 22 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
*knip*

Verder denk ik niet dat je 'er mee moet leren leven'. Ik zelf ben allergisch voor dit soort verschijnselen, het moet gewoon een reden hebben.
Ik zou proberen het probleem middels eliminatie op te lossen:
- Wat gebeurt er als je enkel default ACCEPT draait, en de bekende drie regels?
- Wat gebeurt er als je een nieuwere iptables draait?
- Wat gebeurt er als je een nieuwere kernel draait?
- Wat gebeurt er als je een nieuwere OpenSSH draait?

Voor hetzelfde geld loop je tegen een 'bug' in iptables, OpenSSH of PuTTy aan.

[ Voor 20% gewijzigd door B-Man op 18-04-2006 15:26 ]

[vanaalten]

Als eerste even een bedankje voor alle suggesties tot nu toe. Ik ben het wel met B-man eens, ook al probeer je er mee te leven, het blijft toch knagen...

Maar goed, het probleem is nog niet opgelost:
@Guru Evi:
Probleem heb ik echt alleen na een reboot. Als ik als root vanaf de command line het script start kan ik probleemloos direct erna met ssh inloggen.

In /var/log/messages en /var/log/dmesg kan ik geen aanwijzingen vinden. Enkel dat iptables gestart wordt en conntrack/ipt_recent geladen worden.

Versies:
Kernel 2.6.8 (om precies te zijn, 2.6.8-16sarge2)
OpenSSH_3.8.1p1
iptables 1.2.11
lsmod:

code:

Module                  Size  Used by
ipt_recent             11148  2 
via_agp                 9056  1 
agpgart                34600  1 via_agp
eth1394                21576  0 
via_rhine              22120  0 
mii                     5024  1 via_rhine
ohci1394               35492  0 
ieee1394              111256  2 eth1394,ohci1394
nls_iso8859_1           4032  1 
nls_cp437               5696  1 
vfat                   14656  1 
fat                    46016  1 vfat
vt1211                 18308  0 
i2c_sensor              2880  1 vt1211
i2c_isa                 1984  0 
i2c_core               24176  3 vt1211,i2c_sensor,i2c_isa
8250_pnp                8384  0 
8250_pci               17984  0 
8250                   21152  2 8250_pnp,8250_pci
serial_core            23648  1 8250
ipt_state               2080  4 
ipt_conntrack           2688  0 
ip_conntrack_ftp       72368  0 
ip_conntrack           35296  3 ipt_state,ipt_conntrack,ip_conntrack_ftp
ipt_limit               2528  0 
ipt_multiport           2048  0 
ipt_REJECT              6880  1 
iptable_filter          2880  1 
ip_tables              18368  7 ipt_recent,ipt_state,ipt_conntrack,ipt_limit,ipt_multiport,ipt_REJECT,iptable_filter
snd_via82xx            28644  0 
snd_ac97_codec         69988  1 snd_via82xx
snd_pcm_oss            55080  0 
snd_mixer_oss          20096  1 snd_pcm_oss
snd_pcm                98728  2 snd_via82xx,snd_pcm_oss
snd_timer              25732  1 snd_pcm
snd_page_alloc         11752  2 snd_via82xx,snd_pcm
snd_mpu401_uart         7968  1 snd_via82xx
snd_rawmidi            25124  1 snd_mpu401_uart
snd_seq_device          8200  1 snd_rawmidi
snd                    56388  9 snd_via82xx,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_mpu401_uart,s
nd_rawmidi,snd_seq_device
longhaul                8080  0 
ide_cd                 42336  0 
cdrom                  40700  1 ide_cd
sd_mod                 19040  2 
usb_storage            68992  1 
scsi_mod               84096  2 sd_mod,usb_storage

iptables -nvxL:

code:

Chain INPUT (policy ACCEPT 14261 packets, 1897575 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
     242    19560 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state RELATED,ESTABLISHED 
      21     1260            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state NEW recent: SET name: DEFAULT side: source 
      20     1200 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state NEW recent: UPDATE seconds: 120 hit_count: 2 name: DEFAULT side: source reject-with icmp-port-unreachable 
       1       60 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state NEW 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 15783 packets, 2390061 bytes)
    pkts      bytes target     prot opt in     out     source               destination

---

@B-Man:
Nieuwere versies van kernel/iptables/openssh installeren is vooralsnog geen optie. Ik draai Debian stable (Sarge), voel er niets voor om naar testing of unstable te gaan.

Ik heb wel even je suggestie geprobeerd om m'n iptables script te minimaliseren:

code:

iptables -A INPUT  -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT  -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -A INPUT  -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 120 --hitcount 2 -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT  -p tcp --dport 22 -m state --state NEW -j ACCEPT

... da's alles wat ik er nu in heb staan. Misschien relevant om te melden hoe ik dit opstart:
In /etc/network/interfaces definieer ik het volgende:

code:

auto eth0
iface eth0 inet static
pre-up /etc/iptables.scr
up route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
down route del -net 224.0.0.0 netmask 240.0.0.0 dev eth0
address 192.168.1.3
netmask 255.255.255.0
gateway 192.168.1.1
broadcast 192.168.1.255

Met een pre-up activeer ik bovenstaande iptables script.
(de extra 224.0.0.0 routes zijn er pas recent bijgekomen, het ssh-probleem had ik daarvoor al)

Ofwel, de default policy is ACCEPT (getest, na een reboot is in elk geval de http-port bereikbaar) en alleen de ssh-port wordt nog door iptables gereguleerd. Het resultaat is in elk geval nog hetzelfde: enkele minuten wachten voor ik kan inloggen.

PuTTY kunnen we in elk geval uitsluiten: ik heb het ook vanaf m'n werk als ik met OpenSSH 3.6.1 probeer in te loggen.

Zonder die regels met ratelimiting krijg ik in elk geval meteen toegang in plaats van die paar minuten wachttijd, dus dat dat de oorzaak is lijkt mij wel waarschijnlijk. Ik heb echter nog niet echt een goed idee van die precieze wachttijd - die is volgens mij eerder rond de vijf minuten dan die 1 a 2 die je zou kunnen verwachten. Ik weet ook niet of het doen van een mislukte inlogpoging nog invloed heeft op de wachttijd.

Iemand nog suggesties? Misschien dat ik anders de iptables mailing list maar eens ga aanschrijven, daar zit mogelijk nog wat meer iptables specifieke kennis.

Edit:
nog twee testen gedaan:

1. iptables script met die vier regels van hierboven, maar dan de derde (die het feitelijke reject-werk doet) uitgecommentarieerd. Resultaat: geen wachttijd voor het inloggen - eigenlijk wat ik had verwacht.
2. iptables script met die vier regels van hierboven, maar niet automatisch na booten laten starten. Reboot, zonder wachttijd mocht ik inloggen (zoals verwacht). Handmatig iptables script opstarten, niets aan de hand, mocht gewoon doorwerken. Exit ssh-sessie - en jawel, daarna mocht ik weer een tijdje niet inloggen.

Ofwel, na een reboot staat er ergens een soort van 'vlaggetje' omhoog waardoor m'n iptables script de eerste keer een paar minuten ssh-toegang weigert. Zodra het 'vlaggetje' weg is blijft het gewoon goed werken.

Waar moet ik het zoeken?

[ Voor 7% gewijzigd door vanaalten op 18-04-2006 18:34 ]

[Verwijderd]

Ik weet helaas geen antwoord op je vraag, wel heb ik nog iets leuls voor je om eens te gaan overwegen.... portknocking!

dmv iptables zet je ssh toegang (poort 22) dicht.
nu draait er een daemon (knockd) die een reeks poorten in de gaten houdt op activiteit. Jij steld bv in dat zodra jij dmv een portknock client poort 9000, 7000, 5000, 8000 (in die volgorde) aanklopt er een iptable regel in komt dat ssh wél toestaat. Zo kan je lekker werken op de box. verlaat je de box weer, doe je deze;fde combinatie aankloppen alleen in reverse order en de ssh poort wordt weer dichtgegooid.

Dit is natuurlijk een voorbeeld alles is anders in te stellen en volgens mij kan je ook dmv een timeout de poort vanzelf weer laten dichtgooien.

[B-Man]

@vanaalten: wat gebeurt er als je de hitcount verhoogt?
Het is maar een gokje, maar dat is het enige duidelijke verschil in het script. (Naast een andere hoeveelheid tijd dat iemand geblokkeerd wordt, resp. 2 en 5 minuten).

[vanaalten]

B-Man schreef op woensdag 19 april 2006 @ 17:58:@vanaalten: wat gebeurt er als je de hitcount verhoogt?
Het is maar een gokje, maar dat is het enige duidelijke verschil in het script. (Naast een andere hoeveelheid tijd dat iemand geblokkeerd wordt, resp. 2 en 5 minuten).

Ik heb het ook even geprobeerd met jouw instellingen, maar dat maakt geen verschil.

Het lastige is dat het moeilijk goed meetbaar is (oh, en frustrerend werk is...): volgens mij wordt de wachttijd beinvloed door inlogpogingen.
Gisteravond en vanochtend wat testen gedaan. Bijvoorbeeld om 22:30 kwam na een reboot alles weer op. Vanaf toen om de 30 seconden geprobeerd in te loggen (seconds=120, hitcount=5, dus dat zou nog net mogen - ik zat ook iets ruimer dan die 30 seconden). 11 minuten lang lukte het niet om in te loggen. Toen ruim twee minuten gewacht en ik kon direct inloggen.

'seconds' eens op 15 gezet en na een reboot nog eens om de 30 seconden geprobeerd in te loggen. Mocht weer niet, na een paar minuten weer ruim twee minuten gewacht en toen mocht het ineens wel.
Overigens heb ik ook wel gehad dat ik ruim twee minuten wachtte en dat ik toen ook nog niet mocht inloggen, dus heel duidelijk is het allemaal niet.

Hitcount experiment... wel eens blackjack gespeeld?
Hitcount op 50: direct inloggen na reboot.
30... direct inloggen na reboot.
20... wachttijd na reboot (al had ik het idee dat het minder streng was dan bij hitcount=5

Uiteindelijk ligt de magische grens op 21: met hitcount=21 heb ik geen inlogvertraging.
Vaag, heel vaag.

Overigens vind je wel dingen op internet dat die 'recent' module al niet helemaal foutvrij is (iets met jiffies en overflows van 32-bits getallen en zo). Ook iets van dat de kernel na een reboot zo staat ingesteld dat die jiffies-counter na ruwweg vijf minuten voor het eerst over de kop gaat. Ik dacht nog even dat het daar aan zou kunnen liggen, maar die wachttijd is soms minder dan 5 minuten.

[B-Man]

@vanaalten: Als het constant _wel_ werkt met hitcount=21, dan heb je je probleem nu in ieder geval 'opgelost'. Mogelijk is dit probleem in een nieuwere kernel opgelost, aangezien ik er geen last van heb?
Ik heb ook een gelezen dat ipt_recent nog niet helemaal foutvrij is, maar heb er zelf nog niets van gemerkt.

[vanaalten]

Tja, opgelost... een hitcount van 21, dat geeft een potentieele aanvaller wel wat meer kansen dan je 'm gunt. In elk geval moet ik de tijd dan wel flink wat hoger zetten.

Als ik komende dagen wat meer tijd heb ga ik het even in de iptables mailinglist gooien - eens kijken of daar mensen bekend zijn met het probleem en een oplossing weten.
Het lijkt mij dat er na een reboot ergens iets opgeslagen is waardoor de boel geblokkeerd wordt - als ik weet *waar* dat is kan ik het na een reboot misschien eerst even wissen.

Mocht ik meer weten, dan laat ik het hier wel weten!