ilyet sem láttam még

Linux-security

Miközben élet-halál harcot vívok a levelezési rendszeremmel, a Debian 9 -es szerveren a /var/log/auth.log -ban a következőket találtam:

Nov  1 20:48:33 nusi sshd[1689]: Failed password for root from 218.92.0.141 port 30866 ssh2
Nov  1 20:48:36 nusi sshd[1689]: Failed password for root from 218.92.0.141 port 30866 ssh2
Nov  1 20:48:40 nusi sshd[1689]: Failed password for root from 218.92.0.141 port 30866 ssh2
Nov  1 20:48:45 nusi sshd[1689]: Failed password for root from 218.92.0.141 port 30866 ssh2
Nov  1 20:48:47 nusi sshd[1689]: error: maximum authentication attempts exceeded for root from 218.92.0.141 port 30866 ssh2 [p
reauth]
Nov  1 20:48:47 nusi sshd[1689]: Disconnecting authenticating user root 218.92.0.141 port 30866: Too many authentication failu
res [preauth]
Nov  1 20:48:47 nusi sshd[1689]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.92.0.141
user=root

Ahogy elnézem, hasonló kaliberű címekről ismétlődik ez a próbálkozás. Tény a szerverem látható a netről - pl. az ssh 22 port.

Kezdjek el félni?

  • 3153 megtekintés

( ncc1701 | 2019. 11. 01., p – 21:00 )

Fail2ban-t a portra. Be kell állítani, h kettő hibás próbálkozás után pár nap bant kaphat az az ip cím. Aztán van, h botnetről próbálkoznak, az ellen nem véd annyira.

Sosem kellet ilyesmihez nyúlnom, hol lehet ilyet beállítani?

Egyébként mint mondtam, ez csak egy kupac, több ilyen van néhány perc múlva más, hasonló ip címről ugyanez a menetrend. Ráadásul ki az a majom aki root -al próbálkozik ssh -n?

Az ip cím valami hamis lehet. Ha megpingelem nem látok domain nevet.

* Én egy indián vagyok. Minden indián hazudik.

ajanlom figyelmedbe az alabbi keresoszavakat:
login throttling/brute force/dictionary attack
mondjuk okosan kell megirni a dolgot: pl root-kent nem lepunk be, ha vki rootket probalkozik, mehet a tiltolistara. 
Esetleg ha nem tiltolistazni akarsz, akkor pl 2login try/60sec limitet belosz (es ha beallitod az SSH multiplexelest, akkor 1 is eleg).

( uid_21239 | 2019. 11. 01., p – 21:40 )

Ebben semmi meglepo nincs. Ha kiteszel barmit a netre, 1-2 nap alatt megtalalja valami bot vagy script kinabol vagy az oroszoktol. fail2ban az elso amit felrakok ilyen gepekre.

Nalunk amugy VPN-en is probalkoznak. 

( answ | 2019. 11. 01., p – 21:46 )

Szerkesztve: 2019. 11. 01., p – 21:51

Fail2ban + SSH magas portra. Még így is néha megtalálnak.

Figyelj rá, hogy Buster upgrade töri majd fail2ban SSH védelmét (mondjuk én 8 óta használom). Ismert hiba, ki kell kommentelni egy sort egy az upgrade által behozott új config fájlban.

Ja és én portscanre is használom fail2ban-t, megpróbál néhány portot az IP és már megy is listára.

(egyébként Buster upgrade Dovecot-ot is töri, ha pop3s-t használsz, ssl_dh miatt) 

( tovis v | 2019. 11. 01., p – 22:30 )

Köszönöm, ezt jól át kell néznem. Szerintem egy rossz mozdulat és kezdhetem elölről.

Akár ki is zárhatom magam.

OFF: Néhány évvel ezelőtt, az XP -vel jártam úgy, hogy ki kellett tennem a távoli hozzáférés lehetőségét. Bekapcsoltam a logokat (ott ezt valamiért be kellett kapcsolni) és elhűlve láttam amint valaki(k) máris piszkálják a portot és próbálnak belépni. Átraktam a portot felülre és többé nem néztem a naplót. Évekig nem volt komoly probléma. Ámen.

