Dotaz: Identifikace zdroje ssh útoků

[LuděkS]

Zdravím, potřeboval bych radu / nasměrování:

Situace:

- firewall se zablokovanými porty, s výjímkou vpn, ssh a VoIP telefonní ústředny povolenými porty:
- port ssh je 3232 a je přesměrovaný na server ve vnitřní síti, kde ssh běží na standardním portu 22

SSH server ve vnitřní síti (AlmaLinux) eviduje řadu útoků.
Root přihlášení pomocí hesla mám samozřejmě vypnutý, veškerou standardní ochranu (firewalld, selinux, fail2ban... atd., mám zapnutou.

Port na serveru jsem přesměroval na 3232 a od té chvíle se útoky znásobily:

Od posledního úspěšného došlo k 2233 neúspěšným pokusům o přihlášení

...Část výpisu

sshd[43922]: Received disconnect from 185.174.137.156 port 43838:11: Bye Bye [preauth]
sshd[43922]: Disconnected from authenticating user root 185.174.137.156 port 43838 [preauth]
sshd[43924]: Failed password for root from 58.230.203.182 port 50020 ssh2
sshd[43924]: Received disconnect from 58.230.203.182 port 50020:11: Bye Bye [preauth]
sshd[43924]: Disconnected from authenticating user root 58.230.203.182 port 50020 [preauth]
sshd[43928]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=211.252.87.118  user=root
sshd[43928]: Failed password for root from 211.252.87.118 port 46264 ssh2
sshd[43928]: Received disconnect from 211.252.87.118 port 46264:11: Bye Bye [preauth]
sshd[43928]: Disconnected from authenticating user root 211.252.87.118 port 46264 [preauth]
sshd[43984]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=124.41.217.33  user=root
sshd[43984]: Failed password for root from 124.41.217.33 port 56390 ssh2
sshd[43984]: Received disconnect from 124.41.217.33 port 56390:11: Bye Bye [preauth]
sshd[43984]: Disconnected from authenticating user root 124.41.217.33 port 56390 [preauth]
sshd[43986]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=131.186.47.190  user=root
sshd[43986]: Failed password for root from 131.186.47.190 port 35196 ssh2
sshd[43986]: Received disconnect from 131.186.47.190 port 35196:11: Bye Bye [preauth]
sshd[43986]: Disconnected from authenticating user root 131.186.47.190 port 35196 [preauth]
sshd[43990]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=185.174.137.156  user=root
shd[43990]: Failed password for root from 185.174.137.156 port 43858 ssh2
sshd[43990]: Received disconnect from 185.174.137.156 port 43858:11: Bye Bye [preauth]
sshd[43990]: Disconnected from authenticating user root 185.174.137.156 port 43858 [preauth]
sshd[43995]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=167.71.236.26  user=root
sshd[43993]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.230.203.182  user=root
sshd[43995]: Failed password for root from 167.71.236.26 port 59268 ssh2
sshd[43993]: Failed password for root from 58.230.203.182 port 50054 ssh2
sshd[43995]: Received disconnect from 167.71.236.26 port 59268:11: Bye Bye [preauth]
sshd[43995]: Disconnected from authenticating user root 167.71.236.26 port 59268 [preauth]
sshd[43993]: Received disconnect from 58.230.203.182 port 50054:11: Bye Bye [preauth]
sshd[43993]: Disconnected from authenticating user root 58.230.203.182 port 50054 [preauth]
sshd[43999]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=211.252.87.118  user=root
sshd[43999]: Failed password for root from 211.252.87.118 port 59556 ssh2
sshd[43999]: Received disconnect from 211.252.87.118 port 59556:11: Bye Bye [preauth]
sshd[43999]: Disconnected from authenticating user root 211.252.87.118 port 59556 [preauth]
sshd[44012]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.230.203.182  user=root
sshd[44012]: Failed password for root from 58.230.203.182 port 50086 ssh2
sshd[44012]: Received disconnect from 58.230.203.182 port 50086:11: Bye Bye [preauth]
sshd[44012]: Disconnected from authenticating user root 58.230.203.182 port 50086 [preauth]
sshd[44016]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=124.41.217.33  user=root
sshd[44016]: Failed password for root from 124.41.217.33 port 40344 ssh2
sshd[44016]: Received disconnect from 124.41.217.33 port 40344:11: Bye Bye [preauth]
sshd[44016]: Disconnected from authenticating user root 124.41.217.33 port 40344 [preauth]

...

Mohu server ještě víc obrnit, ale potřeboval bych pochopit odkud to jde.

- zvenčí to být nemůže (uvedené porty jsou zavřené).
- všechny win počítače ve vnitřní síti jsou aktualizované proskenované a chráněné pomocí Bitdefenderu.
- všechno o čem vím je aktuální

- zapadá mne: hacknutá telefonní ústředna? Nebo nějaká tiskárna? Nebo něco jiného..?

Jakým způsobem bych se dopátral kde je problém?
Přemýšlel jsem, že bych udělal nějaký honeypot server a zkusil to analyzovat.
Ale možná je nějaký jednodušší systém. Nevíte, prosím někdo?
Děkuji moc nasměrování!

Odpovědi

[Max]

Tohle:
Failed password for root from 124.41.217.33 port 40344 ssh2

Neznamená, že se ti někdo připojuje na ssh přes port 40344, ale že se ti IP 124.41.217.33 pokouší přihlásit na ssh server. Zmíněný port 40344 je pak port na straně klienta, né serveru.
Jinými slovy, běžný útok na ssh z internetu. Použij fail2ban s whitelistem pro své IP, nebo rovnou dropuj ssh komunikaci celou a povol si jen své vlastní IP, ze kterých přistupuješ.
Zdar Max

[Max]

Jinak osobně nevidím žádný smysl ve změnách čísla portu. SSH vždy nechávám na portu 22 a ošetřuji si komunikaci firewall pravidly.
Zdar Max

[LuděkS]

Díky moc, už jsem Tvou odpověď uviděl. S těmi porty jsem si to myslel podobně, ale nebyl jsem si jistý. Bylo mi divné, že je toho tolik i když není ven povolený standardní port 22. Protože se jedná o síť, která byla v žalostném stavu, rád bych si byl jistý, že to nejde zevnitř. Tak mne to dost znejistělo..

[lertimir]

Z mého pohledu je zcela a naprosto zbytečné mít povolené příhlašování se jménem a heslem zvenčí. A to je v tom logu děje. Pokud je povolené pouze přihlašování pomocí klíčů server zařízne komunikaci okamžitě pokud nemá klíče, k uváděným dialogům o chybných heslech vůbec nedojde. Pro mne je to mnohem podstatnější než změny portů. Na všech systémech, které používám, na ssh jdou útoky.

[LuděkS]

Je mi to divné, když píšeš "běžný útok z internetu", protože jinde se to neděje. Není mi jasné, jak by to mělo probíhat: Pokud by byl otevřený port 22, tak to chápu. Pokud je otevřený pouze vysoký port, chápu to méně, ale umím si představit, že by to někdo zkusil skenovat a pak zneužít. Pokud ale ty porty změním a útoky pokračují, tak je mi to divné. Přece na druhé straně nesedí někdo, kdo se snaží kompromitovat pouze tento server. A pokud je to bot, tak proč se to na jiných veřejných IP adresách neděje?

Potřeboval bych nějak vyloučit ostatní alternativy.

[[Jooky]]

Zmena portu na ssh (a inych sluzbach) ti v nicom nepomoze. Jedine co tym dosiahnes je frustracia ludi, co to musia pouzivat (potreba si pamatat port, manualne ho zadavat, a podobne) ... oscanovat IP na otvorene porty spolu aj s identifikaciou beziacej sluzby je vec na par sekund, maximalne par minut. Bezne "utok" prebieha tak, ze si bot najde IP, zisti ake su na nej dostupne sluzby (cez identifikaciu sluzieb, nie porty) a potom uz cielene na konkretnu sluzbu pusti utok.

Prehodenie sluzby na iny port nezabrani utoku a ani ho nespomali. Kedze stale vela ludi si mysli, ze cele riesenie bezpecnosti je len prehodenie napr. ssh na iny port, tak taketo servre su o to zaujimavejsie (povacsinou veci, ktore by realne poriesili bezpecnost tam pokulhavaju ...)

Co sa tyka "co s tym" ... Ja nastavujem ssh aby bolo dostupne napr. len cez VPN. Ked uz musi byt dostupne "z vonku", tak to zalimitujem na rozsahy, z ktorych sa bezne ludia pripajaju. Napr. na svojom servri mam pristup povoleny z adries, ktore patria Slovenskym ISP. Od kedy to takto robim tak je pokoj.

[GeorgeWH]

Jedine co tym dosiahnes je frustracia ludi, co to musia pouzivat (potreba si pamatat port, manualne ho zadavat, a podobne)

Od toho tu predsa mame ~/.ssh/config. Ale inac suhlasim.

[[Jooky]]

V praci mame nieco cez 1000 zariadeni a kazde ma primarne + OOB pripojenie. Prihlasuje sa na nich cca 50 ludi ... ked by niekto prisiel a pomenil porty, tak nie je sanca aby mal kazdy clovek aktualny ssh config + niekto pouziva putty, niekto mobu a niekto linux. Do toho kebyze windows admin porobi nieco podobne s rdp, tak mozu rovno zrusit cely support ... ked ma niekto jeden server a prihlasuje sa sam, tak je to ine.

Ssh pouze přes VPN je dobré do té doby, dokud funguje VPN .

[Vtipnéř]

Zmena portu na ssh (a inych sluzbach) ti v nicom nepomoze.

Všechny zdravím.

Změnu čísla portu taky používám, ale pro ssh mám nastaveno přihlašování jen s použitím klíče. Nicméně ještě mi v domácí síti běží VDR s webovým rozhraním VDRadmin-AM pro nastavování nahrávání, kam se občas hlásím z venku a z různých adres. Z diskuse usuzuji, že to asi není moc bezpečné, takže prosím o radu, jak by to bylo lepší, napadá mne např. použít VPN či ssh tunel.

Díky.

Jirka

[Max]

Tak jsi si odpověděl, VPN nebo SSH tunel :).
Zdar Max

