Gelukkig staan op de meeste servers van enige relevantie de optie PasswordAuthentication op "no" en zet men dan PubkeyAuthentication op "yes" wat behalve veel veiliger ook veel handiger is. En dan maar hopen dat de private sleutel netjes met een wachtwoord of pin beveiligd is.

Joep, dan heb je de private sleutel in de functie van een user/password (iets wat je weet) opgeslagen op je eigen machine. Je hebt eigenlijk een trust gedefinieerd tussen die twee. Veel veiliger?
- je geeft zelf al aan zodra de private key lekt ben je het haasje.
- komisch: het is het zelfde argument wat je kan gebruiken om sterke passwords, functioneel overeen komend met een private key, geen change policies op los te laten. Zeg je nu dat het eens bent met die stelling?
- Bij privilege escalation, (let op: dat is een functioneel process), dan is er de vraag van hoe dat technisch in te vullen. Het ganbare is sudo, maar wat als je x11 nodig hebt, wat dan?

Overigens maakte ik me over de bug in het artikel niet zoe druk. Om brute force aanvallen te ontmoedigen is tijd de belangrijkste factor. Als je zorg dat elke inlog (zeker de foute) een minimale acceptabele tijd duurt, neem iets tussen de 1-5 secondenn dan is het nog alleen een kwestie van monitoring. Zoiets kan je op vele manieren doen, (ergens afdwingen).

Publickey authentication aan. Probleem opgelost toch. poort 22 alleen openzetten naar de IP's die je ook gebruikt. Sowieso een rare gewoonte om poort 22 maar open te zetten naar de hele wereld. Dan komen de scanners iedere minuut al 20x langs. En als dat dan al moet om wat voor een reden dan ook doe er dan iets fail2ban achtigs voor heb je er ook geen last van. Minor bugje wat mij betreft.

Nee, beiden aan is de oplossing, niet het een of het ander ...

Dat ligt eraan waar je gebruikers zitten. b.v. het populaire GitHub heelt ook poort 22 open naar de gehele wereld. Soms ontkom je er niet aan.

Fail2ban is een enorm zware oplossing, er hangt een python script aan je sshd logs dat bij ieder bericht dat naar het log geschreven wordt actief wordt, met als gevolg dat als je echt door een massieve brute force aanval van een botnet getroffen wordt, je systeem op load 100 gaat en je in feite gewoon gedost wordt.

Iptables biedt modules waarmee je fail2ban-achtige functionaliteit in de kernel kunt laten afhandelen dmv. een paar firewall regels, en dat gaat vele malen effectiever om met je resources. Met de ipset module kun je eenvoudig banlists implementeren (zelfs met tijdelijke bans), en met de recent module kun je herhaalde toegang op poorten detecteren. Combineer de recent module met stateful firewalling en je telt alleen nieuwe toegangspogingen tot bepaalde poorten, en combineer dat met de ipset module om ip's die dat te vaak doen automatisch te bannen.

Met een beetje nadenken en de manuals lezen kun je zo in 3 firewall regels je ssh-poort in-kernel laten bewaken. Hark dan nog eens 1x per dag met een cronjob over de sshd logs heen om de paar vissen die door het firewall-net geglipt zijn te vangen en je zit minstens net zo safe als met fail2ban, maar dan met een systeem dat ordes van grootte minder resources gebruikt en met 1 of 2 firewall regels ook voor andere services te gebruiken is.

Staat er ergens beschreven hoe je dit met iptables kan doen. Ik ben wel geintresseerd. welke 3 iptables regels zijn nodig en hoe moet het log worden geparsed.

Ik heb een bash script geschreven dat het opzetten van de firewall-regels zowel voor ipv4 als ipv6 automatiseert, en een systemd service script om de boel te activeren en te deactiveren, het installeren kost wel wat handarbeid want de scripts zijn niet gepackaged.

Als er belangstelling voor is dan publiceer ik de scripts, maar zoals gezegd vergt het wel wat handarbeid om het aan de praat te krijgen.

Het parsen van de logs is op zich niet ingewikkeld, je zoekt met een regex naar regels met "Invalid user" en onthoudt het sshd pid-nummer van die melding, zoekt verder totdat je een "Received disconnect from" melding met hetzelfde sshd-pid gevonden hebt (dat is de volgende regel in de log) en onthoudt dat ip. Als je op die manier een ip meer dan 3x tegenkomt dan ban je het (door het ip met het ipset commando toe te voegen aan de blacklist die het bovengenoemde script opzet).

Het parsing script publiceren heeft niet veel zin omdat dit veel te specifiek is voor mijn situatie (er worden nog veel meer services gecontroleerd).

goeie tips. zet ook altijd password auth uit, poort nr wijzigen en gebruik CFS (config server).
ben ook benieuwd naar de regels en log parse waar anoniem het over heeft. thx

Ik heb het script op pastebin gezet.

1) Plaats dit script http://pastebin.com/m3DWnfyt in je /usr/local/libexec/ directory. Dit is een sysv init script dat alle zware firewall-werk automatiseert.

2) Plaats dit script http://pastebin.com/HERDK6rn in je /etc/systemd/system/ directory. Dit is het systemd script dat systemd vertelt hoe om te gaan met het bovenstaande init script.

3) Maak in de /etc/sysconfig/ directory een bestandje genoemd banlist.conf en zet daar je eigen TRAPS en PORTS specificatie in (zie het eerste script). Een trap specificatie bepaalt hoeveel hits per hoeveel seconden er mogen plaatsvinden in een bepaalde controleketen, en een port specificatie verbindt die controleketen aan een of meerdere poorten.

