Openssh :bannen op naamreeks

[Boudewijn]

Jaja vage titel.

Ik heb een stel dozen met SSH open aan het net hangen, en ik draai daar scripts als denyhosts en fail2ban enzo op. Gaat hardstikke prima.

Nu zie ik echter dit verschijnsel optreden op een van mijn machines (primaire mailserver, vrij belangrijk ding):

code:

Dec 10 20:48:57 calzone-mail sshd[41565]: error: PAM: authentication error for illegal user lavina from ppp-70-226-82-138.dsl.klmzmi.ameritech.net
Dec 10 20:54:05 calzone-mail sshd[42280]: error: PAM: authentication error for illegal user lavina from host87-163-static.30-87-b.business.telecomitalia.it
Dec 10 21:08:44 calzone-mail sshd[44199]: error: PAM: authentication error for illegal user lavinia from 200141223106.user.veloxzone.com.br
Dec 10 21:13:52 calzone-mail sshd[45173]: error: PAM: authentication error for illegal user lavinia from 124.42.124.87
Dec 10 21:18:40 calzone-mail sshd[45680]: error: PAM: authentication error for illegal user lavonn from 89-96-172-100.ip13.fastwebnet.it
Dec 10 21:28:41 calzone-mail sshd[46977]: error: PAM: authentication error for illegal user lavonn from n219076222027.netvigator.com
Dec 10 21:33:52 calzone-mail sshd[47682]: error: PAM: authentication error for illegal user lavonne from ex216126.uac63.hknet.com
Dec 10 21:38:43 calzone-mail sshd[48391]: error: PAM: authentication error for illegal user lavonne from 23.red-80-24-4.staticip.rima-tde.net
Dec 10 21:43:42 calzone-mail sshd[49268]: error: PAM: authentication error for illegal user lavonne from 88.red-80-34-55.staticip.rima-tde.net
Dec 10 21:48:39 calzone-mail sshd[49825]: error: PAM: authentication error for illegal user lawanda from 188-120-207-85.vychcechy.adsl-llu.static.bluetone.cz
Dec 10 21:53:54 calzone-mail sshd[50499]: error: PAM: authentication error for illegal user lawanda from ppp-69-217-30-214.dsl.applwi.ameritech.net
Dec 10 21:58:39 calzone-mail sshd[50864]: error: PAM: authentication error for illegal user lawanda from 189.17.23.210
Dec 10 22:03:30 calzone-mail sshd[51374]: error: PAM: authentication error for illegal user lawrence from 84.123.175.87.dyn.user.ono.com
Dec 10 22:08:36 calzone-mail sshd[51866]: error: PAM: authentication error for illegal user lawrence from 179.26-246-81.adsl-static.isp.belgacom.be
Dec 10 22:18:39 calzone-mail sshd[52893]: error: PAM: authentication error for illegal user lawrencia from 194.224.118.61
Dec 10 22:23:36 calzone-mail sshd[53438]: error: PAM: authentication error for illegal user lawrencia from 207-250-220-196.escient.com
Dec 10 22:28:42 calzone-mail sshd[53775]: error: PAM: authentication error for illegal user lawrencia from 213.136.105.130
Dec 10 22:33:39 calzone-mail sshd[54296]: error: PAM: authentication error for illegal user lawson from 218.108.238.140
Dec 10 22:38:46 calzone-mail sshd[54813]: error: PAM: authentication error for illegal user lawson from n219076222027.netvigator.com
Dec 10 22:49:28 calzone-mail sshd[55995]: error: PAM: authentication error for illegal user layla from 121.138.216.194
Dec 10 22:53:45 calzone-mail sshd[56357]: error: PAM: authentication error for illegal user layla from 200.248.82.130
Dec 10 22:58:42 calzone-mail sshd[56720]: error: PAM: authentication error for illegal user layla from 170.56.255.20
Dec 10 23:03:43 calzone-mail sshd[57285]: error: PAM: authentication error for illegal user layne from 58.196.4.2
Dec 10 23:08:49 calzone-mail sshd[57851]: error: PAM: authentication error for illegal user layne from mvx-200-196-50-26.mundivox.com
Dec 10 23:18:42 calzone-mail sshd[58847]: error: PAM: authentication error for illegal user lazar from 88.red-80-34-55.staticip.rima-tde.net
Dec 10 23:28:40 calzone-mail sshd[59750]: error: PAM: authentication error for illegal user lazar from 53.red-80-38-150.staticip.rima-tde.net
Dec 10 23:38:31 calzone-mail sshd[60721]: error: PAM: authentication error for illegal user lazaro from 207-250-220-196.escient.com
Dec 10 23:43:42 calzone-mail sshd[61207]: error: PAM: authentication error for illegal user lazaro from 169.red-80-32-193.staticip.rima-tde.net
Dec 10 23:53:31 calzone-mail sshd[62414]: error: PAM: authentication error for illegal user lazarus from 207-250-220-196.escient.com
Dec 10 23:58:24 calzone-mail sshd[62783]: error: PAM: authentication error for illegal user lazarus from 121.33.199.39

