Forum Mjukvara Linux och övriga operativsystem Tråd

Massvis med SSH anslutningar

1 2
Skriv svar
Permalänk
Medlem
●

Massvis med SSH anslutningar

Hej. Jag har upptäckt en sak på min maskin som kör debian som verkar lite oroväckande. Jag är inte så haj på sånt här men jag anar att något är fel.

Om jag kör netstat -a | grep ssh får jag ut massvis med rader. Här är ett urklipp.

2574/inetd      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      4099/sshd       
tcp        0      0 0.0.0.0:39191           0.0.0.0:*               LISTEN      1848/rpc.statd  
tcp        0      0 192.168.1.49:50392      207.58.151.50:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:55934      112.78.205.12:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:51610      112.78.201.172:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:45866      112.78.205.176:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:57398      207.58.140.92:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:37463      112.78.205.106:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:45554      112.78.201.95:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:34166      207.58.152.149:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:47026      112.78.204.140:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:38523      207.58.149.47:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:44488      112.78.201.136:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:37941      207.58.141.171:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:41490      112.78.201.63:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:40619      207.58.151.245:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:40852      112.78.201.63:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:43597      207.58.149.64:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:51844      207.58.150.68:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:54965      207.58.151.43:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:45589      112.78.205.143:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:36527      207.58.149.115:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:58287      112.78.205.150:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:41843      207.58.141.171:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:33843      112.78.204.209:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:38250      207.58.150.84:22        TIME_WAIT   -               
tcp        0     20 192.168.1.49:59365      112.78.205.17:22        ESTABLISHED 12040/sshd      
tcp        0      0 192.168.1.49:38322      112.78.204.92:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:35372      112.78.201.76:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:53592      112.78.201.165:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:37493      112.78.200.78:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:48189      207.58.149.184:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:42869      207.58.150.241:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:41663      207.58.145.197:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:45174      207.58.150.235:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:37645      112.78.201.76:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:53921      207.58.145.230:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:59529      112.78.200.228:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:54892      207.58.148.178:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:52712      207.58.151.117:22       TIME_WAIT   -               
tcp        0      0 192.168.1.49:47727      112.78.200.38:22        TIME_WAIT   -               
tcp        0      0 192.168.1.49:50836      207.58.151.95:22        ESTABLISHED 12255/ssh

Totalt så är det säkert tusentals rader. Betyder det är att folk från dessa IPn försöker ansluta till min dator?
När det står ESTABLISHED, betyder de att de har lyckats ansluta och tagit sig in? Någon som har något förslag på vad detta kan vara och vilka åtgärder som jag bör vidta.

Här kommer ett utklipp från top också som visar hur många processor (ssh och sshd som körs). Är inte detta lite konstigt?

 9256 1004      20   0   964  548  464 S  0.7  0.1   0:29.54 ssh                
 9441 1004      20   0   964  548  464 S  0.7  0.1   0:31.26 ssh                
 9461 1004      20   0   964  548  464 S  0.7  0.1   0:25.78 ssh                
 9525 1004      20   0   964  564  480 S  0.7  0.1   0:24.46 ssh                
 9820 1004      20   0   964  548  464 S  0.7  0.1   0:24.80 ssh                
 9908 1004      20   0   964  548  464 S  0.7  0.1   0:22.76 ssh                
 9923 1004      20   0   964  548  464 S  0.7  0.1   0:22.56 ssh                
10386 1004      20   0  1912  864  444 S  0.7  0.1   0:16.10 sshd               
10389 1004      20   0  1912  864  444 S  0.7  0.1   0:16.08 sshd               
10392 1004      20   0  1912  864  444 S  0.7  0.1   0:16.24 sshd               
10396 1004      20   0  1912  864  444 S  0.7  0.1   0:16.04 sshd               
10401 1004      20   0  1912  864  444 S  0.7  0.1   0:16.00 sshd               
10416 1004      20   0  1912  864  444 S  0.7  0.1   0:16.02 sshd               
10438 1004      20   0  1912  864  444 S  0.7  0.1   0:15.96 sshd               
10439 1004      20   0  1912  864  444 S  0.7  0.1   0:16.20 sshd               
10455 1004      20   0  1912  864  444 S  0.7  0.1   0:16.32 sshd