[LuděkS]

Řeším to stejně (VPN). Jen mne překvapila intenzita, protože ssh servery jsou i na jiných místech a nikde to nebylo tak dramatické. Změnu portu používám jako doplňkovou věc spolu s ostatními zabezpečeními, protože to dosud výrazně zmírňovalo tlak na server (oproti standardnímu portu 22). Díky!

[lertimir]

Před pár lety, když jsem ještě nepřešel zcela na klíče. byla u mne frekvence pokusů o login tak 3 - 20 za minutu. Takže to byly tisíce za den. A změna portu nemá smysl, počet útoků se nezměnil. Co to změní je přihlašování pouze klíči, kdy útočník je zaříznut dříve než odesílá jméno/heslo. Pak ví že nemá šanci a zaznamená se to i do obecných databází, ke kterých čerpají další boty a útoky přestanou.

[Petr Fiedler]

Napr. na svojom servri mam pristup povoleny z adries, ktore patria Slovenskym ISP.

Víte prosím někdo, kde získat aktuální seznam rozsahů českých IP adres? Já jsem našel tohle, ale ten web na mě moc důvěryhodně nepůsobí a navíc je ten seznam z roku 2016.

@[Jooky]: To do toho konfiguráku zadáváš úplně všechny ty rozsahy, nebo něco vynecháváš?

