.

19.12.2007 21:00 | asdgf | poslední úprava: 26.11.2009 20:42

.        

Anketa

Komentáře

[Luboš Doležel (Doli)]

Stačí filtrovat spojení z asijských zemí jako Korea, Čína, Taiwan apod., o hodně to sníží množství podobných "útoků".

[trekker.dk]

Mohl bys sem hodit nějaký link, kde by se nechaly sehnat rozsahy IP adres?

[unknown_]

+1, to bych ocenil a použil

[Luboš Doležel (Doli)]

http://www.hakusan.tsg.ne.jp/tjkawa/lib/krfilter

[trekker.dk]

Dík

[David Jaša]

Mě se osvědčilo pouhé omezení na jedno nové spojení za sekundu:

iptables -A syn_flood -p tcp --dport 22 -m limit --limit 1/s --limit-burst 1 -j RETURN

(Nová ne-SYN TCP spojení jsou zahozena a všechno ostatní prochází syn_floodem). Dlouho byly všechny Authentication failure v logu jen moje překlepy v hesle, teď se vyskytly za poslední dva měsíce dokonce dva útoky - celkem závratných 184 řádků v logách. Boti se s touto konfigurací ani nesnaží o kulometnou palbu a s dalším pokusem čekají desítky sekund až minuty.

[Ondrej 'SanTiago' Zajicek]

Cimz sis vyrobil peknou diru pro DoS utok, ne?

[David Jaša]

Zvažoval jsem to. Pak jsem si řekl, že chvilková nedostupnost při probíhajícím DoS útoku mi nevadí, ale za to by mi silně vadilo, kdybych se nemohl připojit, protože by se IP aktuálního počítače dostala na blacklist. Přes connlimit by to bylo lepší, nicméně takto to funguje už dva a půl roku to velmi dobře a nechce se mi to předělávat.

[Scarabeus IV]

Aspon si nastav fail2ban nebo neco takoveho, usetris aspon misto v logu.
Nastavis tam treba 2 spatna zadani po sobe ban na 2 hodinky a je to...

[trekker.dk]

Před nějakým časem tady vyšel blog o nějakém modulu pro PAM, který tohle dělal. Útočníkovi se po zabanování dále dařilo spojit se s ssh démonem, ale ten modul mu už po několika špatných pokusech neuznal ani správné heslo.

Když jsem na to ale nedávno koukal, nezdálo se mi, že by to byl nějak živý projekt.

[disorder]

ja som pocul pekne slova o ipt_recent, ale autor asi nema netfilter ;)

[Scarabeus IV]

po pravde ja nechci banovat cele rozsahy, slusni lide jsou vsude, ale jen ty kteri delaji neco nekaleho a pokud si prectete co vsechno dela fail2ban tak by se vam to mohlo vsem libit
http://www.fail2ban.org/

[Josef Kufner]

Lepší je nastavit MRTG (sledovat rychlost růstu auth.log) a kochat se kopečkama...

[Heron]

To nedělá člověk, tohle dělá nějaký bot-net a hledá takto další členy. Jednou jsem řešil nějaký problém u zákazníka (reinstall serveru), chtěl jsem se připojit k sobě domů (ssh) a nešlo to. Běžely u něj podivné procesy, co permanentně odesílaly něco po síti. (Nezjišťoval jsem co, stejně to čekalo format disku). Doma jsem následně zjistil, že ajpina zákazníka skončila v hosts.deny po zásahu denyhostu.

[unknown_]

Ten denyhost vypada zajimave, minimalne to zkusim.

[Luk]

denyhosts je dobrý. Kromě normálního režimu činnosti (lokální banování útočníků) lze použít i tzv. synchronizovaný režim, kdy se banované adresy sdílejí mezi uživateli programu (aktuálně 27000 uživatelů) prostřednictvím databáze na denyhosts.net. Pak je server chráněn proti potenciálním útočníkům už předem.

[petr_p]

Přesně tak. Obvykle se jedná o napadené staré neudržované stroje (to jsou ti debianisti, co tvrdí cosi o fungujících věcech). Stačí se připojit na TCP/22 a druhá strana ochotně poví verzi OpenSSH, OpenSSL a možná i druh distribuce.

