Bug in OpenSSH maakt brute-forcen wachtwoorden makkelijker

Een bug in OpenSSH maakt het mogelijk om, afhankelijk van de kwaliteit van de verbinding, duizenden loginverzoeken per minuut te sturen. Ook als het maximale aantal loginpogingen laag wordt ingesteld is dat mogelijk.

De kwetsbaarheid in OpenSSH maakt het veel eenvoudiger om ssh-servers te brute-forcen. De beveiligingsonderzoeker King Cope heeft het probleem ontdekt en details erover gepubliceerd op de oss-sec-mailinglijst.

Normaliter is het aantal loginpogingen op een OpenSSH-server beperkt en een beheerder van een server kan dat maximale aantal zelf verder verlagen. Dankzij de kwetsbaarheid is het aantal loginpogingen in de praktijk echter onbeperkt. De kwetsbaarheid is eenvoudig te misbruiken; er hoeft enkel een relatief simpel OpenSSH-commando te worden gebruikt.

Brute-forcing op OpenSSH-servers is al een groot probleem; vooral servers met simpele wachtwoorden vallen snel ten prooi aan aanvallers, die het internet scannen op kwetsbare servers. Beheerders van servers met een beveiligingscertificaat hoeven zich minder zorgen te maken. Er is nog geen patch voor OpenSSH doorgevoerd, al heeft de ontdekker wel al een patch geschreven.

Reacties (115)

King Cope had deze bug ook al op zijn blog geplaatst. Hij heeft nu gelukkig een CVE ingediend.
Link voor meer informatie over de bug: https://kingcope.wordpres...lity-maxauthtries-bypass/

Het gaat om het volgende commando, zoals King Cope beschrijft:

A simple way to exploit the bug is to execute this command:

ssh -lusername -oKbdInteractiveDevices=`perl -e 'print "pam," x 10000'` targethost

Update:
Deze aanval is getest op FreeBSD 10.1 en oudere versies zoals 6.2.
The attack has been tested against a new FreeBSD 10.1 system and older FreeBSD versions such as version 6.2.

Update 2:
TL;DR:
Waar 'KbdInteractiveAuthentication'' op value 'Yes' staat in SSHD, is kwetsbaar.

As for the fix: this is something the OpenSSH folks need to address, as it cannot be fully rectified otherwise. And to be clear: issue is not specific to FreeBSD, but applies to any OpenSSH setup (distro, etc.) where KbdInteractiveAuthentication defaults to yes in sshd; see sshd_config(5) for details.

Update 3:
En hier nog een heleboel informatie te vinden over de bug:
http://arstechnica.com/se...ers-to-password-cracking/

[Reactie gewijzigd door CyberDonky op 22 juli 2015 16:36]