[LuděkS]

Jediné, co mne od klíčů odrazuje je to, že se potřebuju přihlašovat z různých strojů a míst. Obávám se, že na klíč někde zapomenu a budu v háji. Synchronizovat klíče přes nějaký cloud se mi nechce (ledaže bych to ještě šifroval) a tahat to s sebou na klíčence už vůbec..

[lertimir]

Tak v této chvíli už vůbec nerozumím v jaké rovině bezpečnosti se pohybuješ. A o čem se vlastně vůbec bavíme. Ty "různé stroje" jsou linux nebo WIN? Jsi za ně bezpečnostně zodpovědný? Věříš, že tam není keylogger, třeba jako útok? Kolik takových systémů je? Pokud jsou to cizí stroje, věříš správcům a jejich bezpečnostním protokolům? Jinak je to prostě ruleta a je vlastně skoro jedno co s tím děláš?

Vycházel jsem z toho, že normálně mám všude s sebou notebook. To je mé bezpečné pracoviště, v něm mám své klíče a z něj se připojuji kam potřebuji. Max jsou někde ještě stroje, za které zodpovídám bezpečnostně, nad nimiž mám moc a do nich si ty klíče mohu nahrát také. Odjinud se nikdy nijak nikam nepřipojuji. Připojení s heslem (silným) mám výjimečně povolené v nějaké nejmenší síti (domácí síť, VLAN v servrovně ap.) v níž je systém, čistě proto abych ve výjimečné situaci, když by něco bylo s klíčem tak se k systému dostal jsem-li fyzicky tak, aby bezpečnost byla zajištěna i jinak.

