Wat te doen tegen SSH aanvallen

[bobsquad]

Beste Medetweakers,

Zit al een geruime tijd met dit probleem. Ik krijg voordurend ssh inlog attempts te verduren op mijn firewall.
Het gaat nu al rond de 1800 aanvallen per dag. Kan ik hier iets aan doen? Zoals ik kijk naar de IP adressen komen de meesten uit Azie.

Ik kan wel op IP adressen gaan blokkeren maar dit is geen doen. Aangezien ik van meerdere en soms onbekende netwerken toegang moet hebben tot mijn firewall is het ook geen optie om deze alleen toe te voegen onder allowed hosts.

Het gaat hier trouwens om een Hardwarematige Astaro firewall. Deze is *nix based. Is er een mogelijkheid om bijvoorbeeld een hele reeks van een Chinese provider te blokkeren of moet ik deze aanvallen maar laten gaan voor wat het is?

code:

2009:09:20-21:34:19 fw sshd[13873]: Failed password for invalid user jab from 190.220.14.195 port 38678 ssh2
2009:09:20-21:34:23 fw sshd[13881]: reverse mapping checking getaddrinfo for host195.190-220-14.telmex.net.ar [190.220.14.195] failed - POSSIBLE BREAK-IN ATTEMPT!
2009:09:20-21:34:23 fw sshd[13881]: Invalid user historic from 190.220.14.195
2009:09:20-21:34:23 fw sshd[13881]: error: Could not get shadow information for NOUSER
2009:09:20-21:34:23 fw sshd[13881]: Failed password for invalid user historic from 190.220.14.195 port 39053 ssh2
2009:09:20-21:34:34 fw sshd[13903]: reverse mapping checking getaddrinfo for host195.190-220-14.telmex.net.ar [190.220.14.195] failed - POSSIBLE BREAK-IN ATTEMPT!
2009:09:20-21:34:34 fw sshd[13903]: Invalid user lily from 190.220.14.195
2009:09:20-21:34:34 fw sshd[13903]: error: Could not get shadow information for NOUSER
2009:09:20-21:34:34 fw sshd[13903]: Failed password for invalid user lily from 190.220.14.195 port 39422 ssh2

[BCC]

Ik zou ze gewoon geautomatiseerd blokkeren. Je kan ze moeilijk bellen en vragen of ze willen ophouden

[ Voor 10% gewijzigd door BCC op 20-09-2009 22:12 ]

[CyBeR]

Wat deze dingen doen is heel simpel: men heeft een lijst inlognamen en een lijst wachtwoorden, en probeert het een met het ander te combineren. Zolang jij geen users hebt op die lijst met password op die lijst komen ze niet binnen.

Elke host op 't internet met ssh heeft hier last van. Ik besteed er al heel lang geen aandacht meer aan. Zorg wel dat root logins disabled zijn trouwens.

[bobsquad]

Kijk ik vind het zelf reuze irritant aangezien ik elke dag een log krijg van alle events en door dit gezeik bestaat 80% de gegevens in mijn mailtje uit deze aanvallen. Ik kan ze er wel uitfilteren maar ben wel benieuwd wat er allemaal op mijn firewall gebeurd.

Hierbij lijkt mij het makkelijkste om rejects te doen van Aziatische ISP's weet alleen niet hoe ik het voor elkaar krijg dat hij van die ISP's dit dropt.

[CyBeR]

bobsqaud schreef op zondag 20 september 2009 @ 22:18:
Hierbij lijkt mij het makkelijkste om rejects te doen van Aziatische ISP's weet alleen niet hoe ik het voor elkaar krijg dat hij van die ISP's dit dropt.

Dat helpt niet. Als je ze nu van aziatische ip's krijgt is dat toeval. Want dat zijn gewoon compromised hosts en die vind je overal.

[BCC]

Inderdaad je kan beter gaan whitelisten dan blacklisten (als dat mogelijk is natuurlijk).

[GiantLeap]

Fail2Ban installeren? (klik)

Lees net dat het hier gaat om een (hardware?) firewall, dus weet niet of het mogelijk is.

[ Voor 34% gewijzigd door GiantLeap op 20-09-2009 22:27 ]

[bobsquad]

Ik zou heel graag willen gaan whitelisten, hierbij alleen het probleem is dat ik soms van locatie's werk waar ik vooraf geen IP instellingen heb zodat ik ze niet kan toevoegen via een whitelist.

Zelf al wel range's toegevoegd maar dan kom ik soms nog in een situatie terecht dat ik via ssh niet mijn firewall kan bereiken.

Ik weet niet of het handig is om SSH eventueel op een andere poort te zetten zodat misschien de kans kleiner wordt dat je een attack krijgt en of hier voordelen/nadelen aanzitten.

[Verwijderd]

Wat te doen? Niks.

Het is zonde van de moeite. Normaal gesproken heb je weinig reden om in je logs te gaan kijken. Een paar geautomatiseerde scripts halen er de boeiende informatie wel uit als je die nodig hebt.

[Nielsvr]

bobsqaud schreef op zondag 20 september 2009 @ 22:26:
Ik zou heel graag willen gaan whitelisten, hierbij alleen het probleem is dat ik soms van locatie's werk waar ik vooraf geen IP instellingen heb zodat ik ze niet kan toevoegen via een whitelist.

Zelf al wel range's toegevoegd maar dan kom ik soms nog in een situatie terecht dat ik via ssh niet mijn firewall kan bereiken.

Ik weet niet of het handig is om SSH eventueel op een andere poort te zetten zodat misschien de kans kleiner wordt dat je een attack krijgt en of hier voordelen/nadelen aanzitten.

Zorg dan dat er een VPN verbinding beschikbaar is waar je dat soort dingen vanaf kan regelen. Zo deed ik het in ieder geval in mijn server tijden.

