Login alleen toestaan met een keyfile. Succes :)

Zorg ervoor dat een administrator account nooit direct kan inloggen zul je
bedoelen...

Verder is het weren van Linux systemen al voldoende om de logs aardig
schoon te houden. ;-)

De grap is dat mijn ssh-server ruim onder de 1024 draait,
maar net boven de 22 en dat ik al meer dan een half jaar
(sinds ik die poort gewijzigd heb) geen enkele attack meer
gezien heb.

Ik heb er ook aan zitten denken om iets in mijn iptables te
zetten om die attacks tegen te houden maar ik wilde eerst
dit proberen. En wat blijkt, het werkt. Ondanks dat dit
"security by obscurity" is.

Security through obscurity
Je kunt root niet renamen.
Ooohh... Dus *BSD, AIX, Solaris etc. mag wel?

Het gaat hier om een oplossing voor *nix systemen, stelletje dappere windows dodo's ;)

"Hetgeen u niet wil dat u geschiedt, doet dat ook een ander
niet..."

Het hernoemen van het root account is wel degelijk mogelijk,
of het wenselijk is, is iets anders...

usermod -l blauw root

-dappere dodo :P

DenyHosts?

Wel eens geprobeerd? Dan heb je vast ook gemerkt dat er niet veel meer werkt ;)

Wauw.. 39 stuks..

FreeBSD (ok.. misschien niet commercieel genoeg?) had er in 2006 maar 26..
http://www.freebsd.org/security/

Lees nog eens goed...

-> "of het wenselijk is, is iets anders..."

;-)

Kan ook via Iptables:

http://fail2ban.sourceforge.net/

Deze leest je log files uit. na x keer een error wordt ip
voor y time gebloked in je iptables firewall. Werkt zeer
goed. Krijg per keer een mailtje en zie dat er toch 2 a 3
ip's per dag worden geblokt.

of gewoon met je firewall iedereen voor een uur blokken die
meer dan 3 synpakketjes in 1 minuut op poort 22 dumpt.

niets scripts of whatever, gewoon native met je packetfilter

Waneer stopt de redactie eindelijk eens met deze password fud.

Password authenticatie is achterhaald, 'dat weten we allemaal',
behalve blijkbaar de redactie van security.nl dan :-(

Gewoon de mogelijkheid om met passwords in te loggen
uitzetten (zou de standaard config moeten zijn eigenlijk),
en je hebt nooit last van dit soort problemen.

Password authenticatie is het probleem, dat los je niet om
met allemaal geneuzel er omheen, dat los je op door gewoon
te stoppen het te gebruiken.

Het gaat om SSH. Dat gebruik je voor communicatie met
servers die (meestal) niet op je eigen lokatie staan.
Volgens jou moeten we password authenticatie afschaffen. Hoe
wil je dan remote in gaan loggen op een server?

openbsd...2 security leks in 10 jaar.....

Jep wel eens geprobeert, werkt op zich goed, maar inderdaad
niet met alle programma's. De meeste programma's gaan uit
van uid 0. Dan werkt het perfect.

Er zijn inderdaad ook programma's die letterlijk van de
gebruiker root uitgaan, die werken niet meer. Helaas.

Verder is het niet aan te raden, gewoon logins rejecten van
deze gebruiker is een betere en stabielere oplossing.

Authenticatie op basis van certificaten?

Precies.. Alles via su/sudo..
Dat werkt inderdaad opzich goed. Het gaat alleen mis als je je certificaat kwijt raakt (hd crash.. geen backup).. Of als'ie gepikt wordt.. Of anderszins gecompromiteerd... Management van certificaten is niet echt lekker makkelijk
geregeld...

Volgens mij klopt er van deze berekening helemaal niets...

Laten we even uitgaan van een wachtwoord van maximaal 4 karakters en het mogen alleen maar cijfers zijn:

L=4
B=10 (0-9)

Dan is de keyspace:
(10^0)+(10^1)+(10^2)+(10^3)+(10^4) == 1+10+100+1000+10000 == 11111

Bij een max van 3 en alleen (lowercase) letters:

L=3
B=26 (a-z)
Keyspace == (26^0)+(26^1)+(26^2)+(26^3) == 1 + 26 + 676 + 17576 == 18279

Slimmerikken zien hier een sommatie in: Sigma( B^n) met n=0 t/m n=L..

Next.. De gemiddelde tijd dat dat wachtwoord gebruteforced wordt...

T = aantal pogingen per seconde.

Keyspace / T == Totale tijd

De gemiddelde tijd is (statistisch) de helft van de totale tijd...

Je moet dus je policy dusdanig aanpassen dat het wachtwoord veranderd moet worden binnen de gemiddelde tijd dat het wachtwoord gebruteforced wordt.

Met deze berekeningen zie je al vrij snel dat het verhogen van B (de basis, aantal karakter mogelijkheden) een enorme impact heeft op de keyspace, veel meer dan de lengte van het wachtwoord. Bedenk dat NT, bijvoorbeeld, wachtwoorden niet opslaat in ASCII (0-255) maar in UNICODE.. Als je dan uitgaat van een maximum van 8 is de keyspace al astronomisch.

Nb Ja, dictionaries zijn sneller maar we gaan er even vanuit dat een bruteforce de enige mogelijkheid is om het wachtwoord te kraken.

Is het aantal mogelijkheden niet gelijk aan:

'aantal tekens' tot de macht 'aantal mogelijkheden per teken'?
Dus bij 8 cijfers 8^10, bij 8 letters 8^26 en bij
combinaties 8^36?
En dan nog de overige vreemde tekens?

Verder inderdaad standaard niet als root kunnen aanmelden
via SSH(2). In b.v. FreeBSD is dit out-of-the-box al zo
ingesteld.

Zie 'man ssh_keygen voor het aanmaken van een key.
Public key deel naar de server en klaar ben je.

In je sshd config zet je dan:

RSAAuthentication yes
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

En je systeem is vrij van die achterhaalde password
authenticatie.
Password authenticatie moet je niet willen, met ssh kun je het
prima vermeiden, geneuzel met brute-force protectie is dan
niet meer nodig.
Het is triest dat de bovenstaande config niet gewoon de
default is.

Kijk anders eens op :
http://www.debuntu.org/ssh-key-based-authentication

Zie mijn berekening.. Je vergeet de wachtwoorden die uit minder dan 3 karakters bestaan. Het is een maximum van 3.

Sigma(B^n) met n=0 t/m n=L waarbij B het aantal verschillende karakters zijn en L de maximale lengte.

Bij B=3, L=3:

Sigma (3^n) n=0 t/m n=3 == (3^0)+(3^1)+(3^2)+(3^3) == Zullen we ze even uitschrijven

1 van 0 karakters (geen wachtwoord!)
3 van 1 karakter (1-3)
9 van 2 karakters (11-33)
36 van 3 karakters (111-333)

1 + 3 + 9 + 36 == 49 mogelijke wachtwoorden :)

