Gyanakodjak feltörésre?

Linux-kezdő

Kedves HUP-osok!

Sajnos a biztonsági kérdéseknek nem vagyok szakértője. Követem a híreket, nagyjából tudom, miről is van szó, de a részleteket nem értem.

A problémám a következő. Évek óta dolgozok úgy, hogy a munkahelyi gépem éjjel-nappal bekapcsolva megy, hogy itthonról fájlokat tudjak szinkronizálni, futtatást indítani, stb. A munkahelyi gépen egy Ubuntu 12.10 fut, amit rendszeresen frissítek. Tegnap este megpróbáltam bemenni ssh-val és ilyet kaptam vissza:

ssh_exchange_identification: Connection closed by remote host

Ma reggel újra be tudok ssh-zni.

Lehet-e ez annak a jele, hogy valaki a benti gépemen az ssh kulcsokkal szórakozott.

Este, a problémás időben pingelni tudtam a gépet. Harmadik gépre be tudtam ssh-zni, de onnan se engedett be a problémás gépre ugyanezzel az üzenettel.

Gyanakodjak valami manipulációra? Elég egy sima disztribúció-frissítés?

  • 7151 megtekintés

( th v | 2014. 04. 15., k – 07:30 )

Ha dinamikus az otthoni IPd és az ubuntun használsz denyhosts-ot akkor én megnézném az /etc/hosts.deny file-t, hogy nincs-e benne a tegnapi IPd.

--
TH

( ncc1701 | 2014. 04. 15., k – 07:48 )

Két dolgot utólag simán megtehetsz:
-Otthonra no-ip klienset telepíŧesz, és a melóhelyi gépedre a tűzfalon csak azt engeded be
-Az ssh portját áttolod a 22222-re
-És a harmadik :) : fail2ban csomag telepítése, beszigorítása

( Chas | 2014. 04. 15., k – 08:00 )

Én speciel az ssh-t csak vpn-en át engedem. Az meg csak ott van, ahol én vagyok.
De egy knock demon is jó szolgálatot tehet.

Tudom, security-in-depth meg hasonlók, de itt van értelme a VPN-nek? AFAIK amit nyersz vele az még egy réteg azonosítás és encryptálás (ez a security-in-depth) és egy adag szolgáltatás-elrejtés (security-by-obscurity), cserébe a távoli elérés esélyét rontod, mivel így két komponens zavartalan működése kell ahhoz, hogy tudj ssh-zni (ha megborul a VPN szerver és azt azt figyelő/újraindító szolgáltatás, garantáltan nem tudsz távolról belépni).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem azt mondtam, hogy nincs létjogosultsága a vpn-en keresztüli ssh-nak, hanem azt, hogy KIRÁRÓLAGOSAN vpn mögé zárt SSH-ban gondolkozni jelent-e akkora plusz biztonságot, hogy megérje a plusz infrastruktúrát. Az SSH protkoll szinten nyújtja ugyanazokat az authentikációs lehetőségeket, mint egy VPN, protokoll szinten titkosítva van, mint egy VPN. Amúgy meg a VPN-t is zárjuk VPN mögé, mert a VPN-t is fel lehet törni és minek nehezítenénk meg a hekkerek dolgát csak egy VPN-nel? Támadási felület vs. nyereség a hekker számára.

Ha pedig másik topicban való hozzászólásommal problémád van, akkor azt a másik topicban jelezd, légyszíves, köszi, lehetőleg azzal együtt, hogy pontosan mi a nyűgöd.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Igen, csak nem tudják direktben támadni az SSH portot, hanem először a VPN-t kell megtörni. Ha monitorozod a VPN logot, akkor támadás esetén még van esélyed azelőtt lelőni a szolgáltatást, mielőtt sikeresen bejutnának. Ha pedig bejutottak, még mindig ott van az SSH. Viszont így megoldható, hogy az admin oldalakat (munin, *myadmin, webmin, whatever) is VPN mögé tedd, a kényelemről nem is beszélve. Nem vagyok sysadmin, de ez nekem már egész jónak tűnik. De simán lehet, hogy tévedek, ez esetben elnézésed kérem.

-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"

Vannak lábak, amiket nem szeretek kint látni a neten, ilyen az SSH is. Nekem az nem fáj, ha Ti kint hagyjátok, ahány ház, annyi szokás. Nekem ez így biztonságosabb, kényelmesebb, hogy nyitok egy vpn kapcsolatot és ott van minden.

-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"

Részint az elrejtett szolgáltatás/hálózati infrastruktúra miatt, részint mert a kulcs hosszát növeled (*** mondjuk ez jelenthet simán csak lineáris javulást is a biztonságban), kérhetsz két külön felhasználónév/jelszót párost a kulcsokon felül stb.

***: Lineáris javulás alatt mit értek: Egy 2048 bit-es ssh kulcs cserélése egy 4096-osra 2^2048 -> 2^4096-ra változtatja a lehetséges kombinációk számát, míg ha nincs összekötve a vpn-hez és ssh-hez használt kulcs valahogy, akkor (mindkettőnél 2048 bit hosszú kulcsot feltételezve) 2^2048+2^2048 kombinációt kell csak végigpróbálni (először brute force-olva a vpn-t, utána az ssh-t, holott ugye ugyanúgy 4096 bitnyi információ kell a hozzáféréshez).

Szerk.: És igen, a 2^2048 is szép nagy szám.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( horvatha | 2014. 04. 15., k – 08:10 )

Bocs, a kérdésem továbbra is az:

Ez az időleges kitiltás lehet-e a feltörés/feltörési kísérlet jele? Kell-e most újratelepítenem, vagy elég ssh-kulcsot újragenerálni?