Já mám nasazené automatické blokovaní a hlášení po jabberu. A pokud útok přichází z civilizované země, tak si i stěžuji mailem.

Asi nejcivilizovanější jsou ve Finsku, neb tamní ISP byl velmi hovorný a v 3. mailu mi poslal tuto zprávu:

Our customer informed us yesterday that this abuse problem has beens solved. Cracked computer was the reason. Customer improved also their firewall to avoid these in the future. Over all customer acted as a very good example how these things should be dealed cause their contacted personaly to every whois abuse contact which were cracked by their computer... which I must say is a very good thing to see =)

To člověku v boji s větrnými mlýny hned zvedne náladu.

[Milan Jurik]

Přesně tak. Obvykle se jedná o napadené staré neudržované stroje (to jsou ti debianisti, co tvrdí cosi o fungujících věcech).

Nekdy mlceti zlato.

Stačí se připojit na TCP/22 a druhá strana ochotně poví verzi OpenSSH, OpenSSL a možná i druh distribuce.

A nekdy naopak ne.

[Shadow]

Stačí se připojit na TCP/22 a druhá strana ochotně poví verzi OpenSSH, OpenSSL a možná i druh distribuce.

A nekdy naopak ne.

Hmm... já zrovna na serveru používám Debian a jak vidím, tak OpenSSH pěkně a ochotně sděluje kromě své verze i jméno distribuce.

Díval jsem se, jak to přenastavit, ale kromě rekompilace (nebo editace binárky - fuj!) jsem žádnou možnost neobjevil. BSD systémy mají alespoň volbu "VersionAddendum", ale ta v Debianu není.

Docela by mne zajímalo, jak moc veliký bezpečnostní problém tento únik informací představuje, zejména pak, pokud mám aktuální systém (Etch) a pravidelně (denně) aktualizuji.

[Aleš Kapica]

Podle mě žádný. Riziko by to mohlo představovat pouze tehdy, pokud se pokouší útočit skrze bug některé profláknuté verze.

Můj venkovní server se také už několik měsíců někdo pokouší nabourat skrz ssh, ale zatím to neřeším. Uvažoval jsem o něčem jak už tady bylo zmíněno, jenže riziko že bych se pak nemusel na ten stroj dostat je vyšší, než že ho někdo nabourá. Jo kdybych na něm seděl a mohl si problém vyřešit sám, proč ne. Jenže on je dedikován kdesi v matrixu a už pomalu ani netuším kam bych měl zavolat, kdyby po restartu náhodou nenajela síť

[Milan Jurik]

Linuxovi uzivatele tolik broji proti "security by obscurity" a naraz to nekomu vadi? Skryvani identity je kravina, zastavi maximalne tak lamky a ty lze zastavit rozumnejsim zpusobem. Jinak samozrejme Debian je aktualizovan vuci bezpecnostnim chybam docela obstojne.

[disorder]

tiez sa divim, ze tu este nikto nespomenul na vsetky tie obskurne rady spojenie "security by obscurity"

ze by rezignacia?

[Shadow]

Také jsem dospěl k závěru, že tohle je spíše security by obscurity. Banner nijak vlastní zranitelnost služby neovlivní. Pokud je služba zranitelná, pomůže aktualizace a ne změna banneru. A pokud zranitelná není, tak podle mne není moc způsobů, jak informace z něj zneužít. Ale já nejsem expert, tak se raději zeptám.

[xkucf03]

Skryvani identity je kravina

Ale co budu mít jako provozovatel ze zveřejnění používaného SW? A hlavně konkrétní verze?

"security by obscurity" je samozřejmě špatný přístup a nikdy bychom se na něj neměli spoléhat, ale: systém bychom měli navrhnout tak, aby byl bezpečný bez jakýchkoli obscurit a věřili jsme mu. Následně pak můžeme některé skutečnosti zakrýt, abychom bezpečnost systému zvýšili ještě dále nad požadovanou úroveň (přičemž na požadované úrovni bezpečnosti by ten systém měl být i bez jakýchkoli schovávaček).