[easydisk]

Heb zelf SSH ook op een andere poort zitten, nooit last van fake logins..

Nog geen nadelen gevonden..

[Herko_ter_Horst]

Een andere poort voorkomt inderdaad logvervuiling door dit soort automatische scriptjes. Behalve dat je in je client even de juiste poort moet instellen, is er volgens mij geen nadeel.

[vanaalten]

Blokkeren van Korea, China, Hong Kong, Taiwan, Indonesie en India:
Ik gebruikte hiervoor de handleiding en IP database van deze pagina. Prima oplossing, al zal je natuurlijk nooit alles blokkeren. Zombie-PC's vind je overal ter wereld - alleen in bovengenoemde landen wat meer dan gemiddeld.

[bobsquad]

Dank voor alle tips in ieder geval.

Ga eens proberen om SSH op een andere poort te zetten is hier nog enige voorkeur voor dacht zelf aan iets in de 4000 reeks mits mogelijk. Voor de rest qua clients die van mij ssh gebruiken die kan ik allemaal instellen.

Ik zekers ook kijken op iets van een netfilter aangezien dit toch ook een groot deel van het verkeer kan tegenhouden. Heb hierbij nog een vraagje is dat ook in te stellen per poort dat bijv alleen poort 21 & 4432 daarop gefilterd worden?

[Verwijderd]

bobsqaud schreef op zondag 20 september 2009 @ 22:10:
Deze is *nix based. Is er een mogelijkheid om bijvoorbeeld een hele reeks van een Chinese provider te blokkeren of moet ik deze aanvallen maar laten gaan voor wat het is?

Gewoon laten gaan voor wat het is mits je je zaakjes goed op orde hebt natuurlijk

/me mompelt wat over ssh keys

[bobsquad]

Verwijderd schreef op zondag 20 september 2009 @ 22:40:
[...]


Gewoon laten gaan voor wat het is mits je je zaakjes goed op orde hebt natuurlijk

/me mompelt wat over ssh keys

Ik maak al gebruik van keys maar hierbij blijft toch de logvervuiling bestaan helaas. Hierdoor wordt de kans op inbreken op het systeem wel een stuk kleiner maar helaas nog steeds aanwezig. Betreft de hele login procedure hier zitten al genoeg haken en ogen aan om uberhaubt onder root wat te mogen doen. Daar maak ik mij niet druk om. Alleen elk stukje dat ze "dichterbij" komen begint met toch steeds meer te irriteren.

[dion_b]

Herko_ter_Horst schreef op zondag 20 september 2009 @ 22:32:
Een andere poort voorkomt inderdaad logvervuiling door dit soort automatische scriptjes. Behalve dat je in je client even de juiste poort moet instellen, is er volgens mij geen nadeel.

Yup. Hier ook SSH draaien >64000 simpelweg om m'n logs wat hanteerbaarder te houden

Maar idd, gewoon een goede username/pw combo nemen scheelt al stukken. Daarom alleen al geen root-logins toestaan; de grootste risico komt niet voort uit de rechten van root (want je moet altijd uitgaan van escalations als iemand als gewone user al binnenkomt), het komt simpelweg doordat ze bij root alleen password hoeven te gokken, username staat vast.

[Equator]

Dit lijkt me meer iets voor Beveiliging & Virussen

[Verwijderd]

dion_b schreef op maandag 21 september 2009 @ 00:28:
[...]

Yup. Hier ook SSH draaien >64000 simpelweg om m'n logs wat hanteerbaarder te houden

Maar idd, gewoon een goede username/pw combo nemen scheelt al stukken. Daarom alleen al geen root-logins toestaan; de grootste risico komt niet voort uit de rechten van root (want je moet altijd uitgaan van escalations als iemand als gewone user al binnenkomt), het komt simpelweg doordat ze bij root alleen password hoeven te gokken, username staat vast.

Ervan uitgaande dat een root password toch even iets complexer is dan het gemiddelde password, is de kans dat het wachtwoord geraden wordt zó klein dat het al niet eens meer zin heeft om er statistieken op los te laten.

Dat is het hele idee van een moeilijk wachtwoord. Het heeft geen zin om te gokken. Het heeft dus ook geen zin om root logins uit te zetten om inbraak via brute force tegen te houden. Als je root logins wilt uitzetten heb je er over het algemeen een heel andere reden voor.

Denk bijvoorbeeld aan een situatie waarin je meerdere admins hebt die allemaal de servers moeten kunnen beheren. Je wilt in veel gevallen dat ze kunnen inloggen via SSO, elk hun eigen usename, en vervolgens kun je via bijvoorbeeld LDAP en Kerberos er in één keer voor zorgen dat ze niet meer sudo mogen gebruiken als een werknamer bijvoorbeeld het bedrijf verlaat.

PermitRootLogin is handig voor dát soort situaties. De gegevens die de werknemer altijd gebruikte werken niet meer, dus effectief heb je het voor hem onmogelijk gemaakt om nog op dezelfde manier binnen te komen. Als de ex-werknemer nog bij een machine kan komen zal dat dus (voor de rechter) sneller onder "inbreken" vallen. Uiteraard kan elke gebruiker die root kan worden backdoors hebben ingebouwd, maar dat is natuurlijk nog weer een heel ander verhaal.

Uiteraard is dit slechts een fictieve situatie, maar het gaat erom dat bang zijn voor brute force aanvallen absoluut niet nodig is als je goede wachtwoorden gebruikt.

[CAPSLOCK2000]

CyBeR schreef op zondag 20 september 2009 @ 22:22:
Dat helpt niet. Als je ze nu van aziatische ip's krijgt is dat toeval. Want dat zijn gewoon compromised hosts en die vind je overal.

Wat de preciese aanleiding ook mogen wezen, de aziatische IP's zorgen wel voor het leeuwendeel van dit soort portscans en login-pogingen.

