Linux за българи: Форуми

Здравейте,
напоследък ми се случваха няколко apache насочени атаки, и от тогава започнах почти всеки ден да си чета системния лог, което разкри пред мен много интересни неща. Последните няколко дни в лог-а има хиляди редове със следното нещо ...

Aug 27 02:32:50 deb sshd[28987]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=173.0.58.162  user=root
Aug 27 02:32:52 deb sshd[28987]: Failed password for root from 173.0.58.162 port 38593 ssh2
Aug 27 02:32:54 deb sshd[28995]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=173.0.58.162  user=root
Aug 27 02:32:56 deb sshd[28995]: Failed password for root from 173.0.58.162 port 39680 ssh2


това е почти непрекъснато, особенно от снощи насам, не е само от това ip 173...., и от доста други.
Във firewall-а съм си сетнал следния ред ..

/sbin/iptables -A INPUT -i eth0 -p tcp --dport 22 -j DROP


но понеже не съм голям linux корифей, потърсих някакво решение на ssh проблема ми, и открих това .. http://www.pc-freak.net/blog/maximal-protection-of-ssh-attacks-if-your-server-has-to-stay-with-open-port-ssh-secure-shell-to-the-whole-world/ ($2)

изпълних следните неща :

/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state -state NEW -m recent -set
/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state -state NEW -m recent -update -seconds 60 -hitcount 5 -j DROP