[Petr Fiedler]

Vycházel jsem z toho, že normálně mám všude s sebou notebook. To je mé bezpečné pracoviště, v něm mám své klíče a z něj se připojuji kam potřebuji. Max jsou někde ještě stroje, za které zodpovídám bezpečnostně, nad nimiž mám moc a do nich si ty klíče mohu nahrát také. Odjinud se nikdy nijak nikam nepřipojuji. Připojení s heslem (silným) mám výjimečně povolené v nějaké nejmenší síti (domácí síť, VLAN v servrovně ap.) v níž je systém, čistě proto abych ve výjimečné situaci, když by něco bylo s klíčem tak se k systému dostal jsem-li fyzicky tak, aby bezpečnost byla zajištěna i jinak.

+1

[LuděkS]

No ano, mám to také tak. Ale ne všude.

[LuděkS]

Předně: Díky za snahu a za odpověď.
Moje cestování je na jiné téma.

- ano, všechny stroje jsou linux
- ano, jsem za ně odpovědný
- nevěřím, vím, že tam nejsou keyloggery

Notebook s sebou vždy vozti nemusím, práci mám uloženou v cloudu.
Tam ale klíče nahrávat nechci. Navíc, může nastat výjimečná situace, kdy se potřebuji připojit
a nemám s sebou notebook. Například na cestě, z tabletu a podobně.

Pokud se připojuji silným heslem, připojím se odkudkoliv. 
Pokud to přehodím na klíče (což není technicky problém),
může nastat situace, kdy se z jiného zařízení nepřipojím,
si tam zapomenu klíče přidat.

Nebo musím vymyslet, jak klíče zabezpečeným způsobem
synchronizovat. Tomu se vůbec nebráním, jen jsem zatím neměl čas se tím zabývat.

[lertimir]

Nebo musím vymyslet, jak klíče zabezpečeným způsobem
synchronizovat. Tomu se vůbec nebráním, jen jsem zatím neměl čas se tím zabývat.

Tys s klíči nikdy nepracoval, že. Protože nevím o čem mluvíš. Jaké vymyslet "synchronizovat"? Máš systém A na kterém pracuješ a systém B (C,D) do kterého se loguješ s heslem.

1. Na A pustíš ssh-keygen který ti lokálně vygeneruje klíče a na konci specifikuješ lokální heslo pro lokální otevření soukromého klíče. Na man najdeš, jak si navolit parametry pro generování klíče, ale i default je bezpečný.
2. Pak provedeš ssh-copy-id B což je skript používající, kterému zadáš heslo k B a který ti nakopíruje na B veřejný klíč ssh tunelem (opět si přečti man). (samozřejmě lze klíč nakopírovat i přes sftp) A to je vše.
3. Poslední bod zopakuješ pro systémy C, D atd. Jednou a napořád. To je "synchronizace".
4. Jakékoli další ssh B chce nejdříve po tobě lokální heslo ke klíči, a pokud pracuješ tak, že se loguješ, odloguješ, znovu zaloguješ, atd. tak to otravuje psát znovu a znovu heslo a ssh-agent ti na začátku klíče otevře s heslem a pak jednotlivé ssh si pro ně šáhnou do agenta

základní výhoda je v tom, že veškerá práce s hesly se děje lokálně. a tímhle si všechny počítače na kterými vládu propojíš klíčí a máš pokoj. Nahození komunikace s klíči je otázka dvou příkazů a cca 5-20 vteřin při generování hesla. Navíc si to můžeš zavádět postupně až nakonec zjistíš, že již žádné vzdálené hesla nepotřebuješ.

[LuděkS]

Předpokládáš špatně. Vše co píšeš mám za sebou mnohokrát. Jde mi o jinou věc. Nechci to tu vysvětlovat, protože to je jiné téma. Každopádně díky.

[lertimir]

Ok. Když sdělíš jen část problému fajn, je to tvé rozhodnutí.

