Hackingförsök?

[nire]

Hej, efter att ha läst i loggfilen på min server så hittar jag det här.

Vad betyder det? Har nån kommit åt min nyckel och försöker logga in?

 

 

sshd:

Authentication Failures:

unknown (200.63.217.xxx): 282 Time(s)

root (200.63.217.xxx): 38 Time(s)

mysql (200.63.217.xxx): 2 Time(s)

adm (200.63.217.xxx): 1 Time(s)

apache (200.63.217.xxx): 1 Time(s)

ftp (200.63.217.xxx): 1 Time(s)

games (200.63.217.xxx): 1 Time(s)

mail (200.63.217.xxx): 1 Time(s)

news (200.63.217.xxx): 1 Time(s)

nobody (200.63.217.xxx): 1 Time(s)

operator (200.63.217.xxx): 1 Time(s)

rpm (200.63.217.xxx): 1 Time(s)

sshd (200.63.217.xxx): 1 Time(s)

Invalid Users:

Unknown Account: 282 Time(s)

 

 

Failed logins from:

200.63.217.xxx(xxx.217.uio.satnet.net): 50 times

 

Illegal users from:

200.63.217.xxx(xxx.217.uio.satnet.net): 282 times

 

 

[mk22gq]

Kan du inte begränsa med t.ex iptables vilka adresser som får ansluta till ssh (port 22)!

 

[fhe]

Det är bara en massa robotar som kryper omkring på nätet och testar vanlig ssh-inloggning med vanliga användarnamn, jag har inte kollat vad de kör för lösenord men hos mig verkar det bara bli ett par försök per user så jag antar att de helt enkelt testar inget alls och samma password som usern (säkert inte helt ovanligt med apache/apache).

 

