Как да се преборим от brute force, spam, нагли ботове и т.н.

D

domainer

Member
Наскоро попаднах на едно доста добро решение fail2ban. Слагам им линк, защото мисля че си го заслужават.

Накратко (личен превод):
Fail2ban сканира лог файловете (/var/log/httpd/error_log, access_log, mail_log) и банва IP-тата които имат подозрителни признаци -- много отхвърлени логин операции, търсене на експлоити, и т.н. Fail2Ban променя firewall правилата и отхвърля IP адресите за определено време (предефинирано), може и за неопределено. Операции като пращане на мейли, отваряне на CD-ROM също могат да се конфигурират. Fail2Ban има включени разнообразни предефинирани настройки (повечето от тях са изключени по дефолт) - apache, curier, ssh, postfix, ftp, и т.н.

Изисква се root достъп за да се инсталира пакета. Могат да се конфигурират допълнителни jails (правила), които не са трудни за запознатите с unix системите. Пишат се филтри (regex правила за сканиране на различен тип лог файлове), след това се указват jails за всеки един филтър.
Примерно при 3 грешни опита за логване през SSH - БАН на IP-то за определено време (може и перманентен бан) :twisted:

Хубавото е, че има писан плъгин за WP, който при маркирване на коментар като спам, логва в указан файл IP-то на писателя. Този файл може да се въведе в fail2ban за сканиране и да се баннат лошите спамери.
Линк към плъгина - http://blog.shadypixel.com/spam-log-plugin/

Какво е предимството на fail2ban пред akismet, и другите подобни пакети - fail2ban модифицира iptables и спира вредителите на unix ниво. Сървъра не харчи излишни ресурси за apache/php за спамерите. Много полезно за малки VPS решения.

Понеже имам 40+ сайта на моя VPS, във различни папки /var/www/html/site1, /var/www/html/site2 и т.н.
съм конфигурирал плъгина от всички сайтове да логва в един и същи файл - /var/www/html/spam.log

Понеже инструкциите от линка не ми помогнаха -
в jail.conf се добавя:
Код: 
# This is for WordPress spammers

[wordpress-spam]

enabled  = true
port     = http
filter   = wp-spam
action   = iptables[name=WP-SPAM, port=http]
           sendmail-whois[name=WP-SPAM, [email protected]]
logpath  = /var/www/html/spam.log
maxretry = 1
findtime = 2419200
bantime  = 2419200

Във filter.d съм добавил файл wp-spam.conf
Код: 
[Definition]

failregex = ^\s*comment id=\d+ from host=<HOST> marked as spam$
ignoreregex =

В инструкциите от линка е пропуснато да се сложи "action"!

fail2ban има вградени jails - ssh, proftpd, sasl, apache-tcpwrapper, postfix-tcpwrapper, vsftpd-notification, vsftpd-iptables, apache-badbots, apache-shorewall, php-url-fopen, lighttpd-fastcgi, ssh-ipfw, named-refused-udp, named-refused-tcp

Преди да го сложа, не знаех че имам brute force SSH login заявки. Вече доста IP-та се споминаха.

Аз лично съм настроил почти всичко на месечен бан (bantime), времето за търсене на филтри - месец (findtime), максимални опити - 1 и т.н. Сложил съм 2 IP-та за игнориране на правилата (от които влизам) за всеки случай.

Съвсем случайно намерих този пакет. Надявам се да е полезно на някой.
 
От: Как да се преборим от brute force, spam, нагли ботове и т.н.

Доста е полезно! Аз използвам fail2ban да пазя само ssh-тата, че там проблема е по-критичен.
 
От: От: Как да се преборим от brute force, spam, нагли ботове и т.н.

Внимавайте да не ви банне IP адресите на CloudFlare. След като логовете на Apache не съдържат истинските IP адреси, а само IP адресите на CloudFlare (ако ползвате техните услуги) не ми е ясно как ще работи нормално

mobilio каза:
Доста е полезно! Аз използвам fail2ban да пазя само ssh-тата, че там проблема е по-критичен.
Увеличете...

Добре е да си смениш порта на SSH на някой случаен порт (примерно 2474).

/etc/ssh/sshd_config
Код: 
Port 2474

После за да се логнеш:

ssh root@твоя-сървър.нет -p 2474

sftp -P 2474 root@твоя-сървър.нет

Гледай съответния порт да е някой забутан, който не се ползва за нищо популярно.

Добре е също така да се разкара FTP сървъра - вместо ftp може да се ползва sftp.
 
От: Как да се преборим от brute force, spam, нагли ботове и т.н.

Това със смяната на порта не ми харесва, защото използвам sftp.

Но гледам друго - тук пишеш да се логвам с root@! А аз точно него съм го забранил да се логва. Логвам се с потребител и после sudo или su. Така те нито знаят потребителя, нито паролата.

Отделно - експериментирам със ключове. Това нещо е МЕГА добро защото повече никога не помниш потребители, пароли и т.н. Само неудобството е, че не може да се логнеш на случайна машина (ако нямаш ключа под ръка)...
 
От: От: Как да се преборим от brute force, spam, нагли ботове и т.н.

mobilio каза:
Това със смяната на порта не ми харесва, защото използвам sftp.
Увеличете...

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

Щом ползваш sftp няма никакъв проблем да се логваш след като смениш порта. Ако се логваш от команден ред:

Вместо:

sftp user@твоя-сървър.нет

Пишеш:

sftp -P 2474 user@твоя-сървър.нет

Ако ползваш някаква програма с графичен интерфейс - трябва да намериш къде се пише порта и да го смениш от 22 на 2474 (или както си го номерирал).

Ако програмата ти не поддържа промяна на порта - може да я смениш.
 
От: Как да се преборим от brute force, spam, нагли ботове и т.н.

А аз имах в предвид, че смяната на порта е решение колкото щрауса дето си зарива главата при опасност. Затова и не го и правя.
 
От: Как да се преборим от brute force, spam, нагли ботове и т.н.

Разликата е, че при смяна на порта количеството на атаките намалява - четеш по-малко съобщения в логовете (ако изобщо някой ще се занимава да проверява всички портове един по един - обикновено когато е сменен адреса на порта се ползват и дълги пароли или ключове и това отказва кракерите да се занимават със сървъри, където порта на SSH е променен).
 
От: От: Как да се преборим от brute force, spam, нагли ботове и т.н.

mobilio каза:
А аз имах в предвид, че смяната на порта е решение колкото щрауса дето си зарива главата при опасност. Затова и не го и правя.
Увеличете...

Може ли да се обосновеш защо? Аз мисля, че смянта на порта е задължителна, защото сигурно 90-95% от атаките се правят от ботове, които сканират за "default" портове. Ок, спада към Security via Obscurity (не ми идва на български :lol:), обаче ще си спестиш доста главоболия и трафик така. Няма софтуер, който да не поддържа избиране на порт (поне аз не съм срещал). Ключовете и забраната на руут също са задължителни.

@mobilio долния пост - четеш избирателно...
 
Последно редактирано:
От: Как да се преборим от brute force, spam, нагли ботове и т.н.

http://serverfault.com/questions/189282/why-change-default-ssh-port

Whatever port you chose, if you do move away from 22, make sure it is below 1024. Under most Unix-a-like setups in their default config, only root (or users in the root group) can listen on ports below 1024, but any user can listen on the higher ports. Running SSH on a higher port increases the chance of a rogue (or hacked) user managing to crash your SSH daemon and replace it with their own or a proxy.
Увеличете...

Сега вижте пак щрауса и ще ви светне ламбичката...
 
От: Как да се преборим от brute force, spam, нагли ботове и т.н.

Това с 1024-тия порт е интересно, не го знаех.

Ако случайно някой кракер успее да убие SSH сървъра и започне да слуша на същия порт, при опит да се логна SSH клиента ще изпищи, че има проблем. Нали затова са данните във файла ~/.ssh/known_hosts?

Ако частните ключове на сървъра (/etc/ssh/ssh_host_*_key) са прочетени - това значи, че кракерът е имал достъп като root и стартирането му на фалшив SSH сървър е безсмислено.
 
От: Как да се преборим от brute force, spam, нагли ботове и т.н.

Аз последният път като правих опити за смяна на порта - си убих всякакъв достъп до впс-а - SSH/FTP. Хубаво че провайдъра има rescue режим през SSH с временна парола.
Не го знаех това за ограничението до 1024-ти порт. Може би съм сложил нещо над това. Не съм сигурен, но може би другата седмица ще тествам с по нисък порт.
Това с алтернативен акаунт и su, не ми е удобно заради фтп клиента. Тествах преди малко. Нямам права за нищо. Другия проблем е, че със su файловата система се mount-ва в read only режим и е нужно re-mount-ване.