K původní otázce i když myslím, že to už zaznělo. Ať máš ssh kdekoliv, na jakémkoliv portu najdou to, a pokud se dostanou k autentizaci jméno a heslo, zaznamenají do databází a z ní to bude čerpat více botnetových sítí. Kdysi jsem si udělal test, že jsem spustil ssh na portu 80 a na portu přes 50000, kde server nemá co dělat. Našli to stejně. Ono zase algoritmicky není takový problém naposílat SYN packet na všechny porty (klidně z různých strojů botnet sítě) a u portů, kde dostanou SYN/ACK postupně zkusit, co tam běží, zvláště, když ssh je jeden z mála protokolů, které port mění. file2ban pomůže, ale problém nevyřeší. Jak jsem psal, dostal jsem se někde i do situace, kdy pokusů o login byly tisíce za hodinu, file2ban totiž tomu botnetu tím zaříznutím také sdělí, kolik pokusů je možné před zaříznutím (pokud programátoři botnetu nejsou blbí, tak tohle je jedna s logických informací, která by v té databázi mohla být - adresa,port, existence F2B, počet volných pokusů, relaxační čas kdy systém blokaci uvolní)

[LuděkS]

Jasně, rozumím a souhlasím. Díky.

[LuděkS]

PS: Ještě odpovídám, protože si vážím tvého času a odpovědí.
Nejde o to, že bych něco nechtěl sdílet, ale o to, že původní otázka byla o identifikaci útoků.

Řeším paralelně x věcí současně a v tomto případě mne ten tlak na přesměrovaný port prostě překvapil.

Jde o společnost, která měla v minulosti vážné bezpečnostní problémy,
mimo jiné hacknutý kamerový systém, který byl zneužitý k nebezpečnému provozu atd., atd.
Postupně se to dává celé dohromady. Souvisí to s energetikou a současnou bezpečnostní situací.
To je jedna velká oblast.
Druhá věc je nastavení mého pracovního ekosystému a jeho zabezpečení.
Třetí věc je jak to všechno bezpečně propojit.
Čili je to o dost složitější, na jiné téma, než byl původní dotan (nejde tedy jen o to jak nastavit klíče).

Díky!

[lertimir]

Když přednáším studentům o bezpečnosti, tak jim mimo jiné říkám, že je třeba si nastavit bezpečnostní perimetry, do perimetru si nastavit jeden jedinný vstupní bod s definovanou kontrolou, do vyšších úrovní procházet několik perimetrů a několik kontrolních bodů. Např. kdysi jsem trochu měl info o managemetu jednoho DNS root serveru. Ten jako server měl pouze a jedině DNS a nic jiného na té adrese neběželo, a management byl prováděn tak, že na jiných dvou adresách, připojených do zcela jiných a různých dvou sítí dvou různých poskytovatelů běžely dva servery s pouze a jen ssh a s přístupem přes klíče, které fyzicky byly ve stejné servrovně a z nich přes prastarou seriovou linku bylo jediné spojení na hlavní DNS server.

[Peter Golis]

Notebook s sebou vždy vozti nemusím, práci mám uloženou v cloudu.

Ehm, toto vyzerá na zásadný bezpečnostný problém. Človek by mal mať svoj pracovný nástroj počas výkonu práce, a ten nástroj má spĺňať určité bezpečnostné štandardy. Nejaký kryptovací kľúčik alebo iný elektrický občiansky preukaz nestačí.

Hint: keylogger na heslo alebo pin pre kryptokľúčik, hasák a podobne.

[LuděkS]

No právě. Mně jde ale o jinou věc, kterou v souvislosti s tím řeším - ale to už se odkláníme od původní otázky. Díky.

[Peter Golis]

Blbé je že aj keby si so sebou nosil MikroPC (vo forme špeciálneho telefónu ktorý pripojíš na cudzie zariadenie typu klávesnica a externý monitor), tak si nepomôžeš. A kredence ti kľudne zoberú. Aj keby si to nosil, tak dostať hasákom po pätách zlomí každého.

Bez vlastného a zabezpečeného NB nemáš ani náznak riešenia.

PS: Dävno pradávno som sa zabával keď som si nahodil Linux Desktop na HTC Rhodium. Tak malý NB s vysúvacou QWERTY klávesnicou a kovovým rámom videl málo kto.

[LuděkS]

Rozumím. To už se ale bavíme IMHO o nějakém vysokém levelu armádního zabezpečení státního tajemství ( s tím hasákem).