* Én egy indián vagyok. Minden indián hazudik.

Na elolvastam mit tud ez az Instance Connect. Azért ez nem semmi tákolás :)
Ha én csinálnám ezt szerveren, azt mondanák hogy Pistike megint alkotott.

https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-instance-connect-for-ssh-access-to-your-ec2-instances/

Az "akár ki is zárhatom magam"-hoz... Egyszerűen írsz egy scriptet, ami betölti a szabályokat, bekér egy y/n választ, és ha nem válaszolsz x időn belül vagy nemet nyomsz, akkor visszatölti az eredetit. A bash része egyszerű, a "timeout-tal kérdez valamit"-re én anno Perl-ben követtem el ezt:
 

#!/usr/bin/perl
use  strict;
use warnings;
my $val = undef;
my $timeout = 5;

until (defined $val) {
       print "Rendben (i/n)? ";
       eval {
            local $SIG{ALRM} = sub { die "alarm\n" };
            alarm $timeout;
            $val = <STDIN>;
            chomp $val;
       };
       if ($@) {
          die $@ if $@ ne "alarm\n";
          warn "\n";
          $val = 'n';
       };
       $val = $val eq 'i' ? 0 : ($val eq 'n' ? 1 : undef);
}
exit $val;

Ha meg a fail2ban-tól félsz, akkor tessen ssh-kulcs+google authenticator beüzemelni - a f2b mellett- úgy kisebb az esély, hogy elcseszerinted a logint.

( peterson v | 2019. 11. 02., szo – 06:01 )

Hát jó, akkor elmondom, mert talán nem tudtad.

A home routered nyújtotta látszatbiztinságon, és a modemeden is túl, odakint...

Szóval ha valaki azt mondta neked, hogy az szép hely, akkor átb*szott.

Odakint ronda, sötét, mocskos világ van, tere botokkal, pásztázókkal, meg minden csunyasággal.

Amikor standard porton pub ip-re tetted az ssh-t, bekukucskáltál ebbe a világba. Az meg visszanézett rád.

Egyébként, ahogy fentebb írták: magas port+ fail2ban.

"A megoldásra kell koncentrálni nem a problémára."

( Jo_OKerR | 2019. 11. 02., szo – 11:04 )

Szerkesztve: 2019. 11. 02., szo – 11:05

Igen, netre kirakott ssh-nál alap a fail2ban.

Én emellett geoip-t is használok mindig, ha nem kell hogy minden országból elérhető legyen, ezzel a próbálkozások 90%-át alapból megfogja, el sem jutnak az auth-ig.

( tovis v | 2019. 11. 02., szo – 11:36 )

Reggelre már finomodott a módszer, egyszer csak mindenféle fura felhasználói névvel próbálkozott.

Egyelőre elraktam a port címet, most elhallgatott. Persze, ha komolyan gondolta akkor nem sokára újra megjelenik.

A biztonságtechnikából tudom, hogy ha valaki beakar törni azt nem lehet megakadályozni, legfeljebb megnehezíteni (hátha akkor valami könnyebb prédát fog keresni). Így arra gondoltam, hogy a pálya nehezítés helyett, inkább valami olyanra lenne szükségem amivel detektálom, hogy valaki illetéktelen bejutott és elkezdett randalírozni (pl. rootkit). A snort, ha jól értem az ip mozgást (traffic) figyeli. Tapasztalataim szerint az ilyen szoftverek, heurisztikus minta kereséssel próbálják felderíteni a behatolót. Nekem inkább valami olyan kellene, ami jelzi, hogy feltörtek - mondjuk küld egy emailt. Aztán én eldöntöm mi legyen.

Használtok/tudtok ilyesmiről?

* Én egy indián vagyok. Minden indián hazudik.

"Ha egy profi be akar jutni hozzád, vagy már be is jutott, azt észre sem fogod venni hidd el :)"

Nem vagyok hívő. Paranoid megközelítés (lehet kell ehhez a szakmához). Valamiért csak kell neki a szerverkém, használja. A rajta levő tartalmak nem hiszem, hogy felkavarnák. Marad a spam és bitcoin.  Vagyis a tevékenységet kellene figyelni, lehetőleg egy másik géppel?