Als je meerdere computers moet beheren zou je een jumphost kunnen overwegen.
Een jumphost is een server die niks anders doet dan als tussenstation dienen.
Je timmertje je servers helemaal dicht, en staat alleen de jumphost toe om verbinding te maken met die machine.
Je jumphost beveilig je ook zo goed mogelijk. Aangezien je alleen SSH hoeft te draaien op deze machine zou dat niet al te lastig moeten zijn.
Als je dan naar je server wil verbinden log je eerst in op je jumphost, en 'spring' je vanaf daar verder naar je eigen server.
Als je maar 1 server hebt is het vrij zinloos.

[bobsquad]

De Firewall wordt in principe al gebruikt als jumphost.

Het heeft geholpen om SSH via een andere poort te laten lopen. Betreft de aanvallen uit Azie, ik heb zo'n 30 firewalls in beheer waar het grootste gedeelte 80 a 90 procent toch uit Azie komt. Aangezien we niks doen betreft SSH met Azie leek mij dit het handigste idee maar helaas moet ik daar van alles voor gaan installeren. Ik ben daar zelf niet zo voor op een firewall. Helaas moeten zulke maatregelen omdat een x aantal mensen zoiets leuk vind (wat ik nog steeds niet snap).

Ik heb me er nu maar bij neergelegd en ook alleen maar de sucessvolle ssh logins worden nu geregistereerd. Dit scheeld aanzienlijk in log

[Verwijderd]

bobsqaud schreef op maandag 21 september 2009 @ 17:14:

Ik heb me er nu maar bij neergelegd en ook alleen maar de sucessvolle ssh logins worden nu geregistereerd. Dit scheeld aanzienlijk in log

En nu kun je dus niet meer aantonen dat iemand eerst 362 keer een verkeerd wachtwoord heeft gebruikt voor het account pietje met wachtwoord "pietje294".

Het probleem zit hem toch alleen in de analyse van logfiles?

[bobsquad]

Verwijderd schreef op maandag 21 september 2009 @ 18:14:
[...]

En nu kun je dus niet meer aantonen dat iemand eerst 362 keer een verkeerd wachtwoord heeft gebruikt voor het account pietje met wachtwoord "pietje294".

Het probleem zit hem toch alleen in de analyse van logfiles?

Opzich gaat het er alleen om dat het makkelijk aan te tonen is wie wanneer waar heeft ingelogd met SSH voor onderhoud. Dus alleen accepted is momenteel meer als genoeg voor mij. Via executive reports die elke dag worden verstuurd.

[GraveR]

Hiervoor gebruik ik DenyHosts. Voordeel is dat het automatisch blokkeert en (eventueel) synchroniseert met een database van andere 'attackers'. Op die manier wordt de kans van een succesvolle hack tot vrijwel 0 gereduceerd.

[pennywiser]

Fail2ban + Logwatch vind ik de beste combi. Elke dag een overzichtelijke mail met al je log highlights. Sensitivity is instelbaar. Maar ook toen ik nog geen Fail2ban gebruikte heb ik nooit enig probleem ondervonden door de vele log entries.

Overigens kan je Fail2ban ook voor oa. Postfix en Apache gebruiken.

Edit @ hierboven: Denyhosts werkt ook goed.

[ Voor 7% gewijzigd door pennywiser op 22-09-2009 14:54 ]

[Boudewijn]

Dat is het hele idee van een moeilijk wachtwoord. Het heeft geen zin om te gokken. Het heeft dus ook geen zin om root logins uit te zetten om inbraak via brute force tegen te houden. Als je root logins wilt uitzetten heb je er over het algemeen een heel andere reden voor.

Eigenlijk wel, en wel om 2 redenen.

1: Je weet zeker dat er een root gebruiker op het systeem is als het een NIX doos is. Dat betekent dat je 1 van de 2 items al weet (un is 1, pw is 2). Als alleen 'boudewijn684' in kan loggen wordt het een stuk lastiger dat te raden.
2: Een gebruiker die su gebruikt heeft 2 passwords nodig. 1 password raden is genoeg voor shell xs, maar dan moet er nog een 2e password zijn om root te worden.

Mi maken beide effecten het lastiger om root xs te verkrijgen als brute-forcer.

[nero355]

Je hoeft toch alleen het volgende te doen eventueel i.c.m. Firewall+andere poort :

- Root login uit.
- Keys aanmaken die met password beveiligd zijn.
- Normale Password logins uitschakelen.

Op deze manier wordt de connectie gedropt indien er geen Key aanwezig is of de username niet klopt Genoeg toch

[bobsquad]

Met boudewijn eens.

Alleen je ziet wel heel vaak dat de gebruiker dezelfde wachtwoord heeft als root en dan heeft het opzich niet zoveel nut. Mits ze al kunnen inloggen op de gebruiker.
Ik denk ook dat als er een "schil" overheen hebt je toch iets meer gemoedsrust hebt.
Aangezien de aanvallen voor het overgrote deel als username root hebben.

[ Voor 4% gewijzigd door bobsquad op 22-09-2009 15:34 ]

[bobsquad]

nero355 schreef op dinsdag 22 september 2009 @ 15:33:
Je hoeft toch alleen het volgende te doen eventueel i.c.m. Firewall+andere poort :

- Root login uit.
- Keys aanmaken die met password beveiligd zijn.
- Normale Password logins uitschakelen.

Op deze manier wordt de connectie gedropt indien er geen Key aanwezig is of de username niet klopt Genoeg toch

Je krijgt helaas dan nog steeds grote logs van aanvallen. Ik heb ze nu zelf uitgezet en heb besloten mij hier niet meer aan te ergeren schiet je toch niks mee op. Alleen ik snap het nut niet van die aanvallen