Tack för din tid!

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Kolla upp /var/log/auth.log så ser du vad som pågår. Förmodligen botar som försöker bruteforca lösen.
Sätt upp SSHd på en annan port än 22 och installera fail2ban.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Just det! Glömde output från auth.log

tail /var/log/auth.log ger följande

Jul  1 17:07:01 servern CRON[12510]: pam_unix(cron:account): could not identify user (from getpwnam(downs))
Jul  1 17:08:01 servern CRON[12511]: pam_unix(cron:account): could not identify user (from getpwnam(downs))
Jul  1 17:09:01 servern CRON[12512]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul  1 17:09:01 servern CRON[12520]: pam_unix(cron:account): could not identify user (from getpwnam(downs))
Jul  1 17:09:01 servern CRON[12512]: pam_unix(cron:session): session closed for user root
Jul  1 17:10:01 servern CRON[12527]: pam_unix(cron:account): could not identify user (from getpwnam(downs))
Jul  1 17:11:01 servern CRON[12528]: pam_unix(cron:account): could not identify user (from getpwnam(downs))
Jul  1 17:12:01 servern CRON[12529]: pam_unix(cron:account): could not identify user (from getpwnam(downs))
Jul  1 17:13:01 servern CRON[12531]: pam_unix(cron:account): could not identify user (from getpwnam(downs))
Jul  1 17:14:01 servern CRON[12532]: pam_unix(cron:account): could not identify user (from getpwnam(downs))

Användaren som heter downs har jag tagit bort. Det var ett gammalt konto som jag inte längre använder.

En annan konstig sak jag har lagt märkte till är detta

tail /var/log/message

Jul  1 17:14:29 servern kernel: [961132.150046] ssh[12534]: segfault at 0 ip 08048e33 sp bfe45450 error 4 in ssh[8048000+c0000]
Jul  1 17:14:29 servern kernel: [961132.474874] ssh[12535]: segfault at 0 ip 08048e33 sp bfe45450 error 4 in ssh[8048000+c0000]
Jul  1 17:15:37 servern kernel: [961200.213941] ssh[12499]: segfault at 0 ip 08048e33 sp bfe45450 error 4 in ssh[8048000+c0000]
Jul  1 17:15:37 servern kernel: [961200.230580] ssh[12501]: segfault at 0 ip 08048e33 sp bfe45450 error 4 in ssh[8048000+c0000]
Jul  1 17:15:37 servern kernel: [961200.403633] ssh[12543]: segfault at 0 ip 08048e33 sp bfe45450 error 4 in ssh[8048000+c0000]
Jul  1 17:15:37 servern kernel: [961200.442399] ssh[12544]: segfault at 0 ip 08048e33 sp bfe45450 error 4 in ssh[8048000+c0000]
Jul  1 17:15:37 servern kernel: [961200.556430] ssh[12536]: segfault at 0 ip 08048e33 sp bfe45450 error 4 in ssh[8048000+c0000]
Jul  1 17:15:37 servern kernel: [961200.594203] ssh[12545]: segfault at 0 ip 08048e33 sp bfe45450 error 4 in ssh[8048000+c0000]
Jul  1 17:15:39 servern kernel: [961201.849242] ssh[12541]: segfault at 0 ip 08048e33 sp bfe45450 error 4 in ssh[8048000+c0000]
Jul  1 17:15:39 servern kernel: [961201.935276] ssh[12542]: segfault at 0 ip 08048e33 sp bfe45450 error 4 in ssh[8048000+c0000]

Segfault, låter inte så bra. Vad kan det tänkas vara?

Angående att byta port som sshd lyssnar på. Den lyssnar väll på port 22 och de inkommande anslutningarna går ju till portar på 40-50000. Hur kan de då ansluta till sshd? Jag är lite förvirrad över detta

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●