* Én egy indián vagyok. Minden indián hazudik.

( gee v | 2019. 11. 02., szo – 12:52 )

Ez normális, és nem kell törődni vele.

Gondolom PermitRootLogin No és PasswordAuthentication No megvolt. Így ezek a próbálkozások figyelmen kívül hagyhatóak.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( peterson v | 2019. 11. 02., szo – 13:28 )

Szerkesztve: 2019. 11. 02., szo – 13:30

"nem kell törődni vele."

Ez azért igencsak nagyvonalú. ;)

 

Szerk: gee-nek terveztem válaszolni, csak mobilról elk*tam. Sry.

"A megoldásra kell koncentrálni nem a problémára."

Szóval nyugodtam hagyja a posztoló, hogy brute forceolják.

Aham. Ha már elavult szarokat használ.

Elég idő alatt kipörget bármit, főleg ha az nem random, - mint ahogy azt rengeteg helyen használják még a "szakemberek" is.

Mert reális esélyét látod annak, hogy pont a szerencsétlen balfasz - hup.hu kommunikációt fogják feltörni, mert ezzel mihez is jutnak hozzá?

https://iotguru.cloud

Az, hogy próbálnak belépni, az egy biztonsági esemény. Még ha nem veszélyes, akkor is esemény, amivel törődni kell. A támadónak az is információ, ha nem reagálsz. ;)

A "ugyan mit vinnének el", és a "mért pont egem nyomnának fel" hozzáállás manapság már egy laikustol is erős... :)

"A megoldásra kell koncentrálni nem a problémára."

A "ugyan mit vinnének el", és a "mért pont egem nyomnának fel" hozzáállás manapság már egy laikustol is erős... :)

Minden védelmet érdemes mérlegelni, a túlzott védelem pont annyira káros, mint az elégtelen védelem, sőt, sokszor károsabb.

https://iotguru.cloud

A botok nem azt nézik hogy épp egy "szerencsétlen balfasz - hup.hu" user vagy a NASA szervereit nyomják-e éppen. Pörgeti az IP tartományt, amig nem talál egy olyan cimet, ahol az a szolgáltatás fut amire épp vadászik.

Aláírás _Franko_ miatt törölve. 
RIP Jákub.
neut @

A botok nem azt nézik hogy épp egy "szerencsétlen balfasz - hup.hu" user vagy a NASA szervereit nyomják-e éppen.

Nem, nem azt, de ha amúgy a legalapvetőbb dolgokat betartod, minthogy például viszonylag korrekt jelszavad legyen és/vagy kulccsal lépj be, akkor sokra nem tudnak menni. A védelem meg legyen már arányos azzal, amit védünk.

https://iotguru.cloud

PasswordAuthentication No

után

Szóval nyugodtam hagyja a posztoló, hogy brute forceolják. Elég idő alatt kipörget bármit

Mit pörget ki? Az RSA kulcsot? Miközben jelszavakkal próbálkozik? Inkább nem várom meg, amíg sikerül.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( pepo v | 2019. 11. 02., szo – 23:19 )

Várom, hogy az ilyen topik címek elszaporodjanak. Tippeim:

  • Ezt kuksizd meg.
  • A mindenit!
  • Úúú, bazd meg!

Így aztán későbbiekben mindannyiunk (le)épülésére lesz egy halom használhatatlan és kersehetetlen kupac szar.

Trey bá', nem lesz az egyértelmű címadással kapcsolatos szabály? (Mintha lett volna, de lehet, hogy a BB fórumok eleme volt.)

READY.
󠀠󠀠‎‏‏‎▓

( rascy | 2019. 11. 03., v – 10:32 )

Szerkesztve: 2019. 11. 03., v – 10:34

- fail2ban (már azért is jó, hogy átláthatóbbak és jóval kisebbek maradjanak a log fájlok)
  szerintem 1 napig is maradhat a ban, de ha elég nagy bot hálózat akadt rád, akkor sok IP címük lesz