[nero355]

Mja ik bedoelde meer vanuit security perspectief. Die logs delete ik wel om de zoveel tijd

[Luppie]

Ik gebruik zelf denyhosts, dit is een script die automatisch ieder IP op basis van een treshold in de hosts.deny zet. Je kan hierbij aangeven of ze dan alleen voor SSH geblokkeerd moeten worden of voor elk protocol. Ik heb er ondertussen voor gekozen om ze dan maar meteen helemaal te blokkeren.

Je hebt daarnaast ook de mogelijkheid om je hosts.deny te synchroniseren, waardoor notoire scriptkiddies al standaard worden opgenomen in je blocklist.

http://denyhosts.sourceforge.net/

[Bergen]

GraveR schreef op dinsdag 22 september 2009 @ 14:53:
Hiervoor gebruik ik DenyHosts. Voordeel is dat het automatisch blokkeert en (eventueel) synchroniseert met een database van andere 'attackers'. Op die manier wordt de kans van een succesvolle hack tot vrijwel 0 gereduceerd.

Yep, Denyhosts werkt uitstekend. Je kunt het aantal failed logins instellen voordat iemand geblokkeerd moet worden en ook na hoeveel tijd het IP weer moet worden vrijgegeven. Bijvoorbeeld een IP-blokkade na 3 mislukte logins en weer vrijgeven na een uur. (Want stel dat je zelf met je botte kop 3x een typfout maakt, dan is het wel handig dat je het na een uur opnieuw kunt proberen.)

Ik heb een keer meegemaakt dat de brute force logins telkens na het vrijgeven gewoon weer verder gingen. Het viel me toevallig op toen ik het log aan het bekijken was ivm een probleem. De "hacker" (right...) probeerde ook alléén maar op root in te loggen en laat die nou net uit staan. Nadat het bijna een week zo ging heb ik de hoster gemaild en toen was het ook snel afgelopen. Blijkbaar hebben ze dus wel ingegrepen.

[Verwijderd]

Zoals eerder al vermeld DenyHosts (*nix, cygwin), maar kijk ook eens naar "port knock" mechanisme (*nix, win) en sshd_block (win).
Op zich zolang je passphrases gebruikt zit je redelijk safe. Met een andere poort vertraag je het probleem alleen maar (security by obscurity).

Bergen schreef op dinsdag 22 september 2009 @ 15:50:
[...]
Nadat het bijna een week zo ging heb ik de hoster gemaild en toen was het ook snel afgelopen. Blijkbaar hebben ze dus wel ingegrepen.

Feit is dat de meeste van dit soort "dictionary" attacks komen van onschuldige gebruikers wiens computer is gekaapt...

[ Voor 40% gewijzigd door Verwijderd op 22-09-2009 16:02 ]

[Boudewijn]

Een 3e voordeel van mijn attack is dat ik weet dat een root-login NOOIT legitiem is bij mij (ook omdat PermitRootLogin uitstaat) en je dus na 1x dat proberen al de ban in gaat (op mijn eigen gewhitelistte ip na, want ik zou eens per ongeluk niet wakker zijn ).

Werkt op die manier best aardig.

[Verwijderd]

Mijn default sshd ziet er qua inlog policy altijd zo uit:

PasswordAuthentication no
PermitRootLogin without-password

Sshd op andere poorten draaien ben ik geen voorstander van evenals systemen zoals Denyhosts of Fail2ban. Maar goed meningen verschillen daarover

[Verwijderd]

Boudewijn schreef op dinsdag 22 september 2009 @ 14:57:

Eigenlijk wel, en wel om 2 redenen.

1: Je weet zeker dat er een root gebruiker op het systeem is als het een NIX doos is. Dat betekent dat je 1 van de 2 items al weet (un is 1, pw is 2). Als alleen 'boudewijn684' in kan loggen wordt het een stuk lastiger dat te raden.

Lastiger? Met een degelijk wachtwoord heb je al een extreem kleine kans. Ik durf te beweren dat er nog nooit, nergens ook ter wereld, een degelijk root wachtwoord via brute force is geraden via SSH. Een kans van praktisch nul kleiner willen maken is zinloos.

2: Een gebruiker die su gebruikt heeft 2 passwords nodig. 1 password raden is genoeg voor shell xs, maar dan moet er nog een 2e password zijn om root te worden.

Effectief verschilt het niet van een twee keer zo lang wachtwoord. Een gebruiker met shell access op je server kan al erg genoeg zijn, er hoeft immers maar een package exploitable te zijn. Ik blijf bij mijn punt. Root login disablen doe je niet omdat je bang bent voor brute force aanvallen, je doet het omdat je bang bent voor inbraken van bijvoorbeeld ex-personeel of via exploits.

Mi maken beide effecten het lastiger om root xs te verkrijgen als brute-forcer.

IMHO hoef je alleen maar te weten dat de beste verdediging tegen brute force een kwestie is van tijd kopen. Elke extra bit die bij je wachtwoord erbij komt verdubbelt het aantal benodigde pogingen. Meer tijd kopen dan 16 zuwalibotriljard heeft geen zin. Tegen die tijd bestaat de server al niet meer.

[Verwijderd]

Verwijderd schreef op dinsdag 22 september 2009 @ 17:14:
Mijn default sshd ziet er qua inlog policy altijd zo uit:

PasswordAuthentication no
PermitRootLogin without-password

Sshd op andere poorten draaien ben ik geen voorstander van evenals systemen zoals Denyhosts of Fail2ban. Maar goed meningen verschillen daarover

hiermee vermijdt je geen Brute Force Attacks mee... Niet dat het kwaad kan als je passphrases gebruikt en geen onnodig accounts hebt als root, administrator, guest, etc etc. Ik word alleen al moe als ik mijn router leds zie trillen door een of andere <vul maar in>. Dus 1 minuutje werk om met DenyHosts of sshd_block de indringer na 3x kloppen te bannen. Lekker rustig voor de ogen (die leds dan he).