Když máme bezpečný systém a rozhodujeme se, zda přidat ještě nějaké skrývání identity, máme na vahách na jedné straně nulové přínosy (z neskrývání) a na druhé straně pochybné a malé přínosy (ze skrývání). A je jasné, že něco, i když jakkoli malého, bude vážit více než nic. Proto považuji za chybu, když OpenSSH server vykecá verzi operačního systému.

V době mezi objevením chyby a vydáním opravy (resp. aktualizací aplikace) prozrazení přesné verze programu zvyšuje pravděpodobnost průniku do systému.

[Shadow]

V době mezi objevením chyby a vydáním opravy (resp. aktualizací aplikace) prozrazení přesné verze programu zvyšuje pravděpodobnost průniku do systému.

Vzhledem k tomu, že bannery se dají falšovat a útočníci to vědí, lze předpokládat, že zkušenější útočník se pokusí využít mnoha dostupných zranitelností bez ohledu na banner. A hloupý útočník se zase třeba na bannery vůbec dívat nebude a prostě jen zkusí nějaký exploit. A ono to třeba vyjde. Čili, dopad pravdivosti banneru na pravděpodobnost průniku do systému je IMO značně spekulativní.

[xkucf03]

1. Jasně že ty přínosy jsou pochybné a malé, ale každopádně jsou lepší než nic (nula).
2. Kolik lidí si tu identifikaci změní, když kvůli tomu musejí překompilovat OpenSSH? Já to taky nedělám (ale jen kvůli tomu, že SSH nemám přístupné z Internetu)

[Milan Jurik]

Zkuste si prostudovat, jak OpenSSH zahajuje komunikaci a proc je pro nej prinosnejsi, kdyz vi, kdo je na protistrane.

[xkucf03]

Vím jak ta komunikace vypadá. Jde mi o tohle: SSH-2.0-OpenSSH_4.6p1 Debian-5build1. Opravdu si myslíš, že druhá strana musí vědět, že používám Debian, aby se mnou mohla komunikovat??

[Milan Jurik]

Ne, jenze co ma vyznam vedet, ze tam je Debian? Podstatna je verze OpenSSH, proti ktere je treba najit pripadne problemy.

[Shadow]

Debian v banneru SSH může mít i jistý pozitivní vliv:

It helps auditing a large farm of Debian machines.

For example, there is currently no reliable way to remotely tell if a box running OpenSSH 1.2.3 is using an up-to-date Debian version with the security fix. An attacker will simply try all his exploits and move to the next machine if they are unsuccesful. The good guys can do that, too, but they cannot be sure if they just got the offsets wrong or something like that, so that the machine is vulnerable despite the attack was not successful.

A samozřejmě, pokud vyjde nová verze OpenSSH s opravenou bezpečnostní chybou, Debian stable nepovýší verzi balíčku, ale opatchuje stávající verzi OpenSSH. Takže v banneru zůstane stará verze, o které se bude útočník moci domnívat, že je zranitelná, a pokusí se ji napadnout. Pokud tam ovšem uvidí, že se jedná o Debian, který opravu chyby backportoval do této starší verze, může jít jinam a nebude zbytečně zatěžovat server. Pokud tedy banneru věří. Ovšem takový útočník bude útočit i v případě, že v banneru zmínka o Debianu nebude.

[Dent]

Nejdelší blog na abclinuxu.cz? :))

[unknown_]

I to je možný, ale nebylo to původně zamýšleno

[disorder]

tak zazipuj + base64

[rastos]

Ako keby nestačilo napísať:

Dec 18 09:15:10 ssh sshd[1762]: Failed password for invalid user sleeper from 60.250.118.78 port 40749 ssh2
Dec 18 09:15:14 ssh sshd[1764]: Nasty PTR record "60" is set up for 60.250.118.78, ignoring
Dec 18 09:15:14 ssh sshd[1764]: User root from 60.250.118.78 not allowed because not listed in AllowUsers

... a to sa opakuje pre 400 rôznych IP adries.

[disorder]

klamat?

[Jan Drábek]

Zajimavý, já měl server s veřejnou IP jel od rána až do večera - 16 hodin - na ssh ani jiné služby jsem zvlášťní útoky nikdy nezažil.