и ми изписа това : Bad argument `NEW'

не разбирам iptables, и за това ми е въпроса ...какво да правя, предполагам че все някой ден може и да успеят да ме хакнат, след толкова много пробване. Как да защитя sshd-то ?

П.С eth0 = external connection

Напълно нормално е ако ssh ти е на порт 22 (default).
Сложи си denyhosts (позлва /etc/hosts.*) или fail2ban (ползва iptables)
Аз ползвам първото, /etc/hosts.deny скоро ще достигне 400 записа при мен ;)

+1 за denyhosts

и забрани root да влиза под ssh. След като влезеш винаги можеш да направиш su или sudo.

Така се прибавя и един елемент на "изненада" - освен паролата трябва да познаеш и име с което да влезеш което прави задачата почти неизпълнима.

Алтернатива е да прибавиш сертификати на ssh, но на мен не ми харесва много защото често се налага да влизам от различни машини и да си мъкна и сертификата не ми харесва.

Аз съм с id_rsa. Малко е неудобно наистина ако влизаш от "нови" машини, но моите са няколко на които съм добавил вече публичния ключ.
Ако не ти е проблем може да се спреш на този вариант.

С ключовете има един кофти проблем като администрираш повече машини. Завързват се едни системи на доверие и се стига дотам, че ако хакнат едната, могат да се сдобият с достъп до още няколко. Знам че решението е да се слагат passphrases, обаче тогава става толкова неудобно, колкото и без ключове с добавен бонус като смениш ключа някъде да ходиш да пействаш на 10 места. Грозно.

Добре де, ама аз ли съм прост. В /etc/ssh/sshd_config, едно такова редче:

AllowUser username@1.1.1.1

И може да влиза само определен потребител от точно определена машина. По-добро от това здраве му кажи. А ако се окаже, че дори това може да се прецака, направо ще се откажа от ssh. То не стига, че няма свястен jail...

hosts.deny и силна парола според мен е напълно достатъчно .

Аз първо си смених порта на SSHd и оттогава fail2ban почти не се включва... [_]3 [_]3 [_]3

Сложих denyhosts настройх в denyhost.conf следното :

SECURE_LOG = /var/log/auth.log
HOSTS_DENY = /etc/hosts.evil
PURGE_DENY = 2w
BLOCK_SERVICE  = sshd
DENY_THRESHOLD_INVALID = 5
DENY_THRESHOLD_VALID = 10
DENY_THRESHOLD_ROOT = 1
DENY_THRESHOLD_RESTRICTED = 1
WORK_DIR = /var/lib/denyhosts
SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS=YES
HOSTNAME_LOOKUP=YES
LOCK_FILE = /var/run/denyhosts.pid

-----------------------------------------------------------------------------------------
стартирам :  /etc/init.d/denyhosts.dpkg-new start
                   Starting DenyHosts: denyhosts.
-----------------------------------------------------------------------------------------

след това правя следното :
                  cat /var/log/denyhost
----
2011-08-29 13:35:57,840 - denyhosts   : INFO     restricted: set([])
2011-08-29 13:35:57,841 - denyhosts   : INFO     Processing log file (/var/log/auth.log) from offset (1271495)
2011-08-29 13:35:57,845 - denyhosts   : INFO     launching DenyHosts daemon (version 2.6)...
2011-08-29 13:35:57,853 - denyhosts   : INFO     DenyHosts daemon is now running, pid: 21640
2011-08-29 13:35:57,853 - denyhosts   : INFO     send daemon process a TERM signal to terminate cleanly
2011-08-29 13:35:57,853 - denyhosts   : INFO       eg.  kill -TERM 21640
2011-08-29 13:35:57,856 - denyhosts   : INFO     monitoring log: /var/log/auth.log
2011-08-29 13:35:57,857 - denyhosts   : INFO     sync_time: 3600
2011-08-29 13:35:57,857 - denyhosts   : INFO     purging of /etc/hosts.evil is disabled
2011-08-29 13:35:57,857 - denyhosts   : INFO     denyhosts synchronization disabled

-----------
cat /etc/hosts.evil

# DenyHosts: Mon Aug 29 12:27:12 2011 | sshd: 78.128.54.166
sshd: 78.128.54.166
# DenyHosts: Mon Aug 29 12:27:12 2011 | sshd: 31.193.132.8
sshd: 31.193.132.8
# DenyHosts: Mon Aug 29 12:27:12 2011 | sshd: 192.168.0.2
sshd: 192.168.0.2
# DenyHosts: Mon Aug 29 12:27:12 2011 | sshd: 213.128.83.34
sshd: 213.128.83.34
# DenyHosts: Mon Aug 29 12:27:12 2011 | sshd: 211.202.3.84
sshd: 211.202.3.84
# DenyHosts: Mon Aug 29 12:27:12 2011 | sshd: 173.0.58.162
sshd: 173.0.58.162
# DenyHosts: Mon Aug 29 12:27:12 2011 | sshd: 87.120.171.135
sshd: 87.120.171.135
# DenyHosts: Mon Aug 29 12:27:12 2011 | sshd: 175.103.44.59
sshd: 175.103.44.59
# DenyHosts: Mon Aug 29 12:27:12 2011 | sshd: 218.15.221.84
sshd: 218.15.221.84
# DenyHosts: Mon Aug 29 12:27:12 2011 | sshd: 173.254.212.133
sshd: 173.254.212.133
# DenyHosts: Mon Aug 29 13:12:15 2011 | sshd: 192.168.1.83
sshd: 192.168.1.83
------------------------------------------------------------------------------------------

сега пробвах от друго PC, направих десетки грешки на root password-а и нито го блокира, само го добави в /etc/hosts.evil - последния запис. 192.168.1.83, спокойно мога да продължа да пробвам паролата на root.

....

П.С : промених hosts.evil с hosts.deny и заработи, но когато написах

ps -aux |grep denyhosts

Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
root      1842  0.0  0.0   3300   744 pts/1    S+   14:32   0:00 grep denyhosts

Аз го стартирам още с boot-а на машината, настроил съм го с tool-а rcconf да е boot on startup, та въпроса ми е следния необходимо ли е добавяне в crontab за chek през определено време.

Съжалявам, че флудя форума. Само да кажа, че се справих с проблема. Благодаря за коментарите. Всичко работи както трябва.

С ключовете има един кофти проблем като администрираш повече машини. Завързват се едни системи на доверие и се стига дотам, че ако хакнат едната, могат да се сдобият с достъп до още няколко. Знам че решението е да се слагат passphrases, обаче тогава става толкова неудобно, колкото и без ключове с добавен бонус като смениш ключа някъде да ходиш да пействаш на 10 места. Грозно.

gat3way (и всички) - слагаме пас фраза на ключа. Преди  работа добавяме ключа в ssh-agent с ssh-add. По време на работа ползваме ssh-key forwarding с ssh -A myserver1, ssh -A myserver2, ssh -A myserver3 и т.н. След работа изтриваме ключа от ssh-agent с ssh-add -D. Може дори да зададем време на живот на ключа в агента с ssh-add -t XX. Копираме само публичния ключ навсякъде, частния си остава на лаптопа. За мобилните - носим си го на флашка. За параноиците - на криптирана. А относно смени на ключа - аз имам два, единият е 10, другият 5 годишен, досега не съм сменил никой от двата, нито пък съм ги губил. Пък и да е копиране ще е ssh-copy-id (вярно, малко неприятно като се срещнат много уних-и от времето на Балканските войни без ssh-copy-id ). Като замижа на тема сигурност си правя някой временен за rsync между две машини, да не оставям частния си ключ насам-натам и да няма нужда от пас фраза. За мен този алгоритъм е задоволителен, но ако има какво да допълните ще прочета с удоволствие.

@ghoof - идеално решение за статичен IP, но ако е динамичен става малко фал.

За супер-пупер сигурност има и port knocking - но за мен на сегашната ми работа е просто излишно.

инсталирай си fail2ban и го настрой да блокира на 3 опита за по час:
bantime  = 3600
maxretry = 3
findtime = 3600
с тези настройки бързо минава мерака да ръчкат, и няма да ти товарят трафика
освен това в /etc/rc.local вмъкваш това:

GeSHi (Bash):
/sbin/modprobe iptable_filter
/sbin/iptables -N SSH_WHITELIST
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

и после гледаш логовете, ако някой IP адрес е много упорит може да го блокираш за вечни времена през iptables

В тези iptables команди има нещо гнило. Никой пакет няма да попадне в последните две правила, понеже -j SSH_WHITELIST вече е пратило пакета в друга верига.

http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=393512859

може и без ipset в нея

В тези iptables команди има нещо гнило. Никой пакет няма да попадне в последните две правила, понеже -j SSH_WHITELIST вече е пратило пакета в друга верига.

пробвай да видиш дали няма  ;D

В тези iptables команди има нещо гнило. Никой пакет няма да попадне в последните две правила, понеже -j SSH_WHITELIST вече е пратило пакета в друга верига.

Ако няма изпълнение на -j ACCEPT/DROP/REJECT в тази верига пакетът се праща към следващия ред на поредицата от правила, точно след "скока" към веригата

с denyhosts мисля, че се справих ...може да пробвате на penchev.dyndns.org, тъкмо и аз ще проверя след това, дали работи ефективно.

Добрата практика е забраняваш root-а да се логва обясниха колегите защо, сменяш порта на някои голям че да не те заниамват глупави скенери с много логове, хубава паролка нещо перверзно поне 10-12 символа. Ако ще влизаш само от един хост направо бичиш през iptables drop на всички заявки със сорс различен от твоя, ако ли не здраве да е. Случая с denyhosts е малко свински защото понякога решава, че и твоя хост му е мястото в блеклистата, или поне имаше такива бъгове преди 2-3 години и така нежно режеше достъпа, та се налагаше да се оказва мрежи и хостове, абе голяма кочина беше.

Със сменен порт, парола от 50 символа, букви (големи и малки) + цифри + Permit root login no, живота е песен  :D

Със сменен порт, парола от 50 символа, букви (големи и малки) + цифри + Permit root login no, живота е песен  :D

това не е сериозно с 50 буквено-цифрена парола :).

Не зная дали смяташ че е сериозно, паролите ми обикновенно са такива, за щастие и ги помня  :)

Не зная дали смяташ че е сериозно, паролите ми обикновенно са такива, за щастие и ги помня  :)

То помненето лесно, но писането трудно ... особено когато не виждаш символите.

Споко, справям се  :) това да е проблем.

То помненето лесно, но писането трудно ... особено когато не виждаш символите.

Аз като малко по мързелив си имам тулче дето ssh-ва към различните машини и тоя проблем ми е решен :D

Случая с denyhosts е малко свински защото понякога решава, че и твоя хост му е мястото в блеклистата, или поне имаше такива бъгове преди 2-3 години и така нежно режеше достъпа, та се налагаше да се оказва мрежи и хостове, абе голяма кочина беше.

този проблем се решаваше елементарно с добавяне на адреса ти в host.allow, който, доколкото си спомням, има приоритет пред host.deny.

този проблем се решаваше елементарно с добавяне на адреса ти в host.allow, който, доколкото си спомням, има приоритет пред host.deny.

Точно така се решава ама в един момент като ти се наложи да влизаш през някъде от тамбукту и ти резне достъпа гадина и най близкия нет е на 50 километра и не си имал време да се впишеш в hosts.allow леко неприятно се получава ;)