Av informationen du gett ser det ut som att det är tvärtom.. användaren downs kör ett cronscript varje minut som försöker ansluta till ett par olika ssh-servrar. Om det inte är något du satt upp själv är det ganska troligt att din server blivit hackad.

Visa signatur

Det kan aldrig bli fel med mekanisk destruktion

Redigera
Citera flera Citera
Permalänk
Medlem
●

Det var lite det jag hade på känn också, för om jag minns rätt så var lösenordet till downs kontot väldigt simpelt.

Om jag kör cat /etc/passwd | grep downs så får jag blankt som svar. Detta tyder på att downs-konto är borta, inte sant?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Det är du som ansluter till andra datorer ditt jävla spån :D. Nån har tagit sig in o börjat bruteforca andra datorer från din. Kolla top/ps efter suspekta program som körs.

Råkade själv ut för samma sak när jag glömde kvar ett konto som hette test med lösen test :).

Visa signatur

CCNP

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av maniak:

Det är du som ansluter till andra datorer ditt jävla spån :D. Nån har tagit sig in o börjat bruteforca andra datorer från din. Kolla top/ps efter suspekta program som körs.

Råkade själv ut för samma sak när jag glömde kvar ett konto som hette test med lösen test :).

Gå till inlägget

Hehe! Ja, verkar som att de redan är inne hos mig

Om du tar en titt på mitt första inlägg så postade jag ett urklipp från top som visar massvid med ssh/sshd processer som ligger igång. Kan jag få reda på vilket konto som skapade processen?

Vad är nästa steg? Lösenordsbyte på alla konton, en omstart av servern kanske för att bli av med alla skräpprocesser som ligger igång.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Yes råkade ut för deta för MÅNGA år sedan när jag försakade min router i väntan på en ny opch lämnade port 22 öppen i iptables.
Först och främst. SSH ska inte ligga på port 22.
Sedan ska du disabla Root som användare som får logga in.
Vill du bli root är det bättre med en annat konto som kan logga in via ssh som har rätt att bli root via su eller sudo.
efter det så är det alltid bra med nåt program eller script som kollar om ett anslutning försöker logga in via icke tillåtna användare då primärt root eller försöker ansluta via port 22 sedan även om användaren är giltlig men inte lösenordet så bör man ha en limit på tex 3 försök. Så försöker någon logga in med root användaren så banas dom omgående eller misslyckas att logga in efter tex 3 försök med fel lösenord så banas IP:et säg en vecka. Finns sådana program och dessa parametrar går att confa.

Som någon sa du har troligen redan blivit hackad av ett sådan här script och vad det gör är att det i sin tur tankar ner sig från någon server och sedan startar flera liknande script och försöker ta över fler datorer som har dålig säkerhet på ssh och root kontot och ligger på default port 22. Dessa script använder ofta en lista på vanliga lösenord som ligger på en server på nätet.
Därför bör du ha nåt helt ologiskt lösenord med blandade siffror och bokstäver typ 20 tecken lågt så kan dom aldrig matcha det mot någon ordlista eller liknande.

För att bli av med det får du hitta vad dessa script och program har lagt sig. Döda dess processer och sedan radera alla filerna. Lägger sig ofta nånstans där igen tänker påt /tmp tex eller i en hemmadir kanske. Startar du bara om så kommer dom garanterat starta upp sig igen då dom säkert lagt en rad i nån av iniscripten för bootprocessen.

Visa signatur

Yotube videos om retro hårdvara och spel
Gallerier om retro hårdvara
Brain Drain Retro Lan Discord server
Braindrain Retro Lan social media websida

Redigera
Citera flera Citera
Permalänk
Medlem
●

Mitt root-lösenord är väldigt ologiskt. Det är långt och innehåller specialtecken. Ska byta från port 22 och se till att root inte kan logga in, tack för tipset!

Nu är alla downs processer dödade och netstat visar inte längre en massa äckliga anslutningar. Även outputen från ps -ae ser i mina ögon normal ut.