De hosts gaan ook voor een maandje de banlijst in na 2 foute pogingen (jaja straf beleid), maar het is hier duidelijk te merken dat het 1 georganiseerde(re) attempt is vanaf verschillende IPs.

Nu heeft deze machine maar 1 user die alleen met een pubkey in kan loggen (daarom neem ik hem ook als voorbeeld) maar ik heb ook machines waar ik users op heb die ik niet aan de pubkey krijg (fact of life, kan ik niet veranderen).

Nu is dit soort aanvallen niet geweldig efficient, maar het zijn er wel *veel*, en ze volgen een duidelijk patroon.
Weet iemand of ik daar wat leuks mee kan gaan doen qua banning?
IK draai zowel debian (nepfilter) als freebsd (pf).


Het is nu vrij rustig maar met 2000 attempts per uur (daar zitten een aantal machines ruim boven ) worden mijn logs er niet leesbaarder op.

[Tofu]

Ik kan de thread niet direct meer terugvinden, maar op dit forum heb ik dezelfde "attack" al zien langskomen.
De gemakkelijkste oplossing is SSH gewoon op een andere poort draaien (<5000).
Natuurlijk dan nog steeds in combinatie met fail2ban en dergelijke..

[maxjuh]

Ben bang dat het enigste wat je kan doen (wat je ook al doet) is inderdaad bannen na 2 foutieve pogingen en de pubkey (maar ja niet iedereen wil daar dus aan beginnen). Je zou natuurlijk nog een andere port kunnen gebruiken voor SSH maar daar komen de botnets dan ook wel weer achter via een portscan.

Achtergrond ruis van het internet noem ik dit.

[Verwijderd]

maxjuh schreef op donderdag 11 december 2008 @ 00:14:

Achtergrond ruis van het internet noem ik dit.

Juist. En fgrep -v is dus je vriend.

[Equator]

Opties:
Configureer je sshd dat er slechts 1x per minuut ingelogd mag worden. Dat zorgt er wel voor dat ze dit minder vaak kunnen proberen. Stopt het probleem niet, maar helpt wel.

quote: http://www.openbsd.org/cg...0&manpath=OpenBSD+Current

MaxAuthTries
Specifies the maximum number of authentication attempts permitted
per connection. Once the number of failures reaches half this
value, additional failures are logged. The default is 6.

MaxSessions
Specifies the maximum number of open sessions permitted per net-
work connection. The default is 10.

MaxStartups
Specifies the maximum number of concurrent unauthenticated con-
nections to the SSH daemon. Additional connections will be
dropped until authentication succeeds or the LoginGraceTime ex-
pires for a connection. The default is 10.