- magas ssh port vagy OpenVPN (és beállítod, hogy csak ezen keresztül legyen elérhető az ssh)
- ha nincs sok user, akkor sshd_config-ban AllowUsers (és a userek neve ne user meg user1 legyen)
- root ne léphessen be ssh-n és te is ssh kulccsal használd
- port knocking (kinyit a tűzfalon egy portot, ha előtte bekopogsz x portokon)
- viszont nem csak ssh-n törhetik fel, van rajta webszerver? apache, nginx vagy bármi a 80-as porton?

"Akár ki is zárhatom magam" - gondolom van mobilneted, akkor azon keresztül tudsz unban-olni: fail2ban-client set sshd unbanip $ip

Bocsánat! Napok óta nincs kijelzésem ha új bejegyzés van!? Nem tudtam meddig vezet a történet.

A fail2ban -on még gondolkodom - mostanra túl sok időm ment el, feltorlódtak a feladatok és ez nem tűnik 10 perces feladatnak.

Az sshd_config -ban az allow users jól hangzik, bár mint jeleztem a kis robot túltette magát a root -on és elkezdett mindenféle bugyuta felhasználó nevekkel próbálkozni. A jelszavaim mostanra közepesen erősnek számítanak (de évekkel ezelőtt még a strong kategóriában futottak.. (Sok púp volt a fejemen a felhasználóimtól ezek miatt) A port címet még aznap felnyomtam. Az OpenWrt routerem ssh portja (elvileg) csak belülről elérhető) viszont még használom a 80 -as és a 443 -ast. Lehet ezeket is érdemes letolni? Mi lesz az encrypt -el?

Amire még nem kaptam ötletet, útmutatást az hogy vegyem észre ha bejutottak. Mint azt többen, többször említettétek, ha akarják tuti feltörik - ezzel teljes mértékben egyetértek, csak idő kérdése. Amit látok és ismergetek az a snort, de az is az ip kommunikációt figyeli - persze jó ha előbb észrevesszük ha gond van, de továbbra is az érdekel hogy tudom a rendszeremet ellenőrizni.

Az én meggyőződésem, hogy a védelmi eszközöknek egyszerűnek kell lennie mint a faék. Ha túl bonyolult, nehezen kezelhető és átlátható, akkor pont a védelmi eszközt fogják megcélozni. Minél bonyolultabb valami, annál könnyebb megtörni, ráadásul a felhasználó és az üzemeltető is kínlódik.

* Én egy indián vagyok. Minden indián hazudik.

A 80-as és a 443-as portok helyett is használhatsz mást, de persze ez esetben értesítened kell a felhasználóidat, hogy mostantól a https://domain.tld:22443 -on érhetik el pl. a webmail-t.

Amennyiben ez nem járható, akkor mindenképpen a portok mögött lévő szolgáltatást kell megerősítened.
És ha van security update hozzá akkor feltétlenül frissítened.

A "hogy veszed észre" jó kérdés, mert szerintem ha profi "szakember", akkor ahogy írták nem biztos hogy észrevehető.
Google-ben erre keress rá: "how to check if my linux server has been hacked"

Én két dolgot tudok javasolni, ami nekem segített:

  1. munin-t felrakod (publikusan ne legyen elérhető) és beállítod, hogy ha pl. a load vagy a cpu használat vagy a postfix mailqueue x érték fölé megy, akkor küldjön mailt neked --- ez nekem segített mikor egyik felhasználóm e-mail fiókját feltörték és hirtelen k. sok levél kezdett menni kifelé
     
  2. logwatch-ot felrakod, e-mail címedre küldést és detail level-t 10-esre beállítod --- én 1-2 naponta végig szoktam pörgetni, még 10 éve 1x így szúrtam ki, egy számomra ismeretlen felhasználó bejelentkezését, ami egy bot volt

( KoGa v | 2019. 11. 06., sze – 16:25 )

Tiltsd le a jelszavas bejelentkezést (és a root belépését), csak kulcs, és meg van oldva.

Windows 10 esetén indítsd el a pageant-ot (tálcán, az óra mellett keresd), jobb klikk, 'Add key', betöltöd a ppk formátumú privát kulcsodat és ennyi. Valószínűleg korábbi Windowsoknál is működik. Részletesebben itt, security szempontjából kicsit problémás, lásd a hivatkozott oldal alját.

