LINUX.ORG.RU

2
Всего сообщений: 38

Snort: базовые правила

Всем добрый вечер!

1. Установил Snort+Barnyard2+PolledPork+Base. Правила PulledPork бесплатные качает, с коробки матюкается на всё жутко. Проблема в том, что я не могу найти эти базовые правила и отредактировать их, т.к. Base не показывает его sid, по msg тоже найти не получается.

В конфиге PulledPork:

#If you are running any rules in your local.rules file, we need to
# know about them to properly build a sid-msg.map that will contain your
# local.rules metadata (msg) information.  You can specify other rules
# files that are local to your system here by adding a comma and more paths...
# remember that the FULL path must be specified for EACH value.
# local_rules=/path/to/these.rules,/path/to/those.rules
local_rules=/etc/snort/rules/local.rules

Получается что что правила пуледпорк пишет в

/etc/snort/rules/local.rules.

Но к сожалению, в этом файле я не могу могу найти Алерт по msg, а sid Base и вовсе не показывает (есть ID, но он левый какой-то, для одинаковых Алертов разный).

2. И второй момент, когда пуледпорк обновляет правила, он скорее всего заменяет файл с правмилами? (хоть это и не логично), тогда смысла в их редактировании и нет, как собственно и в их самих, скорее всего я ошибаюсь.

 ,

cj3z ()

Snort

Как обновить Snort offline

Перемещено Pinkbyte из linux-org-ru

 

wilder123444444 ()

Snort для чайников

Есть много статей по использованию сетевой системы обнаружения (IDS) и предотвращения вторжений (IPS) под названием Snort.

Например, вот эта: Система обнаружения вторжений на базе IDS Snort

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

И хотя есть статья под интригующем названием Система обнаружения вторжения для Чайников. Установка и Конфигурирование SNORT
она по сложности мало чем отличается от предыдущей.

Есть ли у кого простенькое хавту, чтобы в два притопа поставить этот Snort и не заморачиваться с его многочисленными настройками?

Как, например, Fail2ban: установил по дефолту - и забыл про него, а он себе молча работает и не компостирует мозги.

 

chukcha ()

BASE

Установил связку snort - base - mysql, открываю в браузере веб интерфейс там пусто, в чем может быть причина? Вроде все по инструкции делал.

 , ,

Ratpython1 ()

SNORT

Есть уязвимость CVE-2003-0386 Как написать для нее правило для снорта? Я в курсе, что старая узявимость и прочее

 

logonsessons ()

snort: фильтрация ipv6

Короче, пробую сделать фильтрацию в ipv6.

root@filter0:/home/user# cat /etc/snort/rules/local.rules
reject tcp any any -> any any (msg:"HTTP test";sid:10000001;react; rev:001;)
root@filter0:/home/user#
При пропуске tcp трафика получаем:
Commencing packet processing (pid=982)
Decoding Raw IP6
11/05-22:17:22.489083  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:53140 -> 2a02:6b8::2:242:80
11/05-22:17:23.047332  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:80 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:53140
11/05-22:17:23.047632  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:53140 -> 2a02:6b8::2:242:80
11/05-22:17:23.048062  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:53140 -> 2a02:6b8::2:242:80
11/05-22:17:23.602873  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:80 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:53140
11/05-22:17:23.605475  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:80 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:53140
11/05-22:17:23.605595  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:53140 -> 2a02:6b8::2:242:80
11/05-22:17:23.617973  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:24.046448  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:24.046755  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:24.047220  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:24.550999  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:24.551093  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:24.551164  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:24.551225  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:24.551306  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:24.551514  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:24.551573  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:24.566602  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:24.566611  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:24.945299  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:24.947580  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:25.345172  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.481638  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.484309  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.484309  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.486201  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:25.486210  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:53140 -> 2a02:6b8::2:242:80
11/05-22:17:25.535520  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.537952  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.537952  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.537952  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.538065  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:25.538069  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:25.617089  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.623854  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.623854  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.623940  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:25.956013  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.956707  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.956707  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:25.956730  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:80 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:53140
11/05-22:17:25.957124  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:25.958759  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:53140 -> 2a02:6b8::2:242:80
11/05-22:17:25.958767  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:26.445400  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:26.445421  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a02:6b8::2:242:443 -> 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833
11/05-22:17:26.450655  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443
11/05-22:17:26.450662  [**] [1:10000001:1] HTTP test [**] [Priority: 0] {TCP} 2a01:d0:c353:7:fd0d:6096:9f6c:e5af:54833 -> 2a02:6b8::2:242:443

