Gå til innhold

[LØST]Mulig med blokkering av hosts som prøver å bruteforce SSH?


Anbefalte innlegg

Får hver dag flere tusen mislykkede innloggingsforsøk med ssh i auth.log.. slik som dette:

 

Klikk for å se/fjerne innholdet nedenfor

Mar 13 06:27:06 archaic sshd[18636]: Invalid user pc06 from 124.192.3.248

Mar 13 06:27:10 archaic sshd[18638]: Invalid user pc07 from 124.192.3.248

Mar 13 06:27:15 archaic sshd[18640]: Invalid user pc08 from 124.192.3.248

Mar 13 06:27:20 archaic sshd[18643]: Invalid user pc09 from 124.192.3.248

Mar 13 06:27:25 archaic sshd[18645]: Invalid user pc10 from 124.192.3.248

Mar 13 06:27:30 archaic sshd[18647]: Invalid user pc11 from 124.192.3.248

Mar 13 06:27:36 archaic sshd[18649]: Invalid user pc12 from 124.192.3.248

Mar 13 06:27:41 archaic sshd[18651]: Invalid user pc13 from 124.192.3.248

Mar 13 06:27:46 archaic sshd[18653]: Invalid user pc14 from 124.192.3.248

Mar 13 06:27:51 archaic sshd[18655]: Invalid user pc15 from 124.192.3.248

Mar 13 06:27:56 archaic sshd[18657]: Invalid user pc16 from 124.192.3.248

Mar 13 06:28:01 archaic sshd[18659]: Invalid user pc17 from 124.192.3.248

Mar 13 06:28:05 archaic sshd[18661]: Invalid user pc18 from 124.192.3.248

Mar 13 06:28:10 archaic sshd[18663]: Invalid user pc19 from 124.192.3.248

Mar 13 06:28:15 archaic sshd[18665]: Invalid user pc20 from 124.192.3.248

Mar 13 06:28:20 archaic sshd[18667]: Invalid user sms from 124.192.3.248

Mar 13 06:28:25 archaic sshd[18669]: Invalid user smf from 124.192.3.248

Mar 13 06:28:29 archaic sshd[18671]: Invalid user svf from 124.192.3.248

Mar 13 06:28:40 archaic sshd[18673]: Invalid user stf from 124.192.3.248

 

De kommer aldri inn uansett, jeg har bra nok sikkerhet, men er litt lei av loggfiler som blir enorme.

 

Er det noen måte å konfigurere systemet på så den evt. blacklister hosts etter et gitt antall mislykkede innloggingsforsøk?

Endret av Sokkalf^
Lenke til kommentar
Videoannonse
Annonse

Jeg bruker:

denyhosts - an utility to help sys admins thwart ssh hackers

Den tar automatisk 3 feilede påloggingsforsøk og legger i hosts.deny.

Foreløpig har den kun hatt jobben med å stenge ute meg selv når jeg har skrevet brukernavn og passord feil for mange ganger...

 

Det er ikke en direkte konfigurasjon da man legger inn noe nytt,,, men skal gjøre jobben:)

Endret av mariunae
Lenke til kommentar
  • 3 uker senere...

Har kjørt public key auth lenge, så at noen skulle komme inn har jeg ikke vært særlig bekymret for.

 

mariunaes løsning har forøvrig fungert strålende, så noen ytterligere tiltak ser jeg ikke som nødvendig.

 

Tviler ikke på at bytte av port tar de aller aller fleste, men det stopper bare de automatiske angrepene fra bots etc. Sitter det noen der som er bestemt på å komme seg inn, tar det ikke lange tiden før han/hun finner ut hvilken port du kjører ssh på. Da er det viktig å sørge for at man har sikkerheten ivaretatt, og ikke kun kjøper seg falsk trygghet ved å tro at portbytte stopper alle.

Lenke til kommentar
Har kjørt public key auth lenge, så at noen skulle komme inn har jeg ikke vært særlig bekymret for.

 

mariunaes løsning har forøvrig fungert strålende, så noen ytterligere tiltak ser jeg ikke som nødvendig.

 

Tviler ikke på at bytte av port tar de aller aller fleste, men det stopper bare de automatiske angrepene fra bots etc. Sitter det noen der som er bestemt på å komme seg inn, tar det ikke lange tiden før han/hun finner ut hvilken port du kjører ssh på. Da er det viktig å sørge for at man har sikkerheten ivaretatt, og ikke kun kjøper seg falsk trygghet ved å tro at portbytte stopper alle.

 

Vel i ditt spørsmål snakker du nettopp om disse streif login forsøkene. Det er sjelden disse ipene kommer tilbake igjen, (slik at denyhosts får noen virkning)

Lenke til kommentar

Klart, jeg hadde sikkerheten på plass og var jo i bunn og grunn ikke bekymret for dem. Alt jeg lette etter var noe som ble kvitt all spamen i loggene (var jo umulig å lete etter reelle situasjoner pga at man måtte vasse gjennom titusenvis av linjer med tull), og det tok denyhosts seg av. Bytte av port hadde funket fint det og, men jeg er såpass lat at jeg ikke gidder ekstraarbeidet med å konfigurere en haug med klienter til å bruke riktig port.

Lenke til kommentar

Jeg mener ikke å flisespikke, men hvis 10-20 ip'er hver får 3 forsøk hver periode (el. lignende gjennom denyhosst), vil det fortsatt bli tilsvarende mange entries i loggen, i tillegg til de entries som er lovlige (fra dine klienter)

 

Min erfaring fra når jeg brukte deny.hosts , var at samme IP sjelden kom tilbake for å prøve igjen.

 

Du kan enkelt kjøre sshd på 2 porter, en på 22 og en på annet.tall.her , og tillate kun dine klienter på port 22 og den.andre.porten for resten av verden

 

EDIT: småtterier

Endret av Torbjørn
Lenke til kommentar

3 forsøk hver blir 3 entries i loggen. Det er en enorm forbedring fra de tusentalls entries jeg hadde fra enkelte IPer før.

 

Nå har jeg ~450 entries i loggen per dag.

Før hadde jeg mellom 15000 og 20000 entries i loggen per dag.

 

Denyhosts har dermed hjulpet betraktelig for meg, uten noen ekstra config av ssh overhodet. Jeg anser det dermed som den beste løsningen (for meg!).

Lenke til kommentar
Tviler ikke på at bytte av port tar de aller aller fleste, men det stopper bare de automatiske angrepene fra bots etc. Sitter det noen der som er bestemt på å komme seg inn, tar det ikke lange tiden før han/hun finner ut hvilken port du kjører ssh på. Da er det viktig å sørge for at man har sikkerheten ivaretatt, og ikke kun kjøper seg falsk trygghet ved å tro at portbytte stopper alle.

Det er sant, men i løpet av alle årene jeg har kjørt SSH-server på non-standard port, har jeg aldri opplevd et eneste innbruddsforsøk. Dette i skarp kontrast til alle forsøkene på ymse brukernavn/passord-kombinasjoner som har vært testet mot port 22.

 

Det skal litt til før noen gidder å portscanne alle 65536 portene på en tilfeldig maskin, så da må det nesten være noen som kjenner deg og har et spesielt ønske om å bryte seg inn på akkurat DIN server. Eller at du jobber i Pentagon, NSA osv. :p

 

Men såklart, man skal ikke basere sikkerheten alene på dette. Er også viktig med oppdatert programvare og gode passord (evt. RSA/DSA keys)

Endret av Langbein
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...