Alternatively, random early drop can be enabled by specifying the
three colon separated values ``start:rate:full'' (e.g.
"10:30:60"). sshd( will refuse connection attempts with a
probability of ``rate/100'' (30%) if there are currently
``start'' (10) unauthenticated connections. The probability in-
creases linearly and all connection attempts are refused if the
number of unauthenticated connections reaches ``full'' (60).

Configureer de pam login module met de mogelijkheid dat de gebruiker in een lijst van geautoriseerde gebruikers moet zitten. (iets in de richting van: in-list /etc/myalloweduserlist)
Dit zorgt ervoor dat het gehele login-deel al niet meer gebeurt als ze een user gebruiken die niet in de lijst staat. (En natuurlijk staat root niet in die lijst)
Misschien moet je hiervoor een aparte login.pam module voor maken, als je de bestaande login pam module nog voor andere zaken gebruikt.

Combinaties met hosts.allowed e.d. maken het een vrij secure geheel.

[ Voor 47% gewijzigd door Equator op 11-12-2008 09:49 ]

[Verwijderd]

Deze aanvallen hebben totaal geen zin als je keys gebruikt. Voor users die inloggen met een wachtwoord is dit een ander verhaal. Ik raad daarom sterk af om ssh te gebruiken zondder keys. Bij mij in de organisatie is het zelfs verboden.

Mocht je toch te maken hebben met users die om wat voor reden dan ook niet aan de keys te krijgen te zijn dan zou ik kiezen voor een oplossing via Pam:

pam-shield

of

pam-abl

[Verwijderd]

Equator schreef op donderdag 11 december 2008 @ 09:43:
Configureer de pam login module met de mogelijkheid dat de gebruiker in een lijst van geautoriseerde gebruikers moet zitten. (iets in de richting van: in-list /etc/myalloweduserlist)
Dit zorgt ervoor dat het gehele login-deel al niet meer gebeurt als ze een user gebruiken die niet in de lijst staat. (En natuurlijk staat root niet in die lijst)

Dit kan ook met het AllowUsers statement in je sshd config:

AllowUsers
This keyword can be followed by a list of user name patterns,
separated by spaces. If specified, login is allowed only for us-
er names that match one of the patterns. Only user names are
valid; a numerical user ID is not recognized. By default, login
is allowed for all users. If the pattern takes the form US-
ER@HOST then USER and HOST are separately checked, restricting
logins to particular users from particular hosts. The allow/deny
directives are processed in the following order: DenyUsers,
AllowUsers, DenyGroups, and finally AllowGroups.

[Equator]

Verwijderd schreef op donderdag 11 december 2008 @ 10:15:
[...]


Dit kan ook met het AllowUsers statement in je sshd config:
[...]

Dat klopt, maar als je dit via pam doet, kom je dus niet tot aan de sshd, maar wordt je er al eerder vanaf gekeild

Het is een soort trapje

iptables
hosts.allow/deny
pam
service

(lijstje onder voorbehoud)

Hoe eerder je zoiets stopt, hoe beter.

[icyx]

Equator schreef op donderdag 11 december 2008 @ 10:53:
[...]

Dat klopt, maar als je dit via pam doet, kom je dus niet tot aan de sshd, maar wordt je er al eerder vanaf gekeild

Het is een soort trapje

iptables
hosts.allow/deny
pam
service

(lijstje onder voorbehoud)

Hoe eerder je zoiets stopt, hoe beter.

Kijk, ik heb geen idee hoe dit via PAM moet, maar is het niet alsnog verstandig om het op deze manier te configureren, al is het alleen maar om 'erbij' te hebben? Als er toch maar een user op kan inloggen, met keys, dan is het iets wat je instelt, en klaar. Mocht, om wat voor reden dan ook, PAM falen, dan heb je altijd de service zelf ook nog, die daar ook nog op checkt. En het zit niet in de weg natuurlijk, die extra 2 lines configuratie.

[Equator]

Helemaal mee eens..

Alleen moet je daar of de zelfde file voor gebruiken (indien mogelijk) anders heb je dubbel werk..

[begintmeta]

Equator schreef op donderdag 11 december 2008 @ 09:43:
Opties:
Configureer je sshd dat er slechts 1x per minuut ingelogd mag worden. Dat zorgt er wel voor dat ze dit minder vaak kunnen proberen ...

Dit is wel een lekkere ingang voor denial-of-service natuurlijk.

Positieve toegangslijsten en verbieden van wachtwoordlogins lijkt me beter.

[Boudewijn]

Ja dat kan dus nou net niet.
Ding moet wel bereikbaar zijn voor 'goede' users. Passwords kan ik niet verbieden en ook niet een vast ip per user. Andere poort idem, maar helaas.

User die xs moeten hebben krijgen een AllowUsers directive over het algemeen.

grep -v is een betje onhandig; het haalt ook veel nuttige meldingen weg.

[Verwijderd]

Moeten er veel mensen via SSH inloggen op je servers? Wat ik altijd doe is een iptable rule aanmaken waarmee slechts enkele ip adressen kunnen inloggen via SSH.

[Boudewijn]

True, maar dat geef ik net aan. Ik weet niet waar ze vandaan gaan inloggen, vandaag hier, morgen daar.

[Keeper of the Keys]

Ik gebruik op een van mijn machines port-knocking en ben daar zeer tevreden over...
Mensen die port-scannen zien helemaal niet dat de machine ssh draait alleen voor mensen die zich eerst identificeren foor de juiste poorten met de juite flags etc. te 'kloppen' zet knockd/iptables 22 open.
In mijn logs zie ik sindsdien geen enkele poging om te brute forcen meer.

Je kunt op zich ook met One time knocks werken (net als One Time Passwords), je kunt unieke knocks hebben per user, je kunt of instellen dat ze ook weer moeten knocken om de firewall dicht te laten gaan of juist dat na periode X na de succesvolle knock de firewall weer dicht gaat.

Voor zover ik weet is het helaas niet mogelijk op het moment om die timeout af te laten hangen van netwerk activiteit....

Een potentieel nadeel is dat er (voor zover ik weet) geen knock client is voor windows, maar als je simpelere knock hebt (alleen maar poorten en niet specifieke tcp vlaggen en andere dingen) dan kun je waarschijnlijk ook succesvol kloppen met telnet (al kan ik me voorstellen dat dat flink irritant is)...

offtopic:
@Equator
Zou je niet juist via sshd bij PAM terecht komen?
Alle PAM enabled login 'deamons' praten met PAM, maar op zich komt jou aanmelding van gebruiker X toch eerst bij sshd die dat dan doorgeeft (en dan zou die dus lochischerwijs eerst de UserAllowed variable kunnen nalopen....

[Verwijderd]

Ik moet zeggen ik vind dit wel een heel aardig programma. Geschreven in C dus lekker snel En met aardig wat voordelen ten op zichte van vergelijkbare tools.

http://sshguard.sourceforge.net/

Advantages over similar tools

Many tools exist with the purpose of mitigating the problem of brute force login attacks against a SSH server. Sshguard appears superior to all of them (to all whose I know of) when summing up the features:

There is some functional difference from other tools to sshguard:

* it supports whitelisting
* it supports IPv6 natively
* it can recognize several logging formats transparently (so it does not require filters)
* it can recognize host names automatically from log files (it's not tricked by addresses in non-IP form)
* its blocking behaviour is easily customizable and can react differently depending on the attacked service

There is some non-functional difference from other tools to sshguard:

1. a very large part of these tools are simple scripts. So, they require a permanent interpreter application which usually takes a lot of system memory. Which, on servers, is very precious.
Sshguard is written in C, and designed to be 0-impact on system resources.
2. several tools require customization (hack & play).
Sshguard is designed for extreme ease of use (plug & play).
3. many tools are OS- or firewall-specific (usually Linux).
Sshguard is designed to work on many OSes and can operate several firewall systems; see Compatibility.
4. nearly all tools are constraintly written for their operating scenario.
Sshguard can be extended for operating with custom/proprietary firewalls with very very few effort.