Då gäller det alltså att hitta scriptet som kördes. Ska leta igenom de mapparna du nämde. Finns det någon annan taktik för att hitta dem? Om scripten körs av cron borde väll cron på något sätt ha koll på vart scripten ligger? Användaren downs hade för övrigt ingen egen hemmapp.

Redigera
Citera flera Citera
Permalänk
Medlem
●

först o främst borde du BLÅSA servern helt så ALLT försvinner. Lägg inte in något som du inte vet vad är från gamla installationen på den nya installationen

Sedan ska ALLA användare som kan logga in via ssh ha lösenord på minst 10 random tecken.

Sedan byt port på ssh.

När du gjort detta kan du sova bättre på nätterna

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av Droogie:

Hehe! Ja, verkar som att de redan är inne hos mig

Om du tar en titt på mitt första inlägg så postade jag ett urklipp från top som visar massvid med ssh/sshd processer som ligger igång. Kan jag få reda på vilket konto som skapade processen?

Gå till inlägget

1004 är id-nummer för användaren som äger processen, kör "id 1004" för att få ett namn.

Citat:

Vad är nästa steg? Lösenordsbyte på alla konton, en omstart av servern kanske för att bli av med alla skräpprocesser som ligger igång.

Om jag var du skulle jag installera om hela operativsystemet. Om den som hackat dig lyckats bli root kan han ha lagt in bakdörrar som är omöjliga att upptäcka.

Visa signatur

Det kan aldrig bli fel med mekanisk destruktion

Redigera
Citera flera Citera
Permalänk
Medlem
●

Du bör som andra rekommenderar installera om hela maskinen.

Det är omöjligt att veta om den som kommit in i maskinen gjort något ytterligare (har de lyckats bli root kan de ta bort alla spår av att de blivit root).

Förutom tipsen att köra ssh på annan port än 22 och att inte tillåta root att logga in via ssh så går det även att använda rsa-nycklar för att logga in.
SSH with authentication key instead of password

Då måste alltså den som loggar in remote ha en nyckel (och lösenordet till den) för att komma åt maskinen.
Lokalt går det fortfarande bra att logga in med användarnamn och lösen (även root).

Visa signatur

"Computers make it easier to do a lot of things, but most of the things they make it easier to do don't need to be done." - Andy Rooney

Redigera
Citera flera Citera
Permalänk
Medlem
●

Tack för all er hjälp. Får väll bli en ominstallation någon dag nu då samt lite mer kryptiska lösenord

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag sitter här och försöker komma fram till vad det egentligen är som har hänt. Borde inte alla misslyckade inloggningsförsök loggas? Hamnar de i filen /var/log/faillog? Den filen är nämligen inte läsbar för mig.

Samt, hur fan kan de bruteforca sig in på ett konto när de inte ens vet username (downs i mitt fall). Måste de ha tagit sig in via root-kontot? Där har jag som sagt ett relativt starkt lösenord.

Här är en del av outputen från kommandot last (visar lyckade inloggningar). Notera att jag personligen aldrig har loggat in med kontot downs 

downs    pts/0        s15310349.online Thu May 13 20:55 - 20:55  (00:00)    
xx      pts/0        cxx-xx-xx-xx. Thu May 13 18:52 - 20:16  (01:23)    
downs    pts/0        s15310349.online Wed May 12 23:04 - 23:04  (00:00)    
xx      pts/0        cxx-xx-xx-xx. Wed May 12 15:13 - 15:14  (00:00)    
downs    pts/0        oilennium.com    Mon May 10 16:05 - 16:06  (00:00)    
downs    pts/1        oilennium.com    Sun May  9 19:10 - 19:11  (00:00)    
downs    pts/0        oilennium.com    Sun May  9 18:58 - 21:09  (02:11)    
xx      pts/0       xx-xx-xx-xx. Sun May  9 12:40 - 12:44  (00:03)    
downs    pts/0        oilennium.com    Sat May  8 22:05 - 22:07  (00:01)    
downs    pts/0        oilennium.com    Fri May  7 18:35 - 18:36  (00:01)       
xx      pts/2        xxx-xx-xx. Thu May  6 23:05 - 23:05  (00:00)    
xx      pts/1        xx-xx-xx-xx. Thu May  6 21:51 - 00:12  (02:21)