A putty keygen-nel vagy mi a neve pillanatok alatt tudsz generalni. Puttyba/winscp-be/SFTPNetDrive-ba meg hasonloan, next-next-finish bonyolultsaggal betoltheto.

Androidon az f-droid repobol felteszed a termuxot, es onnantol az ottani csomagkezelobol (apt/pkg nevre is hallgat, es azonos a parameterezese) az ssh klienst, es ugyanugy megy, mint minden mas Linuxos gepen.

A strange game. The only winning move is not to play. How about a nice game of chess?

Én mindig csak kulccsal lépek be putty-val is. Fejből nem tudom, de az puttygen vagy micsoda nevű cucc által generált kulcsot pubi részét ki lehet olyan formában íratni, amit egy az egyben bemásol az ember az authorized_keys-be, a putty konfigjában meg megkeresed az authentication részt, beállítod, hogy hol a privát kulcs, aztán tillárom hajj, megy minden.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( Z0l v | 2019. 11. 07., cs – 06:57 )

Én fwknop-ot használtam erre a célra és nagyon elégedett voltam vele. Nem csak SSH-ra jó, titkosított és van kliens Androidra is.

( fsanyee | 2019. 11. 10., v – 11:08 )

sshd_config-ban ha kidobalod a gyengebb dolgokat Ciphers, MACs, KexAlorithms-bol, sok ezekbol nem jut el az elso probalkozasig sem, nalam ezzel van tele a log:

sshd[3591]: Unable to negotiate with 222.186.175.167 port 52364: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 [preauth]
 

journalctl -S yesterday | grep -c 'Failed password'
24
journalctl -S yesterday | grep -c 'no matching key exchange method found'
1355

azon kivul, hogy az ilyen random kapcsolatok nagy resze nem jut el addig sem, hogy jelszoval probaljon belepni? semmivel.

Ha jelszóval be lehet lépni, akkor ugye a jelszó erősségének megfelelő valószínűséggel törhető amúgy is, függetlenül attól, hogy milyen protokollal csatlakoznak épp a próbálkozók. Tényleg semmivel nem biztonságosabb, felesleges üzemeltetési kockázatot tettél a rendszeredbe, felesleges munkát tettél a rendszeredbe és ezzel csak a biztonságérzeted növekedett, a kockázatot nem csökkentetted. Sokkal többet tudnál tenni a jelszavas belépés korlátozásával és a megfelelő jelszó policy önkéntes vagy kötelező használatával.

https://iotguru.cloud

Ha a lehetséges próbálkozások számát csökkenti, az már előny.

Miért lenne előny? Ez egy tipikusan értelmetlen és felesleges változtatás a rendszeren, ami semmi előnyt nem ad: a botok amúgy se jutnak be, mert nem fogják véletlenül eltalálni a jelszavadat, akik meg célzottan be akarnak menni, nem akadnak fel azon, hogy le van tiltva pár gyengébb protokoll...

Pont olyan ez, mint másik portra tenni az SSH-t: a botok amúgy se jutnának be, aki be akar próbálkozni kicsit is nagyobb intelligenciával, az megtalálja a portot, magadat meg jól meg tudod szopatni, ha valahonnan épp le van tiltva az a port, amire tetted az SSH-t.

https://iotguru.cloud

( NevemTeve | 2019. 11. 10., v – 13:17 )

Szerkesztve: 2019. 11. 10., v – 14:26

Off: PuTTY -> OpenSSH irány esetén egyszerűbb PuTTY oldalon generáltatni a kulcspárt, és a publikus kulcsot átvinni szerveroldalra, mint fordítva; ugyanis az OpenSSH kb. négyféle formátumban tudja tárolni a privátkulcsot, ezek közül a puttygen csak egyet fogad el. (Legalábbis az én méréseim szerint.)

( tovis v | 2019. 11. 11., h – 21:50 )

Csak halkan, miután elpakoltam a portot még mindíg csend van .)

* Én egy indián vagyok. Minden indián hazudik.