Btw. jeden typ útoku předpokládá nejprve přehlcení logu až do velikosti disku (proto je dobré nemít disk /var/log - či jaký v / ale na externím oddílu) a potom se systém začne chovat podivně ať už je v chrootu (...) nebo ne...

[unknown_]

Až budu mít chvilku času, tak si přes crona hodím posílání starých logů na mail, a zároveň jejich mazání. Ale nemyslím si, že toto by byl právě ten typ útoků, tento "útok" trval jenom asi 45 minut. Myslím, že by toho bylo potřeba výrazně víc.

[Shadow]

Já provozoval SSH honeypot (kojoney) na serveru s veřejnou IP. A řadu "úspěšných" útoků i s pokusy nainstalovat na server nějaké svinstvo jsem zažil.

[unknown_]

A to využili bezpečností díru, nebo prostě "uhádli login a password" ??

[Shadow]

Jednalo se o _honeypot_, takže uhádli login a heslo, což bylo samozřejmě velmi jednoduché (Kojoney má databázi mnoha obvyklých jmen a hesel).

[Shadow]

Jak se těchto automatizovaných útoků zbavit? Přehodit SSH na jiný port, port knocking, ssh-faker, apod. Dá se také zakázat ověřování heslem a používat jen klíče.

A co tím útočníci získají? I když získají "jen" neprivilegovaný účet v chrootu, mají přece celou řadu možností, jak toho využít. Odesílání spamu, DDoS, atd.

[unknown_]

Hm, to přehození portu mě nenapadlo, je to zajímavej nápad. Nastavím a uvidím

[Marián Kyral]

Já si na domácím routeru (wl-500gP) nastavil pravidla do iptables a mám klid. Během útoku se router stal nepoužitelný, nestíhal ani obsloužit všechny příchozí spojení

Útoky většinou přicházely v noci a trvaly kolem hodiny.

# Block SSH brutal force attack
insmod ipt_recent
iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 5 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 5 --name SSH -j DROP
iptables -A SSHSCAN -j ACCEPT

[Shadow]

Já svůj domácí router nastavuji tak, že přesměruji určité porty na svůj domácí server. SSH provozuji, ale na jiném portu (přesněji, na serveru je SSH na portu 22, ale router na něj přesměrovává jeden ze svých vyšších portů).

Port 22 jako takový jsem svého času přesměrovával na honeypot, pak jsem zkusil tarpit a nyní prostě nic nepřesměrovávám a nechávám příslušné pakety routerem zahazovat. Automatizované útoky jsou většinou zaměřené výhradně na port 22, takže jeho "přemístěním" jsem dosáhl eliminace těchto útoků.

SSH jako takové pak ještě chráním podobně jako vy.

[satanatas]

jojo, k*vy jedni boti :+). taky jsme měli na servu jednu takovou potvoru, několik měsíců se v logu vyskytovali tyto hlášky, ale nikomu se tam nepodařilo nabourat. přicházeli z celé Evropy a Ameriky. pak stačilo přidat jeden účet, nastavit mu slabé heslo a hned byl život veselejší :+) jo ale sshčko poslouchalo na portu 2222 a stejně se o to pokoušeli i na tomto portu.

[Shadow]

Skenovat celý rozsah portů u každého cíle ze zvoleného rozsahu IP adres asi boti moc dělat nebudou. V tomto případě bych spíše uvažoval nad tím, že příslušný bot měl v zásobě pár alternativ, kde by ještě SSH port mohl být. A port 2222 k zařazení do takového seznamu alternativ přímo vybízí.

Můj SSH port zatím ještě nikdo neobjevil. Ale faktem je, že pokud je bot chytřejší a nejprve si osahá (všechny) porty cíle, pak ten pravý SSH port objeví. Proto je vhodné ten správný port ještě nějak dále chránit (fail2ban, denyhosts, iptables+recent/limit, apod.).

[koulinek]

Ja si SSH na domaci serverik prostuchuju na firewallu portforwarderem jen z nekolika konkretnich verejnych IP + rozsah co prideluje O2 na CDMA a zbytek pokusu o TCP22 v tichosti zahazuju.

[xxx]

Presne tak, kazdej server se hodi na leechovani na irc.