Ok, dus als je KbdInteractiveAuthentication op 'no' hebt staan (of, als die niet ingesteld staat, 'ChallengeResponseAuthentication', zie http://manpages.ubuntu.co...y/man5/sshd_config.5.html ). Dan ben je niet kwetsbaar?

Volgens mij was dat standaard als zo op mijn debian omgeving.

Als ik die exploit (lokaal) uitprobeer, dan krijg ik een wachtwoord prompt.

Dus zo heel erg open is het allemaal dus niet?

Als ik die exploit (lokaal) uitprobeer, dan krijg ik een wachtwoord prompt.

Dat is het idee, dat commando omzeilt de beperking van het aantal loginpogingen, het logt niet voor je in. Je zal zelf nog moeten brute-forcen (met een script).

En dan is er gelukkig fail2ban of denyhosts wat een beetje beheerder standaard heeft draaien als er geen andere IDS/IPS oplossing in het netwerk staat.

Of de echte slimme beheerders zorgen dat je daarnaast kunt inloggen d.m.v. een authentication key i.p.v. een wachtwoord

Of, die slimme beheerders leunen niet op een ding, maar doen gewoon alles

GSSAPI + Pubkey only
fail2ban/denyhosts
IDS
IPS
Firewall met geografische blokkades als je daar toch geen verkeer van verwacht

je vergeet :
ssh op een andere poort dan 22 laten luisteren

True Maar dat is dan ook weer iets wat je niet altijd kan doen als er eisen zijn om default poorten aan te houden om dat andere mensen outgoing firewalls hebben

Bovendien biedt het geen enkele extra beveiliging. De meeste aanvallers doen toch eerst een poortscan en dan zijn ze er snel genoeg achter op welke poort je SSH server draait.

Het biedt geen beveiliging, maar de kans dat je server flinke hoeveelheden cpu resources aan SSH kwijt is door brute force aanvallen neemt enorm af.

Ik denk dat 't wel degelijk helpt...

Tuurlijk - dezelfde daemon met dezelfde kwetsbaarheden (if any) luistert nog steeds, maar deze is wel veel lastiger te vinden. Tegen een overheid-gesponsorde groep aanvallers zal het niet helpen, maar tegen script kiddies of gasten die voor de fun bezig gaan helpt het wel degelijk: die hebben geen tijd om ranges poorten te scannen om te zien of wellicht op een van die andere 65500 poorten een SSH daemon draait.

Iemand enig idee wat de impact voor gangbare Linux smaken is? Ubuntu of embedded smaken op Soynology NAS-en bijvoorbeeld?

Een scriptkiddie die gewoon alleen op poort 22 scant zal je met de standaard poort vinden en onnodig veel CPU resources vragen. Een scriptkiddie die specifiek jouw systeem wil aanvallen vindt de afwijkende poort wel.

Het zijn voornamelijk OpenWRT routers die ik op afwijkende poort instel, CPU resources van zo'n ding zijn vrij beperkt en SSH implementatie is ook vrij basic (dropbear is niet te vergelijken met OpenSSH). Als je dan een brute-force aanval over je dak krijgt gaat de snelheid van je internetverbinding gewoon omlaag.

Volgens mij scannen ze vaak alleen de eerste 2000 poorten of iets in die richting.
Een uitgaande firewall is vaak toch al een probleem als je naar iets anders wil verbinden dan http(s)

je bent port-knocking nog vergeten https://wiki.archlinux.org/index.php/Port_Knocking

Die kon ik nog niet, bedankt.

Dat heet security through obscurity (https://nl.wikipedia.org/wiki/Security_through_obscurity) en is geen beveiliging. Het is meer van 'wat niet weet, wat niet deert'. Dat is natuurlijk een gevaarlijke aanname, want je kunt in deze tijd niet verwachten dat een aanvaller niet weet te vinden op welke poort je de kwetsbare service hebt draaien.

[Reactie gewijzigd door dôh op 23 juli 2015 10:32]

Dat werkt alleen als je SSH alleen maar gebruikt voor beheerders. Als SSH ook door gewone gebruikersin een grotere organisatie nodig is betekend het dat je de hele dag bezig bent accounts te unbannen en uitzonderingen aan het maken voor bijvoorbeeld sales tijdens hun zakenreis door China.

Ja, maar dan ga je uiteraard niet heel China blokkeren he. Je weet over het algemeen wel vanaf waar mensen mogen inloggen. Stel dat je nooit personeel buiten je eigen land hebt zitten of nooit in China en Rusland, dan blokkeer je die lekker. Of heel Azie, Afrika en Amerika.

Lukraak wat random dingen blokkeren zou natuurlijk nergens op slaan. Je kan uiteraard wel altijd een jumpbox of gateway kunnen gebruiken voor dat soort landen, en dan wel alles blokkeren zodat je een buitenland-jumpbox hebt.

Maar op het moment dat je SSH door 'gewone gebruikers' laat gebruiken heb je volgens mij al geen doorsnee organisatie meer en kan je alles qua IT vast een stuk beter slijten aan het 'personeel' dan bij een organisatie waar 'de rest' niks weet van de hardware en software die ze dagelijks gebruiken.

Bijvoorbeeld een partij die shared hosting aanbiedt kan vaak moeilijk ssh blokkeren, je kunt daar dan wel met vpn gaan werken maar dat kom je bij de budget hosting omgevingen gewoonweg niet tegen. Dus ssh open, met password ipv pubkey, klanten genereren hun eigen passwords in het control panel (Plesk/Cpanel/DirectAdmin) en maar hopen dat het goed gaat.

Beste wat je dan nog kan doen is afdwingen dat een bepaalde sterkte password wordt gebruikt en iptables rules om een max aantal nieuwe connecties per x tijd toe te staan voor ssh.

Een hoster waar ik een tijdje gebruik van maakte, gebruikte whitelists voor IP's die verbinding mochten maken. Voor de gebruiker ook niet ideaal, maar je beperkt wel je risico's. Gebruikers konden dan zelf aangeven vanaf welke IP adressen ze SSH verbinding wilden maken.

Maar goed, ze draaien dan wel weer DirectAdmin over HTTP en niet via de secure versie

Of, die slimme beheerders leunen niet op een ding, maar doen gewoon alles

Slimme beheerders kijken naar het risico, de benodigde functionaliteit en de kosten.
Als bijvoorbeeld SSH enkel voor beheer gebruikt wordt is het veel handiger dit gewoon voor externe verbindingen te blokkeren en een VPN te gebruiken als je er voor beheer van buiten bij moet...

Dat is waar, maar hoe beheer je je VPN server van buiten af als VPN niet werkt?

En los daar van: hoe bescherm je je VPN?

Het is een oneindig probleem, je kan protocollen oneindig in 'veiligere' protocollen encapsuleren, maar aan het eind van de rit zal je je AAA toch ergens moeten managen en monitoren.

Private vlan voor beheer tussen kantoor lokatie en datacenter, dan heb je geen vpn nodig om in je management vlan te komen vanaf je kantoor.

Bij voorkeur zelfs alleen key-based logins toestaan en wachtwoorden helemaal verbieden. Je hebt altijd wel iemand die denkt dat "admin123" een sterk wachtwoord is of dat je best even een account met het wachtwoord "test" kan hebben.

Op mijn servers zijn wachtwoordlogins dus helemaal niet toegestaan.

Zwakke wachtwoorden zijn al lang geen excuus meer om password logins te verbieden, sterke wachtwoorden kun je gewoon afdwingen.
key-based logins zijn inderdaad veiliger, maar vaak ook een stuk minder gebruikersvriendelijk, vooral als men meerdere apparaten gebruikt.

sterke wachtwoorden kun je gewoon afdwingen.

Gewoon een minimum van 12 karakters, en geen gezeik over cijfers en speciale tekens graag...

Ik snap nooit welke idioot bedacht heeft dat "Welkom-01" een hogere score krijgt dan "Mhjvadtvdb" (*).

(*) Mieke hou je vast aan de takken van de bomen....

[Reactie gewijzigd door cdwave op 23 juli 2015 09:03]

Welkom-01 heeft een brute-force aanval nodig van 256 tot de macht 9 combinaties. = 4722366482869645213696

Mhjvadtvdb heeft een brute force aanval nodig van 52 tot de macht 10
combinaties. = 144555105949057024

Een cijfertje en een leesteken scheelt dus een hoop.

Nee hoor.

"Welkom-01" heeft maar 26^6 * 8 * 10^2 combinaties. De password policy zorgt ervoor dat iedereen een wachtwoord maakt in de vorm vann woord-met-hoofdletter, tekentje, volgnummer. Piece of cake om te raden met een dictionary attack.

Ik ben benieuwd hoe je op berekening 26^6 * 8 * 10^2 komt.

Wat is je formule erachter?

Welkom is inderdaad wel een dictionairy woord, maar als ik een wachtwoord echt MOET weten doe ik altijd brute force, want dat checkt alle combinaties. Ik ga er dan geen bibliotheek aan boeken tegenaan gooien. Dat kost immers meer tijd en moeite.

Maar gooi je "Mhjvadtvdb" maar eens in John the Ripper en geef aan dat het alleen letters zijn. Kan je zien hoe snel dat gaat.

> Ik ben benieuwd hoe je op berekening 26^6 * 8 * 10^2 komt

Die is ook niet correct omdat hoofdletters vergeten worden en er meer speciale karakters zijn, maar 't zou zijn 26 letters in 't alfabet (6x), 8 speciale tekens (!@#$%^&*) en dan getallen van 0 tot 9 (2x).

Maar iig, dat klopt dus niet.

Nu haal je er ineens een password policy bij die je vooraf niet vermeld hebt. Vreemd verhaal zo wat blijkbaar deels in jouw hoofd leeft en deels hier op tweakers staat.

Welk-om01 en daar gaat je formule

Oh, zo kwam die op die formule! Tja's dat zijn een hoop aannames..

https://xkcd.com/936/

Passphrases of gewoon zoals XKCD zegt 4 random woorden, makkelijk te herinneren en veilig.

En voor SSH gewoon key-based authentication (met een passphrase op de private key), zo lastig is het niet.

"c0rrect%hors3&b4ttery-stapl3" is nog steeds een zwaarder wachtwoord dan "correct horse battery staple".

En de mensen die in een kennis economie niet tikken kunnen, moeten maar op het land gaan werken, ofzo.

Vanwege het toegevoegde leesteken '-'

Jouw Mieke gebruikt alleen hoofdletters en kleine letters.
Welkom-01 gebruikt hoofdletters, kleine letters, leestekens en cijfers.

Qua brute force krijg je dus een veel groter aantal karakters wat je mee moet nemen in het genereren van een password.

[Reactie gewijzigd door mxcreep op 23 juli 2015 10:32]

Naieve aanname. Dat ik toevallig een liedje koos als basis wil niet zeggen dat ik geen cijfers had willen/mogen gebruiken. "1234hvhvp" is ook op een liedje gebaseerd.

Er zijn maar heel weinig leestekens, en slechts een stuk of vijf daarvan kun je zonder "shift" bereiken dus die worden bijna altijd gebruikt. Daardoor wordt het aantal mogelijke combinaties juist minder, want je weet op voorhand dat van de meestal 8 karakters er minstens eentje een teken uit die set van vijf gaat zijn, en er zit ook zeker een cijfer in waar er maar tien van zijn.

Huh? Je hebt geen shift toets op jouw keyboard? Ik snap deze beredenering niet. Je kan geen ~!@#$%^&*()_+ tikken?

Kan wel, maar is een toets extra, plus lastige vingerzetting.

Dus bij het intikken van een nieuw wachtwoord ga je niet snel voor de "@" of "+" maar eerder voor een "-" of ";", want dat typt veel sneller. Natuurlijk nogal generaliserend, mar als je een bedrijf met duizend accounts binnen wil komen, hoeft er maar eentje te zijn die aan de verwachtingen voldoet.

Het grote verschil zit hem in "toestaan dat leestekens gebruikt worden", wat het aantal mogelijke combinaties flink vergroot, en "verplichten dat tenminste een leesteken voor komt", wat het aantal mogelijke combinaties juist veel kleiner maakt.

Terugkomend op dat bedrijf met duizend werknemers, waarschijnlijk hebben tientallen werknemers vanwege de "strong password policy" een woord van vijf letters met als eerste een hoofdletter, een streepje, slash of punt, en dan een volgnummer van twee cijfers. Een dictionary attack heeft binnen een paar duizend pogingen wel een winnaar gevonden.

[Reactie gewijzigd door cdwave op 23 juli 2015 15:12]

Leuk verhaal.. Ik ben misschien beperkt in mijn visie door mijn type diploma. Ik tik dit ook terwijl ik niet naar het toetsenbord kijk. Waarom zou ik?

Maar goed, zelfs voor normaal personeel is het toch niet zo moeilijk een haakje of een % teken te doen? Dat is toch geen lastige vingerzetting? Het is niet alsof ik CTRL-BREAK met een hand probeer te toetsen.

En je aanvalsplan gaat ook voor de zwakste schakel. Ik vind root of Administrator password een stuk interessanter dan het wachtwoord van de receptioniste, die nergens in mag.

Hoezo naieve aanname ? Ik baseerde me puur op het gegeven voorbeeld, jij gaf zelf aan dat het je verbaasde dat de ene string sterker bevonden werd dan de andere.

https://xkcd.com/936/

Een woord uit het woordenboek met de eerste letter als hoofdletter + punctuatie + 2 getallen, minder veilig dan het voorbeeld in de xkcd zou ik zo zeggen

Ook 2 factor authentication is een mooie extra laag.
How To Protect SSH With Two-Factor Authentication

Dat is ook een van de standaard dingen die ik installeer naast de extra beveiligingen op mijn containers. Ik ben alleen bang dat de gemiddelde systeembeheerder deze code op zijn eigen smartphone zal zetten om zo het beheer in eigen hand te houden wat natuurlijk de normale gang van zaken is.

However, wat als deze systeembeheerder zijn telefoon verliest? Wat als de systeembeheerder hiervan geen backup heeft? Er zal een recovery plan moeten zijn, bovendien lijkt het mij niet echt een goede optie voor bijv. grote bedrijven omdat wanneer de medewerker uit dienst treed, hij nog steeds de tokens heeft en deze misschien vanwege redenen deze niet wilt overhandigen.

Kortom, niet voor alle zaken is dit geschikt imo. maar dat ligt natuurlijk aan de situatie en de omgeving waarin gewerkt wordt.

Bij het installeren krijg je een lijstje one-time codes, deze zou je offline in een kluis kunnen bewaren.

Your emergency scratch codes are:
30287010
70585905
68748337
15176712
38041521

Bij uit dienst treding kun je een nieuwe secret key genereren en de oude werkt dan niet meer.

Of combinatie van bijde voor het geval je je key een keer verliest
AuthenticationMethods publickey,password


AuthenticationMethods
Specifies the authentication methods that must be successfully completed for a user to be granted access. This option must be followed by one or more comma-separated lists of authentica‐
tion method names. Successful authentication requires completion of every method in at least one of these lists.

For example, an argument of “publickey,password publickey,keyboard-interactive” would require the user to complete public key authentication, followed by either password or keyboard inter‐
active authentication. Only methods that are next in one or more lists are offered at each stage, so for this example, it would not be possible to attempt password or keyboard-interactive
authentication before public key.

For keyboard interactive authentication it is also possible to restrict authentication to a specific device by appending a colon followed by the device identifier “bsdauth”, “pam”, or
“skey”, depending on the server configuration. For example, “keyboard-interactive:bsdauth” would restrict keyboard interactive authentication to the “bsdauth” device.

This option is only available for SSH protocol 2 and will yield a fatal error if enabled if protocol 1 is also enabled. Note that each authentication method listed should also be explic‐
itly enabled in the configuration. The default is not to require multiple authentication; successful completion of a single authentication method is sufficient.

[Reactie gewijzigd door Firedragon op 22 juli 2015 17:24]

Het helpt al een hoop om niet de default poort 22 te gebruiken.
Kwam er een tijdje terug dat mijn Raspberry Pi bestookt werd met (onsuccesvolle) login pogingen. Zelfs met root login verboden. De makkelijkste optie was om een andere poort te gebruiken. De scanners hebben sindsdien mijn SSH niet meer weten te vinden.
Scheelt al gauw 10MB aan logs per week (en zo'n 60.000 login pogingen per dag).

Dat gaat leuk worden als de opslagmedia waarop je de key opgeslagen hebt minder betrouwbaar blijken dan je in eerste instantie dacht

En dan is er gelukkig fail2ban of denyhosts

Helaas werkt dat nauwelijks tegen een botnet. Je moet gewoon zorgen dat je wachtwoorden niet te bruteforcen zijn.

Dat wil ik nou ook weer niet beweren. Stel je zet zoiets op een 3 maximale foute logins (moet voldoende zijn als je het toch weet). Bruteforce dus "a", "b", "c" zijn voorbij gekomen en je ip is geblocked. Dan moet je met je hele botnet communiceren dat deze drie geprobeerd zijn, waardoor de andere vervolgens met de rest verder kan. Dan heb je wel een gigantisch botnet nodig wil je hier wat mee bereiken, of je moet ervan uitgaan dat je gebruik kan maken van een dictionary maar dan nog heb je erg veel computers nodig. Daarnaast is er ook nog een username nodig. Zo eenvoudig is het zeker niet, maar dat neemt natuurlijk niet weg dat het wel een mogelijkheid is.

Ja maar een slimme programmeur doet dat op account niveau en dan mag je bijvoorbeeld 15 minuten niet inloggen op dat account ongeacht welke machine je gebruikt.

Pff, dan kan ik 3/4 van de dag niet op root, admin, chris, james inloggen, en nog wat andere Amerikaanse namen. Die worden de hele dag door gebruteforced door botnets.

"Gewoon zorgen"
Ja maar.. dat is hier het hele punt of niet dan?
Het is een imperfect systeem met imperfecte gebruikers. Als sysadmin ben je ervoor verantwoordelijk dat iedereen een goed ww maakt, maar, in de praktijk blijkt dat toch echt anders te liggen. Er is altijd wel weer een manier om het te kraken.
Zo zei een leraar tegen mij een flink aantal jaar terug: geen enkel systeem is niet te kraken want er is wel altijd een sleutel te vinden.

Moeilijker kunnen we het wel maken.

Voor ssh verbindingen moet je überhaupt geen login met wachtwoord toestaan. Ik gebruik zelf standaard public key authentication (is nog makkelijker en sneller ook ) i.c.m. een custom port.

daar hebben we hier CSF voor.
Deze blokkeert gewoon de ip adressen na 3 foute inlogpogingen ongeacht hoe de instellingen van ssl zelf zijn

Kun je die niet gewoon configureren als "totaal 5 ssh pogingen = block alles"?

Ja zeker. En hoe wil je dan zelf ooit nog ermee verbinding maken?

door te zorgen dat het IP wat je hebt in de allow list (whitelist) staat,

Mocht onverhoopt alle communicatie geblokkeerd zijn zo als je schetst dan heb je een backup nodig in de vorm van een drac/ilo en/of kvm over ip, of een toetsenbord en beeldscherm als de server binnen bereik staat.

dit zijn juist de zaken waar je van te voren over moet nadenken.

[Reactie gewijzigd door fvdberg op 23 juli 2015 10:04]

fail2ban, CSF/LFD, BPF en dergelijken zijn allemaal kwetsbaar voor logspoofing!
Die kan je beter niet gebruiken tenzij je de enige bent die op de server kan; je kan beter iets gebruiken dat direct inhaakt op PAM... In plaats van logs doornemen om te detecteren wat stoute persoontjes aan 't doen zijn.
Vooral fail2ban is dan lekker kwetsbaar, want die doet niet veel meer dan de logjes doornemen natuurlijk.

Als je Fail2Ban op je server draait, kan elk persoon met toegang tot je server via SSH of zelfs via Cron Jobs (denk aan een shared hosting server; cPanel met CSF bijvoorbeeld ook.) door middel van logspoofing ervoor zorgen dat je server zichzelf helemaal afsluit van het internet.
Daar heb je slechts een one-liner voor nodig die opeens een x aantal neppe log entries naar /dev/log flikkert; en klabam: Fail2Ban ziet het als legitiem probleem en stopt vervolgens de hele reeks die je spoofed in de ban... Waarmee je de server zichzelf dus kan laten null-routen.

De enige manier er omheen is door die functies uit te knallen: maar dan heeft je hele Fail2Ban ook niets meer om mee te werken... Erg fijn dus.
Zolang de developers dit niet oplossen zou ik me niet al te snel meer wagen aan dat soort spul.

(Incidentally; op cPanel is cpHulkd (wat echt verschrikkelijke software is, all-round) dus niet kwetsbaar want die werkt *wel* netjes met PAM )

[Reactie gewijzigd door WhatsappHack op 22 juli 2015 19:31]

Ik vind je bericht een beetje overtrokken. Als je met meerdere (untrusted) users te maken hebt moet je sowieso anders om gaan met je beveiliging. Key files in plaats van passwords bijvoorbeeld, dan heb je heel fail2ban niet nodig.
Elke internet facing server waar je alleen of met andere (al dan niet collega) beheerders op inlogt is prima gebaat bij Fail2Ban, zeker als je ssh op poort 22 wil blijven servicen want zonder word je gek van de botnets. Volgens mij is het leeuwendeel van de servers op internet alleen door beheerders te benaderen via SSH en werkt het dus over het algemeen prima. Of dat in specifieke gevallen ook zo is is aan de beheerder te beoordelen. Bij Fail2Ban is duidelijk na te gaan of het een goed idee is om het te implementeren of niet.

[Reactie gewijzigd door Anoniem: 80487 op 22 juli 2015 22:48]

Mja dat is een beetje stating the obvious: natuurlijk ga je anders om met beveiliging...
... Maar niet dusdanig anders dat je dus niet vatbaar bent voor dit probleem; tenzij je of alle diensten uitschakelt (en wat moeten die users dan uberhaupt op je systeem??) of je disabled gewoon de log toegang volledig: met de kantekening dat cron dus ook helemaal niets meer naar de logs kan schrijven. Dat kan ook weer problemen opleveren.

Het enige probleem is dus dat je verschillende usecases hebt waarbij password authentication gewoon mogelijk moet zijn; of daar het handigste is. Security vs usability.
En dat is ook prima mogelijk, mits je maar de juiste maatregelen neemt: en dus software gebruikt die niet vatbaar is voor spoofing.


Maar dat alles terzijde...
Een paar behoorlijk belangrijke aspecten die je denk ik over 't hoofd hebt gezien:
1.) Je hoeft niet per definitie in te loggen naar SSH om dit probleem te misbruiken.
2.) Het gaat helemaal niet uitsluitend om SSH, dus je kan wel leuk kijken naar enkel keyauth gebruiken, en dat kan je ook doen uiteraard; en ook SSH nog eens op een andere poort: helemaal prima... Maar dan zit je alsnog met het feit dat Fail2Ban niet uitsluitend SSH monitored en dus ook via diverse andere services een enorme flood aan bans kan veroorzaken als iemand die one-liner uitvoert. Of je nou alleen op de server zit of met meerdere, of je SSH nu op keys zet of niet: brute-force beveiliging is ook wel zo fijn op andere diensten dan uitsluitend SSH. ... En ook die zijn vatbaar voor dit probleem. Dus stel jij schakelt in Fail2Ban de SSH brute-force monitoring uit omdat je dat toch niet gebruikt, maar je monitored wel FTP en het script kidje propt "pure-ftpd" (voorbeeld) authentication failures in je logs in plaats van SSH: dan krijg je alsnog hetzelfde gelazer.
3.) Het hele punt is dat het geen echte authentication failures zijn, maar nep. Dat is waar spoofing voor staat. Dus zelfs als jij SSH dichttimmert, maar Fail2Ban monitored nog altijd (voor andere diensten, e.d.); dan kan je dus IP's spoofed bannen door naar de logs te schrijven.

En dan nog, en dit wordt een overdreven voorbeeldje: zelfs op een server waarbij je slechts met 1 user te maken hebt en je alles helemaal dichtgetimmerd hebt; enkel poort 80 en SSH op een random privileged port (die ontdekt kan worden via portscanning.) is in theorie beschikbaar voor het publiek want je wilt enkel een webservertje draaien en verder enkel zelf toegang... Dan NOG kan het een probleem zijn, omdat dit gelazer ook via PHP (hallo exploits.) te misbruiken valt. En ga zo maar door. Mits je Fail2Ban draait: uiteraard, dat staat voorop. Sure, als je alle poorten dichtgooit zul je het misschien niet nodig hebben; maar zelfs met een firewall die alle poorten dichtknalt (behalve voor bepaalde IP's) heb ik alsnog brute-force monitoring draaien... Je weet maar nooit. (Al gebruik ik dus andere software. )
Zeker als er meerdere beheerders zijn wil ik dit alsnog monitoren. Maar afijn.
Dit was dan ook slechts een zwaar overtrokken voorbeeldje om aan te geven dat het in allerlei scenarios dus een probleem is: zodra Fail2Ban draait en er draait een site op en/of er hebben meerdere users toegang: dan heb je dus een potentieel probleem, want dan ben je kwetsbaar voor deze aanval. Alle poorten dichttimmeren en dan nog Fail2Ban draaien zal idd lichtelijke paranoide zijn; maar er zijn er zat die alsnog een vorm van detectie draaien.

Bottom line: het is en blijft een probleem, hoe je er ook naar wilt kijken.
Tuurlijk zijn er een paar usecases waarbij dit totaal geen probleem zal zijn (en je Fail2Ban ook inderdaad wellicht niet eens nodig hebt); maar over het algemeen is brute-force detectie een behoorlijk belangrijke feature om op je server te implementeren, en daar zeg ik dus van: doe het dan wel goed, en met software die NIET vatbaar is voor log spoofing!
Vroeger of later levert het echt gezeik op, want die 'bug' wordt steeds vaker misbruikt.

Doe dus vooral wat je niet laten kunt, I'm just providing a fair warning.
Over het algemeen zal het ook niet super snel misbruikt worden, maar zeker op shared servers is het risico enorm hoog... En niet enkel met SSH.
Het is niet voor niets dat alle developers (die van Fail2Ban, die van CSF, die van APF, et cetera) stuk voor stuk allemaal waarschuwen dat dit een behoorlijk groot probleem is.

[Reactie gewijzigd door WhatsappHack op 22 juli 2015 23:40]

Fail2Ban monitored absoluut zeker wel alleen SSH als je dat als zodanig inricht. Additionele services moet je zelf configureren.
Als je keyauth gebruikt (en dus wachtwoorden uitzet) draai je overigens geen Fail2Ban want er is dan geen sprake meer van een brute force. (op de SSH service)

Exploits in software zijn verder altijd een probleem. In welke context dan ook. Dus als je via een of andere php exploit binnen komt is dat het probleem niet Fail2Ban's vatbaarheid voor logspoofing.

[Reactie gewijzigd door Anoniem: 80487 op 22 juli 2015 23:38]

Fail2Ban monitored absoluut zeker wel alleen SSH als je dat als zodanig inricht. Additionele services moet je zelf configureren

Ja als je dat als zodanig inricht, maar waarom zou je in hemelsnaam enkel SSH monitoren? o0

Als je keyauth gebruikt (en dus wachtwoorden uitzet) draai je overigens geen Fail2Ban want er is dan geen sprake meer van een brute force. (op de SSH service)

Het tussen de haakjes stukjes beantwoord eigenlijk de eigen opmerking al: als je dus niet uitsluitend SSH draait, en wel op brute-force controleert op andere services (wat een zeer groot aantal mensen doen; zeker gezien het aantal guides dat het heeft over "protect multiple services") dan heb je dus gewoon draaiend.

... En nogmaals: als je Fail2Ban geinstalleerd hebt staan terwijl je keyauth gebruikt (zullen er ook vast wel een aantal zijn ) dan nog is het een probleem.

Het is, hoe je het ook wend of keert, gewoon een probleem.
Je kan het wegwuiven, en dat mag je wat mij betreft ook doen; maar ontkennen dat het een probleem is heeft gewoon echt geen zin.

Exploits in software zijn verder altijd een probleem. In welke context dan ook. Dus als je via een of andere php exploit binnen komt is dat het probleem niet Fail2Ban's vatbaarheid voor logspoofing.

En als er een race condition in Apache zit die root access kan veroorzaken als iemand via een geexploite wordpress installatie een scriptje kan uitvoeren, dan is zeker ook het probleem niet dat Apache zo'n race condition kan veroorzaken: maar is het probleem dat Wordpress te kraken valt?

Natuurlijk is het een probleem!
Als software op de server met een super simpel commando'tje gewoon de server zichzelf kan laten DoS'en/hele IP reeksen in de ban kan gooien: dan is dat een behoorlijk probleem. o0

Ontken ik ergens dat die kwetsbaarheid bestaat dan? Ik vind slechts dat je het probleem groter maakt dan hij is.
Je formuleert je posts op een manier alsof het absoluut zeker een kutplan is om Fail2Ban toe te passen terwijl de werkelijkheid veel genuanceerder is.

waarom zou je in hemelsnaam enkel SSH monitoren? o0

Ik gebruik Fail2Ban puur en alleen om scriptkiddies en botnets van mijn SSH login af te houden en zo belasting van mijn server als gevolg daarvan in te perken. Het is niet persé een maatregel om te zorgen dat ze er niet in komen daar heb ik o.a. root login voor uitgeschakeld en exotische login variabelen voor aangemaakt.

[Reactie gewijzigd door Anoniem: 80487 op 23 juli 2015 00:07]

Ontken ik ergens dat die kwetsbaarheid bestaat dan? Ik vind slechts dat je het probleem groter maakt dan hij is.
Je formuleert je posts op een manier alsof het absoluut zeker een kutplan is om Fail2Ban toe te passen terwijl de werkelijkheid veel genuanceerder is.

Dan zullen we het oneens moeten zijn over hoe groot het probleem is.
Ik vind het een enorm probleem (maar ik werk dan ook bizar veel met shared servers, en slecht summier met prive server(tjes); dus wellicht kijk ik er anders tegenaan): en het is ook lang niet het enige probleem met logs... Maarja, de een kijkt wat anders tegen beveiliging en beveiliging tegen DoS aanvallen aan dan de ander; ik ben daar agressief in en wil het risico zeer strict beperken; jij bent daar kennelijk wat losser in: prima! Ieder z'n ding.

Dat tweede gedeelte is onzin, want ik beschrijf juist exact onder wat voor soort omstandigheden het 't grootste probleem is, en heb ook aangegeven op welke momenten het een veel minder groot probleem (maar nog steeds niet risico vrij...) is.
Heb duidelijk geschreven hier dat als het bijvoorbeeld een prive servertje is waar je in je eentje opzit: het probleem behoorlijk beperkt is en Fail2Ban prima kan helpen; dan weegt 't nadeel wss niet op tegen 't voordeel.

Ik gebruik Fail2Ban puur en alleen om scriptkiddies en botnets van mijn SSH login af te houden en zo belasting van mijn server als gevolg daarvan in te perken. Het is geen maatregel om te zorgen dat ze er niet in komen daar heb ik o.a. root login voor uitgeschakeld.

Dan zal je een van de weinigen zijn als je verder geen andere services monitored; en ben je dus kwetsbaar voor deze aanval...
Vooral op shared servers worden over het algemeen *alle* daemons gemonitored. En terecht. En shared hosting servers maken nu eenmaal een heeeeeel erg groot deel van het WWW uit: en daarom vind ik het dus een behoorlijk probleem.

[Reactie gewijzigd door WhatsappHack op 23 juli 2015 00:08]

en ben je dus kwetsbaar voor deze aanval...

Hoe? SSH is de service waar over gesproken wordt in dit nieuwsbericht. Dat is nou net de service die gemonitord wordt door Fail2Ban. Na 3 foute pogingen zit je in de firewall. (en ja ik sluit mezelf geregeld buiten, maar allicht heb ik meerdere wegen naar rome )

[Reactie gewijzigd door Anoniem: 80487 op 23 juli 2015 00:16]

Uhm, een van de eerste dingen die je voor fail2ban normaliter instelt is daarom toch juist "ignoreip"? Een simpele instelling waarmee je voorkomt dat je eigen ip(s) en bijvoorbeeld localhost gebanned worden.

Uiteraard houd je dan wel het issue dat op shared hosting mensen eenvoudig andermans ip kunnen blocken.
Gelukkig heb ik daar dan zelf weer niet mee te maken (alleen eigen servers).

En dat werkt fantastisch als je een statisch IP hebt. Ik zit bij Ziggo dus ik ga niet dat ding steeds updaten. Mezelf deblokkeren is niet zo moeilijk.

Uh, wat voor zooitje zou je dan moeten draaien als users naar /var/log/auth.log mogen schrijven? Verder kan fail2ban en ook denyhosts prima geconfigureerd worden om alleen naar PAM te luisteren via PAM module hooks in plaats van logs.

Dus kwetsbaar is vooral kwetsbaar in kwetsbare configuraties. Stel dat je kwetsbaar wil zijn, dan heb je nodig:

- Toegang tot de logs
- fail2ban of denyhosts met alleen log-checking
- geen fallback methodes (zoals een whitelisted gateway box ergens die niet door andere gebruikers beheerd worden)

Op dat moment heb je waarschijnlijk genoeg toegang om gewoon een iptables regel te maken waardoor je iedereen behalve je eigen IP blokkeert op poort 22. Of je zorgt dat alleen pubkey auth mag en stelt je AuthorisedKeys file in op een bestand waar alleen jij bij kan in plaats van de user-directory's .ssh map.

Met andere woorden: zo kwetsbaar is het nou ook weer niet.

Wat voor zooitje? Gewoon standaard Linux server met Fail2Ban?
Het gaat voornamelijk om de /dev/log functionaliteit, die je standaard gewoon hebt. Dat zit nu eenmaal zo in Linux ingebakken.
Fail2Ban leest ook van /var/log/messages, en daar kan je zonder pardon berichten in genereren.

Ik denk dat je het probleem ook verkeerd begrijpt.
Je hebt geen toegang tot de logs nodig als in "ik kan hem even met nano openen", maar je moet er enkel naar kunnen *schrijven*. En dat kan... Via de log socket.
Tuurlijk kan je vast wel weer met een plugin het een en ander wijzigen waardoor er totaal niet meer naar de logs gekeken wordt: maar dan zit je dus eigenlijk al niet meer echt met Fail2Ban te werken; en hoeveel mensen zullen dat nou doen...? Als jij 't al zo ingesteld hebt staan, zal je een van de weinigen zijn. Ook CSF heeft hier opties voor, maar dan werkt de brute force detectie niet meer naar behoren. (Lees: niet.)

Lees even dit verhaaltje van m'n vrinden bij Rack911:
http://www.webhostingtalk.com/showthread.php?t=1344458

Het gaat ook niet om servers waar slechts 1 gebruiker uberhaupt toegang heeft.
Als jij een prive servertje hebt waar niemand anders op inlogt, op welke wijze dan ook, dan boeit het allemaal vrij weinig. Maar zijn er meerdere users? Dan heb je dus al een probleem.

Fail2Ban is derhalve nog altijd kwetsbaar, dat zeggen ze zelf ook en vermelden daar ook doodleuk de "exploit" zelf bij:

Fail2Ban should not be run on systems which provide ssh/CGI/PHP services to unknown users without any level of trust. They might be able to block other users from ssh and probably other access with a call to logger. A malicious user may also write via PHP's openlog()/syslog() to syslog.
Logging systems supporting authentication (e.g. journal) might provide adequate resolution for this in the future.

Tenzij je bijvoorbeeld heel /dev/log afslacht; maar dat levert ook weer wat problemen op... Voornamelijk voor cron jobs van users kan dat bloedirritant zijn.
Het is een behoorlijke clusterf*ck.

[Reactie gewijzigd door WhatsappHack op 22 juli 2015 20:54]

daar heb je ip allow en deny lijsten voor om dat te voorkomen. ik vind je post daarom zwaar overtrokken . ik vraag me af of je wel eens met csf gewerkt hebt op een productieserver

[Reactie gewijzigd door fvdberg op 23 juli 2015 09:58]

Ik werk daar dagelijks mee, we beheren hier enorm veel servers die voorzien zijn van CSF.

Je snapt duidelijk het probleem niet; lees gewoon even de uitleg van RFX en van Chirpy (makes van CSF) zelf die dus precies onderschrijft wat ik zeg, dan begrijp je misschien waar het om gaat.

Maar meestal werken die op de hosts.allow file, en die staat een reeds in gang gezette verbinding niet in de weg. Dus dat betekent dat een aanvaller door deze bug in plaats van 3 pogingen wel tot 10.000 pogingen kan doen tot hij geblokkeerd wordt.

Ik ben blij dat ik RSA keys gebruik (op smartcard zodat die keys zelf ook niet te kopieren zijn)

In het geval van fail2ban niet, die maakt een rule aan in de interne firewall die meteen alle pakketjes voor die host niet meer door laat, ook actieve verbindingen komen niet door en openstaande sessies worden gesloten.

Aha dat wist ik niet, ik heb alleen ervaring met denyhosts. Die werkte destijds met hosts.allow. Ik dacht dat fail2ban ook zo werkte.

Tegenwoordig draai ik het niet meer omdat mijn servers toch geen paswoord authenticatie accepteren dus brute forcers worden meteen afgekapt. Het opzetten van hun verbindingen geeft wel wat 'achtergrondruis' vanwege de CPU overhead van de encryptie maar dat was me niet het gedoe waard om zo'n script te installeren.

Ik draai gewoon alles, dan heb je bij het falen van een systeem tenminste niet meteen een groot gat in je AAA zitten. Bovendien haakt fail2ban bijvoorbeeld lekker in op ELK als je wil weten hoeveel door je firewall regels toch nog binnen komt om daarna gebanned te worden. Kan je IP blokken en ASN's filteren

Klopt, deze tools blokkeren gewoon na een X aantal keer de complete connectie van het IP.

Waarom wordt port knocking nog niet standaard gebruikt of ten minste ondersteund?

Zoals deze bug maar weer laat zien zitten er gewoon bugs in de SSH server dus eigenlijk wil je gewoon voorkomen dat iemand zelfs maar kan zien dat er een SSH server draait.

Port knocking is niet echt een goede beveiliging. Het is heel makkelijk te sniffen omdat er niets ge-encrypt is.

Het is beter om gewoon goede authorisatie te gebruiken (public/private sleutels van goede lengte).

Port knocking is natuurlijk ook niet bedoeld als enige beveiliging maar als extra laag.
Goede sleutels zijn ook belangrijk maar bijvoorbeeld Debian had een paar jaar geleden per ongeluk slechte sleutels..

Als er via brute-forcing naar je wachtwoord wordt gezocht denk ik niet dat ze connecties naar jouw machine zitten te sniffen.

Het helpt dus zeker wel in dit geval.
Een andere poort dan 22 werkt ook om een hoop pogingen af te weren, aangezien je eerst een poortscan zou moeten doen, in plaats van domweg voor elke host poort 22 te proberen.

In de security community is men niet zo enthousiast over port knocking omdat het een vals gevoel van veiligheid geeft, het is security-through-obscurity.

Dat is het toch niet? Het is een extra shared secret en het is het drastisch verkleinen van het attack surface.

Zoals @GekkePrutser hier onder ook aangeeft, het is makkelijk te sniffen, en dus vatbaar voor man-in-the-middle aanvallen.

Is dat zo? Volgens mij zijn veel aanvallers helemaal niet in staat zoiets te sniffen, dan heb je toch tenminste toegang tot een deel van het netwerk nodig..

Het helpt inderdaad niks tegen aanvallers die wel de mogelijkheid hebben tot sniffen.

Mja, met SSH is 't wel zo fijn dat je eigenlijk overal kan inloggen omdat de wachtwoorden toch goed versleuteld worden uitgewisseld.
Op een openbaar WiFi netwerk in een kantoor ruimte (eg: seats2meet) lekker aan de snuif gaan met je laptopje en je weet vast wat te vinden. Dan helpt aankloppen niet meer.

Het zou vaker mogen worden ingezet maar het is vaak niet haalbaar.
Je moet namelijk op z'n minst een paar poorten op de router/firewall hier voor kunnen gebruiken. Dat is steeds lastiger in een wereld waarin steeds meer NAT wordt gebruikt.
Daarnaast zitten er veel mensen op beperkte netwerkjes. Bv in de trein if in een hotel. Daar kun je niet zomaar willekeurige poorten openen en een port-knock doen.

Waarom (hele verhaal)?
Misschien is port knocking niet de juiste term maar er kan toch gewoon een magic UDP packet (naar port 22 of een andere) gestuurd worden?

Dat de client achter NAT zit is irrelevant.

Ik had het over servers achter NAT of een corporate firewall, die zijn tegenwoordig heel normaal. Het is niet meer vanzelfsprekend dat iedere server direct toegang heeft tot een eigen IPv4-adres met 65K poorten. Dat die poorten ook nog bereikbaaar zijn voor alle clients is nog zeldzamer.

Magische UDP-pakketjes hebben het probleem dat ze door veel netwerken niet worden doorgegeven. In de zakelijke wereld eist men als snel dat systemen altijd bereikbaar moeten zijn, ook als je in een vage hotelkamer ergens in een Chinese achterbuurt zit (of dat ook verstandig is, is een andere discussie

Duizenden logins per minuut is toch helemaal niet zoveel? Ik heb het even gecheckt wat ik zelf gebruik voor m'n NAS: een wachtwoord van 9 karakters met per karakter 63 mogelijkheden. Dat is 1,56x10¹⁶ mogelijkheden. Als ik daarbij uitga van een bruteforcesnelheid van 10.000 wachtwoorden per seconde (dus niet per minuut zoals in het artikel wordt geschetst), dan duurt het maximaal 50.000 jaar voordat mijn wachtwoord geraden is.

Als dan root login ook nog uitstaat, moet je ook nog raden welke usernames er bestaan en bij welke username dit wachtwoord hoort.

iets wat trouwens meer en meer standaard is in distributies (gelukkig)

In Debian 8 nu voor het eerst default, maar met PermitRootLogin no heb je het zelf ook snel geregeld

Of je gebruikt gewoon enkel key authentication, hurr durr.

Jouw wachtwoord ja, maar er zijn ook mensen die een simpel wachtwoord hebben.

Als je nu nog een computer aan het internet hebt hangen met SSH en wachtwoorden kun je in elk geval wachten totdat je gehackt wordt. SSH beveilig je met public/private keys en je root account is geblokkeerd. En om bruteforcers dwars te zitten, stel je je firewall strak in en/of gebruik je fail2ban.

Het voordeel van FreeBSD is dan weer dat ssh root login default uit staat...
Neemt niet weg dat je een andere tool/firewall moet gebruiken om te blacklisten, maar zorgt in ieder geval voor dat je niet gelijk root bent

Toevoeging: als je PasswordAuthentication nog op yes hebt staan ( als je zelf om een of andere reden niet kan verplichten om keys te gebruiken ), dan is fail2ban in dit geval ook niet meer afdoende.
Fail2ban scant de logs en de bruteforcer is al binnen voor fail2ban kan ingrijpen...

Storm in glas water natuurlijk.

Zelfs met duizenden attempts per seconde duurt het nog steeds miljoenen jaren om binnen te komen. Eenvoudige verdediging is om je wachtwoorden met twee a drie karakters te verlengen, dat biedt voldoende compensatie want dat verhoogt de brute-force tijd al met een factor 1000.

Een systeem met een "standaard" wachtwoord is toch wel kwetsbaar, met of zonder deze bug. Als het aantal inlogpogingen significant invloed zou hebben op je veiligheid, dan moet je toch serieus aan andere dingen gaan werken.

Het is wel een effectieve manier om een DDOS aanval uit te voeren.

Zelfs met duizenden attempts per seconde duurt het nog steeds miljoenen jaren om binnen te komen.

Alleen als je uitgaat van sterke wachtwoorden. Het hele probleem is dat je dat als beheerder van een gedeelde server nooit volledig kunt afdwingen. Zodra men door deze bug vrij snel een dictionary attack kan uitvoeren zullen een aantal wachtwoorden sneller gevonden worden. Men moet ook nog de juiste username hebben, maar het gaat zeker niet om "miljoenen jaren", eerder om dagen/weken.

Gelukkig heeft Ubuntu iig al tijden standaard als setting:

PermitRootLogin without-password

Alle machines bij ons bedrijf hebben vaak een firewall voor SSH, maar die gene die toch aan het internet hangen hebben sowieso PasswordLogin op false staan.

Alles vind plaats door middel van public/private keys en nergens gebruiken wij password logins.

Brute forces wens ik iedereen dan ook veel success toe.

Leuk detail, wij hebben veel servers aan IPv6-only hangen en daar heb ik nog nooit een brute-force gezien. Even het internet scannen over IPv6 zit er ook niet in, dus daar ben je iig van botnets af.

Even het internet scannen over IPv6 zit er ook niet in, dus daar ben je iig van botnets af.

Dat zou ik niet zo hardop durven roepen. Het is simpelweg niet aantrekkelijk genoeg nu, wacht maar tot er meer ipv6 adoptie plaatsgevonden heeft.

Meer ipv6 adressen betekent ook meer potentiele botnet computing power.

Ik wel. Hardop. Scanning in IPv6 ruimte is volstrekt kansloos, zelfs in het kleinste uitgedeelde blok heb je nog 2^64 adressen. Dat zijn 18446744073709551616 adressen. Als je een /48 hebt (zoals ik en de meesten) wordt het 2^80 adressen, oftewel 1208925819614629174706176 adressen.

En als je de hele range wilt scannen... Tsja. 2^128. Volstrekt kansloos. Ook met alle computers die in IPv4 space bestaan. Dat heeft niets met al dan niet aantrekkelijk te maken, maar puur met de ontzettend grote hoeveelheid adressen.

Als je blind gaat scannen is dat waar, maar dat zou dom zijn. Voor SLAAC-adressen heb je wellicht gelijk, maar juist servers krijgen normaal gesproken een vast IPv6 adres. Die zijn niet willekeurig verspreid over het hele mogelijk spectrum maar blijken vaak in het eerste gedeelte van de toegekende range te zitten; omdat het makkelijk te onthouden is, omdat men een vergelijkbaar adres als van het IPv4 adres van de server wil gebruiken, etc.

In bedrijven blijken ook vaak VLAN nummers gebruikt te worden om een range te subnetten. Hieruit kun je ook weer aannames maken over de mogelijke/waarschijnlijke gebruikte adressen.

Stel je weet dat iemand het netwerk 2001:db8:a0b::/48 heeft. Dat lijkt een onoverkomelijke lijst adressen. Echter dan heb je een hoge kans op succes door de volgende adressen te scannen: 2001:db8:a0b:X::Y

X is hierbij een VLAN waarde, volgens Cisco waarschijnlijk tussen 1 en 1001.
Y is waarschijnlijk een getal tussen 0 en 255, omdat die range in IPv4 gebruikt werd.

Het aantal te scannen adressen in dit voorbeeld is te vergelijken met een 10.0.0.0/14 en dat is zeker haalbaar.

Zoals @daemonix al aan geeft, IPv6 scannen is compleet nutteloos en onhaalbaar.

Botnets moeten lijsten gaan bijhouden van welke adressen ooit gewerkt hebben, maar daar blijft het ook bij.

Mijn IPv6 thuis staat volledig open, succes met mijn Linux desktop en alle andere PC's vinden. Al geef ik je de /64, dan vind je ze nog steeds niet.

Ik heb fail2ban draaien die de ip's doorstuurt naar mijn firewall. De firewall maakt dan een rule aan om al het verkeer de blokeren van dat ip na 3 foute pogingen. De lijst begint al aardig lang te worden en de ip's zijn vaak uit de zelfde range...

Dat komt omdat er meestal een x aantal servers tegelijk worden geexploit binnen een bepaald segment van een netwerk; bijvoorbeeld Bedrijf A heeft in Rack CY t/m CZ 90 servers staan, die allemaal met bijv. puppet zijn opgezet en de beheerder dus overal dezelfde domme fout heeft gemaakt. Scriptje schrijven en voila, je voegt er weer 90 toe aan je botnet; voornamelijk binnen de range die dat bedrijf gebruikt.

En dan heb je ook nog dat er vaak per provider gescanned wordt, et cetera.
Niets mis mee.

Hou er wel rekening mee dat Fail2Ban zelf kwetsbaar is voor aanvallen; als je de enige bent met toegang tot de server is er geen probleem: is het een shared server, dan kan je het eigenlijk beter verwijderen en een betere oplossing zoeken die niet via syslog draait.

Of gebruik CSF (http://configserver.com/cp/csf.html).
Deze blokkeert ook (tijdelijk of permanent, wat jij wilt) IP's op basis van authenticatie failures op diverse services, waaronder SSH. Voordeel van CSF is dat je IP's kunt whitelisten, zodat deze nooit geblokkeerd worden.

CSF kan nog veel meer, maar je bepaalt zelf wat er wel of niet gebruikt wordt.

CSF heeft dezelfde zwakte, daarom bieden ze tegenwoordig die RESTRICT_SYSLOG functionaliteit aan. (Maar dan gaan je LF_* functies kapot.)

Het probleem met whitelists is dat er nog steeds een aantal issues zijn:
1.) Whitelisten van grote reeksen maakt de detectie waardeloos, omdat het toch nooit iets blokkeert
2.) Er kan nog steeds een DoS uitgevoerd worden, waarmee onder andere:
- Alle werkelijk bans geflushed kunnen worden als je deny_ip_limit redelijk hebt ingesteld
- Er kunnen grote reeksen worden toegevoegd aan de droplist, waardoor nog steeds een aantal partijen je server niet kunnen bereiken
3.) Het kan een mailflood veroorzaken

Helaas!

"Er is nog geen patch voor OpenSSL doorgevoerd"

Moet dat niet OpenSSH zijn?

For future reference:
Geachte Redactie
Zie "Feedback" knopje bovenaan artikelen.

Je moet ook geen wachtwoord hebben dat voor de hand ligt of uberhaubt voorkomen kan in een wordlist.