[Boudewijn]

Effectief verschilt het niet van een twee keer zo lang wachtwoord. Een gebruiker met shell access op je server kan al erg genoeg zijn, er hoeft immers maar een package exploitable te zijn. Ik blijf bij mijn punt. Root login disablen doe je niet omdat je bang bent voor brute force aanvallen, je doet het omdat je bang bent voor inbraken van bijvoorbeeld ex-personeel of via exploits.

ja maar de username moet geraden worden, en ik kan een root login poging meteen bannen.

IMHO hoef je alleen maar te weten dat de beste verdediging tegen brute force een kwestie is van tijd kopen. Elke extra bit die bij je wachtwoord erbij komt verdubbelt het aantal benodigde pogingen. Meer tijd kopen dan 16 zuwalibotriljard heeft geen zin. Tegen die tijd bestaat de server al niet meer.

daarom voeg ik complexiteit toe doordat mensen ook de username moeten raden.

[ Voor 4% gewijzigd door Boudewijn op 22-09-2009 17:44 ]

[CAPSLOCK2000]

Het handige van Fail2Ban is dat het ook naar je FTP en webserver kijkt.
Iemand die 10 keer probeert in te loggen op m'n ssh kan een legitieme gebruiker zijn die z'n wachtwoord is vergeten, of iets onhandig gescript heeft.
Wie achtereenvolgens op m'n FTP en m'n SSH probeert in te loggen is duidelijk iets van plan en vliegt een tijdje de blacklist in. Ik houd ook een lijstje bij met IP's die ooit geblacklist zijn. Als je daar twee keer op voorkomt dan heb je blijkbaar met enkele dagen tussentijd proberen in te breken, en mag je permanent het gat in.


PS. Op zich hoeft de unix root gebruiker geen "root" te heten. Ik heb er wel eens over gedacht om m'n root account te hernoemen, en onder "root" een sandbox te plakken om een beetje krakers te pesten. Maarja, krakers pesten is over het algemeen goed idee, en ik heb een statisch ip, dus ik heb het maar niet gedaan.

PS2. Je moet niet blind je root account gaan renamen. Er is vast wel software die er van uit gaat dat er wel een root account is. Test dus goed voor je zoiets doet.

[ Voor 30% gewijzigd door CAPSLOCK2000 op 22-09-2009 17:44 ]

[Verwijderd]

Verwijderd schreef op dinsdag 22 september 2009 @ 17:37:
[...]


hiermee vermijdt je geen Brute Force Attacks mee... Niet dat het kwaad kan als je passphrases gebruikt en geen onnodig accounts hebt als root, administrator, guest, etc etc. Ik word alleen al moe als ik mijn router leds zie trillen door een of andere <vul maar in>. Dus 1 minuutje werk om met DenyHosts of sshd_block de indringer na 3x kloppen te bannen. Lekker rustig voor de ogen (die leds dan he).

Ik wil geen Brute Force Attacks vermijden. In loggen met passwords vind ik maar erg onveilig dus daar maak ik geen gebruik van. Er zijn in het verleden en nu nog steeds serieuze problemen geweest met die autoban daemons/scripts. Dus ik mijd die dingen als de pest.

[Verwijderd]

Effectief is een pki infrastructuur niet anders dan wachtwoorden gebruiken. Een private key is eigenlijk niets anders dan een bizar moeilijk wachtwoord. Uiteindelijk komt het allemaal neer op iets verzinnen dat niet meer binnen redelijke tijd geraden kan worden. Kan het wel dan verveelvoudig je het aantal benodigde bits dat juist wordt geraden.

Het enige significante verschil is dat je bij algoritmes waarbij een wachtwoord als hash wordt opgeslagen eigenlijk naar de maximale sterkte van de hash moet kijken.

[BCC]

Inderdaad. Microsoft heeft hier laatst nog een hele interessante paper over gepubliceerd. De conclusie was dat je veel beter degrading logins kon hebben dan ingewikkelde passwords te enforcen.

Deze was het: http://research.microsoft...ormac/papers/hotsec07.pdf

[ Voor 18% gewijzigd door BCC op 22-09-2009 18:17 . Reden: Link toegevoegd ]

[Boudewijn]

Verwijderd schreef op dinsdag 22 september 2009 @ 18:05:
Effectief is een pki infrastructuur niet anders dan wachtwoorden gebruiken. Een private key is eigenlijk niets anders dan een bizar moeilijk wachtwoord. Uiteindelijk komt het allemaal neer op iets verzinnen dat niet meer binnen redelijke tijd geraden kan worden. Kan het wel dan verveelvoudig je het aantal benodigde bits dat juist wordt geraden.

Het enige significante verschil is dat je bij algoritmes waarbij een wachtwoord als hash wordt opgeslagen eigenlijk naar de maximale sterkte van de hash moet kijken.

Maar een 4096 bit sleutel is vrij fors als je dat als wachtwoord uit gaat drukken.

Ik ben aan het overwegen om RSA (het bedrijfs) SecureID tokens in te zetten.
Iemand hier daar een mening over?


@TS: Je hebt het over een firewall. Is het een idee om gewoon alleen van de binnenkant van de FW SSH te allowen? Dat scheelt een slok op een borrel.

[bobsquad]

Ja eigenlijk wel maar dat is vrij lastig ivm de openvpn software die dan geinstalleerd moet worden om van afstand onderhoud/updates te installeren.

bestreft RSA Keys vrij weinig ervaring mee alleen bij het inloggen bij mijn hosting. Hier nooit problemen mee gehad en ook geen aanvallen. Dit zal de hostingspartij van mij wel afvangen.