In het script zijn standaard 3 traps aangemaakt, een ssh trap die 4 hits per 10 minuten toestaat, een bt (bittorent) trap die 20 hits per 20 seconden toestaat en een scan trap die 3 hits per minuut toestaat. In het script zijn 4 ports gemaakt, de ssh trap wordt verbonden met poort 22/tcp, de bt trap met poort 6881/tcp en met 6881/udp en de scan trap met alle andere open poorten. Deze specificaties zijn uiteraard te overriden in je eigen conf bestand.

4) Installeer de iptables ipset en xt_recent modules.

5) Maak met firewall-cmd of met iptables en ip6tables voor zowel ipv4 als ipv6 een chain aan die INPUT_ban heet en jump vanuit de INPUT chains naar de zojuist gemaakte chains. Zorg ervoor dat je de jump plaats na de regel waarin RELATED en ESTABLISHED packets worden geaccepteerd, maar voor de regels die poorten openzetten voor services.

6) Typ "sudo systemctl enable banlist" in de console om te zorgen dat de autobanner automatisch start bij het booten van het systeem.

7) Typ "sudo systemctl start banlist" om de autobanner nu te starten.

8) Neem eventueel ipv4 ip's en netblocks die je nooit wilt bannen op in de whiitelist ipset en ipv6 ip's en netblocks in de whitelist6 ipset.

Klaar! (hoop ik)

Het script zorgt ervoor dat zowel de whitelist, de blacklist als de tijdelijke banlist reboots overleeft. Door deze lists als ipsets te implementeren kunnen er miljoenen ip's aan deze lijsten toegevoegd worden zonder dat dit het systeem ernstig belast. Ook de firewall configuratie is niet erg belastend voor het systeem (veel minder dan fail2ban).

Ik vond pam_abl wel handig, maar die wordt niet meer ondersteund geloof ik?

Het slechte nieuws: het is geen bug in OpenSSH, maar een reeks van dommiteiten van FreeBSD en OSX.

1 Het blijkt dat er geen begrenzing binnen de genoemde OS'en op herhaalde wachtwoord reeksen.
2 Ondanks de waarschuwingen is FreeBSD (en blijkbaar OSX) niet over op een vertragend algoritme voor password hashes (zoals bcrypt).(dus de herhaalde tests kunnen op maximum snelheid worden doorgevoerd)
3 Ondanks herhaalde waarschuwingen is het gebruik van het ontzettend complexe PAM gebeuren nog steeds heel populair. PAM ligt ten grondslag aan de problematiek bij FreeBSD.
4 en tenslotte FreeBSD gebruikt slechte defaults.

Het OpenSSH project kan geen rekening houden met alle varianten van operating systems en de eventuele slechte keuzes die daarmee samenhangen.

http://comments.gmane.org/gmane.os.openbsd.misc/223677

Vooral de uitgebreide reactie van Theo de Raadt is to-the-point.

Dat gedeelte van zijn argumentatie is nu juist een cirkelredenering (of een sales pitch). PAM is de standaard manier om met authenticatie om te gaan in de Unix-wereld en als je als De Raadt/OpenBSD besluit om het anders te doen met BSD Auth van BSD/OS dan moet je niet doen alsof de rest van de Unix-wereld rare gekkies zijn met hun PAM-gebeuren en dat je met zoiets exotisch geen rekening houden kunt.

Veel meer to the point is het dat het specifiek de FreeBSD implementatie van PAM is die problemen veroorzaakt (terwijl b.v. OpenSSH + Linux PAM geen problemen geeft). En ja, PAM is een vreselijk complex onding, maar dat is nu het issue niet, het issue is dat er zo snel mogelijk een lek in de authenticatie gefixt worden moet en daarbij helpt "alle PAMs moeten oprotten uit Unix-land"-politiek bedrijven geen moer.

PAM is niet 'de standaard manier om met authenticatie om te gaan'. Iedere unix heeft zijn eigen methode.

En zoals je zelf al constateert: de grootste groep van openssh+pam heeft er geen last van. Fix het probleem aan de bron: FreeBSD (items 1, 2 en 4) en ga niet lopen vitten dat openssh voor een kleine groep moet worden aangepast omdat zij hun zaakjes niet op orde hebben. Het is geen probleem van OpenSSH, het is een probleem van FreeBSD.

En ter aanvulling: http://bsdly.blogspot.ca/2015/07/the-openssh-bug-that-wasnt.html en http://it.slashdot.org/story/15/07/25/0146204/the-openssh-bug-that-wasnt

Storm in een FreeBSD glas water. Geen bug in OpenSSH.

SysV:
AIX -> PAM
Solaris -> PAM
HP-UX -> PAM
IRIX -> PAM
UnixWare -> PAM

BSD:
FreeBSD -> PAM
NetBSD -> PAM
Dragonfly -> PAM
SunOS -> PAM
Darwin -> PAM
BSD/OS -> BSD Auth
OpenBSD -> BSD Auth
Ultrix -> BSD Auth

Aix PAM + LAM Loadable Authentication Module google IBM.

Kuch! maar een "Storm in een FreeBSD glas water. Geen bug in OpenSSH."

OpenSSH heeft een "feature" die het mogelijk maakt om heel veel inlogpogingen tegelijk te doen........ PAM is heel erg snel...... rara waar ligt het probleem?

Scripts als hierboven doen daartegen geen barst, ik zie tien log pogingen per uur met steeds nieuwe IP adressen die max twee keer achter elkaar gebruikt worden. Slechts 1 Pam error per keer en Denyhosts schrijft iedere keer 17, steeds bijna dezelfde, URLs naar de logfile....