Utána kicsit biztonságosabbra átkonfigurálok dolgokat a tanácsaitok szerint, de először jó lenne, ha tudnám, hogy ez a kitiltás valami kavarás jele volt-e.

Előre is kösz!

( andrej_ v | 2014. 04. 15., k – 09:05 )

A 12.10-es Ubuntura szerintem már nincs support. Azt nézd meg, hogy a ssh bináris milyen (file /usr/sbin/sshd) és ha statikusan linkelt, akkor kezdhetsz gyanakodni.

( tompos v | 2014. 04. 15., k – 12:35 )

Akkor is ezt irja, ha csak siman flood-oljak (ertsd: probalkoznak szotar alapjan) es tul sokat kap. Egy ideig ilyenkor ezt csinalja.
Ne gyanakodj meg forumozz, hanem nezd meg az auth logot, wtf tortenik:)

t

Pedig nagyon gyenge ez a szám. Mert hackerként próbálhatom az 1111, 2222... változatokat.
Egy profi végig teszteli, hogy milyen port van nyitva.
Jó megoldás még a root számára az ssh tiltása, majd egy másik felhasználóként belépve is lehet su parancsot használni.

......................
Egymás segítésére még: http://pc-kozosseg.com

Szerintem 10000 feletti portokat már nem nézik végig portscannel. Mondom, nekem megszűnt a próbálkozás. Pedig vagy 8-10 éve fut itthon szerverem nyitott ssh-val.
Root login pedig evidens, h tiltott. :) AllowUsers = usernév, oszt lehet próbálkozni. Ha meg ügyfél szervere, akkor ez még meg van fejelve azzal, h csak kulcs alapon lehet belépni. Sok sikert a betöréshez. :)

( atomjani | 2014. 04. 15., k – 15:10 )

A belépéseket nem logolja a rendszered? Igaz ott is törölheti a nyomát.

......................
Egymás segítésére még: http://pc-kozosseg.com

( Hanrik | 2014. 04. 16., sze – 05:10 )

Hi!

Én is inkább arra voksolnék, hogy log átnézés után csak egy bizonyos ip-ről engedni a belépést. A dyn.com egy fiok ingyenes ès máris belehet állitani a tűzfalat,hogy minden máshonnan érkező kérést dobjon el.

Üdv.

( doncarlos v | 2014. 04. 16., sze – 21:18 )

Egy ideje akartam nyitni egy topikot de ez pont jókor jött.

Első problémám az volt hogy egyszer csak nem tudtam belépni a volt melóhelyem szerverére (még besegítek azért kell). Azt hittem az utódom törölte az accot de miután kiderült hogy nem nyúlt hozzá (abszolut nem is vágja) kezdtem gyanakodni. Bementem és lokálba se tudtam belépni, sem az én sem az ő userével. Na ekkor jött a para és hát grub->recovery mode->jelszó reset után tudtunk csak bemenni.
A belépés után egyből elkezdtem az auth.logot nyálazni és bár nem találtam olyan üzenetet ami sikeres belépést mutatna vagy bármi mást, tele volt a log ilyen üzenetekkel:

cerebellum sshd[14893]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=oblatif.com
cerebellum sshd[14893]: Failed password for invalid user search from 88.191.156.160 port 58299 ssh2

Fail2ban egyből belőve, azóta csak 1-1 sor van. Azt még mindig nem tudom hogy lettünk "kizárva". A fail2ban mellett mi még a jó óvintézkedés? ssh másik portra? más valami? Hogy lehetne "kikerülni" a célkeresztből? Csak mert eddig (amíg én dolgoztam ott) sosem volt ilyen.

Most ilyen a f2b stat:

1 110.75.162.239
1 117.78.0.185
1 122.252.127.94
1 176.28.51.78
1 180.166.10.186
1 1.93.32.251
1 199.203.52.30
1 200.55.198.147
1 211.20.51.166
1 221.120.224.179
1 221.179.89.90
1 61.129.33.35
1 61.16.173.78
1 61.218.17.119
3 101.227.170.42
3 110.75.162.238
3 115.29.12.249
18 193.227.50.25
53 106.37.191.120
61 88.191.156.160

Adatok mentése és gyalu, mert nem lehet tudni, hogy változott-e valami, és ha igen micsoda. Nem, a csomagkezelő ellenőrző funkciója nem jó válasz - legfeljebb akkor, ha "tiszta" forrásból bootolva csekkolod - természetesen a checksum-okat is valahonnan a meglévő rendszereden kívüli forrásból szedve.
Az biztos, hogy amíg nem tudod, hogyan lettetek kizárva, addig a gépet nem célszerű kiengedni a nagyvilág felé, illetve érdemes az ssh-n belőni a csak kulcsos authentikációt, illetve a shadow-ba egy másik gépen(!) beállított hosszú és bonyolult jelszó hash-ét berakni. Backdoor persze lehet ezek után is bármelyik hálózaton figyelő alkalmazásban, úgyhogy a teljes és részletes ellenőrzést nem fogod megspórolni.

Az, hogy melyik porton fut az ssh, az csak pici nehezítés, gyanítom egyébként azt, hogy nem ott mentek be.

Köszi az infókat, gyalu mindenképpen lesz, csak most még innen fut a weboldal és az iskolavezetés nem nézné jó szemmel a downtime-ot, mivel most már nem munkaidőben csinálnám, jó kérdés hogy mikor lenne rá időm.

Ha felhúzom majd az új szervert akkor is jönni fognak még az SSH próbálgatások igaz? De a f2b meg a 10000 fölötti ssh port segíthet a dolgon?