Mně šlo o to - ale to už se odchylujeme od původní otázky - že pokud se přihlašuji se silným heslem, které znám jen já,
přihlásím se v případě krajní nouze odkkudkoliv na planetě.
Pokud vše nastavím na klíče a nebudu mít s sebou svoje zařízení, jsem v háji.
Většinu obsahu, který potřebuji k práci, mám na cloudu.
Jednotlivá zařízení, ze kterých pracuju, synchronizuji také tak, abych mohl na jednom přestat pracovat
a na druhém mohl pokračovat (jedno kde se geograficky nacházím).
Vše je samozřejmě šifrované, včetně disků a přenosu.

Takže by asi nebyl problém "synchronizovat" i klíče (čemuž logicky neporozumněl lertimir, protože jsem mu to dostatečně nevysvětlil).
Nechce se mi to tu celé popisovat, protože je to jiné téma než na které jsem se ptal.

Když to shrnu, přemýšlel jsem nahlas:
- Zaskočila mne úroveň útoků na přesměrovaném ssh portu, protože v ostatních případech se to v takovém rozsahu neděje.
- přemýšlel jsem (nahlas) o tom, jak to udělat, když vypnu přihlášení heslem a přejdu na klíče, abych si někdy nezapomněl
zařízení, a nebyl (typicky, když jsem hodně daleko), v háji.
Trochu se obávám svěřit tyto věci cloudu. Asi zbytečně, pokud šifruji přenos na straně klientů i serverů.
Byl to jen takový zbrklý "paranoidní" impuls. V podstatě to asi nebude problém.

Díky!

[lertimir]

Pokud vše nastavím na klíče a nebudu mít s sebou svoje zařízení, jsem v háji.
Většinu obsahu, který potřebuji k práci, mám na cloudu.
Jednotlivá zařízení, ze kterých pracuju, synchronizuji také tak, abych mohl na jednom přestat pracovat
a na druhém mohl pokračovat (jedno kde se geograficky nacházím).

Tady je hezky vidět, jak každý uvažujeme v jiném bezpečnostním kontextu. Pro mne v kontextu, který popisuješ by vzniklo. Pokud nebudu mít dostatečnou konektivitu jsem v háji., protože se pohybuji i na lokacích, kde konektivita je mizerná - v hluboké přírodě. A proto představa, že nemám své zařízení je nemyslitelná. Nebo pokud ho nemám, nepracuji.

A poslední poznámka, lokální soukromý klíč k ssh s kvalitním heslem je bezpečný. Tedy i když by útočník jej vyndal soubor s ním z těch zašifrovaných disků, cloudu, lokálního zařízení tak bez hesla (nebo hasáku) se ke klíči nedostane.

[LuděkS]

Jasně. S bezpečností klíčů nemám vůbec žádný problém.

[xxl]

Na povolování / blokování podle států bývalo rozšíření xtables-addons, konkrétně xt_geoip.ko. Ale bylo nutné pravidelně aktualizovat databázi ip adres pro jednotlivé státy. Což se stahovalo někde z webu https://www.maxmind.com/en/geoip2-databases pomocí xt_geoip_dl_maxmind. Bývalo to zadarmo, ale už není.

[Petr Fiedler]

Díky moc!

[[Jooky]]

@[Jooky]: To do toho konfiguráku zadáváš úplně všechny ty rozsahy, nebo něco vynecháváš?

Cele rozsahy pre koncovych uzivatelov. Udaje som si pozbieral sam. Napr. teraz som v sieti Antik Telecomu. Pozrel som si aku mam WAN a tu pohladal v ripe databaze. Vysledok:

inetnum:        88.212.36.0 - 88.212.43.255
netname:        ANTIK_NETWORK
descr:          ANTIK PAT Customers
country:        SK
admin-c:        ATIN4-RIPE
tech-c:         ATIN4-RIPE
mnt-by:         ANTK-MNT
mnt-domains:    ANTK-MNT
status:         ASSIGNED PA
created:        2012-08-15T09:53:43Z
last-modified:  2017-08-10T14:43:47Z
source:         RIPE

role:           ANTIK Telecom IP Network Administrator
address:        Carskeho 10, Kosice, Slovakia
admin-c:        ZILL1-RIPE
tech-c:         ZILL1-RIPE
nic-hdl:        ATIN4-RIPE
mnt-by:         ANTK-MNT
created:        2017-08-10T14:38:16Z
last-modified:  2017-08-10T14:41:33Z
source:         RIPE # Filtered