iptables tycker jag är för jobbigt att använda för ändamålet så jag kör istället DenyHosts (http://denyhosts.sourceforge.net/).

Den uppdaterar /etc/hosts.deny baserat på misslyckade försök i logfiler samt från en central databas dit andra laddat upp sina erfarenheter.

 

Fungerar ruskigt bra, trots att jag bara har folk svartlistade i en vecka har jag just nu 1500 IP-adresser mot vilka mina tjänster helt enkelt inte svarar på tilltal.

 

(för den som undrar: jo, det skulle kanske gå att infiltrera den centrala databasen så att man av ren illvilja kan låsa ut folk men den är inte så korkad och har rätt bra med möjligheter för att hindra att datorägaren själv blir utlåst).

 

[Coleburn]

Iptables tycker jag är för jobbigt att använda för ändamålet så jag kör istället DenyHosts (http://denyhosts.sourceforge.net/).

 

...vilket kurerar symptomen märkbart, och definitivt stoppar brute-force mot root-pwd.

 

Den stora, och obegripliga, frågan är däremot:

Varför har ingen byggt in en liknande funktionalitet i sshd?

x antal misslyckade inloggningar inom y minuter leder till z minuters deny . Enkla configvärden i sshd_config och saken skulle vara klar, istället för att man måste fibbla med 3:e parts lösningar och/eller iptables.

 

 

==Coleburn==

 

--------------------

"It takes a lot of knowledge to

really mess something up!"

 

[inlägget ändrat 2006-11-28 23:10:55 av Coleburn]

[fhe]

Varför har ingen byggt in en liknande funktionalitet i sshd?

Jag vet naturligtvis inte men om jag fick gissa så skulle gissningen vara att det är smartare att ha det på en annan nivå helt enkelt för att man inte bara vill begränsa möjligheten att gissa med ssh utan även med andra tjänster och då blir det ju bara mer jobb om alla applikationer ska tvingas ha en liknande funktion.

 

[nire]

Om jag fattat det rätt så

* behöver nån inte nödvändigtvis ha kommit åt min nyckel?

 

* och sålänge nån inte har min nyckel kommer den personen omöjligt in?

 

Så jag behöver alltså inte bry mej så mycket av vad som står i loggarna sålänge okända ipadresser inte står under lyckade inloggningar?

 

Och denyhosts kan jag använda för att slippa se massa misslyckade inloggningar i loggen men har ingen större betydelse eftersom det inte går att komma in ändå?

För jag kan inte förstå hur nån skulle ha kommit åt nyckeln.

 

Tack för svaren!

 

 

[fhe]

behöver nån inte nödvändigtvis ha kommit åt min nyckel?

Jag förstår inte riktigt varför du tror att någon nyckel har med saken att göra men "nej".

 

och sålänge nån inte har min nyckel kommer den personen omöjligt in?

Det beror väl på hur du har konfigurerat din ssh, det är relativt ovanligt att folk konfigurerar ssh så att det bara går att logga in med en publik och privat nyckel. Default fungerar lösenordsinloggning lika bra och det är det man försöker använda.

 

Så jag behöver alltså inte bry mej så mycket av vad som står i loggarna sålänge okända ipadresser inte står under lyckade inloggningar?

Det är enklare att se eventuella lyckade intrång (inte bara över ssh) om man inte har loggar fulla med rapporter om misslyckade försök så jag tycker nog det kan vara värt att bry sig, dessutom tar det mindre kraft av datorn om den inte ens bryr sig om att öppna dörren när kända robotar knackar på.

 

men har ingen större betydelse eftersom det inte går att komma in ändå?

Är du verkligen så duktig att du kan garantera att det inte finns något sätt att komma in på din dator med 100% säkerhet? Om du tror det skulle jag föreslå att du funderar igen, om du inte tror det så skadar det knappast att minska risken.

 

 

[nire]

Jag förstår inte riktigt varför du tror att någon nyckel har med saken att göra men "nej".

Men som jag föstått det så måste man ha den privata nyckeln som matchar serverns publika för att kunna logga in (med lösenord)?

 

Det beror väl på hur du har konfigurerat din ssh

Jag har inte gjort några konfigureringar utan jag har använt fedoras rpm för att installera bara.

 

[fhe]

Men som jag föstått det så måste man ha den privata nyckeln som matchar serverns publika för att kunna logga in (med lösenord)?

Nej

 

[nire]

Okej känner att ja måste plugga på lite i ämnet

Men vad har man isf nycklarna till?

Dom används väl för att kryptera och dekryptera datan som skickas emellan?

Jag säger inte att jag inte tror dej när du säger att det funkar utan rätt nyckel, jag tror dej, men hur funkar det som då?

 

[fhe]

Publika och privata nyklar när det gäller ssh använder man som ett sätt att identifera sig om man inte vill använda lösenord (det blir som ett flera hundra tecken långt lösenord som är väldigt svårgissat).

 

Inledningen till den här texten förklarar lite om hur det fungerar:

http://the.earth.li/~sgtatham/putty/0.55/htmldoc/Chapter8.html

 

[nire]

Okej tack för svaren !

 

[mk22gq]

nycklarna är till för den krypterade anslutningen som som skiljer ssh från telnet som skickar allt i klartext.

 

[nire]

okej men hur kan man logga in utan rätt nyckel om det man skickar är krypterat med en nyckel som inte stämmer överens med nyckeln på servern?

användarnamnet o lösenordet borde väl inte kunna dekrypteras isf. tycker jag?

 

 

[fhe]

okej men hur kan man logga in utan rätt nyckel om det man skickar är krypterat med en nyckel som inte stämmer överens med nyckeln på servern?

För att signaturen mk22qq blandar ihop saker.

Ett public/private nyckelpar används bara om man använder den sortens inloggning, använder man lösenord skiter ssh-servern fullständigt i din publika och privata användarnyckel. Precis som den struntar i om du har ett kort i en kortläsare, en engångskod på ett skrapkort eller något annat sätt att verifiera att du är du.

 

Att ssh-sessionen som sådan är krypterad har inte med saken att göra, det är en helt annan nyckel.

 

[mk22gq]

När du ansluter till din ssh server så får du serverns PUBLIKA nyckel skickad till dig och servern får din PUBLIKA nyckel från dig.

 

Så att allting du skriver endast kan dekrypteras av rätt server som har den skyddade PRIVATA nyckeln. Likaså kan endast du dekryptera det som krypterats med din PUBLIKA nyckel.

 

Nu kan lösenord och resten skickas utan att någon annan få ut nåt vettigt av det, även om de kan avlyssna sessionen så kan de ej dekryptera datan utan att ha rätt PRIVATA nyckel. Den privata nyckeln hålls därför alltid hemlig.

 

Googla lite på assymetrisk kryptering så får du nog mer info.

 

[mk22gq]

För att signaturen mk22qq blandar ihop saker.

OK, trodde ni snackade om certifikatet man godkänner när man ansluter, inte om automatisk inloggning med delade nycklar.