Но, фильтрация не работает. Трафик у меня зеркалируется так:
root@router:/home/ad# ip6tables -t mangle -L -v
Chain PREROUTING (policy ACCEPT 5439 packets, 1521K bytes)
 pkts bytes target     prot opt in     out     source               destination 
 2242  285K TEE        all      any    any     2a01:d0:c353:7:fd0d:6096:9f6c:e5af  anywhere             TEE gw:fd00:10:1::254
 2682 1200K TEE        all      any    any     anywhere             2a01:d0:c353:7:fd0d:6096:9f6c:e5af  TEE gw:fd00:10:1::254

Chain INPUT (policy ACCEPT 467 packets, 32072 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain FORWARD (policy ACCEPT 4867 packets, 1481K bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain OUTPUT (policy ACCEPT 5386 packets, 1517K bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain POSTROUTING (policy ACCEPT 10263 packets, 2999K bytes)
 pkts bytes target     prot opt in     out     source               destination 
root@router:/home/ad#
В чём может быть проблема?
С ipv4 всё работает нормально.
Тоже самое и при маршрутизации.

 , , , ,

ne-vlezay ()

Не компилируется snort

При компиляции ошибка:

/bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2 -DSF_VISIBILITY -fvisibility=hidden -fno-strict-aliasing -Wall  -lpcre -L/usr/lib -ldumbnet -o snort debug.o decode.o encode.o active.o log.o mstring.o hashstring.o parser.o profiler.o plugbase.o snort.o  strlcatu.o strlcpyu.o tag.o util.o detect.o signature.o mempool.o sf_sdlist.o fpcreate.o fpdetect.o pcrm.o byte_extract.o sfthreshold.o packet_time.o event_wrapper.o event_queue.o ppm.o log_text.o detection_filter.o detection_util.o rate_filter.o pkt_tracer.o obfuscation.o sfdaq.o reload.o idle_processing.o reg_test.o  output-plugins/libspo.a detection-plugins/libspd.a dynamic-plugins/libdynamic.a dynamic-output/plugins/liboutput.a preprocessors/libspp.a parser/libparser.a target-based/libtarget_based.a preprocessors/HttpInspect/libhttp_inspect.a preprocessors/Session/libsession.a preprocessors/Stream6/libstream6.a sfutil/libsfutil.a control/libsfcontrol.a file-process/libfileAPI.a file-process/libs/libfile.a  reload-adjust/libreload_adjust.a -lnghttp2 -lz -ldaq_static -ldumbnet -lpcre -lpcap -lnsl -lm -lm  -lcrypto -ldl -L/usr/local/lib -ldaq_static_modules  -lsfbpf -lpcap -lsfbpf -lpcap -lz -llzma -lpthread -lpthread -lpthread
libtool: link: gcc -g -O2 -DSF_VISIBILITY -fvisibility=hidden -fno-strict-aliasing -Wall -o snort debug.o decode.o encode.o active.o log.o mstring.o hashstring.o parser.o profiler.o plugbase.o snort.o strlcatu.o strlcpyu.o tag.o util.o detect.o signature.o mempool.o sf_sdlist.o fpcreate.o fpdetect.o pcrm.o byte_extract.o sfthreshold.o packet_time.o event_wrapper.o event_queue.o ppm.o log_text.o detection_filter.o detection_util.o rate_filter.o pkt_tracer.o obfuscation.o sfdaq.o reload.o idle_processing.o reg_test.o  -L/usr/lib output-plugins/libspo.a detection-plugins/libspd.a dynamic-plugins/libdynamic.a dynamic-output/plugins/liboutput.a preprocessors/libspp.a parser/libparser.a target-based/libtarget_based.a preprocessors/HttpInspect/libhttp_inspect.a preprocessors/Session/libsession.a preprocessors/Stream6/libstream6.a sfutil/libsfutil.a control/libsfcontrol.a file-process/libfileAPI.a file-process/libs/libfile.a reload-adjust/libreload_adjust.a -lnghttp2 /usr/local/lib/libdaq_static.a /usr/lib/libdumbnet.so -lpcre -lnsl -lm -lcrypto -ldl -L/usr/local/lib /usr/local/lib/libdaq_static_modules.a /usr/local/lib/libsfbpf.so -lpcap -lz -llzma -lpthread
preprocessors/HttpInspect/libhttp_inspect.a(h2_common.o): In function `on_frame_recv_callback':
/usr/src/snort-2.9.11/src/preprocessors/HttpInspect/utils/h2_common.c:791: undefined reference to `nghttp2_session_set_next_stream_id'
preprocessors/HttpInspect/libhttp_inspect.a(h2_common.o): In function `initialize_nghttp2_session_snort':
/usr/src/snort-2.9.11/src/preprocessors/HttpInspect/utils/h2_common.c:865: undefined reference to `nghttp2_option_set_no_http_messaging'
/usr/src/snort-2.9.11/src/preprocessors/HttpInspect/utils/h2_common.c:884: undefined reference to `nghttp2_session_upgrade2'
/usr/src/snort-2.9.11/src/preprocessors/HttpInspect/utils/h2_common.c:869: undefined reference to `nghttp2_option_set_no_http_messaging'
collect2: error: ld returned 1 exit status
Makefile:527: ошибка выполнения рецепта для цели «snort»
make[3]: *** [snort] Ошибка 1
make[3]: выход из каталога «/usr/src/snort-2.9.11/src»
Makefile:558: ошибка выполнения рецепта для цели «all-recursive»
make[2]: *** [all-recursive] Ошибка 1
make[2]: выход из каталога «/usr/src/snort-2.9.11/src»
Makefile:516: ошибка выполнения рецепта для цели «all-recursive»
make[1]: *** [all-recursive] Ошибка 1
make[1]: выход из каталога «/usr/src/snort-2.9.11»
Makefile:382: ошибка выполнения рецепта для цели «all»
make: *** [all] Ошибка 2

real    0m2.834s
user    0m1.572s
sys     0m0.548s

В чём проблема?

 ,

ne-vlezay ()

Агенты snort ?

Собственно вопрос вот в чем, существуют ли агенты для IDS Snort ? Т.е. сам snort у меня стоит на одной машине, но мог при этом собирать алерты с других машин (на которых стоят агенты, или каким-либо другим способом).

 ,

sa1mon ()

barnyard2 alert_syslog_full

Есть кто живой, у кого работает alert_syslog_full на удаленный syslog? В базу пишет норм, а в syslog daemon даже пакеты не шлет. Уже не знаю, за что зацепиться.

 

macumazan ()

Snort, Suricata rules

Делитесь кто какие, откуда списки правил использует.

 , ,

Deleted ()

Не отключается правило suricata

Не получается отрубить определённое правило, остальные нормально отрубаются, а это нет. Куда копать ?
disablesid 2240002
Need help !

 , ,

Deleted ()

af-packet и libpcap не работает на veth интерфейсах

Короче, решил я поднять snort в контейнере в режиме afpacket. Однако на правила реакции по каким-то непонятним причинам небыло. Я включил snort в режиме pcap - таже самая реакция. Однако в режиме nfq все правила работали нормально. Почему afpacket и libpcap не работает на veth-интерфейсах в netns?

 , , , ,

ne-vlezay ()

snort не видит фрагментированные пакеты с рандомным содержанием в режиме nfq

Короче, если в режиме afpacket или pcap сделать:

system@ne-vlezay80-pc:~$ nc ya.ru 80
aa
bb
HTTP/1.1 400 Bad Request
Server: nginx
Date: Sat, 30 Jul 2016 11:47:41 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 166
Connection: close

<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>
То snort покажет alert
Commencing packet processing (pid=4554)
Decoding Ethernet
07/30-11:51:03.382911  [**] [1:1000003:1] Filtred! [**] [Priority: 0] {TCP} 10.247.1.48:53620 -> 93.158.134.3:80
Но, в режиме nfq он почиму-то не видит пакеты с aa bb. В чем проблема?

 , , , ,

ne-vlezay ()

snort не запускается daq

Вот что выдаёт:

root@ne-vlezay80-pc:/usr/src/daq-2.1.0# LD_LIBRARY_PATH=/usr/local/lib snort --daq-dir /usr/local/lib/daq --daq-list
dump: Module API version (0x10003) differs from expected version (0x10002)
/usr/local/lib/daq/daq_dump.so: Failed to register DAQ module.
pcap: Module API version (0x10003) differs from expected version (0x10002)
/usr/local/lib/daq/daq_pcap.so: Failed to register DAQ module.
afpacket: Module API version (0x10003) differs from expected version (0x10002)
/usr/local/lib/daq/daq_afpacket.so: Failed to register DAQ module.
nfq: Module API version (0x10003) differs from expected version (0x10002)
/usr/local/lib/daq/daq_nfq.so: Failed to register DAQ module.
ipfw: Module API version (0x10003) differs from expected version (0x10002)
/usr/local/lib/daq/daq_ipfw.so: Failed to register DAQ module.
No available DAQ modules (try adding directories with --daq-dir).
root@ne-vlezay80-pc:/usr/src/daq-2.1.0#

В интернете по этому поводу ответа нет

 , , ,

ne-vlezay ()

snort как заставить его аналезировать мелкие пакеты?

Вот конфиг: http://paste.debian.net/785678/

Вот правило:

alert tcp any any -> any 80 (dsize:>78; content:"casino.org"; fast_pattern; content: "/ruletka.html"; nocase; rev:1; sid: 1000001; react;)

Если посылать пакет с нормальным mtu, то реакция есть:

Распознаётся casino.org (casino.org)… 212.113.133.146
Подключение к casino.org (casino.org)|212.113.133.146|:80... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа... 301 Moved Permanently
Адрес: https://www.casino.org/ruletka.html [переход]
--2016-07-28 01:07:44--  https://www.casino.org/ruletka.html
Распознаётся www.casino.org (www.casino.org)… 104.122.248.110
Подключение к www.casino.org (www.casino.org)|104.122.248.110|:443... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа... 404 Not Found
2016-07-28 01:07:44 ОШИБКА 404: Not Found.

07/27-22:07:44.258682  [**] [1:1000001:1] [**] [Priority: 0] {TCP} 10.247.1.14:33792 -> 212.113.133.146:80

Если посылать пакет с маленьким mtu через wget или netcat, то реакции нет. Как заставить snort блокировать мелкие пакеты?

 , , , ,

ne-vlezay ()

Защита от сканирования портов

Имеется snort. Факты сканирования портов выявляет, отображает в логах, но хотелось бы настроить блокировку по ip. Нарушитель попытался просканировать порты, в итоге соединение прервалось, и больше он с этого айпи ничего сделать не может. Но это в идеале. Или как-нибудь связать snort с iptables. Возможно такое?

 ,

maider123 ()

snort 2.9.8.0 и base и mysql

snort не стартует после добавления строки в snort.conf: output database: log, mysql, user=snort password=xxxxxx test dbname=snort host=localhost с ошибкой: FATAL ERROR: snort.conf(530) Unknown output plugin: «database». Подскажите, пожалуйста, что нужно поправить, чтобы заработало

 , , ,

worsvch ()

Suricata/Snort (NFQ) «теряют» второй входящий подряд DNS запрос на сервер.

Решил на выходных обстоятельно потыкать палочкой на своем наборе виртуальных серверов в Snort и Suricata (gentoo, qemu-kvm, сетевые virtio, все через статически прописанные tap-ы с бриджами), уж больно заинтересовало в каком они сейчас состоянии. Поставил на DNS сервер Snort, программа отлично работает — оповещает и блокирует, но обнаружилась какая-то аномальная работа в режиме NIPS (NFQ) — «пропадает» второй пакет приходящий на DNS сервер при последовательных запросах (A+AAAA) от клиента. Если запросы идут с достаточным интервалом для ответа DNS сервера, второй пакет с запросом проходит (не «теряется»). Выключил Snort, поставил на сервер Suricata, запустил как NIPS (тоже NFQ) и все повторилось 1 в 1 (все работает, фильтрует, пишет в логи алерты и блокирует... но второй пакет с DNS запросом опять заходит и «теряется» на уровне ядро-юзер спейс не доходя до DNS сервера). Думал, что их фильтрует как DNS флуд, только вот у той же Suricata стоит «request-flood: 500» по умолчанию, что «немного» больше чем 2, да и логи подозрительно молчат у обеих программ (хотя правила отрабатываются отлично, пишет в лог алерты).

Запустил wireshark и начал смотреть на сетевой интерфейс виртуального сервера:

  • При включенном на сервере NIPS (стоит и на входящие и на исходящие пакеты):
    15	0.091477407	192.168.64.4	192.168.64.1	DNS	73	Standard query 0x83c2 A ldap.corp.net
    16	0.091492929	192.168.64.4	192.168.64.1	DNS	73	Standard query 0x63f1 AAAA ldap.corp.net
    17	0.092691561	192.168.64.1	192.168.64.4	DNS	89	Standard query response 0x83c2 A ldap.corp.net A 192.168.64.3
    ...
    20	5.096090016	192.168.64.4	192.168.64.1	DNS	73	Standard query 0x83c2 A ldap.corp.net
    21	5.096631256	192.168.64.1	192.168.64.4	DNS	89	Standard query response 0x83c2 A ldap.corp.net A 192.168.64.3
    22	5.096737005	192.168.64.4	192.168.64.1	DNS	73	Standard query 0x63f1 AAAA ldap.corp.net
    23	5.098640900	192.168.64.1	192.168.64.4	DNS	73	Standard query response 0x63f1 AAAA ldap.corp.net
    

    Как видно, в первом блоке на DNS сервер из сети приходит два запроса, а уходит только один ответ, клиент ждет 5 секунд и отсылает повторный запрос, но с уже большим интервалом по времени между пакетами. DNS сервер в логах клятвенно заверяет, что второй пакет из первого блока (с AAAA запросом) к нему вообще не поступал. При повторном запросе от клиента через 5 секунд - временной интервал между запросами выше, и сервер успевает ответить на первый запрос (А) до поступления второго (AAAA). В логах DNS все это отображается аналогично информации полученной снифером. Если задать через iptables запись в лог (-j LOG до -j NFQUEUE) — пишет тоже самое, что ловлю на снифере, т. е. пакеты 100% заходят и идут до передачи в юзер спейс.

  • Если NIPS выключен:
    7	0.058400579	192.168.64.4	192.168.64.1	DNS	73	Standard query 0xb226 A ldap.corp.net
    8	0.058433208	192.168.64.4	192.168.64.1	DNS	73	Standard query 0xfa0b AAAA ldap.corp.net
    9	0.058548122	192.168.64.1	192.168.64.4	DNS	89	Standard query response 0xb226 A ldap.corp.net A 192.168.64.3
    10	0.058611081	192.168.64.1	192.168.64.4	DNS	73	Standard query response 0xfa0b AAAA ldap.corp.net
    

    Оба запроса проходят и DNS отвечает на них. В логах DNS все так и отображается.

  • Если сам сервер выступает в роли DNS клиента (например, при резолве yandex.ru) с включенным NIPS (стоит и на входящие и на исходящие пакеты):
    1	0.000000000	192.168.64.1	192.168.64.10	DNS	69	Standard query 0xabf7 A yandex.ru
    2	0.000018120	192.168.64.1	192.168.64.10	DNS	69	Standard query 0x70df AAAA yandex.ru
    ...
    5	0.003540832	192.168.64.10	192.168.64.1	DNS	133	Standard query response 0xabf7 A yandex.ru A 77.88.55.66 A 77.88.55.55 A 5.255.255.5 A 5.255.255.55
    6	0.003941852	192.168.64.10	192.168.64.1	DNS	97	Standard query response 0x70df AAAA yandex.ru AAAA 2a02:6b8:a::a
    

    Т. е. предположение, что NIPS не хватает временного интервала не подтвердилось, клиентские (исходящие) DNS запросы с такими же интервалами отлично обрабатывает.

Полностью убирал правила, собирал Suricata вообще с конфигурацией "--disable-detection", вносил udp 53 в исключения на Snort и выключал работу по dns вообще в Suricata, выключал все что можно, но даже «голые» Suricata и Snort ведут себя так же. Пока на входящем 53 udp сидит Suricata или Snort и обрабатывают nfq очередь, я ловлю этот нюанс со 100% вероятностью. Очередь nfqueue всегда около нулевая (судя по «cat /proc/net/netfilter/nfnetlink_queue»), нагрузки никакой нет 100%, плюс, fail open на обеих программах задействован. Логи на вопрос «где пакет?» молчат как партизаны на допросе.

Самое смешное, в статистике нет ни слова что пакет вообще был потерян или заблокирован:

  • как-то так для Snort:
    Packet I/O Totals:
    Received:         223
    Analyzed:         223 (100.000%)
    Dropped:            0 (  0.000%)
    Filtered:            0 (  0.000%)
    Outstanding:            0 (  0.000%)
    Injected:            0
  • вот так для Suricata:
    <Notice> - (Recv-Q1) Treated: Pkts 182, Bytes 43384, Errors 0
    <Notice> - (Recv-Q1) Verdict: Accepted 182, Dropped 0, Replaced 0

Идеи закончились... ощущение, что я не учитываю какую-то мелочь, но какую — понять не могу. Может, кто-то сталкивался с подобным?

 ,

viewizard ()

Есть ли ПО, которое может обнаружить подозрительную активность в логах squid?

Доброго времени суток

Сабж

Сразу уточню, моральный облик пользователей меня не интересует ( от слова «вообще» ). Что нужно, так это поиск активности, которая характерна для вирусов, червей и прочих зловредов. Т.е. IDS. Также интересно, если можно задать профиль устройства и искать отклонения ( вот это - принтер, ему веб без надобности. а это телевизор, для него характерен только ютуб )

Для сетевого трафика есть snort. Но хотелось бы что-то подобное для squid

 , ,

router ()

Ищу сетевого аналитика ИБ

Нам (http://ksyslabs.ru) нужен уникальный человек. Я бы даже сказал редкий. Нам нужен аналитик ИБ, основной задачей которого будет развитие и поддержка базы сигнатур для snort. Нужно будет перелапатить имеющиеся открытые базы, проанализировать актуальность сигнатур, собрать определенный набор сигнатур, регулярно поддерживать и развивать их, черпая данные из открытых источников. В свободное от этой деятельности время нужно будет описывать модели сетей для специализированных IDS (это не сложно, научим).

Человек нам нужен грамотный, имевший опыт парсинга CVE и работы с паттернами. Денег - предлагайте, пока что профессионального аналитика мы не встречали. для связи - sartakov@ksyslabs.org

Офис - марьина роща, хотим фултайм, но можем взять студента (откуда правда у него опыт работы с CVE?), к удаленке пока не готовы (но кто знает, пишите).

Можем без специального образования, но лучше с ним.

 ,

sartakov ()