[pennywiser]

Verwijderd schreef op dinsdag 22 september 2009 @ 17:46:
[...]

Er zijn in het verleden en nu nog steeds serieuze problemen geweest met die autoban daemons/scripts. Dus ik mijd die dingen als de pest.

Draai al een tijdje meer maar nooit iets over gehoord, afgezien van dat je door onhandigheid zelf de dupe ervan kan worden.

Graag onderbouwen met voorbeelden eo links.

[bobsquad]

Ik mijd ze net zoals Stacheldraht maar alleen omdat ik geen extra software op mijn firewall wil gaan installeren. Het zou best leuk zijn als je zelf een firewall maakt/configureerd. Niet een out-of-box firewall van 600 euro waar dan 3 jaar maintenance.

Betreft de sofware ontwikkelingen weet ik wel dat ze bij Astaro druk bezig zijn om dit probleem van ssh attacks op een actieve manier aan te pakken. Mischien wel door middel van zo'n script maar dat is nu nog koffiedik kijken helaas.

P.s. heb wel mijn root username gewijzigd omdat ik mij daar veiliger bij voel. Hierbij voor zover gelukkig nog geen problemen gevonden betreft de software/database die er op draaien.

[Boudewijn]

Tsja ik heb denyhosts wel op mijn virtuele productie-omgevingen staan.
Echter wel mijn eigen IP gewhitelist.


Het host os accepteert maar ssh vanaf een paar IP adressen, en alleen pubkey. Daarom prima beveiligd.

[bobsquad]

Het ligt er natuurlijk maar net aan hoe je zelf ssh gebruikt.

Ik gebruik nu toch dit commando handmatig aangezien het me opviel dat er heel veel verkeer van bepaalde ip adressen afkomt. Deze heb ik in ieder geval al op de blacklist gezet.

code:

grep sshd /var/log/sshd.log |grep Invalid |awk '{print $10}' |uniq -c |sort -

[Verwijderd]

Op de vele honderden servers die wij beheren maken we ons daar echt niet druk over. Als je zo paranoïde bent kun je beter eens de cijfertjes erbij pakken en kijken hoe klein een kans van bijvoorbeeld 1:2¹²⁸ is. Uiteraard is 1:2⁴⁰⁹⁶ nog véél kleiner. Ga daarna met de meest optimistische schattingen die er maar bestaan kijken hoe lang het duurt om een significant deel van de mogelijkheden af te lopen.

Ik besteed mijn tijd liever aan échte uitdagingen

[bobsquad]

Tuurlijk Cheatah dat begrijp ik maar je probeert toch zo effectief mogelijk en met zo weinig mogelijk middelen de kans zo klein mogelijk te maken. Dit is toch een priveproject dus kwa tijd die ik er in steek is het niet zo'n groot probleem. Heb zelfs een Command Center ingericht om zsm op de hoogte te zijn van deze kwesties.

Zit nu net nog even de logs na te kijken. Wat mij opvalt is dat de aanvallen vanaf een bepaalde datum wel explosief zijn gestegen. Is hier een verklaring voor of wordt het desbetreffende dnshost/ip adres dan opgenomen in een botnet om zo meer combinatie's te testen?

[ Voor 59% gewijzigd door bobsquad op 22-09-2009 21:15 ]

[Turdie]

bobsqaud schreef op zondag 20 september 2009 @ 22:10:
Het gaat hier trouwens om een Hardwarematige Astaro firewall. Deze is *nix based. Is er een mogelijkheid om bijvoorbeeld een hele reeks van een Chinese provider te blokkeren of moet ik deze aanvallen maar laten gaan voor wat het is?

code:

2009:09:20-21:34:19 fw sshd[13873]: Failed password for invalid user jab from 190.220.14.195 port 38678 ssh2
2009:09:20-21:34:23 fw sshd[13881]: reverse mapping checking getaddrinfo for host195.190-220-14.telmex.net.ar [190.220.14.195] failed - POSSIBLE BREAK-IN ATTEMPT!
2009:09:20-21:34:23 fw sshd[13881]: Invalid user historic from 190.220.14.195
2009:09:20-21:34:23 fw sshd[13881]: error: Could not get shadow information for NOUSER
2009:09:20-21:34:23 fw sshd[13881]: Failed password for invalid user historic from 190.220.14.195 port 39053 ssh2
2009:09:20-21:34:34 fw sshd[13903]: reverse mapping checking getaddrinfo for host195.190-220-14.telmex.net.ar [190.220.14.195] failed - POSSIBLE BREAK-IN ATTEMPT!
2009:09:20-21:34:34 fw sshd[13903]: Invalid user lily from 190.220.14.195
2009:09:20-21:34:34 fw sshd[13903]: error: Could not get shadow information for NOUSER
2009:09:20-21:34:34 fw sshd[13903]: Failed password for invalid user lily from 190.220.14.195 port 39422 ssh2

Dit ip-adres wat je in je startpost geeft komt niet uit Azie, maar uit Latijns-Amerika, namelijk uit Argentinie.

Ik zou gewoon DenyHosts gebruiken om je SSH te beveiligen.En zoals eerder genoemd ook SSH op een andere poort laten draaien,vergeet dat niet om de standaard poort 22 te blokkeren in je firewall.Ook is fail2ban volgens mij wel een goede optie om SSH te beveiligen, ook eerder genoemd.

[bobsquad]

Beste Shadowman12 zoals al eerder aangegeven is dit ook maar een simpel voorbeeld.

betreft de extra software ik ben daar dus geen voorstander van om extra software op mijn firewall's te installeren.

[Turdie]

bobsqaud schreef op dinsdag 22 september 2009 @ 21:17:
Beste Shadowman12 zoals al eerder aangegeven is dit ook maar een simpel voorbeeld.