Ik ben niet zon wiskundige, maar als ik het na ga dan klopt
die berekening van SirDice inderdaad wel. Dit aangezien je
niet altijd de maximale lengte van een wachtwoord hebt, maar
ook kleinere wachtwoorden kan hebben.

Een variant waarbij er een minimale en maximale lengte is:

Sigma(B^n) met n=L1 t/m n=L2; B is de basis; L1 de minimale
lengte; L2 de maximale lengte.

Bij een wachtwoord van 2 cijfers zijn er deze mogelijkheden:
00 01 02 03 04 05 06 07 08 09 10 11 12 ... 99
Dus100 mogelijkheden, want 2 ^ 10 (2 tekens, 10
mogelijkheden per teken).

Bij een wachtwoord van 2 letters zijn er deze mogelijkheden:
AA AB AC AD AE ... ZU ZV ZW ZX ZY ZZ
Nu zijn er 2 ^ 26 = 67108864 mogelijkheden

Nu een wachtwoordje van 8 tekens, die elk een cijfer,
letters en nog zo'n 10 vreemde tekens.
Voor elke positie in het wachtwoord zijn er 10 + 26 + 10 =
46 mogelijkheden.
Voor het hele wachtwoord, wordt dat dan in principe 8 ^ 46 =
3.4844914372704098658649559801013e+41 mogelijheden. En dàt
is het aantal mogelijkheden dat een brute force attack in
principe moet checken.
Het aantal toegestane wachtwoordcombinaties is natuurlijk
lager, als je bepaalde tekens maar een bepaald aantal malen
mag gebruiken. Maar de brute force attack 'weet' niet
hoevaak elk teken mag voorkomen.

Ehhh... 2 ^10 = 1024

Zucht.. Beter opletten bij wiskunde ;)
Een wachtwoord van 2 cijfers heeft een minimum aantal en een maximum aantal van 2:
B=10; L1=2; L2=2;

Sigma(10^n) met n=2 t/m n=2 == 10^2 == 100 ;P
B=26; L1=2; L2=2;
Moet ik die ook voorrekenen? Of geloof je het nu wel? ;)

Het gaat om het minimale en het maximale aantal karakters

En om mezelf maar te quoten:

B=52 als je alleen hoofd/kleine letters accepteert. B=62 met cijfers erbij. Reken maar na hoeveel mogelijkheden dat al zijn als je 6 t/m 14 karakters accepteert.

Definieer "even bezig". Ja tuurlijk kost het tijd om daar doorheen te komen. Maar een beetje off-line password cracker doet er al snel een paar miljoen per seconde. En vergeet niet dat, sinds 1965, de wet van Moore nog steeds redelijk
geldt ;)

[
of gewoon met je firewall iedereen voor een uur blokken die
meer dan 3 synpakketjes in 1 minuut op poort 22 dumpt.

niets scripts of whatever, gewoon native met je packetfilter
]

Cool, geef mij ff de PF rules voor die.. (-: