IDS своими руками

Меня-таки достали постоянные брутфосы на ssh, проводимые с зомбоящиков. Раньше я замечал эти атаки благодаря logcheck, который присылал мне на почту все аномалии, и затем блокировал адреса руками в файрволе. И меня даже раздражало не то, что приходится что-то делать самому (в конце концов, говорить “iptables -A INPUT -s чего-нибудь -j DROP” даже приятно :) ), сколько то, что заблокировать можно было бы прямо вначале атаки, а я это делал или уже после, или где-то в середине.

Upd: найдено более универсальное средство, см. ниже.
Я посмотрел некоторые IDS. Они, конечно, большие и красивые, но больно не хотелось из-за такой простой задачи - выполнение некоторого действия при появлении некоторой записи в логах - ставить этих монстров, которые мало того что сами немаленькие, так еще и требуют, чтобы некоторые компоненты системы (например файрвол) были настроены так как им надо.

В итоге был выбран следующий путь:

apt-get install syslog-ng/testing

в /etc/syslog-ng/syslog-ng.conf

destination dpr_ids { program("/usr/local/sbin/ids.sh" ); };

filter f_ssh_auth_error {
facility(auth)
and level(info)
and match("sshd")
and match("Illegal user");
};

log {
source(s_all);
filter(f_ssh_auth_error);
destination(dpr_ids);
};

И простой скриптик /usr/local/sbin/ids.sh

#!/bin/sh
#Jul  7 15:43:44 eol sshd[21538]: Illegal user admin from ::ffff:158.250.17.23

grep –line-buffered -E “^w{3} [ :0-9]{11} [._[:alnum:]-]+ sshd[[0-9]+]: Illegal user [^[:space:]]+ from [:a-f.[:digit:]]+”|
sed -u -r ’s/^w{3} [ :0-9]{11} [._[:alnum:]-]+ sshd[[0-9]+]: Illegal user (.+) from ::ffff:([.[:digit:]]+)$/2 1/’|
while read HOST USER;do
case “$USER” in
“admin”|”webadmin”|”aaa”) #То что часто встречается в атаках в числе первых, но отсутствует в реальной жизни
iptables -A INPUT -s “$HOST” -j DROP
logger -t”ids.sh” — “Blocking host $HOST cause of ssh bruteforce.”;;
esac
done

Upd: Черт возьми, все украдено до нас:

~# apt-cache show fail2ban
Package: fail2ban
Priority: optional
Section: net
Installed-Size: 268
Maintainer: Yaroslav Halchenko
Architecture: all
Version: 0.6.1-8
Depends: python (>= 2.3), iptables, lsb-base (>= 2.0-7)
Filename: pool/main/f/fail2ban/fail2ban_0.6.1-8_all.deb
Size: 50234
MD5sum: d5dc280fcc6e5bf72919029c14c94d32
SHA1: ee1e0f64a81ee8ba7344b80e4be4d349c8a2c0b9
SHA256: 6d9767e762df1573a1aa381a7e25b10fdf7470f95614a4efbf4fafb59756db5a
Description: bans IPs that cause multiple authentication errors Monitors (in daemon mode) or just scans log files (e.g. /var/log/auth.log, /var/log/apache/access.log) and temporarily bans failure-prone addresses by updating existing firewall rules. Currently, by default, supports ssh/apache but configuration can be easily extended for scanning the other ASCII log files. Firewall rules are given in the config file, thus it can be adopted to be used with a variety of firewalls (e.g. iptables, ipfwadm).
.
Homepage: http://www.sourceforge.net/projects/fail2ban

RSS feed | Trackback URI

15 Comments »

+ Comment by sinus
2006-07-08 23:30:26

перенеси ссх на другой порт

+ Comment by GQ
2006-07-09 10:26:44

А нафик?
Во-первых, “это доставит мне неудобство” (с) N.O.E.D
А во-вторых, это не решает проблемы.

+ Comment by sinus
2006-07-11 19:57:43

это неудобств не доставит поверь мне :) просто попробуй и ты удивишься, когда не обнаружишь в логах записей :)
можно еще разрешать доступ к этому порту только для определенных ип

+ Comment by GQ
2006-07-12 07:11:32

ну давайте, учите меня, что удобно, что нет. =\ Ты будешь постоянно отвечать пользователям, которые будут регулярно забывать порт?

+ Comment by sinus
2006-07-12 18:46:54

я никого не учил, а давал совет ;)
не надо плохо думать о пользователях, раз забудут, ну два забудут, потом навсегда запомнят :)

(Comments wont nest below this level)
 
 
 
 
 
+ Comment by RCP
2006-07-08 23:35:22

норм
ништяк

 
+ Comment by RCP
2006-07-08 23:36:47

если не юзаешь ssh из инета ваще лучше заблокровать доступ извне, а если юзаешь то реал на другой порт перекинуть

+ Comment by GQ
2006-07-09 10:27:20

Зачем нужен ssh, если его не использовать? =\

+ Comment by RCP
2006-07-13 23:20:34

а может ты извращенец и тестируешь брутфорсер к ssh на локальной тачке?

 
 
 
+ Comment by KA6AH
2006-07-13 00:01:44

Зачот, в хозяйстве пригодится. Ботнеты действительно уже задрали. А нестандартный порт - признак трусости :)

+ Comment by RCP
2006-07-13 23:25:15

блин а как так опперативно поправили дырку с NFS в freebsd на совете, блин аж завидно.

 
 
+ Comment by Zladey
2006-07-13 08:35:45

Враги не пройдут

 
+ Comment by RCP
2006-07-24 23:05:51

попрошу статьи такого рода (по возможности) размещать на http://ultim.techlab.info/linux/

+ Comment by GQ
2006-07-25 02:07:05

The connection has timed out

The server at ultim.techlab.info is taking too long to respond.

* The site could be temporarily unavailable or too busy. Try again in a few
moments.

* If you are unable to load any pages, check your computer’s network
connection.

* If your computer or network is protected by a firewall or proxy, make sure
that Firefox is permitted to access the Web.

 
 
+ Comment by www2
2008-12-24 14:03:02

У меня в голове есть политика деления сервисов: они могут быть публичные, локальные, административные.

Публичные ДОЛЖНЫ быть доступны отовсюду, поэтому фильтровать их фаерволлом бессмысленно. Именно для них и предназначены различные автобан-скрипты по различным критериям. Типичные представители - smtp-сервер, web-сервер.

Локальные - должны быть доступны только для определённых подсетей. Их фильтрую фаерволлом, разрешая доступ только с тех подсетей, которым этот доступ необходим. Типичные представители - samba, squid, pop3- и imap-серверы (если нет мобильных клиентов).

Административные - должны быть доступны только с тех адресов и подсетей, где могу оказаться я или другие админы этого ресурса. Их тоже фильтрую фаерволлом, а различные системы мониторинга и статистики вроде nagios или awstats дополнительно защищаю паролем и ssl. Как правило список разрешённых IP настолько мал, что необходимости в автобан-скриптах просто нет.

Обязательно на каждой из администрируемых единиц настроить логирование, на логи натравливать logwatch и отправлять отчёты по почте в свой служебный почтовый ящик. Хотя бы каждое буднее утро посвящать время изучению отчётов.

Про стойкость паролей и обновление сервисов даже и говорить не нужно. Пароли должны быть сильными, сервисы должны регулярно патчиться (чему очень способствует использование на серверах стабильной ветки Debian).

 

Identify yourself with

or fill the following fields:

You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> in your comment.

Trackback responses to this post