Нищо, поне научих нещо полезно :)
 
От: Как да се преборим от brute force, spam, нагли ботове и т.н.

Аз до сега карам с порт на две хиляди и някой си порт и нямам проблеми. Настроил съм защитната стена да блокира всички портове с изключение на тези, които се ползват (разрешени са само SSH на нестандартен порт, http, https, webmin/usermin, icmp).

Преди да сменя порта предвидливо разреших новия порт за да не остана без достъп.

Не виждам какъв е проблема да имаш достъп като root чрез SSH/SFTP. Ако имаш достатъчно дълга и сложна парола на root.
 
От: Как да се преборим от brute force, spam, нагли ботове и т.н.

happyslacker каза:
Не виждам какъв е проблема да имаш достъп като root чрез SSH/SFTP. Ако имаш достатъчно дълга и сложна парола на root.
Увеличете...

По-скоро с ключ, като и ключа да има парола. Като внимаваш на кого даваш ключа :lol:

@mlazarov има ситуации, в който и това се налага.

mobilio имам чувството, че избирателно чете/пише, дори с последния си пост :cry:
 
Последно редактирано:
WTF? Ключ никога на никого не се дава - той е персонален и се ползва от един човек. Не би трябвало да има ситуация, при която да напуска едно устройство.
 
От: Re: Как да се преборим от brute force, spam, нагли ботове и т.н.

Не виждам какъв е проблема да се ползва парола (вместо ключ, който да се защитава с парола). Ако паролата е примерно "02l3iTGqv30WIiVqnLjK" (със или без кавичките).

Разбира се паролите не се помнят - помни се само паролата, която отключва паролите.
 
От: Re: Как да се преборим от brute force, spam, нагли ботове и т.н.

happyslacker каза:
Не виждам какъв е проблема да се ползва парола (вместо ключ, който да се защитава с парола). Ако паролата е примерно "02l3iTGqv30WIiVqnLjK" (със или без кавичките).

Разбира се паролите не се помнят - помни се само паролата, която отключва паролите.
Увеличете...

Аз ги помня :) имам една подобна от над 15г. вече.
 
От: Как да се преборим от brute force, spam, нагли ботове и т.н.

Странно е как вместо да си улеснявате живота си го усложнявате.

Аз НИКОГА не влизам като root през ssh, Даже като се замислям май и на машините където ръчкам също го правя това. Влизам като потребител и после си вдигам правата (su или sudo -i) ако ми се наложи. За web - 1) се прави ОТДЕЛЕН потребител като му се разрешава да пише във /var/www (или група от потребители) или 2) /var/www/ се насочва към неговата папка с ln или 3) НАЙ-сетне се научавате какво прави webdav и защо трябва да се използва (върху https естественно!).

Това, че SSH е видим не означава че може да се използва. За да го използваш трябва валидна комбинация - user/pass. Повечето брутфорсъри пробват root по дефиниция и само като им шибнеш един ред "PermitRootLogin no" и бедните увяхват много бързо. После с един fail2ban зачистваш глупостите ЕВЕНТУАЛНО. Варианта за key е супер - но малко стопира историята. Примерно няма да можеш да се логнеш от телефон и/или таблет.

ВЪВ всички случаи обаче схемите които описах са малко по... абе не са за новаци. Трябват малко знания и акъл.

BTW - разбиван съм от дупка на phpMyAdmin и оттогава разбрах защо CentOS примерно го няма като пакет стандартно.

PS - пропуснах една гъзария която в момента пробвам! Правите на сървъра някакъв VPN (промерно OpenVPN). И вързвам ssh да слухти от OpenVPN (забранявам външните му мрежи, остават вътрешните и OpenVPN). Така мога да се логвам отвън само след VPN, и отвътре без проблем. Но това го правя само защото има ФИЗИЧЕСКИ достъп до машината.

PS2 - ето и съветите от CentOS http://wiki.centos.org/HowTos/Network/SecuringSSH общо взето правя почти всичко без точка 5 (което е смяната на порта...)
 
Последно редактирано:
Трябва да си влезнал или регистриран, за да отговориш тук.

Горе