xx är egentligen andra konton som jag använder. 7 maj kom första lyckade inloggningen med kontot downs.

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●

Ifall du hade blankt lösenord på downs-kontot (eller lösenord "downs" eller liknande) så kan det mycket möjligen ha ingått i en dictionaryattack mot din SSH-server där de helt enkelt bara testar en stor mängd användarnamn med triviala lösenord och noterar när de lyckas. Det är antagligen precis det som din dator har stått och gjort åt någon illvilig person sedan intrånget skedde.

För att skydda sig mot SSH-attacker kan fail2ban som någon nämnde vara värt att kolla upp. Själv använder jag LIMIT-reglen i Shorewall.

Ominstallation är trevligt. En annan sak man kan göra för att skydda sig mot SSH-attacker är att explicit ange de konton man vill ge SSH-access, så kryper inte "test"-konton och liknande igenom.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Lösenordet till kontot downs var enkelt. Minns inte exakt men ett ord på 4-5 bokstäver, inte downs dock.

fail2ban verkar vara ett mycket bra och lätthanterligt program. Det ska jag använda mig utav i fortsättningen!

Redigera
Citera flera Citera
Permalänk
Medlem
●

Personligen tycker jag att det är lite omständigt att byta SSH port, beror väll lite på vad man har burken till iofs men använder man program som använder SSH behöver man oftast använda lite special syntax vid de tillfällena.

Lite tips

Connecton limit med tex iptables är ett bra sätt, och förståss bra användar hantering och lösenord som redan nämts.

Två program som kan vara värt att ta en titt på är rkhunter och denyhosts. rkhunter gör bäst nytta om man lagt in det direkt efter OS installationen då man vet att allt är orört. I det fallet systemet redan är kontaminerat kan det dock rensa bort en del rootkits osv men övriga kontroller kan man inte riktigt lita på. Denyhosts är ett alternativ till fail2ban, tycker att det gör ett bättre jobb samt är implementerat på ett bättre sätt(använder host-filerna istället för iptables).

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Intenso:

Denyhosts är ett alternativ till fail2ban, tycker att det gör ett bättre jobb samt är implementerat på ett bättre sätt(använder host-filerna istället för iptables).

Gå till inlägget

Jag tolkar det som att du anser det bättre att stoppa i host-filerna än iptables. Varför?
IPtables stoppar väl tidigare än host-filerna?

Visa signatur

01001000 01100001 01110010 00100000 01100100 01110101 00100000 01110100 01110010 10000110 01101011 01101001 01100111 01110100 00111111 00100000 00111010 00101001

Redigera
Citera flera Citera
Permalänk
Medlem
●

Kanske det här skulle fungera bättre mot bruteforce?

Block brute force attacks with iptables

Redigera
Citera flera Citera
Permalänk
Medlem
●

De senaste åren har de distribuerade bruteforce-attackerna ökat markant, iallafall hos mig. Det är inte ovanligt att man ser användaren "anna" försöka logga in varannan sekund, fast varje gång från ett nytt ip-nummer. Sen kommer det 100 inloggningsförsök från "berit", varje gång från ett nytt ip. Så håller det på i all oändlighet. Det är lite svårare att filtrera bort.

Visa signatur

"Linux is good because it keeps people out of real kernels"

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Intenso:

Personligen tycker jag att det är lite omständigt att byta SSH port, beror väll lite på vad man har burken till iofs men använder man program som använder SSH behöver man oftast använda lite special syntax vid de tillfällena.

Lite tips

Connecton limit med tex iptables är ett bra sätt, och förståss bra användar hantering och lösenord som redan nämts.