betreft de extra software ik ben daar dus geen voorstander van om extra software op mijn firewall's te installeren.

Niet op je firewall maar op je server of client naar waar je connecteert

[bobsquad]

shadowman12 het gaat om de ssh toegang tot mijn firewall. Vandaar kun je pas met SSH connecten met een server dus een jumphost situatie. Op mijn server kan ik dus niks loggen tenzij ik SSH direct doorlaat en zover wil ik dus niet gaan want dan is het effect van mijn firewall weg.

[Verwijderd]

pennywiser schreef op dinsdag 22 september 2009 @ 19:26:
[...]
Graag onderbouwen met voorbeelden eo links.

http://www.securityfocus....oc&query=fail2ban&x=0&y=0

http://search.securityfoc...c&query=denyhosts&x=0&y=0

Ik heb hier op mijn werk zo'n 150 Linux/Unix servers staan en die staan veilig achter een paar jumpboxen, daarnaast staat bij ons zo'n beetje de doodstraf op het idee dat het inloggen met behulp van passwords slim is

[ Voor 24% gewijzigd door Verwijderd op 22-09-2009 22:16 ]

[Turdie]

bobsqaud schreef op dinsdag 22 september 2009 @ 21:21:
shadowman12 het gaat om de ssh toegang tot mijn firewall. Vandaar kun je pas met SSH connecten met een server dus een jumphost situatie. Op mijn server kan ik dus niks loggen tenzij ik SSH direct doorlaat en zover wil ik dus niet gaan want dan is het effect van mijn firewall weg.

Je kunt wel de poort van ssh veranderen, want hacker/crackers/scriptkiddies voeren standaard attacks en scans uit en proben op poort 22.
How do I change the default port that OpenSSH server uses?

[ Voor 23% gewijzigd door Turdie op 22-09-2009 22:14 ]

[bobsquad]

shadowman12 heel aardig dat je me probeert te helpen daar niet van maar dit is al gewijzigd in een andere poort. Nu wordt standaard alles gedropped op de standaard poort. (dit was al eerder in het topic te lezen).

[Turdie]

Iets anders, wat als deze ene firewall om wat voor reden dan ook uitvalt, kun je niet meer naar je netwerk of wel? En aanvallers zitten meteen in je netwerk, waar je blijkbaar niet wil dat ze in komen, anders zet je er geen firewall voor. Daarom zou ik er nog een SonicWall of Watchguard o.i.d tussen zetten. Vaak kunnen dit soort firewalls ook pakketten inspecteren op malafide verkeer.

[ Voor 11% gewijzigd door Turdie op 22-09-2009 22:31 ]

[bobsquad]

Ik heb zoiets als een SonicWall of Watchguard er tussen staan zo een


Als deze firewall uitvalt krijg ik van mijn Command Center een sms bericht en kan deze zo snel mogelijk gewisseld worden. Dan heb ik liever ook geen netwerkverbinding als er wat is.

Betreft de pakketen die geinspecteerd worden krijg ik dagelijks een mail met daarin:

dit is dan alleen een opsomming in de rest van het bericht staat alles duidelijk dit is dan ook zelf aan te passen aan je eisen.

[Verwijderd]

Even teruggelezen, je gebruikt een Astaro firewall, je wilt wat doen aan die talloze logins en je wilt geen extra software installeren. Dat was toch de vraag?
Volgens mij supports de Astaro (asg v4, v5 en v6) iptables. Dan ben je met 2 regels klaar.

[bobsquad]

Klopt als een postbus.

Alleen die iptables zijn tijdelijk heb met een supportmedewerker van Astaro gesproken. Hij adviseerde mij ook gewoon om het te negeren

[Mafketel]

bobsqaud schreef op dinsdag 22 september 2009 @ 20:25:
Ik mijd ze net zoals Stacheldraht maar alleen omdat ik geen extra software op mijn firewall wil gaan installeren. Het zou best leuk zijn als je zelf een firewall maakt/configureerd. Niet een out-of-box firewall van 600 euro waar dan 3 jaar maintenance.

Betreft de sofware ontwikkelingen weet ik wel dat ze bij Astaro druk bezig zijn om dit probleem van ssh attacks op een actieve manier aan te pakken. Mischien wel door middel van zo'n script maar dat is nu nog koffiedik kijken helaas.

P.s. heb wel mijn root username gewijzigd omdat ik mij daar veiliger bij voel. Hierbij voor zover gelukkig nog geen problemen gevonden betreft de software/database die er op draaien.

Ik heb een tijdje met de astaro software moeten werken.... geef mij maar een kale linux box een stuk gebruiksvriendelijker.
Ik kan me eigenlijk niet herinneren dat de ssh log zo vol liep .... en inmiddels weet ik weer waarom. Je gebruikt een astaro voor garantie en "snelle" recovery. ssh acces verknoeit beide. astaro dient in de webrowser te worden geconfigureerd, ssh stond dus over het algemeen uit.
Maar voor je vraag.... vpn is makkelijk in te stellen en je kunt zelfs van de firewall zelf voor 2ossen de benodigde software + scripts downloaden.

Waarom astaro niet gewoon fail2ban instaleerd is mij niet geheel duidelijk..... er is zelfs een rpm ervan.

Het feit dat een support medewerker zegt dat de iptables tijdelijk zijn is weer een bewijs dat het niet wijs is om geld uit te geven aan support. In de webinterface kun je gewoon iptable rules aanmaken en die blijven er echt wel instaan anders had ik echt geweigerd om met die software te werken. Nu was nog zoiets van het moet maar omdat de baas een gui wil.

[lammert]

Even een eigen case als vb:

Ik heb een Citrix XenServer in een datacenter hangen, met daarop diverse VM's. SSH toegang heb ik nodig, want voor de Citrix beheertools heb je .Net 3.5 nodig en ik heb niet altijd Windows bij de hand, laat staan eentje met XenCenter geinstalleerd.

