Fórum Root.cz
Hlavní témata => Server => Téma založeno: David 23. 04. 2012, 00:16:05
-
Ahoj, mám domácí server Debian squeeze a dnes mi ho někdo úspěšně hacknul. Tuším jak se to stalo - jednoduché heslo roota, podle logu to bral někdo hrubou silou. (Jsem vůl že byl root vůbec povolen přes ssh).
Každopádně budu muset přeinstalovat celý systém. Zajímavé je, když si vypíšu netstat tak vydím toto:
tcp 0 0 *:sunrpc *:* LISTEN root 3754 977/portmap
tcp 0 0 *:44784 *:* LISTEN root 4178 1193/rpc.mountd
tcp 0 0 angel.local:domain *:* LISTEN bind 4354 1281/named
tcp 0 0 localhost:domain *:* LISTEN bind 4352 1281/named
tcp 0 0 *:ssh *:* LISTEN root 5053 1725/sshd
tcp 0 0 localhost:smtp *:* LISTEN root 4982 1702/exim4
tcp 0 0 localhost:953 *:* LISTEN bind 4360 1281/named
tcp 0 0 *:55515 *:* LISTEN statd 3792 990/rpc.statd
tcp 0 0 *:60961 *:* LISTEN root 4092 -
tcp 0 0 *:nfs *:* LISTEN root 4072 -
tcp 0 0 *:swat *:* LISTEN root 4509 1368/inetd
tcp 0 152 angel.local:ssh 10.0.0.1:52980 ESTABLISHED root 5190 1810/sshd: david [p
tcp 0 0 angel.local:37335 Tampa.FL.US.Undern:ircd ESTABLISHED root 5296 1809/sshd
tcp 0 0 angel.local:47117 Tampa.FL.US.Undern:ircd ESTABLISHED root 5173 1809/sshd
tcp 0 0 angel.local:59360 Tampa.FL.US.Undern:ircd ESTABLISHED root 5378 1809/sshd
udp 0 0 angel.local:domain *:* bind 4353 1281/named
udp 0 0 localhost:domain *:* bind 4351 1281/named
udp 0 0 *:36665 *:* root 4173 1193/rpc.mountd
udp 0 0 *:47817 *:* root 4085 -
udp 0 0 *:46816 *:* statd 3789 990/rpc.statd
udp 0 0 *:742 *:* root 3780 990/rpc.statd
udp 0 0 *:mdns *:* avahi 4408 1325/avahi-daemon:
udp 0 0 *:sunrpc *:* root 3745 977/portmap
udp 0 0 *:nfs *:* root 4107 -
udp 0 0 10.0.0.255:netbios-ns *:* root 4957 1695/nmbd
udp 0 0 angel.local:netbios-ns *:* root 4956 1695/nmbd
udp 0 0 *:netbios-ns *:* root 4953 1695/nmbd
udp 0 0 10.0.0.255:netbios-dgm *:* root 4959 1695/nmbd
udp 0 0 angel.local:netbios-dgm *:* root 4958 1695/nmbd
udp 0 0 *:netbios-dgm *:* root 4954 1695/nmbd
udp 0 0 *:38287 *:* root 5171 1809/sshd
udp 0 0 localhost:921 *:* root 4486 1349/lwresd
udp 0 0 *:39971 *:* avahi 4410 1325/avahi-daemon:
tcp 0 0 angel.local:47117 Tampa.FL.US.Undern:ircd ESTABLISHED root 5173 1809/sshd
Z toho usuzuji, že útočník něco nainstaloval na server, a může ho přes ircd vzdáleně ovládat. Chápu to správně? S linuxem si teprve začínáme pořádně rozumět. Zde je ještě výpis ps aux:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 2036 708 ? Ss 19:46 0:00 init [2]
root 2 0.0 0.0 0 0 ? S 19:46 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S 19:46 0:00 [migration/0]
root 4 0.0 0.0 0 0 ? S 19:46 0:00 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S 19:46 0:00 [watchdog/0]
root 6 0.0 0.0 0 0 ? S 19:46 0:00 [events/0]
root 7 0.0 0.0 0 0 ? S 19:46 0:00 [cpuset]
root 8 0.0 0.0 0 0 ? S 19:46 0:00 [khelper]
root 9 0.0 0.0 0 0 ? S 19:46 0:00 [netns]
root 10 0.0 0.0 0 0 ? S 19:46 0:00 [async/mgr]
root 11 0.0 0.0 0 0 ? S 19:46 0:00 [pm]
root 12 0.0 0.0 0 0 ? S 19:46 0:00 [sync_supers]
root 13 0.0 0.0 0 0 ? S 19:46 0:00 [bdi-default]
root 14 0.0 0.0 0 0 ? S 19:46 0:00 [kintegrityd/0]
root 15 0.0 0.0 0 0 ? S 19:46 0:00 [kblockd/0]
root 16 0.0 0.0 0 0 ? S 19:46 0:00 [kacpid]
root 17 0.0 0.0 0 0 ? S 19:46 0:00 [kacpi_notify]
root 18 0.0 0.0 0 0 ? S 19:46 0:00 [kacpi_hotplug]
root 19 0.0 0.0 0 0 ? S 19:46 0:00 [kseriod]
root 21 0.0 0.0 0 0 ? S 19:46 0:00 [kondemand/0]
root 22 0.0 0.0 0 0 ? S 19:46 0:00 [khungtaskd]
root 23 0.0 0.0 0 0 ? S 19:46 0:00 [kswapd0]
root 24 0.0 0.0 0 0 ? SN 19:46 0:00 [ksmd]
root 25 0.0 0.0 0 0 ? S 19:46 0:00 [aio/0]
root 26 0.0 0.0 0 0 ? S 19:46 0:00 [crypto/0]
root 229 0.0 0.0 0 0 ? S 19:46 0:00 [ksuspend_usbd]
root 230 0.0 0.0 0 0 ? S 19:46 0:00 [khubd]
root 235 0.0 0.0 0 0 ? S 19:46 0:00 [ata/0]
root 240 0.0 0.0 0 0 ? S 19:46 0:00 [ata_aux]
root 241 0.0 0.0 0 0 ? S 19:46 0:00 [kmmcd]
root 243 0.0 0.0 0 0 ? S 19:46 0:00 [scsi_eh_0]
root 245 0.0 0.0 0 0 ? S 19:46 0:00 [scsi_eh_1]
root 283 0.0 0.0 0 0 ? S 19:46 0:00 [kstriped]
root 286 0.0 0.0 0 0 ? S 19:46 0:00 [kdmflush]
root 293 0.0 0.0 0 0 ? S 19:46 0:00 [kdmflush]
root 307 0.0 0.0 0 0 ? S 19:46 0:00 [kjournald]
root 381 0.0 0.0 2460 992 ? S<s 19:47 0:00 udevd --daemon
root 543 0.0 0.0 2544 928 ? S< 19:47 0:00 udevd --daemon
root 544 0.0 0.0 2544 912 ? S< 19:47 0:00 udevd --daemon
root 602 0.0 0.0 0 0 ? S 19:47 0:00 [kpsmoused]
root 611 0.0 0.0 0 0 ? S 19:47 0:00 [i915]
root 613 0.0 0.0 0 0 ? S 19:47 0:00 [tifm]
root 618 0.0 0.0 0 0 ? S 19:47 0:00 [ipw2200/0]
root 642 0.0 0.0 0 0 ? S 19:47 0:00 [pccardd]
root 643 0.0 0.0 0 0 ? S 19:47 0:00 [pccardd]
root 768 0.0 0.0 0 0 ? S 19:47 0:00 [firewire_sbp2]
root 800 0.0 0.0 0 0 ? S 19:47 0:00 [kdmflush]
root 837 0.0 0.0 0 0 ? S 19:47 0:00 [kjournald]
root 916 0.0 0.0 0 0 ? S 19:47 0:00 [flush-254:0]
daemon 977 0.0 0.0 1812 500 ? Ss 19:47 0:00 /sbin/portmap
statd 990 0.0 0.0 1940 788 ? Ss 19:47 0:00 /sbin/rpc.statd
root 1138 0.0 0.0 0 0 ? S 19:47 0:00 [rpciod/0]
root 1146 0.0 0.1 27584 1684 ? Sl 19:47 0:00 /usr/sbin/rsyslogd -c4
root 1166 0.0 0.0 0 0 ? S 19:47 0:00 [lockd]
root 1167 0.0 0.0 0 0 ? S 19:47 0:00 [nfsd4]
root 1168 0.0 0.0 0 0 ? S 19:47 0:00 [nfsd]
root 1169 0.0 0.0 0 0 ? S 19:47 0:00 [nfsd]
root 1170 0.0 0.0 0 0 ? S 19:47 0:00 [nfsd]
root 1171 0.0 0.0 0 0 ? S 19:47 0:00 [nfsd]
root 1172 0.0 0.0 0 0 ? S 19:47 0:00 [nfsd]
root 1173 0.0 0.0 0 0 ? S 19:47 0:00 [nfsd]
root 1175 0.0 0.0 0 0 ? S 19:47 0:00 [nfsd]
root 1177 0.0 0.0 0 0 ? S 19:47 0:00 [nfsd]
root 1193 0.0 0.0 2112 360 ? Ss 19:47 0:00 /usr/sbin/rpc.mountd --manage-gids
root 1215 0.0 0.0 1536 196 ? Ss 19:47 0:00 /usr/sbin/acpi_fakekeyd
root 1220 0.0 0.0 1864 748 ? Ss 19:47 0:00 /usr/sbin/acpid
daemon 1248 0.0 0.0 2164 416 ? Ss 19:47 0:00 /usr/sbin/atd
105 1275 0.0 0.0 2584 788 ? Ss 19:47 0:00 /usr/bin/dbus-daemon --system
bind 1281 0.0 1.2 46284 12804 ? Ssl 19:47 0:00 /usr/sbin/named -u bind -t /var/lib/named
root 1291 0.0 0.0 0 0 ? S 19:47 0:00 [kconservative/0]
avahi 1325 0.0 0.1 2956 1536 ? S 19:47 0:00 avahi-daemon: running [angel.local]
avahi 1326 0.0 0.0 2844 488 ? S 19:47 0:00 avahi-daemon: chroot helper
root 1349 0.0 0.6 40376 6928 ? Ssl 19:47 0:00 /usr/sbin/lwresd
root 1355 0.0 0.1 4020 1792 ? Ss 19:47 0:00 /usr/sbin/bluetoothd
root 1368 0.0 0.0 1880 632 ? Ss 19:47 0:00 /usr/sbin/inetd
root 1376 0.0 0.0 0 0 ? S 19:47 0:00 [bluetooth]
root 1384 0.0 0.0 0 0 ? S< 19:47 0:00 [krfcommd]
root 1409 0.0 0.9 26412 10148 ? Ss 19:47 0:00 /usr/sbin/apache2 -k start
root 1436 0.0 0.0 3816 944 ? Ss 19:47 0:00 /usr/sbin/cron
www-data 1485 0.0 0.5 26412 5660 ? S 19:47 0:00 /usr/sbin/apache2 -k start
www-data 1486 0.0 0.5 26412 5656 ? S 19:47 0:00 /usr/sbin/apache2 -k start
www-data 1487 0.0 0.5 26412 5656 ? S 19:47 0:00 /usr/sbin/apache2 -k start
www-data 1488 0.0 0.5 26412 5656 ? S 19:47 0:00 /usr/sbin/apache2 -k start
www-data 1490 0.0 0.5 26412 5656 ? S 19:47 0:00 /usr/sbin/apache2 -k start
root 1695 0.0 0.1 9184 1716 ? Ss 19:47 0:00 /usr/sbin/nmbd -D
101 1702 0.0 0.0 6540 936 ? Ss 19:47 0:00 /usr/sbin/exim4 -bd -q30m
root 1718 0.0 0.2 16588 2952 ? Ss 19:47 0:00 /usr/sbin/smbd -D
root 1725 0.0 0.0 5500 976 ? Ss 19:47 0:00 /usr/sbin/sshd
root 1733 0.0 0.1 16588 1256 ? S 19:47 0:00 /usr/sbin/smbd -D
root 1738 0.0 0.1 13184 1588 ? Ss 19:47 0:00 /usr/sbin/winbindd
root 1749 0.0 0.1 13184 1232 ? S 19:47 0:00 /usr/sbin/winbindd
root 1796 0.0 0.0 1712 568 tty1 Ss+ 19:47 0:00 /sbin/getty 38400 tty1
root 1797 0.0 0.0 1712 568 tty2 Ss+ 19:47 0:00 /sbin/getty 38400 tty2
root 1798 0.0 0.0 1712 564 tty3 Ss+ 19:47 0:00 /sbin/getty 38400 tty3
root 1799 0.0 0.0 1712 568 tty4 Ss+ 19:47 0:00 /sbin/getty 38400 tty4
root 1800 0.0 0.0 1712 564 tty5 Ss+ 19:47 0:00 /sbin/getty 38400 tty5
root 1801 0.0 0.0 1712 568 tty6 Ss+ 19:47 0:00 /sbin/getty 38400 tty6
root 1809 0.0 0.0 2036 900 ? Ss 19:48 0:00 sshd
root 1810 0.0 0.2 8484 2920 ? Ss 19:48 0:00 sshd: david [priv]
david 1812 0.0 0.1 8624 1476 ? S 19:48 0:00 sshd: david@pts/0
david 1813 0.0 0.5 8168 5536 pts/0 Ss 19:48 0:00 -bash
root 1876 0.0 0.1 4148 1284 pts/0 S 19:49 0:00 su
root 1877 0.0 0.3 5924 3288 pts/0 S 19:49 0:00 bash
root 1994 0.0 0.1 3876 1052 pts/0 R+ 20:02 0:00 ps aux
Mým problémem je to, že nemohu zaboha najít co ten dotyčný nainstaloval, popř. změnil - poradíte, kde hledat? ircd jsem nikde nenašel, ale možná je to tím že neumím hledat? Zajímalo by mě to opravdu moc. Předem díky za rady
-
To uz sa niekde riesilo; mne sa zda, ze proces 1809 nie je to SSHD, ktore by si cakal.
-
Mám to. Bylo to chytrý. Nastavil si spouštění pomocí cronu v /var/spool/cron/crontabs/root (náhodou jsem si všiml, že cron předním zapnutý nebyl) a cesta k těm jeho souborům (tvářícím se jako sshd) byla:
/var/tmp/.log/.♦/.public/Docela hukot ... :)
-
Hlavne jsi "vul", kdyz pouzivas pripojeni pres heslo a ne verejny klic na serveru viditelnem z internetu ;-)
-
Jestli to nebyl jouda, tak si tam nainstaloval ještě nějaký další přístup.
Doporučil bych celkovou reinstalaci.
-
jeste neni od veci nastavit fail2ban a nakonfigurovat do toho co nejvic sluzeb, vetsinou to davam tak na 3 pokusy pri neuspesnem prihlaseni na SSH a ta IP adresa ma BAN na 24 hodin :) (mozna by stacily 2 hodiny)
ale roota zakazuju vzdycky
-
První věc po instalaci: přesunout ssh na jiný port.
-
První věc po instalaci: přesunout ssh na jiný port.
Sken portů a tohle úžasné bezpečnostní opatření zdrží útočníka o půl minuty.
-
Sken portů a tohle úžasné bezpečnostní opatření zdrží útočníka o půl minuty.
To neni opatreni proti cilenemu utoku, ale proti botum.
-
Sken portů a tohle úžasné bezpečnostní opatření zdrží útočníka o půl minuty.
To neni opatreni proti cilenemu utoku, ale proti botum.
tak tak.. a ani tohle nebude cílený útok proti konkrétnímu serveru, ale prostě jeden z mnoha, který se proskenováním ip adres chytil :-)
-
Anonymous si vytváří seznam testovacích serverů pro svoje nové rekruty. Měl by ses cítit poctěn :)
Zajímalo by mně, jak moc jednoduché heslo to bylo a jak dlouho útočníkovi trvalo ho prolomit.
Takhle se to stalo na domácím testovacím serveru, nicméně si nedělám vůbec žádné iluze o tom, že se to stává obrovské spoustě lidí i na produkčních serverech a kolikrát o tom ani nevědi, dokavaď admin nedostane zprávu o odpojení jeho spamujícího serveru ze sítě :)
-
No... to heslo bylo opradu jednoduché ... asi první co každého napadne.. root :-) Ale na tom serveru nebylo opravdu NIC co bych postrádal, byl to server vyloženě na hraní. Každopádně byl zapnutej jenom půl dne a tohle se stalo ... já vím že bych měl mít heslo ve stylu
7*6c6)Q>FlD6_8Z-87gk>3&}n, alespoň poučení :-)
-
A jak dlouho ten server bezel an vnejsi siti nez se to stalo? Ono pokud to ma clovek na hrani tak je to v pohode, alespon ma o zabavu postarano, to kdyby clovek chtel tak si zadnyho hackera ne a ne chytit :)
-
Jednou rootem navždy rootem , a jelikož tě na 100% nalomil nějaký robot tak doporučuji reinstalaci . SSH na jiný port nemusíš dávat je to zbytečné, nastav si přihlašování přes klíče a pokud můžeš tak jen přes VPN /není podmínkou/ . Kdysi se mi to taky http://www.abclinuxu.cz/poradna/linux/show/320106 (http://www.abclinuxu.cz/poradna/linux/show/320106) stalo. Dále si nainstaluj nástroje typu denyhost atd..
-
SSH na jiný port nemusíš dávat je to zbytečné, nastav si přihlašování přes klíče a pokud můžeš tak jen přes VPN /není podmínkou/ .
Neni to zbytecne. Jakmile bot najde otevreny ssh port, zacne ho bombardovat pokusy - to vede minimalne k zbytecnemu zahlceni pripojeni. Zakazovani podle IP v dnesni ere botnetu nema moc smysl - tabulka zakazanych IP bobtna a utoky pokracuji.
Pristup k ssh pres vpn je uz uplny nesmysl. Napr. OpenVPN ma stejne silnou autentizaci jako ssh, takze to zadny vyznamny narust bezpecnosti neprinasi, jenom to komplikuje pristup.
-
Nic jiného jsi ovšem nenapsal :) . Vše je jenom o tom že zhoršuješ útočníkovi cestu , tudíž ani změna portu k ničemu nevede atd. atd. A je zbytečné o tom polemizovat neb takových diskusí je na netu tuna.
SSH na jiný port nemusíš dávat je to zbytečné, nastav si přihlašování přes klíče a pokud můžeš tak jen přes VPN /není podmínkou/ .
Neni to zbytecne. Jakmile bot najde otevreny ssh port, zacne ho bombardovat pokusy - to vede minimalne k zbytecnemu zahlceni pripojeni. Zakazovani podle IP v dnesni ere botnetu nema moc smysl - tabulka zakazanych IP bobtna a utoky pokracuji.
Pristup k ssh pres vpn je uz uplny nesmysl. Napr. OpenVPN ma stejne silnou autentizaci jako ssh, takze to zadny vyznamny narust bezpecnosti neprinasi, jenom to komplikuje pristup.
-
tudíž ani změna portu k ničemu nevede atd. atd.
Jisteze vede: presun na jiny port eliminuje celou jednu skupinu utoku a to jsou utoky botu.
VPN ale [skoro] nic neprinasi, protoze jenom pridava druhou vrstvu s uplne stejne silnym zabezpecenim. S trochou nadsazky je to asi tak jako kdyz k jedne FABce pridas druhou, uplne stejnou. Temer shodneho efektu muzes dosahnout zdvojnasobenim delky klice.
-
:)) reaguji naposled /neb to nemá cenu/ Změna portu se s trochou nadsázky dá přirovnat k tomu že jsi místo visacího zámku dal FABku. Prostě si útočník vezme jen jiný paklíč.
-
neb to nemá cenu
Souhlasim.
-
To co ti tam nainstaloval je IRC bot. Pouzivaju na to najcastejsie eggdrop i ked binarka sa asi bude volat inac. Bot sa pripaja do botnetu kde mozu byt aj miliony podobne napadnutych PC a skrze irckovy kanal prijma prikazy od operatorov. Takto je mozne celkom efektivne ovladat velke mnoztvo PC zombies. Celkom bezny utok + instalacia. Mozno by stacilo odmazat binarky a nastavit lepsie hesla, ale je by som radsej reinstaloval. Jeden nikdy nevie.
-
A jak dlouho ten server bezel an vnejsi siti nez se to stalo?
Cca 30 hodin ... a tohle asi nebyl boot, ale někdo živý (v logu bylo vidět i bombardování od bootů, zkoušeli různá jména podle nějakého slovníku) ale tenhle průnik byl z uplně jiné IP.
-
IRC boot se maskoval jako sshd a ještě to vypadá že mám nějaký "upravený" bind... jako řešení vidím kompletní reinstall. Jinak k tomu flamu tady: nebylo by lepší než měnit porty říct které IP se mohou připojit? :) Zakázat všechny kromě... xxx.xxx.xxx.xxx
-
preinstalovat.
krome toho koukam, ze metody jsou docela furt stejny. irc bot & sshd. Pred par lety se mi taky stalo, ze jeden server byl hacknut, poznal jsem to podle toho, ze se mi zvedl nehorazne traffic a pak sem nasel irc bot, ktery slouzil jako redirektor.
dal sem si tenkrat praci, pustil si tcpdump a nasel si, z jakyho irc serveru a kanalu chodej prikazy, tak sem se tam prihlasil, chvili si s tema rumunama povidal (ano skutecne to byli rumuni) a kdyz mi neverili, ze jsem z jednoho jejich hacknuty serveru, tak sem jim zacal zabijet konexe jednu po druhy. pak me vykopli a i kdyz sem stroj komplet preinstaloval a zkonfiguroval znova a lepe, byl aspon 14 dni pod viceci mene nepravidelnou vetsi zatezi :0)
-
Věren heslu: "Všeho s Mírou." musím s Mírou souhlasit. Změna SSH portu slouží skutečně k eliminaci trafiku a hloupích botů a script kiddies spíše než jako bezpečnostní prvek sloužící k znesnadnění přístupu do sítě. Samozřejmě že při "cíleném" útoku si útočník port zjistí scanem ale to už je úplně jiná písnička. Ono totiž k bezpečnosti můžeme přispět nejenom vymýšlením složitých triků jak útočníka nepustit do systému, ale i tím, že mu to nebudeme usnadňovat.
nebylo by lepší než měnit porty říct které IP se mohou připojit?
Pro tvé účely určitě, v praxi ne dost dobře použitelné. Spousta adminů je dosti v pohybu a má ráda, může-li adminovat servery na dálku odkudkoliv s využitím mobilního připojení etc. což by při povolení pouze určitých IP nebylo možné. To už bys rovnou mohl použít druhou síťovku s nezávislým filtrovaným připojením pro přihlášení přes SSH :).
-
Ještě co se týká těch Vašich analogií, tak nechat SSH na defaultním portu je asi stejně chytrý jako dát si na klíče od bytu cedulku s adresou a nebo je ztratit a vyvěsit letáky s nápisem s žádostí vrácení na oné adrese. Beztak jedinej kdo potřebuje mít přístup na SSH je admin tak to opravdu nikterak velký problém není. Navíc může ten port používat u všech serverů co spravuje stejný, protože základní myšlenkou je, že ten port není defaultní a ne kterej port to vlastně kruci je.
-
A jak dlouho ten server bezel an vnejsi siti nez se to stalo?
Cca 30 hodin ... a tohle asi nebyl boot, ale někdo živý (v logu bylo vidět i bombardování od bootů, zkoušeli různá jména podle nějakého slovníku) ale tenhle průnik byl z uplně jiné IP.
Rada úplné reinstalace je vhodná u produkčního serveru. Jestli chceš zkoumat následky útoku a zkoušet různé metody obrany, tak se ho pokus vyčistit.
Hlavně zakaž přihlašování ze sítě heslem a nechej jen přihlášení pomocí klíčů. Změnu defaultního portu SSH považuji za zbytečnou, protože ani se správným heslem se už nikdo nepřihlásí.
BTW: bot a boot jsou dvě slova s rozdílným významem.
-
Mam na testovacom servri s verejnou IP ssh na defaultnom porte 23 (root samozrejme zakazany, ale prihlasovanie heslom povolene) a denne su na server urobene cca. 3 utoky, ktore po par pokusoch vzdy zablokuje denyhosts. V /etc/hosts.deny mam za asi 2 roky prevadzky 2144 zablokovanych IP adries. Zaujimave je sledovat v auth.log, ake uzivatelske mena tie boty skusaju, okrem "root" je tam napriklad "oracle" a v poslednom case som si vsimol multi-kulti "moustaffa" :-)
-
Tak pokud mas ssh na svem serveru SSH na defaultnim portu 23 tak se nedivim ze tam mas tak pusto....
-
Podle mě stačí zabezpečení, který mam já - přihlášení jen s klíčem, root úplně zakázanej, SSH na standard portu. fail2ban a podobný nepoužívam, traffic mi připadá naprosto v pohodě (v řádek kilobajtů, když zrovna nedělám něco velkýho).
Samozřejmě bych udělal komplet čistou instalaci.
-
2 Pavouk106
A jak se projevi na logu pokus o autentifikaci bota kdyz je vypnute prihlasovani heslem? Projevi se to nejak nebo je komunikace proste zahozena?
-
Hlavne jsi "vul", kdyz pouzivas pripojeni pres heslo a ne verejny klic na serveru viditelnem z internetu ;-)
Toz kdyby sshd jel na nejakem podivnem portu, byl zakazany root login, useri meli poradna hesla a jeste tam bylo denyhosts nebo jak se to, se synchronizaci proti vnejsi databazi, tak to je celkem v pohode, at si bruteforcuji, jak se jim zachce. Za tech rekneme pet povolenych pokusu to nestihnou.
-
Tak pokud mas ssh na svem serveru SSH na defaultnim portu 23 tak se nedivim ze tam mas tak pusto....
Samozrejme, ze je to na 22
-
já vím že bych měl mít heslo ve stylu 7*6c6)Q>FlD6_8Z-87gk>3&}n
Takhle überkomplikovaný heslo ani není potřeba, stačí dostatečná délka. Hesla o délce nad 20 znaků bude někdo louskat do alelujá.
-
To si jenom myslíš. Dvacetiznakové heslo složené jenom z písmen (resp. slov, která dávají smysl) se dá prolomit znatelně rychleji, než heslo, které obsahuje i speciální znaky.
-
Na shovávání služeb je super toto http://cs.wikipedia.org/wiki/Port_knocking a ne nějaké změnění defaultního portu.
-
Dvacetiznakové heslo složené jenom z písmen (resp. slov, která dávají smysl) se dá prolomit znatelně rychleji
Vždyť to ani nikde nepopírám ;-) Jen tvrdím, že u takhle dlouhého hesla je doba potřebná k prolomení dostatečně dlouhá i při použití abecedy(velká/malá písmena). Třeba tebou uvedené heslo bych si v životě nezapamatoval.
-
Jinak k tomu flamu tady: nebylo by lepší než měnit porty říct které IP se mohou připojit? :) Zakázat všechny kromě... xxx.xxx.xxx.xxx
"Lepší" z hlediska čeho?
Já se třeba neustále pohybuju mezi X různýma sítěma, v některých z nich mají dokonce stanice veřejné IP adresy. O připojení z mobilu ani nemluvě. Takže pro mě osobně je daleko lepší použít:
1. nestandardní port
2. smart card jako standardní způsob přihlášení
3. kvalitní heslo jako nouzovka když 2 nejde použít
1 je ochrana proti otravujícím botům (hlavně mi vadilo přeplňování logu. zbytečná zátěž serveru a linky není zas taková trága). 2 a 3 je situaci-odpovídající ochrana proti cílenému útoku.
Pokud bych chtěl na tom mým způsobu něco vylepšovat, zvažoval bych one time passwords a delay pro neúspěšná přihlášení. Zatím ale nevidím důvod.
Takhle to vyhovuje mým potřebám, tvoje potřeby můžou být úplně jiné, takže úplně jiné může být i jim odpovídající řešení. Pokud chceš třeba útoky zkoumat, nebo útočníky prudit, můžeš si na port 22 umístit falešné sshčko s nějakým honeypotem :) Fantazii se meze nekladou, záleží jenom na tom, čeho chceš dosáhnout.
-
http://cs.wikipedia.org/wiki/Port_knocking
Stejně nepomůže pokud půjde o cílený útok. Akorát prodlouží. Tu sekvenci ťukání je také možné odposlechnout, nebo se pletu?
-
To si jenom myslíš. Dvacetiznakové heslo složené jenom z písmen (resp. slov, která dávají smysl) se dá prolomit znatelně rychleji, než heslo, které obsahuje i speciální znaky.
Nez ake heslo? 20 znakove heslo zlozene len z pismen prelomis pri offline utoku na lepsom GPU cca za 7,6e7 nasobok veku vesmiru. (~1e18 rokov).
Heslo zo 4 slov, co davaju zmysel (vyber 4 slov z Oxford English Dictionary, rychlo som to nevedel spocitat lepsie): 25876 rokov. A to je stale offline utok pri 2.8mld pokusoch za sekundu; nepocitam s tym, ze niekto moze medzi slovami pouzit / nepouzit medzeru, zacat kazde slovo velkym pismenom a pod. V realnom zivote by to bolo teda radovo horsie uz preto, lebo sa nezvlada bruteforcovat takou rychlostou.
Ak pridame cisla a specialne znaky, tak sme na urovni 20 pismenoveho hesla niekde u 16.5 znaku. To nie je take velke zlepsenie, ak to nie je dobre zapamatatelne.
Inak k flamu tady: Presuvanie na iny port nema vyznam - kazdy aspon trochu schopnejsi bot oskenuje porty. Single packet authorization a port knocking je rozumna alternativa. Nevidim dovod, preco by mal moj SSH port vidiet cely svet.
A vobec nechapem, preco by som mal mat povolene prihlasenie pomocou hesla.
Vyznam port knockingu je hlavne ten, ze nie kazdy sa dostane na take miesto, aby to mohol odpocuvat. A ak sa tam dostane, tak su tu stale dalsie ochranne mechanizmy, totiz tie od samotneho SSH (a medzi tym mi pride SMS, ze sa niekto prihlasuje k serveru a ja spravim opravu).
-
No ale co třeba kdyby to 20ti znakové heslo bylo nějaké jedno opravdu dlouhé anglické slovo? Při troše štěstí a dobrém wordlistu by bylo možné odhalit takovéhle heslo mnohem dřív... podotýkám při štěstí... teoreticky
-
Inak k flamu tady: Presuvanie na iny port nema vyznam - kazdy aspon trochu schopnejsi bot oskenuje porty.
Ze zkušenosti můžu potrvdit opak. Na pěti serverech s sshčkem otevřeným do světa na nestandardním portu během několika let si nepamatuju žádnej útok. Předtím několik denně.
A vobec nechapem, preco by som mal mat povolene prihlasenie pomocou hesla.
A on tě někdo nutí ho mít povolené?
-
Inak k flamu tady: Presuvanie na iny port nema vyznam - kazdy aspon trochu schopnejsi bot oskenuje porty.
Ze zkušenosti můžu potrvdit opak. Na pěti serverech s sshčkem otevřeným do světa na nestandardním portu během několika let si nepamatuju žádnej útok. Předtím několik denně.
Staci si pockat na nejaky 0day ssh exploit a potom zacne zabava (kludne staci aj nieco ako predictable random number generator z Debianu). Alebo mozno bude stacit len niekto schopnejsi a cieleny utok.
A vobec nechapem, preco by som mal mat povolene prihlasenie pomocou hesla.
A on tě někdo nutí ho mít povolené?
To neviem, ale pisete
3. kvalitní heslo jako nouzovka když 2 nejde použít
(a taky pripad si nejak neviem predstavit)
-
Staci si pockat na nejaky 0day ssh exploit a potom zacne zabava (kludne staci aj nieco ako predictable random number generator z Debianu). Alebo mozno bude stacit len niekto schopnejsi a cieleny utok.
...anebo na 0day exploit pro Postfix. Takze asi zavedeme port-knocking pro port 25 :)
To neviem, ale pisete
3. kvalitní heslo jako nouzovka když 2 nejde použít
(a taky pripad si nejak neviem predstavit)
Takovy pripad nastane napriklad tehdy, kdyz se prihlasuju ze stroje, ktery nemam pod spravou a tedy tam nemuzu pouzit smart card (neni podpora), ale zaroven spravci duveruju, ze mi nesnifuje heslo. Jiste je to riziko, ale v jistych situacich jsem ochoten ho podstoupit.
Jinak bych asi znovu zopakoval, ze jsem mluvil o tom, co pouzivam ja. Jini lidi maji jine potreby a tedy i jina reseni, ktere jim neberu.
Jinak bych doporucil ke cteni thread "Nekonecne dlouhy auth.log" http://www.freebsd.cz/listserv/archive/users-l/2008q4/thread.html#22906 a specialne Danuv prispevek: http://www.freebsd.cz/listserv/archive/users-l/2008q4/022935.html
-
Udelej neco, co utocnik neceka a s cim nepocita.
Takova obrana byva necekane ucinna a pritom casto pomerne nenarocna.
Přesně to jsem udělal :D Měl jsem SSH na 22 a heslo pro roota root :D
Tak tohle nečekal :D
-
Takovy pripad nastane napriklad tehdy, kdyz se prihlasuju ze stroje, ktery nemam pod spravou a tedy tam nemuzu pouzit smart card (neni podpora), ale zaroven spravci duveruju, ze mi nesnifuje heslo. Jiste je to riziko, ale v jistych situacich jsem ochoten ho podstoupit.
No i v takovem pripade ale muzu pouzit USB se svym klicem coz bude asi rozumnejsi reseni nez nechavat povolene heslo.
-
...anebo na 0day exploit pro Postfix. Takze asi zavedeme port-knocking pro port 25 :)
...alebo premiestnime Postfix na iny port :).
(Postfix ma na rozdiel od sshd tu vyhodu, ze sa da dost pekne obmedzit; take drasticke obmedzenie sshd by znamenalo aj obmedzenie cez ssh pracujuceho uzivatela)
Takovy pripad nastane napriklad tehdy, kdyz se prihlasuju ze stroje, ktery nemam pod spravou a tedy tam nemuzu pouzit smart card (neni podpora), ale zaroven spravci duveruju, ze mi nesnifuje heslo. Jiste je to riziko, ale v jistych situacich jsem ochoten ho podstoupit.
A co verejny / privatny kluc "na flashke"?
Jinak bych asi znovu zopakoval, ze jsem mluvil o tom, co pouzivam ja. Jini lidi maji jine potreby a tedy i jina reseni, ktere jim neberu.
To ano, ale preco to neriesit efektivnejsie, ked to ide s minimalnou namahou? (To sa vztahuje aj k zapisku "nekonecne dlouhy log").
-
A co verejny / privatny kluc "na flashke"?
To povazuju za daleko nebezpecnejsi nez kvalitni heslo (flashka se da ukrast, nepozorovane zkopirovat, ... cokoli).
Ja *osobne* to hodnotim jako vyssi riziko. Jak to hodnotite vy, to je vase vec.
-
A co verejny / privatny kluc "na flashke"?
To povazuju za daleko nebezpecnejsi nez kvalitni heslo (flashka se da ukrast, nepozorovane zkopirovat, ... cokoli).
Ja *osobne* to hodnotim jako vyssi riziko. Jak to hodnotite vy, to je vase vec.
Ja *osobne* zase hodnotim zaheslovany privatny kluc (AES sifrovanie) pri slusnom hesle + nutnost nieco mat (flashku alebo subor z nej) ako mensie riziko ako samostatne heslo. Ale hodnotenie je zase aj vasa vec.
-
Ja *osobne* zase hodnotim zaheslovany privatny kluc (AES sifrovanie) pri slusnom hesle + nutnost nieco mat (flashku alebo subor z nej) ako mensie riziko ako samostatne heslo. Ale hodnotenie je zase aj vasa vec.
Muzu se zeptat, proti jakemu typu utoku je takove reseni odolnejsi oproti samotnemu heslu?
Jedine, co me napada, je proste odkoukani zadavani hesla kamerou (bez dalsich kroku jako je zkopirovani flashky, to uz by bylo nastejno). Nic jineho me fakt nenapada.
-
2 Pavouk106
A jak se projevi na logu pokus o autentifikaci bota kdyz je vypnute prihlasovani heslem? Projevi se to nejak nebo je komunikace proste zahozena?
Člověče, nebudu kecat - ani mě to nijak nezajímá(-alo).
-
2 Pavouk106
A jak se projevi na logu pokus o autentifikaci bota kdyz je vypnute prihlasovani heslem? Projevi se to nejak nebo je komunikace proste zahozena?
U normálního sshčka takhle:
debug1: No more authentication methods to try.
Když bot nedostane k dispozici autentizaci heslem, tak se nejspis hnedka odpoji, pokud není blbej. Ale kdoví :)
-
Muzu se zeptat, proti jakemu typu utoku je takove reseni odolnejsi oproti samotnemu heslu?
Raz mi to "zachranilo zivot" pri SW keyloggeri na (predtym podla mna) doveryhodnom stroji.
Okrem skoro nepomoze odchytenie hesla (odpocuvanie klavesnice; moze byt aj na HW urovni). Dalej to je bezpecnejsie proti bruteforce-ovaniu, kedze sa heslo nepouziva. A "rozkaz" pouzivat kluce pre vsetkych uzivatelov SSH zvysuje bezpecnost nielen moju, ale aj uzivatelov, na ktorych nemam taky priamy dosah a inak by si mohli dat aj heslo 123456.
Keylogger som odhalil nahodou pri skumani netypickeho chovania; je pravda, ze pri cielenejsom utoku by toto neobstalo - je to niekde na urovni zmeny portu sshd. Ide prave o to, co pisal Dan Lukes - spravit nieco, s cim utocnik nepocita. A s tymto pri nahodnom odchytavani hesiel nepocital, aj ked sa podla pokusov o prihlasenie na server takemuto pristupu potesil.
-
To si jenom myslíš. Dvacetiznakové heslo složené jenom z písmen (resp. slov, která dávají smysl) se dá prolomit znatelně rychleji, než heslo, které obsahuje i speciální znaky.
Jako dobré heslo jsou ideální pro autora zapamatovatelné, krátké věty, s jedním nebo dvěma spec. znaky:
JsemJirka#JeMi27
nebo m9sto diakritiky hodit ekvivalent na ENG kl8vesnici:
MilujuVer4u?:)
nebo s mírnou modifikací podle jména stroje kam přistupuji (třeba server v jménem "saturn")
Saturnm82terov7disky
a jistě se najde spousrta dalších variací ...
-
Ono nejde jen o to SShcko, ale i o sluzby na serveru bezici. Nedavno jsem resil hacknuty server, na kterem bylo ssh presunute na jiny port a ve firewallu presne specifikovane IP adresy. Problem byl vsak nekde jinde. Vlastnik toho serveru jednoho krasneho dne prisel s ti, ze tam chce web server a, ze bude provozovat webovky. Rozjel se web server a bylo. Jenze dotycny pouzil jako motor pro svuj web yoomlu a problem byl na svete. Prez exploit ci sql injection dokazal utocnik efektivne spustit upraveneho ssh daemona v temp adresari. Tento ssh daemon neslouzil jako vstup na server, ale jen jako repeater pro ssh utoky. Takze takova nenasilne vytvorena brana do sveta. Podarilo se mi vse eliminovat, ale chtel jsem tim rict ze ne vzdy dochazi k primemu prolomeni prez ssh. ;)
-
Raz mi to "zachranilo zivot" pri SW keyloggeri na (predtym podla mna) doveryhodnom stroji.
Pokud je nedůvěryhodný stroj, přes který se přihlašuju, padá jakákoliv bezpečnost. Jinými slovy, nezachránil vás klíč, zachránilo vás to, že šlo jenom o keylogger a ne o upravené sshčko.
Okrem skoro nepomoze odchytenie hesla (odpocuvanie klavesnice; moze byt aj na HW urovni).
To je ten samý případ. Mám-li HW, který může číct klávesnici, můžu mít se stejnou námahou HW, který kopíruje obsah flashky.
Dalej to je bezpecnejsie proti bruteforce-ovaniu, kedze sa heslo nepouziva.
Myslím, že tady zaznělo z úst někoho jiného dostatečně jasně, že silné heslo je z praktického hlediska stejně neprolomitelné jako klíč.
A "rozkaz" pouzivat kluce pre vsetkych uzivatelov SSH zvysuje bezpecnost nielen moju, ale aj uzivatelov, na ktorych nemam taky priamy dosah a inak by si mohli dat aj heslo 123456.
Dohled nad hesly jiných uživatelů je úplně jiný problém.
cielenejsom utoku by toto neobstalo - je to niekde na urovni zmeny portu sshd.
Vůbec nejde o cílenější útok. Ono by to neobstálo u malinko jiného útoku stejnými prostředky. Je prostě náhoda, že ses setkal s útokem A a ne útokem B, protože oba vyžadují stejné prostředky.
Podarilo se mi vse eliminovat, ale chtel jsem tim rict ze ne vzdy dochazi k primemu prolomeni prez ssh. ;)
Ono hlavně v tomhle případě nejde o prolomení sshčka, ale o blbě zvolené heslo. Stejně tak se může bruteforcovat heslo klidně k imapu. Proto je alfou a omegou mít buď kvalitní heslo (což nic moc nestojí), nebo kvalitní ochranu proti bruteforce (což stojí hodně).
-
Pokud je nedůvěryhodný stroj, přes který se přihlašuju, padá jakákoliv bezpečnost. Jinými slovy, nezachránil vás klíč, zachránilo vás to, že šlo jenom o keylogger a ne o upravené sshčko.
...
Vůbec nejde o cílenější útok. Ono by to neobstálo u malinko jiného útoku stejnými prostředky. Je prostě náhoda, že ses setkal s útokem A a ne útokem B, protože oba vyžadují stejné prostředky.
Suhlas; ako som pisal, je to podobne ako so zmenou portu SSH - tiez vas zachrani to, ze boty bezne nescanuju porty a neobstalo by to len u trochu zmeneneho utoku. O rovnakych prostriedkoch vo vseobecnosti pochybujem, viz opis dalej.
To je ten samý případ. Mám-li HW, který může číct klávesnici, můžu mít se stejnou námahou HW, který kopíruje obsah flashky.
To by som nepovedal - prinajmensom preto, lebo som uz videl HW keylogger ("medzikus" medzi klavesnicou a PC alebo dokonca odpocuvanie klavesnice na dialku), ale este som nevidel nieco schopne kopirovat obsah prenasany cez USB. Mozno je to tym, ze tieto datove toky byvaju vacsie a teda narocnejsie na priestor (+ulozenie a analyzu); zaroven byva aj viac USB portov a naviac je treba zariadenie lepsie skryt (uzivatel sa pozera, kam picha flashku). Skrytie sice je mozne, ale to uz nezvladne obycajna upratovacka.
Myslím, že tady zaznělo z úst někoho jiného dostatečně jasně, že silné heslo je z praktického hlediska stejně neprolomitelné jako klíč.
Ak je naozaj silne, tak ano.
OT: Ako otestovat silu hesla? Niekde sa pisalo, ze pwgen nedava uplne rovnomerne rozdelenie, takze sa da teoreticky skusat hesla efektivnejsie ako skusanim vsetkych moznosti. Ja si heslo obycajne vymyslim "z miesta" na klavesnici tak, ze napisem napriklad "QzJ1ak!!xISppo" a ten pohyb si zapamatam (nie heslo). Lenze podvedomie moze byt tiez niecim ovplyvnene, rovnako aj pohyby - to by sa mozno dalo nejak rekonstruovat. Je teda take heslo dost dobre na to, aby odolalo bruteforce?
Ono hlavně v tomhle případě nejde o prolomení sshčka, ale o blbě zvolené heslo. Stejně tak se může bruteforcovat heslo klidně k imapu. Proto je alfou a omegou mít buď kvalitní heslo (což nic moc nestojí), nebo kvalitní ochranu proti bruteforce (což stojí hodně).
Ano, moze bruteforcovat, ale dobre heslo je len jeden krok (heslo moze ziskat aj inak, ako to byva u ulozenych FTP pristupov) - dolezite je snazit sa spravit dostatocne oddelenie sluzieb (prienik alebo exploitacia jednej sluzby znamena len jej kompromitaciu; nie kompromitaciu celeho systemu). Potom sa moze hodit obmedzenie poctu spojeni pomocou modulu recent - to moze byt narocne na vykon serveru, preto sa to neda len tak odporucat.
-
Suhlas; ako som pisal, je to podobne ako so zmenou portu SSH - tiez vas zachrani to, ze boty bezne nescanuju porty a neobstalo by to len u trochu zmeneneho utoku. O rovnakych prostriedkoch vo vseobecnosti pochybujem, viz opis dalej.
Já jsem ale netvrdil, že přesun na jiný port je lepší než něco jiného. Narozdíl od vás, který jste tvrdil, že klíč na flashce je lepší než (kvalitní) heslo.
Ak je naozaj silne, tak ano.
No to jsem rad, ze jsme se konecne shodli :)
OT: Ako otestovat silu hesla?
Vynasobit prumerny pocet pokusu potrebnych k uhadnuti hesla casem potrebnym na jeden pokus.
-
- nepokousejte se server "opravit" - namisto toho si udelejte kompletni zalohu na pozdejsi analyzu toho co s stalo
- nainstalujte si cely server znovu a nejlepe bez internetu - nic by nemelo zustat puvodni (i data ci diskovy layout)
- nastavte si spravne zabezpeceni
- vypnete vsechny sluzby (netstat -tupan nezobrazi zadne sluzby na internetove interface)
- provedte update z internetu
- postupne spoustejte sluzby ktere potrebujete
Predejte pripad policii.
Par tipu na zvyseni bezpecnosti (nekompletni a jsou to jen nektere tipy ne zcela vhodne pro vsechny typy nasazeni):
- tam kde se neco nejak prihlasuje, nastavte minimalni pocet neuspesnych pokusu - pak sluzbu omezte
- vse logujte
- vsude kde to jde, nepouzivejte hesla, ale namisto toho klice
- pokud nejste verejny server, pomoci iptables smerem z Internetu zahazujte pres DROP ne pres REJECT, zakazte ICMP - snazte se pro internet vypadat jakoze neexistujete
- pres iptables omezte nejen prichozi, ale i odchozi traffic - svoji sit znate a proto je pravdepodobne, ze odhadnete co uzvatele chteji
- sluzby serveru do internetu provozujte mimo zname rozsahy - ano "nmap" neobelstite
- post scanningu se muzete branit treba port knockingem, ale je to dalsi vrstva, ktera se nehodi pro verejny server
-
Já jsem ale netvrdil, že přesun na jiný port je lepší než něco jiného. Narozdíl od vás, který jste tvrdil, že klíč na flashce je lepší než (kvalitní) heslo.
To ale je lepsie v niektorych pripadoch (nie v tom mojom). Viz spominany HW keylogger (nevylucujem, ze je aj USB keylogger, ale boli by s nim problemy, ktore som opisal; mozete mi pripadne poslat adresu, kde sa da kupit?).
Vynasobit prumerny pocet pokusu potrebnych k uhadnuti hesla casem potrebnym na jeden pokus.
A ako sa teda vypocita pocet pokusov, ked netusim nic o "nahodnosti" hesla? Keby som si nahodou zvolil heslo "Fckgwrhqq2", tak to tiez vyzera nahodne, ale bruteforcne to kde-kto.
-
To ale je lepsie v niektorych pripadoch (nie v tom mojom). Viz spominany HW keylogger (nevylucujem, ze je aj USB keylogger, ale boli by s nim problemy, ktore som opisal; mozete mi pripadne poslat adresu, kde sa da kupit?).
Pro me osobne (opet: muzete to hodnotit jinak) je dulezite, jestli ta dana metoda je vuci kompromitaci urciteho zdroje imunni nebo neni. Pokud imunni neni, musim mit alespon vysokou jistotu, ze k utoku nedoslo.
Klic na flasce proste neni imunni vuci pozmenenemu SW nebo HW uplne stejne jako proti nemu neni imunni heslo.
Jak rikam, jako standardni zpusob prihlaseni pouzivam smart card, u ktere mam temer 100%ni jistotu, ze mi klic nebude ukraden. Pokud ji pouziji na kompromitovanem pocitaci, vznika riziko zneuziti klice v dobe, kdy je tam ta SC pripojena. Mam ale rozumnou jistotu, ze mi klic z ni nebude odcizen. To je vyrazne zvyseni JISTOTY oproti pouziti hesla nebo klici na flasce.
Pokud mam navic duveryhodny zpusob, jak zjistit, ze ke zneuziti v te inkriminovane dobe nedoslo (napr. tak, ze kazde prihlaseni na ony ucty se mi hlasi na mobil - coz ja takhle mam), tak mam prakticky 100% JISTOTOU, ze ke zneuziti nedoslo.
Klic na flasce ale oproti samotnemu heslu neprinasi navic JISTOTU zadnou. Respektive jenom tu, kterou jsem napsal: kdyz nekdo odpozoruje heslo, ale neukradne klic, ke kompromitaci klice nedoslo.
A ako sa teda vypocita pocet pokusov, ked netusim nic o "nahodnosti" hesla? Keby som si nahodou zvolil heslo "Fckgwrhqq2", tak to tiez vyzera nahodne, ale bruteforcne to kde-kto.
Ja bych se na to dival z druhe strany: bruteforce spociva v prohledavani nejakeho stavoveho prostoru, ktery ma nejakou jasne danou velikost. Pokud ma utocnik nejakou znalost, ktera mu umozni stavovy prostor zmensit (napr. vi, ze heslo ma 6 znaku), pak je samozrejme prolomeni hesla snazsi. Utocnik muze pouzit spoustu poznatku z bezneho sveta (napr. vi, ze nejcastejsi jsou hesla typu "root","abcdef","123456", potom jenom mala pismena, potom mala i velka atd.), ale pokud tuhle znalost mam i ja, tak si takove heslo zamerne nezvolim.
A opet tady plati, ze nejucinejsi jsou casto ta nejjednodussi opatreni - napr. jednosekundova prodleva mezi vlozenim hesla a potvrzenim jeho spravnosti + omezeni poctu moznych soucasnych autentizaci -> vyrazne se zvysi doba potrebna pro prolomeni hesla a normalni uzivatele sekunda nezabije. (tohle je jenom priklad, v realu by to melo problemy)
-
A jeste k tomu presunu na jiny port: jak rikam, mam praktickou zkusenost, ze boti skenovani portu s cilem najit ssh (zatim) nedelaji. Takze ssh na nestandardnim portu neni zaplaveno miliony pokusu script kiddies. Neni timpadem problem si hlaseni o neuspesnych pokusech o prihlaseni nechat posilat treba pres jabber -> clovek hnedka vidi, ze dochazi k nejakemu vaznejsimu utoku. Pri ssh na standardnim portu se takovyhle vaznejsi pokus o utok utopi v tech milionech stupidnich pokusu. A to je docela podstatny rozdil.
-
to zni celkem bezpecne, nedalo by se nejak nastavit, aby doba mezi poslanim hesla a overenim nebyla konstantni, ale treba tolik sekund, kolik jiz bylo z te IP adresy pokusu o prihlaseni za tento den?
-
Pro me osobne (opet: muzete to hodnotit jinak) je dulezite, jestli ta dana metoda je vuci kompromitaci urciteho zdroje imunni nebo neni. Pokud imunni neni, musim mit alespon vysokou jistotu, ze k utoku nedoslo.
Klic na flasce proste neni imunni vuci pozmenenemu SW nebo HW uplne stejne jako proti nemu neni imunni heslo.
Klic na flasce ale oproti samotnemu heslu neprinasi navic JISTOTU zadnou. Respektive jenom tu, kterou jsem napsal: kdyz nekdo odpozoruje heslo, ale neukradne klic, ke kompromitaci klice nedoslo.
Date odkaz na eshop, kde je mozne kupit nieco, co bude nepozorovane zaznamenavat data prenasane cez USB tak, aby to zvladla zapojit aj upratovacka a nebolo to velmi napadne? (Velmi napadne = nie som uplne blby, aby som zapojil flashku do medzikusu)
Toto poskytuje odolnost proti jednemu konkretnemu typu utoku - proti pouzitiu upratovacky, ktora je schopna zapojit HW keylogger k lubovolne bezpecnemu systemu.
Jak rikam, jako standardni zpusob prihlaseni pouzivam smart card, ...
My sme AFAIK rozoberali nudzovu moznost heslo vs. privatny kluc na flashke, nie standartny sposob prihlasovania. A kluc na flashke je sice zneuzitelny dlhsie, ale bolo by treba, aby si ho niekto stihol skopirovat pocas par sekund, ked je flashka pripojena a aby potom prelomil heslo k nemu.
Pokud ma utocnik nejakou znalost, ktera mu umozni stavovy prostor zmensit ... pokud tuhle znalost mam i ja, tak si takove heslo zamerne nezvolim.
Tu je problemom to "Pokud ... i ja". Mne robi problem, ze utocnik mozno ma nejaku znalost, o ktorej nemusim tusit.
-
Date odkaz na eshop, kde je mozne kupit nieco, co bude nepozorovane zaznamenavat data prenasane cez USB tak, aby to zvladla zapojit aj upratovacka a nebolo to velmi napadne? (Velmi napadne = nie som uplne blby, aby som zapojil flashku do medzikusu)
Toto poskytuje odolnost proti jednemu konkretnemu typu utoku - proti pouzitiu upratovacky, ktora je schopna zapojit HW keylogger k lubovolne bezpecnemu systemu.
Ale o to prece vubec nejde, jak snadno se to da koupit. Dulezite je, ze si nikdy nemuzete byt jisty, ze k takovemu utoku nedoslo -> klic na flashce nijak nezvysi vasi JISTOTU.
A kluc na flashke je sice zneuzitelny dlhsie, ale bolo by treba, aby si ho niekto stihol skopirovat pocas par sekund
A to je nejaky problem, mit skript, ktery automaticky zkopiruje obsah kazde vlozene flashky? Takove softy existuji i pro windows.
Jeden z X komercne dostupnych HW USB analyzeru: http://www.totalphase.com/products/beagle_usb12/
Jeden z X dostupnych softwaru, kopirujicich flashku bez vedomi uzivatele: http://www.technize.com/usb-hidden-copier-v11-released/
-
A to je nejaky problem, mit skript, ktery automaticky zkopiruje obsah kazde vlozene flashky? Takove softy existuji i pro windows.
Vzhledem k velikosti dnesnich flash disku neni problem mit na flashce hromadu dat mezi kterymi se mimo jiné bude nacházet můj klíč, který se může jmenovat jakkoliv. Pro natažení klíče do ssh clienta mi stačí pár vteřin, pro zkopírování např 8GB flash už pár vteřin nestačí. Flashky o takovýchto i větších velikostech se dneska rozdávají reklamní a také není problém flashku rozdělit na více oddílů případně si flasku dovybavit vlastními soubory generovanými o náhodných velikostech etc. a na ddcko na takové flashce už potřebuješ čas a musíš prováděd onen útok sdíleně a to už mi příjde snažší tu smartkartu nebo i flash disk ukrást.
-
Pro natažení klíče do ssh clienta mi stačí pár vteřin, pro zkopírování např 8GB flash už pár vteřin nestačí.
To je sice pravda, ale pořád zůstávají dvě zranitelnosti, který nemůžeš vyloučit: usb sniffing a upravené ssh.
Čili tu *jistotu* navíc ti to žádnou nedá (kromě falešného pocitu bezpečí).
-
nedalo by se nejak nastavit, aby doba mezi poslanim hesla a overenim nebyla konstantni, ale treba tolik sekund, kolik jiz bylo z te IP adresy pokusu o prihlaseni za tento den?
To by se sice dalo (treba mirnou upravou pam_delay), ale moc by to nepomohlo (psal jsem, ze to je priklad), protoze utoky dneska uz byvaji z ruznych IPcek a z jednoho IPcka se moc neopakuji.
-
To je sice pravda, ale pořád zůstávají dvě zranitelnosti, který nemůžeš vyloučit: usb sniffing a upravené ssh.
Čili tu *jistotu* navíc ti to žádnou nedá (kromě falešného pocitu bezpečí).
USB sniffing - to by som pripajal USB kluc do hentakej veci? Snazim sa byt aspon trochu opatrny a tam by som USB kluc nepichal. Takze toto odola voci "upratovacka attack".
Ad istota, napriklad pri upravenom ssh (klient): istota nie je ani u Smart card s gatekeeprom a one-time passwords. Staci namiesto ukoncenia pripojenia pri exit / ctrl+d nechat toto spojenie v pozadi s tym, ze uzivatel ostane prihlaseny a ssh klient sa tvari, ze sa spojenie ukoncilo.
Preto sa na toto neda spoliehat - ja to len odporucam ako lepsiu alternativu k heslu.
-
Staci namiesto ukoncenia pripojenia pri exit / ctrl+d nechat toto spojenie v pozadi s tym, ze uzivatel ostane prihlaseny a ssh klient sa tvari, ze sa spojenie ukoncilo.
Vždyť jsem to psal: pokud není důvěryhodný HW a SW, nefunguje nic.
Smartcard se ale podstatně liší v tom, že:
1. můžu lehce zjistit, jestli k takové situaci došlo
2. vím, že k ní nemůže dojít v budoucnu
3. vím, že nedošlo ke kompromitaci klíče, jenom k jeho zneužití. Proto taky nemusím klíč měnit a vím, že nebude použit na jiných serverech než na tom, na kterém použit byl.
Ta přidaná hodnota je právě v tom, že určité scénáře můžu s jistotou vyloučit. S klíčem na flashce můžu vyloučit jenom tu kameru.
Preto sa na toto neda spoliehat - ja to len odporucam ako lepsiu alternativu k heslu.
Pokud mi to řešení nedává žádnou jistotu navíc, není to lepší alternativa, ale falešný pocit bezpečí.
-
USB sniffing - to by som pripajal USB kluc do hentakej veci? Snazim sa byt aspon trochu opatrny a tam by som USB kluc nepichal. Takze toto odola voci "upratovacka attack".
Tak jeste jednou a naposledy: neni rozhodujici, jestli to odola "upratovacka attack". Rozhodujici je, jestli mi to dava nejakou jistotu navic. Ona to totiz nemusi byt upratovacka, on to muze byt borec-co-umi-rozdelat-case-a-krabicku-dat-dovnitr-attack.
-
Tak jeste jednou a naposledy: neni rozhodujici, jestli to odola "upratovacka attack". Rozhodujici je, jestli mi to dava nejakou jistotu navic. Ona to totiz nemusi byt upratovacka, on to muze byt borec-co-umi-rozdelat-case-a-krabicku-dat-dovnitr-attack.
Tak ja napriklad firemnemu PC v lubovolnej pobocke doverujem natolko, ze verim, ze tam nie je odpocuvaci software - ale za upratovacku sa nemoze zarucit asi skoro nikto. To ani vtedy, keby tam chodil s nou - instalacia HW keyloggera je vec par sekund. Preto je dolezita odolnost proti upratovacke.
Ta přidaná hodnota je právě v tom, že určité scénáře můžu s jistotou vyloučit. S klíčem na flashce můžu vyloučit jenom tu kameru.
Vždyť jsem to psal: pokud není důvěryhodný HW a SW, nefunguje nic.
Kedze sa nepocita upraveny software, tak s klucom na flashke som zranitelny len pri USB sniffingu.
Dalej budem pisat o upravenom SW, kedze na ten sa vztahovala reakcia
1. můžu lehce zjistit, jestli k takové situaci došlo
Ako? Ak mal utocnik keylogger a vy ste sa prihlasili na roota, tak ma po domnelom odhlaseni skoro urcite aj roota, s ktorym si moze nakopirovat backdoornuty SSH demon (stary napriklad killnut) alebo si moze skusit spravit ine zadne vratka (toto sa da spravit automaticky, keby sa na to utocnik zameral, takze je to otazka ~2-30 sekund).
Ak by ste nemali roota, tak je stale mozne pridat do crontabu alebo .profile "call home", co by mu dalo shell. Alebo sa spusti ako demon (alebo v screene / tmuxe) a po uspechu sa hned odhlasi; pokracovat moze menej viditelne (otazka ~sekundy).
Fantazii sa medze nekladu, moznosti je vela.
2. vím, že k ní nemůže dojít v budoucnu
Ked si tam raz da backdoor, tak ma skoro zarucene bezstarostne dalsie navstevy.
3. vím, že nedošlo ke kompromitaci klíče, jenom k jeho zneužití. Proto taky nemusím klíč měnit a vím, že nebude použit na jiných serverech než na tom, na kterém použit byl.
Zmena klucov je to najmensie a najjednoduchsie, co robim pri kazdom podozreni, ze niekto mohol moje kluce ziskat.
Problem je, ze ked si utocnik niekde prida backdoory, tak uz je system nedoveryhodny a je najlepsie ho preinstalovat. Proti tomu nepomoze asi ani smartcard.
-
@David: zasada je jedna: "hacknutemu serveru never!". Nic viac, nic menej. Pri produkcii revert z backupu, pri deskope reinstall.
Output z ps ti moze byt nanic ak narazis na skuseneho hackera. Process sa da skryt.
Urcite by stalo za to urobit si snapshot toho systemu a restornut ho do virtualky. Ak sa chces ucit, tam mozes ten hacknuty stroj studovat hlbsie.
Asi tak dolezite ako je reinstall je vediet aj ako to spravil. Podla toho co so pisal je to jednoduchy bruteforce. Zmen heslo, zlepsi firewall. Hore sa uz niektori hadali, ze zmenit port. Sice nejakych script kiddies to odradi, ale riesenie to nie je. To uz radsej by som nasadil port-knocking; i ked niektore script su ozaj sofistikovane.
-
Zdravím,
osobně bych na otázku v $SUBJ poradil (za předpokladu že má tazatel zájem):
- přesunout instalaci do virtuálu a zakázat virtuálu přístup k internetu (např. tím že mu nedáte síťovku)
- podívat se tomu "hacku" na zoubek, je to poučné.
- reinstalovat původní instalaci (to v každém případě)
K diskusi ohledně zabezpečení ssh bych z vlastní zkušenosti doporučil (v kontextu toho k čemu tazatel server používá):
- zakázat přihlášení roota
- přesunout SSH na nestandardní port
- používat rozumější (složitější) hesla / používat ssh klíče s heslem a zakázat přihlášení heslem
- fail2ban a pod.
Jsem si jistý že ne všichni budou souhlasit, ale má zkušenost s provozem *nixových serverů to do dnes po spoustu let potvrzuje.
Tyto jednoduché úpravy mají v mém případě 100% úspěšnost ve vyhýbání se útokům (na ssh) na všech serverech co provozuji/jsem provozoval (když to vezmu kolem a kolem, tak přesunutí ssh na nestandardní port je to, co eliminovalo veškeré útoky).
Myslím že je nutné si vždy položit otázku: Jak šťavnatý/zajímavý cíl jsem.
A podle odpovědi přizpůsobit vynaloženou energii na zabezpečení (ssh v tomto případě). Tím nemyslím že nezajímavý cíl = nezabezpečený cíl.
Možností je mnoho v libovolné kombinaci... např.:
- používájní silného hesla
- přesun ssh na nestandardní port
- ssh klíče / certifikáty
- smartcard/usb tokeny
- rsa tokeny
- firewall
- fail2ban/denyhost či podobné
- port knocking
- one-time hesla
- fyzicky nepřipojený server k internetu :)
- a tak podobně
Shrnuto podtrženo... používejte hlavu :)
Letu zdar,
A'kia
-
Jsem si jistý že ne všichni budou souhlasit, ale má zkušenost s provozem *nixových serverů to do dnes po spoustu let potvrzuje.
Tyto jednoduché úpravy mají v mém případě 100% úspěšnost ve vyhýbání se útokům (na ssh) na všech serverech co provozuji/jsem provozoval (když to vezmu kolem a kolem, tak přesunutí ssh na nestandardní port je to, co eliminovalo veškeré útoky).
Presne tak, presun na nestd port + f2b --> zcela cisty log, samozrejme asi zalezi na tom jak je danej server exponovanej, ale treba ne; proste tot jen ma zkusenost za par let provozu.
-
Ak mal utocnik keylogger a vy ste sa prihlasili na roota, tak ma po domnelom odhlaseni skoro urcite aj roota, s ktorym si moze nakopirovat backdoornuty SSH demon [...] Ked si tam raz da backdoor [...]
To už ovšem není otázka toho, o čem se bavíme (bezpečná autentizace, eliminace botů). Tento problém se nijak netýká ssh klíčů a standardně se řeší nějakým IDSkem*. V případě větší míry paranoi nějakým MAC nebo jiným omezením roota (třeba kern.securelevel na FreeBSD).
* protože zdrojem takového útoku může být libovolný bug v sw s rootovským oprávněním
Zmena klucov je to najmensie a najjednoduchsie, co robim pri kazdom podozreni, ze niekto mohol moje kluce ziskat.
No vidite - a ja si tohle poteseni rad odepru :)
Myslim, že jsme téma celkem vyčerpali - vám vyhovuje váš způsob a považujete ho za adekvátně bezpečný pro vaši situaci. Mně vyhovuje jiný způsob a považuji ho za stejně bezpečný a podstatně pohodlnější.
Tím bych to uzavřel a za mě HOWGH :)
-
S tym presunutym sluzby na nestandardny port .. treba si uvedomit, ze i ked to cosi pomoze, tak to nie je riesenie. Ak by sa jednalo o komercny server, tak co potom ? A utoky na web nie su? port 80/443 je (okrem inych) velmi casto pouzivany u script kiddies. Uz chcem vidiet ako budete robit reklamu: nase sluzby su na www.mojafirma.sk:6990 .. parada ..
pri SSH je to sice trosku ine, ale v principe sa jedna o to iste .. branit sa neda utekom ..
-
pri SSH je to sice trosku ine, ale v principe sa jedna o to iste ..
Tak samozrejme pokud ma byt ssh dostupne i nekomu jinemu nez spravcum, musi byt na standardnim portu, o tom prece vubec neni rec.
-
Tak samozrejme pokud ma byt ssh dostupne i nekomu jinemu nez spravcum, musi byt na standardnim portu, o tom prece vubec neni rec.
Naprostej souhlas. Je to jedna z alternativ a nekomu to vyhovuje nekomu ne, v nekterych situacich je to pouzitelne vice, v nekterych mene. Stejne jako ten port knocking, kterej na urcitych pripojenich (zejmena mobilnich) za urcitych podminek nemusi fungovat a ty se nemusis taky dotukat zrovna ve chvili, kdy to nejvic potrebujes.
-
SSH na jiný port nemusíš dávat je to zbytečné, nastav si přihlašování přes klíče a pokud můžeš tak jen přes VPN /není podmínkou/ .
Neni to zbytecne. Jakmile bot najde otevreny ssh port, zacne ho bombardovat pokusy - to vede minimalne k zbytecnemu zahlceni pripojeni. Zakazovani podle IP v dnesni ere botnetu nema moc smysl - tabulka zakazanych IP bobtna a utoky pokracuji.
Pristup k ssh pres vpn je uz uplny nesmysl. Napr. OpenVPN ma stejne silnou autentizaci jako ssh, takze to zadny vyznamny narust bezpecnosti neprinasi, jenom to komplikuje pristup.
Z dokumentace k OpenVPN:
The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:
* DoS attacks or port flooding on the OpenVPN UDP port.
* Port scanning to determine which server UDP ports are in a listening state.
* Buffer overflow vulnerabilities in the SSL/TLS implementation.
* SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).
-
Z dokumentace k OpenVPN:
Ok. Proč si to teda komplikovat a nedat za VPN telnet? :)