Två program som kan vara värt att ta en titt på är rkhunter och denyhosts. rkhunter gör bäst nytta om man lagt in det direkt efter OS installationen då man vet att allt är orört. I det fallet systemet redan är kontaminerat kan det dock rensa bort en del rootkits osv men övriga kontroller kan man inte riktigt lita på. Denyhosts är ett alternativ till fail2ban, tycker att det gör ett bättre jobb samt är implementerat på ett bättre sätt(använder host-filerna istället för iptables).

Gå till inlägget

ssh klienten har ju -p flaga för porten och många program fungera : efter ip addresen bra och sedan porten bara. brukar fungera med user@ip:port
typ sånt. har kört så i många år nu utan problem.

sedan får man ju ha lite regler i iptables med och har man inte nytta för SSH utifrån så är det ju bara att blocka porten.

Visa signatur

Yotube videos om retro hårdvara och spel
Gallerier om retro hårdvara
Brain Drain Retro Lan Discord server
Braindrain Retro Lan social media websida

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Att byta port för ssh är tämligen tandlöst och invaggar ett falskt säkerhetstänkt, scripten som folk använder kollar ju ändå vad för tjänst som svarar på respektive port så om du flyttar sshd till port 33293 så kommer dom bara ansluta mot den istället. Visst alla script kanske inte gör så men bara att flytta porten är ju ingen lösning och om du dessutom inte har någon användare som heter "berit" eller "anna" på din dator så spelar det ju ingen roll hur många gånger dom försöker logga in som någon av dom för dom användarna finns ju inte i systemet.

Däremot att slå av root-login och sätta deny all och sedan explicit allow på dom/den användare som ska få logga in är en bra lösning, och sedan använda sig av typ fail2ban så är saken biff. Bruteforce försök är ju sällan lyckade ändå så länge man inte har något lösenord som förekommer i dom vanligaste dictionary attackerna men om du inte använder dig av ett vanligt ord typ "Katt" så har du ju redan där minimerat chanserna att någon nånsin ska lista ut ditt lösenord. Sedan behöver ju inte just den här rootningen ha kommit via ssh det kan ju lika gärna vara en opatchad FTPD eller dylikt som utnyttjats för anslutningarna utåt är ju resultatet av vad den som tog sig in i servern hade för avsikt att använda den till.

Visa signatur

Cisco - Linux - VMWare
-- Citera mig om ni vill få återkoppling --

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag använder fail2ban för att förhindra bruteforce.

Visa signatur

Intel i5 6600K | Be Quiet, Pure Rock! | Asus Z170 Pro Gaming | Asus GTX 1070 Strix Gaming | HyperX 16 GB (2x8GB) DDR4 2133MHz Fury Black | Samsung 850 Evo 250GB | Skärm: Samsung S27D390H | Chassi: Fractal Design Define R4 Black
Spelnick: Jernhand

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av =JoNaZ=:

först o främst borde du BLÅSA servern helt så ALLT försvinner. Lägg inte in något som du inte vet vad är från gamla installationen på den nya installationen

Sedan ska ALLA användare som kan logga in via ssh ha lösenord på minst 10 random tecken.

Sedan byt port på ssh.

När du gjort detta kan du sova bättre på nätterna

Gå till inlägget

Jag håller med denna användaren om att du borde blåsa datorn, ändra lösenorden på alla dina konton och uppdatera ditt OS kontinuerligt därefter.

Det verkar som någon fick tillgång till din dator och använde den som en attackplattform.

Att byta porten SSH tjänsten lyssnar på är lönlöst. fail2ban är lönlöst om attackern har åtskilliga adresser att attackera från. Detta är ett bra sätt för att undvika bli attackerad. fwknop: Single Packet Authorization and Port Knocking

SSH tjänsten döljs helt och hållet för hackaren.

Om du inte vill blåsa burken så rekommenderar jag att du laddar ner en ny ps (binärfilen) på ett USB-minne från en säker burk och stoppar in i din hackade burk. På så sätt kan du köra en ickemodifierad version av ps. Chansen finns nämligen att hackaren har modifierat ditt ps verktyg för att inte visa eventuella bakdörrar till ditt system som denne har installerat.