Sshd root access als eerste uitgeschakeld, maar in de logs nog steeds die ~2000 loginpogingen per dag. Ik weet dat de kans de nul nadert dat iemand EN username EN wachtwoord EN vervolgens ook nog eens het (andere) root wachtwoord raadt. Maar ik heb alsnog de poort veranderd en in de afgelopen 9 maanden zijn er precies 0 (nul) pogingen geweest, het zijn details, maar het slaapt toch lekkerder

[Mafketel]

Ik ben het helemaal eens met je, maar realiseer je wel dat je niks veiliger bent dan eerst. Voor betere nachtrust met je de deur op slot doen en niet verstoppen.
Hoe zit het eigenlijk in citrix xenserver hoe gaan ze om met aanpassingen op de prompt? (astaro namelijk niet om maar een dwarsstraat te noemen)
Een systeem wat actief reageert op individuen die zich in allerlei bochten wringen om binnen te komen zorgt ervoor dat bruteforce securety fouten veel moeilijker zijn uit te buiten. En je kunt je verder gewoon aan de internet standaarden houden. Misschien dat het zelfs voor minder spam zorgt aangezien je een tijdje niets meer accepteert van die host.

Stap 1 in beveiliging goede passwords, juiste machtigingen, weet wat er draait.
stap 2 vertraag mensen die iets kwaad in de zin hebben, tijd is een van de weinige dingen waar je niet omheen komt.

Stap3 meld abuser aan, al moet ik zeggen dat ik niet van klikken houdt en het dus bijna nooit doe.

Hier wil eigenlijk meteen een vraag aan vast knopen wat is jullie mening over het melden aan abuse adressen van ssh bots , telefooncentrale aanvallers, spam-bots?
Wat ik al zei ik hou niet van klikken(niet met de muis) en stuur maar heel soms een email naar een abuse adres en vraag me af of dat slim is.

edit:
quote weggehaald was overbodig is post hierboven

[ Voor 25% gewijzigd door Mafketel op 23-09-2009 18:24 ]

[Verwijderd]

Mafketel schreef op woensdag 23 september 2009 @ 18:23:

Stap3 meld abuser aan, al moet ik zeggen dat ik niet van klikken houdt en het dus bijna nooit doe.

Hier wil eigenlijk meteen een vraag aan vast knopen wat is jullie mening over het melden aan abuse adressen van ssh bots , telefooncentrale aanvallers, spam-bots?
Wat ik al zei ik hou niet van klikken(niet met de muis) en stuur maar heel soms een email naar een abuse adres en vraag me af of dat slim is.

edit:
quote weggehaald was overbodig is post hierboven

Klikken? Onzin. Abuse is abuse, daarom zijn die mail adressen in het leven geroepen. Het kan ook zijn dat je het IP source adress hiermee een dienst mee bewijst dat zijn/haar/hun computers ge-hijacked of geinfecteerd zijn. Niet dat ik voor een BFA* een mailtje stuur, daar maak ik mij niet druk om, zowiezo geblocked. Echter als iemand via snode wijze op een of andere manier toch toegang verschaft en moedwillig probeert te saboteren, zal ik dat zeker rapporteren.
Als een hond elke dag tegen je tuinhekje plast**, zeg je dat toch ook tegen z'n baasje dat ie daar eens mee op moet houden.

*BFA = Brute Force Attack
** Als je 2 kinderen, 1 en 3/4 turf hoog hebt, dan snap je 'm. Maar idd een b-tje off-topic allemaal.

[ Voor 10% gewijzigd door Verwijderd op 25-09-2009 11:10 ]

[Mafketel]

Verwijderd schreef op donderdag 24 september 2009 @ 13:00:
Klikken? Onzin. Abuse is abuse, daarom zijn die mail adressen in het leven geroepen. Het kan ook zijn dat je het IP source adress hiermee een dienst mee bewijst dat zijn/haar/hun computers ge-hijacked of geinfecteerd zijn.

Dat is eigenlijk ook een beetje de reden dat ik het balletje opgooi. Als er veel mensen zijn die dit denken zou ik er over denken om automatisch een mailtje te laten maken die ik desgewenst direct kan forwarden naar het abuse adres.

Niet dat ik voor een BFA een mailtje stuur, daar maak ik mij niet druk om, zowiezo geblocked.

Nu tast ik in het duister wat betreft BFA . Maar ik interpreteer het maar even als elk klein wissewasje, dus die ssh script aanvallen zijn niet belangrijk genoeg om daar een abuse mailtje voor te sturen

Echter als iemand via snode wijze op een of andere manier toch toegang verschaft en moedwillig probeert te saboteren, zal ik dat zeker rapporteren.
Als een hond elke dag tegen je tuinhekje plast, zeg je dat toch ook tegen z'n baasje dat ie daar eens mee op moet houden.

Nou tegen het tuinhekje of de gevel boeit mij niet zo, al vraag ik me wel af hoe deze personen zouden reageren als ik tegen hun huis of hekje sta te urineren . De zin "ik doe anderen niet aan wat ik mijzelf niet wil laten overkomen" zegt erg veel mensen echt helemaal totaal absoluut niks.
Waar ik mij wel zeer aan irriteer zijn de mensen/honden die tegen mijn fiets staan te plassen en meer , deze staat namelijk in zo'n open kooi op straat.
Maar het uiterste is toch wel de mensen die hun hond gewoon tegen mijn motorhoes laten plassen, daar zit .. ... elke dag met mijn handen aan. Als je daar wat van zegt staan ze je aan te kijken ....... of ze denken dat je ze gaat aanvallen , maar begrijpen waar je het over hebt, nee dat gaat te ver.
sorry zeer offtopic maar zeer irritant....