% Information related to '88.212.32.0/19AS42841'

route:          88.212.32.0/19
descr:          ANTIK_NETWORK_2
origin:         AS42841
mnt-by:         ANTK-MNT
created:        2009-11-12T10:49:08Z
last-modified:  2009-11-12T10:49:08Z
source:         RIPE

cize medzi povolene ide 88.212.32.0/19 ... kedze viem, ze antik ma dva rozsahy, tak som si podobne pohladal druhy a oba mam v configu ... vynechavat z toho nema velmi zmysel, lebo na NAT a priradovanie IP nemam dosah u ISP.

[Petr Fiedler]

OK, dík.

[Peter Golis]

Námatkovo vybratá posledná IP adresa:

$ geoiplookup 124.41.217.33
GeoIP Country Edition: NP, Nepal

To nevyzerá že by boli porty na exponované služby uzavreté. Najmä ak máš SSH exponovaný na WAN porte 3232 a cez PAT je presmerovaný na LAN port 22.

Tie čísla portov z logu znamenajú niečo iné ako si myslíš.

Skús si pozrieť čo s tými útokmi urobil fail2ban, logy sú /var/log/fail2ban.log*

Ak ti vadí tak malý počet odrazených útokov, tak zníž treshold na ban, alebo si nastav geo-blocking firewall. Neviem si predstaviť kto chodí na služobky do Nepálu, Vietnamu alebo Kórei. To vyzerá na klasický útok z botnetu zloženého so zavírených počítačov.

[LuděkS]

Díky. Ještě jsem změnil port a koukám, že jsem zapomněl na změnu u fail2ban.conf. Takže jsem to napravil, právě to běží..
Ještě raději zkontroluji a poladím nastavení (time has too large deviation..).

Ano, mám otevřený port pro ssh na firewallu, který je nyní přesměrovaný na stejně vysoký port na ssh serveru. 
Co, prosím, myslíš, tím, že čísla portů z logu znamenají něco jiné, než si myslím, že znamenají (chtěl bych to pochopit)?

Také si myslím, že je to klasický útok z botnetu ze zavirovaných počítačů. 
Pokud by to bylo zvenčí, jak to, že se to dostane přes vysoký port "dovnitř"?
Myslel jsem, že botnety zkouší ssh útoky přes 22. 
A pokud je to zevnitř, potřeboval bych právě zjistit odkud to jde.
Díky moc!

[Max]

Nerozumíš odpovědi v prvním komentáři, nebo jsi ho vůbec nečetl?
Zdar Max

[LuděkS]

Ahoj, nečetl, protože jsem si jí vůbec nevšiml. Z nějakého důvodu se mi příspěvky od Tebe zobrazují zabalené jako jeden řádek, takže jsem to přehlédl.

[Max]

Tak to mě asi blokuješ, ne?
Zdar Max

[LuděkS]

Příloha:

• Snímek obrazovky z 2022-11-03 13-31-43.png (61266 bytů)

Proč bych to dělal?

[Max]

Podle toho screenshotu mě blokuješ. Proč, to netuším. Rozbalit -> Neblokovat
Zdar Max

[Max]

Jinak koukám, že v seznamu blokkování (Profil -> Nastavení účtu -> seznam blokovaných uživatelů) máš i další lidi...
Zdar Max

[LuděkS]

Blokování vypnuto. Vůbec to ale nechápu. Nejsem si vědomý, že bych to někdy použil.. Každopádně díky!

[LuděkS]

... tedy, že bych to použil ve Tvém případě. U některých trollů tomu rozumím. Jen si pamatuju, že se od nějaké doby Tvoje příspěvky zobrazovaly zabalené. Říkal jsem si, že to tak máš asi schválně. Fakt nechápu. Ale nevadí, je to opravené. Ještě jednou díky.

[Peter Golis]

potřeboval bych právě zjistit odkud to jde

Pokiaľ tie IP adresy z logov nie sú z lokálneho rozsahu (ktorý určite poznáš), tak si si všimol príklad použitia príkazu geoiplookup. Len decentne podotknem že zadarmová databáza IP adries je "mierne" zastaralá, takže to občas hodí nesprávny údaj.

Na mňa zopár krát vyštekol niekto z IP 179.60.147.159 ktorú to reportuje ako ruskú IP aj keď to podľa whois patrí Venezuelskej SAFE-VPN.MOBI. Na ten kontinent sa ešte rusko nedostalo.

Keď som znížil počet pokusov na banovanie, tak to u mňa za posledné dni vyzerá top 5 krajín takto:

Country	Count
US	237
VN	136
RU	101
CN	83
BR	46

PS: Botnety bežne skenujú aj neštandardné porty. A podľa odozvy služby vyberú útok. Navrhoval by som pomeniť heslá na nejaké zložitejšie, alebo prejsť čisto na autentifikáciu kľúčmi.

[LuděkS]

Zajímavé. Překvapilo mne množství pokusů na nestandardním portu. Přihlašování heslem je vypnuté. Zkusil jsem ssh zablokovat na firewallu a skutečně byly všechny útoky zvenčí (chtěl jsem si být jistý). Díky moc!

[lertimir]

přihlašování heslem vypnuté není.

položka

Failed password for root from 58.230.203.182 port 50020 ssh2

se tam nemůže vyskytovat. To lze jedině pokud se dostane přihlašování k heslu. Je to možná PAM autentizace.

pokud si udelám ssh localhost a mám přihlašování jen klíči a samozřejmě nemám klíč u sebe dopadne to takto a žádné "failed password" tam není

lis 08 17:04:58 carbon sshd[29225]: Connection closed by authenticating user xxxxy ::1 port 36242 [preauth]
lis 08 17:04:58 carbon kernel: audit: type=1109 audit(1667923498.616:188): pid=29225 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:bad_ident grantors=? acct="?" exe="/usr/bin/sshd" hostname=::1 addr=::1 terminal=ssh res=failed'
lis 08 17:04:58 carbon audit[29225]: USER_ERR pid=29225 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:bad_ident grantors=? acct="?" exe="/usr/bin/sshd" hostname=::1 addr=::1 terminal=ssh res=failed'

[LuděkS]

Díky všem! S těmi porty to chápu, jen jsem si nebyl jistý. Provozuju vícero ssh serverů, ale nikde jsem neměl tolik útoků jako je zde. Tak mne to trochu vyplašilo. Rád bych přišel na to, proč je to tady o tolik jiné. Navíc před nějakou dobou tam došlo k hacknutí kamer včetně dost nebezpečného provozu (to jsem u toho ještě nebyl), tak jsem trochu vyplašený z každé (pro mne) neobvyklé situace. :)

[Andrej]

AuthenticationMethods publickey
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin no
MaxAuthTries 3
MaxSessions 2

[Max]

VMWare nasadil do vCenter "MaxAuthTries 2". Dělá to pak zajímavou věc. Nejdřív se inicializuje ověření certifikátem, pokud neprojde, inicializuje se ověření pomocí uživatele+hesla. Fór je v tom, že ten druhý krok je brán jako druhý pokus. Tím pádem ten, kdo používá normálního ssh klienta a neudělá bypass v podobě "-o PubkeyAuthentication=no", tak se ani k loginu nedostane a logy by to mělo dál zkrátit. Klientovi rovnou vyskočí "Too many authentication failures".
To jen taková zajímavůstka :).
Zdar Max

[trekker.dk]

No jestli dobře počítám, tak jeden pokus o certifikát by vám měl nechat jeden pokus na heslo, ne? Ovšem ve chvíli, kdy máte v tom SSH klientu klíče dva (např. RSA a ECDSA)...

[Max]

Přesně tak.
Zdar Max

[Petr Fiedler]

+

PasswordAuthentication=no

[Petr Fiedler]

*Bez toho "=".

[LarryL]

A co takhle klepání na porty?

Na serveru budeš mít program (script), který bude sledovat porty. Jakmile vzdáleně klepneš na tebou určené porty ve správném pořadí v časovém rozsahu několika sekund, tak ten program (script) něco vykoná. To "něco vykoná" může být otevření portu 22 nebo povolení přihlášení heslem pro SSH. Jakmile se spojení SSH ukončí, tak se to vrátí do výchozího stavu.

Takže bys např. měl na serveru běžícího SSH daemona jen pro přihlášení klíčem a druhá instance SSH daemona pro přihlášení heslem by se ti spustila až při poklepání na ony porty.