Du kan även testa detta: Various ways of detecting rootkits in GNU/Linux | All about Linux

Lycka till.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Följande ändringar tar 10 sekunder att genomföra och är ett minimum vad man bör göra efter installation:

/etc/ssh/sshd_config:

Port 7391 #valfritt nummer över 1023
PermitRootLogin no
AllowUsers user1 user2 #lägg till alla användare som skall ha ssh access
sudo /sbin/service sshd reload

Jag får inga loginförsök alls efter att jag byter port på mina servrar som står direkt mot internet, men det är ju lämpligt att använda Fail2ban och liknande tjänster ändå.

Tror inte det är många botar som står och portscannar 10k-tals portar när de flesta kör på port 22 ändå, men det förekommer säkert.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av paddaw:

Följande ändringar tar 10 sekunder att genomföra och är ett minimum vad man bör göra efter installation:

/etc/ssh/sshd_config:

Port 7391 #valfritt nummer över 1023
PermitRootLogin no
AllowUsers user1 user2 #lägg till alla användare som skall ha ssh access
sudo /sbin/service sshd reload

Jag får inga loginförsök alls efter att jag byter port på mina servrar som står direkt mot internet, men det är ju lämpligt att använda Fail2ban och liknande tjänster ändå.

Tror inte det är många botar som står och portscannar 10k-tals portar när de flesta kör på port 22 ändå, men det förekommer säkert.

Gå till inlägget

Jo, precis. Det stoppar bottar som bara kör port 22, men det ger inte någon säkerhet.

Visa signatur

CCNP

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

denyhosts är ett ypperligt fint program för att förhindra bruteforce försök, vid temporära attacker. Men ställ in dina IP addresser så att de inte blir blacklistade när du själv råkar skriva fel lösenord några gånger, annars blir man lätt utlåst.
Men får man ett riktigt bottnät på sig så hjälper det inte så himla mycket.

Övrigt kan man också aktivera pam_access och ställa in vilka användare får ansluta från vilka addresser. tror det finns lite dokumentation i /etc/security/access.conf

Annars kan man ju alltid köra port-knocking också, jag är lite tveksam till att "bara" ändra port för SSHn.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Hej, lånar tråden lite
Förlåt om jag är en total noob just nu, men fick syn på den här tråden och fattar inte jättemycket men tycker det är ganska intressant ändå.

Gäller det ni snackar om servrar eller är det för "vanliga" datorer också?
Testade köra netsat och fick ju upp några established jag med, så nu sitter man ju här och är rädd som fan att man sitter med elaka saker i burken (lite pga att jag inte fattar så mycket ).
Vet att man kanske borde skydda sig bättre, men sitter med datorn kopplad direkt mot modemet och är skyddad med AVG och Ad-aware.

Edit: Och hur urskiljer man i sånt fall vad som försöker tränga sig på och vad som ska vara där?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av MP636:

Hej, lånar tråden lite
Förlåt om jag är en total noob just nu, men fick syn på den här tråden och fattar inte jättemycket men tycker det är ganska intressant ändå.

Gäller det ni snackar om servrar eller är det för "vanliga" datorer också?
Testade köra netsat och fick ju upp några established jag med, så nu sitter man ju här och är rädd som fan att man sitter med elaka saker i burken (lite pga att jag inte fattar så mycket ).
Vet att man kanske borde skydda sig bättre, men sitter med datorn kopplad direkt mot modemet och är skyddad med AVG och Ad-aware.

Edit: Och hur urskiljer man i sånt fall vad som försöker tränga sig på och vad som ska vara där?

Gå till inlägget

AVG och Ad-aware, då kör du Windows? Detta gäller Linux/Unix-varianter med en SSH daemon. Du behöver inte oroa dig över dina "ESTABLISHED".

Redigera
Citera flera Citera
Permalänk
Medlem
●

Aha! Missade helt att det bara gällde Linux. Tack för svaret iaf

Redigera
Citera flera Citera
1 2
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara