LINUX.ORG.RU

3
Всего сообщений: 40

Suricata

Добрый день. Я только познаю linux и suricata. Решил написать правило для suricata, чтобы при ping это записывалось в логах. Правило: alert icmp any any -> any any (msg: «AHA»; sid: 1000001; rev: 1; classtype: icmp-event;)

Правило закинул в папку /etc/suricata/rules, назвал test.rules У меня локальной сетью ВМ связаны 4 ОС, и я пингую либо с Lubuntu, либо с Kali на свою Selks, но в /var/log/suricata/fast.log ничего не пишется, просто пустой файл. В чём может быть проблема? Заранее спасибо за помощь!

 

Groon1k ()

juniper srx и suricata за ним - как?

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

1. C учётом архитектуры сети требуется развернуть IDS Suricata.

https://i.imgur.com/9UCuYgN.png

Как я это вижу:

Juniper srx 650, за ним suricata, отфильтрованный трафик отдаём в свитч и из свитча дальше по серверам. Ожидаю подключение вида:

весь трафик из порта juniper -> в порт intel 350t4 отфильтрованный трафик из порта intel350t4 -> в порт свитча.

Suricata разворачиваю на hp dl360g6 (x5670 x2, 16Gb RAM, SSD Intel DC 4610, intel 350t4v2 (не твиканая), Ubuntu 18.04 и Suricata 5.0 из PPA).

2. Также заинтересован в отказоустойчивом кластере.

Будем считать, что у нас есть кластер из SRX 650ых. Требуется кластер для Suricata с учётом того, что у нас два hp dl360g6 в одинаковой конфигурации.

Как достигнуть желаемого?

 , , , ,

Nezie ()

Странности с connmark

Собственно, имеется suricata со следующими правилами:

#pass tls any any -> any any (pcre: "/play.google.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2466;)
#pass tls any any -> any any (pcre: "/google.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2465;)
#pass tls any any -> any any (pcre: "/gstatic.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2467;)
#pass tls any any -> any any (pcre: "/googleservice.com/i"; tls_sni;nfq_set_mark:0x8/0xffffffff; sid:2467;)
pass tls any any -> any any (pcre: "/youtube.com/s"; tls_sni;nfq_set_mark:0x2/0xffffffff; sid:2455;)
pass tls any any -> any any (pcre: "/googlevideo.com/s"; tls_sni;nfq_set_mark:0x2/0xffffffff; sid:2456;)
pass http any any <> any any (content: "tactical-market.ru"; http_header;nfq_set_mark:0x4/0xffffffff; sid:2457;)
pass http any any <> any any (content: "voent.org"; http_header;nfq_set_mark:0x4/0xffffffff; sid:2458;)
pass http any any <> any any (content: "h-mag.ru"; http_header;nfq_set_mark:0x4/0xffffffff; sid:2459;)
pass tls any any <> any any (content: "voent.org";tls_sni;nfq_set_mark:0x4/0xffffffff; sid:2460;)
pass tls any any <> any any (content: "h-mag.ru";tls_sni;nfq_set_mark:0x4/0xffffffff; sid:2461;)
rejectboth tcp any any <> any any (content: "GET http://";content: "Host: "; sid:2462;)
pass http any any <> any any (content: "302";http_stat_code;content: "ivrn.net";http_header;nfq_set_mark:0x64/0xffffffff; sid:2463;)
pass ssh any any <> any any (nfq_set_mark:0x6/0xffffffff; sid:2464;)

#reject tls any any <> any any (content:"www.youtube.com"; tls_sni;nfq_set_mark:0x2/0xffffffff; sid:2456;)

#ytimg.com

iptables:
Chain PREROUTING (policy ACCEPT 228K packets, 138M bytes)
 pkts bytes target     prot opt in     out     source               destination         
   11  3630 RETURN     all  --  *      *       0.0.0.0              255.255.255.255     
 127K  121M RETURN     all  --  eth1   *       0.0.0.0/0            0.0.0.0/0           
  187 11489 RETURN     all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           
10365 2323K RETURN     all  --  vpns0.10 *       0.0.0.0/0            0.0.0.0/0           
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            rpfilter invert LOG flags 0 level 4 prefix "IP SPOOFING: "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            rpfilter invert
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m ipv4options --flags 7 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m ipv4options --flags 3 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m ipv4options --flags 9 
    0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set dpi_detect dst MARK xset 0x40/0xfe
    0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set dpi_detect src MARK xset 0x40/0xfe

Chain INPUT (policy ACCEPT 107K packets, 45M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 120K packets, 93M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 241K  185M DPI        all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 120K   93M DPI_SH     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 2063  123K TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x06/0x02 TCPMSS clamp to PMTU

Chain OUTPUT (policy ACCEPT 109K packets, 24M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 229K packets, 116M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain DPI (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  *      *       198.18.0.0/15        192.168.0.0/15      
    0     0 RETURN     all  --  *      *       192.168.0.0/16       198.18.0.0/15       
    0     0 RETURN     all  --  *      *       192.168.0.0/16       192.168.0.0/16      
 121K   93M NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match ! 0x1/0x1 NFQUEUE num 0

Chain DPI_SH (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 3542 2688K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            connmark match  0x8/0xfe
   53 45450 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match 0x8/0xfe CONNMARK xset 0x8/0xfe
    0     0 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match 0x4/0xfe CONNMARK xset 0x4/0xfe
    8  9366 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match 0x2/0xfe CONNMARK xset 0x2/0xfe
24094   27M CLASSIFY   all  --  *      *       0.0.0.0/0            0.0.0.0/0            connmark match  0x2/0xfe CLASSIFY set 1:11
    0     0 CLASSIFY   all  --  *      *       0.0.0.0/0            0.0.0.0/0            connmark match  0x4/0xfe CLASSIFY set 1:12
    0     0 SET        all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match 0x64/0xfe add-set dpi_detect src
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match 0x64/0xfe LOG flags 0 level 4 prefix "INFOROOM DPI: "
ip6tables:
Chain PREROUTING (policy ACCEPT 314 packets, 60079 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all      eth1   *       ::/0                 ::/0                
 6722 5704K RETURN     all      ppp0   *       ::/0                 ::/0                
    2   112 RETURN     all      vpns0.10 *       ::/0                 ::/0                
    0     0 LOG        all      *      *       ::/0                 ::/0                 rpfilter invert LOG flags 0 level 4 prefix "IP6 SPOOFING: "
    0     0 DROP       all      *      *       ::/0                 ::/0                 rpfilter invert

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

Chain FORWARD (policy ACCEPT 299 packets, 59095 bytes)
 pkts bytes target     prot opt in     out     source               destination         
23065   13M DPI        all      *      *       ::/0                 ::/0                
11539 6450K DPI_SH     all      *      *       ::/0                 ::/0                
  172 13760 TCPMSS     tcp      *      *       ::/0                 ::/0                 tcp flags:0x06/0x02 TCPMSS clamp to PMTU

Chain OUTPUT (policy ACCEPT 13 packets, 896 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 312 packets, 59991 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain DPI (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    1  1280 RETURN     all      *      *       2a01:d0:c353::/48    2a01:d0:c353::/48   
    0     0 RETURN     all      *      *       2a01:d0:c353::/48    2a01:d0:c353::/48   
11526 6448K NFQUEUE    all      *      *       ::/0                 ::/0                 mark match ! 0x1/0x1 NFQUEUE num 0

Chain DPI_SH (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all      *      *       ::/0                 ::/0                 connmark match  0x8/0xfe
    0     0 CONNMARK   all      *      *       ::/0                 ::/0                 mark match 0x8/0xfe CONNMARK xset 0x8/0xfe
    0     0 CONNMARK   all      *      *       ::/0                 ::/0                 mark match 0x4/0xfe CONNMARK xset 0x4/0xfe
   31 36225 CONNMARK   all      *      *       ::/0                 ::/0                 mark match 0x2/0xfe CONNMARK xset 0x2/0xfe
  215 86776 CLASSIFY   all      *      *       ::/0                 ::/0                 connmark match  0x2/0xfe CLASSIFY set 1:11
    0     0 CLASSIFY   all      *      *       ::/0                 ::/0                 connmark match  0x4/0xfe CLASSIFY set 1:12
    0     0 LOG        all      *      *       ::/0                 ::/0                 mark match 0x64/0xfe LOG flags 0 level 4 prefix "INFOROOM DPI: "
Теперь вопрос: почему при вхлде на google.com, правило
  314  115K CLASSIFY   all      *      *       ::/0                 ::/0                 connmark match  0x2/0xfe CLASSIFY set 1:11
начинает срабатывать? По идее оно должно срабатывать, если заходишь на youtube.com.

 , , ,

ne-vlezay ()

suricata блокировка telegram

Вот, ношёл сингтуры для telegram'а в исходниках ndpi:

  if (packet->payload_packet_len == 0)
    return;
  if (packet->tcp != NULL) {
    if (packet->payload_packet_len > 56) {
      dport = ntohs(packet->tcp->dest);
      /* sport = ntohs(packet->tcp->source); */

      if (packet->payload[0] == 0xef && (
          dport == 443 || dport == 80 || dport == 25
        )) {
        if (packet->payload[1] == 0x7f) {
          ndpi_int_telegram_add_connection(ndpi_struct, flow);
        }
        else if (packet->payload[1]*4 <= packet->payload_packet_len - 1) {
          ndpi_int_telegram_add_connection(ndpi_struct, flow);
}
Попытался создать правило на основе этой сингтуры:
rejectboth tcp any any <> any any (dsize:>56;content: "|ef|";content: "|7f|"; sid:2462;)
Но, почему-то когда под это правило попадает телеграм, то https сайты перестают открываться. Что не так?

 ,

ne-vlezay ()

коммуникация Suricata с Mikrotic

Всем привет, что нужно сделать что бы Suricata отправляла сообщение о «DoS атаке» на маршрутизатор(Mikrotic)?

 

nata25669 ()

Отключить логирование для сервиса

Доброго времени суток. Имеется машинка с сурикатой. Для сурикаты имеется unit файл /etc/systemd/system/suricata.service. Суриката так и стартует как демон при старте машины, ну или systemctl start suricata если надо вручную. Суриката посылает сообщения rsyslog'у, а тот уже рассылает куда указано. Но кроме этого суриката засирает своими детектами лог journald. Собственно в этом и есть вопрос - как сделать так что-бы суриката ничего не сообщала в journald? Вообще ничего не хочу от сурикаты в journald. В unit файле добавил строку «StandardOutput=null» в секции "[Service]", но не помогло.

В интернете тонна руководств скопированный от одного к другому как использовать этот самый journald, как использовать systemd. Но ничего не нашёл как отключить сообщения в этом самом journald.

 , ,

Toten_Kopf ()

Тюнинг Suricata на IPS при 2Mpps+

Есть задача сделать сабж в виде L2 моста для анализа траффика и дропа некоторых пакетов по своим правилам.

Целевой траффик около 20Гбит, 2Mpps с перспективой роста.

Собрал тестовый стенд из трех DL360 gen9, карты Intel XL710, ядра 4.9.х, дрова интель последние. Один генератор траффика, второй - приемник, в середине Suricata, она настроена на режим AF_PACKET с копированием пакетов с одного интерфейса на другой и обратно.

Тестирую прогоном pcap-файла через tcpreplay.

Всё, вроде бы, работает отлично - на скоростях до 1.15Mpps на порт ядро и Suricata пакеты не дропают, но вот почему-то дальше во второй порт пакетов *уходит* на ~0.8% меньше чем вошло в первый. Проверял по ethtool -S eno49 | grep tx_packets.

Где оно может теряться? В счетчиках отправляющей карты дропов и оверранов не обнаружил, в сурикате тоже всё по нулям.

 , ,

blind_oracle ()

Suricata в Altell NEO.

Я знаю что это не саппорт Altell, но у этого программного МЭ на борту Vyatta с некоторыми сторонними пакетами, в частности Suricata в качестве IDS/IPS. Вообще, я открыл кейс, но эти ублюдки отвечают по 5 месяцев (без преувеличений), а телефон «сбрасывает». Куплен не мной и куплен только из-за наличия сертификата ФСТЭК (требуется).
Я не имел дел с настройкой ids/ips ранее (был watchguard, который сам блочил всякую нечисть по подписке, лол), прочитал https://xakep.ru/2015/06/28/suricata-ids-ips-197/ и https://habrahabr.ru/post/192884/ для общего ознакомления, ну и, конечно, документацию altell, ибо в конечном счете приходится руководствоваться их синтаксисом и логикой.
И так, у меня, собственно, не работает IPS. Раньше он даже лог не писал и summary не вел, но после factory reset`а начал, и это уже достижение, да. Теперь ведет лог, и в режиме IDS, и в режиме IPS, например (чтобы было понятно, на этой эмуляции 83.246.142.1 - это узел оператора, который является дефолтным шлюзом для моего МЭ/маршрутизатора и в данном случае выступает как «интернет», 83.246.160.242 - мой узел, адрес которого лежит в белом маршрутизируемом пуле ipv4, который я арендую, который находится ЗА altell NEO, т.е. для меня «условно» локальный):

admin@NEO1U# run show idps log
2017/03/22-14:59:15.32609 [**] [1:2101867:2] GPL RPC xdmcp info query  [**] [Classification: Attempted Information Leak] [Priority: 2] {UDP} 83.246.142.1:51482 -> 83.246.160.242:177
2017/03/22-15:00:59.15209 [**] [1:2010937:2] ET POLICY Suspicious inbound to mySQL port 3306  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:3306
2017/03/22-15:01:00.25684 [**] [1:2010937:2] ET POLICY Suspicious inbound to mySQL port 3306  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35627 -> 83.246.160.242:3306
2017/03/22-15:01:00.60414 [**] [1:2101420:12] GPL SNMP trap tcp  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:162
2017/03/22-15:01:00.70867 [**] [1:2101420:12] GPL SNMP trap tcp  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35627 -> 83.246.160.242:162
2017/03/22-15:01:01.72439 [**] [1:2101420:12] GPL SNMP trap tcp  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35628 -> 83.246.160.242:162
2017/03/22-15:01:01.72451 [**] [1:2010937:2] ET POLICY Suspicious inbound to mySQL port 3306  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35628 -> 83.246.160.242:3306
2017/03/22-15:01:03.15822 [**] [1:2002911:4] ET SCAN Potential VNC Scan 5900-5920  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5919
2017/03/22-15:01:04.65724 [**] [1:2002910:4] ET SCAN Potential VNC Scan 5800-5820  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5815
2017/03/22-15:01:04.78230 [**] [1:2010938:2] ET POLICY Suspicious inbound to mSQL port 4333  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:4333
2017/03/22-15:01:04.88813 [**] [1:2010938:2] ET POLICY Suspicious inbound to mSQL port 4333  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35627 -> 83.246.160.242:4333
2017/03/22-15:01:04.99111 [**] [1:2010938:2] ET POLICY Suspicious inbound to mSQL port 4333  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35628 -> 83.246.160.242:4333
2017/03/22-15:01:05.40414 [**] [1:2002911:4] ET SCAN Potential VNC Scan 5900-5920  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5905
2017/03/22-15:01:06.33429 [**] [1:2010938:2] ET POLICY Suspicious inbound to mSQL port 4333  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35629 -> 83.246.160.242:4333
2017/03/22-15:01:06.33437 [**] [1:2010937:2] ET POLICY Suspicious inbound to mySQL port 3306  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35629 -> 83.246.160.242:3306
2017/03/22-15:01:06.33442 [**] [1:2101420:12] GPL SNMP trap tcp  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35629 -> 83.246.160.242:162
2017/03/22-15:01:06.41328 [**] [1:2010935:2] ET POLICY Suspicious inbound to MSSQL port 1433  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:1433
2017/03/22-15:01:06.51638 [**] [1:2010935:2] ET POLICY Suspicious inbound to MSSQL port 1433  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35627 -> 83.246.160.242:1433
2017/03/22-15:01:06.56791 [**] [1:2002910:4] ET SCAN Potential VNC Scan 5800-5820  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5805
2017/03/22-15:01:06.61931 [**] [1:2010935:2] ET POLICY Suspicious inbound to MSSQL port 1433  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35628 -> 83.246.160.242:1433
2017/03/22-15:01:07.72585 [**] [1:2010935:2] ET POLICY Suspicious inbound to MSSQL port 1433  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35629 -> 83.246.160.242:1433
2017/03/22-15:01:08.31589 [**] [1:2002911:4] ET SCAN Potential VNC Scan 5900-5920  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5902
2017/03/22-15:01:08.87572 [**] [1:2002910:4] ET SCAN Potential VNC Scan 5800-5820  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5816
2017/03/22-15:01:08.89738 [**] [1:2010936:2] ET POLICY Suspicious inbound to Oracle SQL port 1521  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:1521
2017/03/22-15:01:09.00171 [**] [1:2010936:2] ET POLICY Suspicious inbound to Oracle SQL port 1521  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35627 -> 83.246.160.242:1521
2017/03/22-15:01:09.09487 [**] [1:2010939:2] ET POLICY Suspicious inbound to PostgreSQL port 5432  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5432
2017/03/22-15:01:09.10467 [**] [1:2010936:2] ET POLICY Suspicious inbound to Oracle SQL port 1521  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35628 -> 83.246.160.242:1521
2017/03/22-15:01:09.16674 [**] [1:2002911:4] ET SCAN Potential VNC Scan 5900-5920  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5909
2017/03/22-15:01:09.20075 [**] [1:2010939:2] ET POLICY Suspicious inbound to PostgreSQL port 5432  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35627 -> 83.246.160.242:5432
2017/03/22-15:01:09.20663 [**] [1:2010936:2] ET POLICY Suspicious inbound to Oracle SQL port 1521  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35629 -> 83.246.160.242:1521
2017/03/22-15:01:09.30475 [**] [1:2010939:2] ET POLICY Suspicious inbound to PostgreSQL port 5432  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35628 -> 83.246.160.242:5432
2017/03/22-15:01:09.37343 [**] [1:2002910:4] ET SCAN Potential VNC Scan 5800-5820  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5812
2017/03/22-15:01:09.40576 [**] [1:2010939:2] ET POLICY Suspicious inbound to PostgreSQL port 5432  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:35629 -> 83.246.160.242:5432
2017/03/22-15:01:10.21325 [**] [1:2002911:4] ET SCAN Potential VNC Scan 5900-5920  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5913
2017/03/22-15:01:10.33358 [**] [1:2002910:4] ET SCAN Potential VNC Scan 5800-5820  [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 83.246.142.1:35626 -> 83.246.160.242:5806
2017/03/22-15:01:14.64475 [**] [1:1390:5] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable code was detected] [Priority: 1] {UDP} 83.246.142.1:37493 -> 83.246.160.242:2
2017/03/22-15:01:14.84655 [**] [1:1390:5] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable code was detected] [Priority: 1] {UDP} 83.246.142.1:37493 -> 83.246.160.242:2
2017/03/22-15:01:14.94839 [**] [1:1390:5] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable code was detected] [Priority: 1] {UDP} 83.246.142.1:37493 -> 83.246.160.242:2
2017/03/22-15:01:15.04979 [**] [1:1390:5] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable code was detected] [Priority: 1] {UDP} 83.246.142.1:37493 -> 83.246.160.242:2
2017/03/22-15:01:28.60777 [**] [1:2010935:2] ET POLICY Suspicious inbound to MSSQL port 1433  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:22611 -> 83.246.160.242:1433
2017/03/22-15:03:09.99195 [**] [1:1390:5] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable code was detected] [Priority: 1] {UDP} 83.246.142.1:40841 -> 83.246.160.242:39838
2017/03/22-15:03:10.19217 [**] [1:1390:5] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable code was detected] [Priority: 1] {UDP} 83.246.142.1:40841 -> 83.246.160.242:39838
2017/03/22-15:03:10.29316 [**] [1:1390:5] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable code was detected] [Priority: 1] {UDP} 83.246.142.1:40841 -> 83.246.160.242:39838
2017/03/22-15:03:10.39506 [**] [1:1390:5] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable code was detected] [Priority: 1] {UDP} 83.246.142.1:40841 -> 83.246.160.242:39838
2017/03/22-15:03:24.25586 [**] [1:2010935:2] ET POLICY Suspicious inbound to MSSQL port 1433  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:22953 -> 83.246.160.242:1433
2017/03/22-15:03:27.26020 [**] [1:2010935:2] ET POLICY Suspicious inbound to MSSQL port 1433  [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 83.246.142.1:22953 -> 83.246.160.242:1433
Как видно, большинство действий имеют приорити 1 или 2, что исходя из моего конфига должно дропаться. Вот конфиг:
[edit]
admin@NEO1U# show idps
   actions {
       other pass
       priority-1 drop
       priority-2 drop
   }
   modify-rules {
       internal-network 83.246.160.240/28
       internal-network 83.xxx/28
       internal-network 83.xxx/24
       internal-network 10.0.0.0/8
   }
   output {
       syslog {
       }
   }
[edit]
Вооот. Но я как при выключенном IPS полностью сканил nmap`ом хост 83.246.160.242, так и при включенном. Да, ips пишет что такой-то нехороший хост 83.246.142.1 (олицетворение Интернета) делает нехорошие вещи, но не блочит его, т.е. по поведению не отличается от IDS. Также при включенном IPS продолжаю nping`ом спамить SYN`ами в 8000 порт (использую на лаптопе минивеб) и минивеб сервер захлебывается, но IPS на это плевать. Тот же WatchGuard на попытку нмапом полапать хост, сразу отправлял в перманентный блок. Здесь же, как я понял, вообще никаких блок листов нет.
Разбор делается через NFQUEUE. Если нужен suricata.yaml - скажите какой кусок, ибо он большой. Но на него влияет только сегмент idps (который я привел выше в «show idps») и включение на интерфейсах. Включен только на одном:
admin@NEO1U# show interfaces ethernet eth0
   address 83.xxx/26
   description INTERNET_TTK
   ips {
       in {
           enable
       }
       local {
           enable
       }
   }
   mtu 1500
[edit]
В общем, если есть идеи - очень прошу.

 ,

nokogerra ()

Суриката + cuda = segmentation fault

Приветствую. Продолжаются мои мытарства с сурикатой. Пересобрал сурикату с поддержкой cuda, выставил в настройках mpm-algo: ac-cuda. Теперь при запуске: surikata -c /etc/suricata/suricata.yaml, суриката сразу вываливается и выдаёт Segmentation fault(core dumped).

В логах самой сурикаты ничего. В kern.log есть такая строка: suricata kernel:

[ 3016.823840] traps: W#06[31069] general protection ip:564a48f47c3f sp:7f37097f8120 error:0 in suricata[564a48d4a000+2b9000]

Та же строка в syslog и в dmesg. Если запускать сурикату с ключом -D, то в логе сурикаты появляются строки:

13/3/2017 -- 10:53:03 - <Error> - [ERRCODE: SC_ERR_CUDA_ERROR(134)] - cuCtxPushCurrent failed.  Returned errocode - CUDA_ERROR_NOT_INITIALIZED
13/3/2017 -- 10:53:03 - <Error> - [ERRCODE: SC_ERR_FATAL(171)] - context push failed.

По этим строкам нагуглил только баг 1059 и больше ничего.

Ubuntu 16.04, kernel 4.4.0-66, Суриката 3.2.1 из исходников, Cuda 8.0.61, драйвера Nvidia 375.26, карта GeForce GTX 750 Ti.

Подскажите чего ей не хватает? Если кто-то заводил сурикату с поддержкой cuda - как собирали? что в конфиге крутили?

 ,

Toten_Kopf ()

Суриката читает не весь трафик

Доброго времени суток. Имелась следующая схема: роутер Микротик, какой-то CCR, к нему в порт е1 входит провайдер, в порт е2 подключен сервер с сурикатой, в порт е3 подключена наша сеть. Весь, проходящий через микротик, трафик дублируется на сурикату. Перед сурикатой запущен trafr от микротика, он передаёт по трубе сурикате, суриката детектит, отсылает всё что видит в Logstash, всем счастье. Но захотелось нам поставить перед Микротиком свитч, сделать зеркалирование трафика с его помощью, убрать trafr из цепочки и запустить сурикату с cuda'ой. Теперь схема такова: шнурок от провайдера в свитч е1, к е2 свитча подключен сервер с сурикатой, е3 свитча идёт в Микротик.

И вот теперь какая-то непонятная фигня с сурикатой - nload показывает полную нагрузку на интерфейсе сурикаты, цифры совпадают с цифрами в Микротике, свитч всё исправно зеркалирует. Но теперь суриката почти ничего не детектит. Т.е. алерты пишутся, что-то детектится, но совершенно не в таких количествах как до изменений. Раньше лог был засран сообщениями о трояне Linux.Mirai, теперь же ни одного сообщения о нём. Вообще теперь осталось очень малое количество алертов с приоритетом 1, почти все они UDP, и просто мизерное количество сообщений от TCP.

Не меняя настроек подключили сурикату по старому - всё работает. Пока разбирались нашлась ещё странность - если tcpdump запустить на схеме через свитч и писать всё в stdout - он ловит малое количество пакетов. Очень много «kernel dropped» пакетов. Если запустить на первой схеме - пакеты сыпятся как из пулемёта. Но! - если запустить tcpdump по схеме через свитч и при этом писать в файл, а не в stdout, то он ловит все пакеты, как и при первой схеме.

Сурикату пробовали запускать и с cuda и без неё, и в режиме af-packet и pcap. Результата одинаковый. Подскажите, пожалуйста, какую настройку ей подкрутить что бы оно заработало?

P.S. Суриката 3.2.1 скомпилированная, сервер Ubuntu 16.04

 ,

Toten_Kopf ()

не могу подружить suricata и rsyslog

Доброго времени суток. Ситуация следующая - имеется IDS суриката 3.2, скомпилированная из исходников, стоит на убунту 16.04. Имеется logstash на другой машине, тоже убунту 16.04. Хочу сообщения от сурикаты отправлять в logstash через rsyslog. Сам rsyslog сообщения прекрасно пересылает - я их принимаю. Не могу подружить сурикату с rsyslog'ом. В файле конфигурации включил всё где есть упоминание про syslog, но результата нету. Подскажите, пожалуйста, чего сурикате не хватает? Подозреваю что криво сконфигурирован rsyslog.

 , ,

Toten_Kopf ()

Snort, Suricata rules

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

 , ,

Deleted ()

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

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

 , ,

Deleted ()

Анализ мелких пакетов через suricata

Вот скрипт:

function init (args)
    local needs = {}
    needs["payload"] = tostring(true)
    return needs
end

function match(args)
    	for k,v in pairs(args) do
		if tostring(k) == "payload" then
			a = tostring(v)
			if  a:find("GET") and a:find("Host: ")  then
                            return 0
			end
                        if a:find("POST") and a:find("Host: ")  then
                            return 0
                        end
                        if a:find("HEAD") and  a:find("Host: ")  then
                            return 0
                        end
                        if a:find("PUT") and  a:find("Host: ")  then
                            return 0
                        end
                        if a:find("PATCH") and  a:find("Host: ")  then
                            return 0
                        end
                        if a:find("CONNECT") and  a:find("Host: ")  then
                            return 0
                        end
                        if a:find("TRACE") and  a:find("Host: ")  then
                            return 0
                        end
					print("Find mil HTTP packet\n")
		end		
	end
end 
 
return 0
--eof
Короче, как сделать так чтобы от просматривал только пакеты вначале сессии. Потому что этот скрипт просматривает многие пакеты.
Ещё скрипт:
function init (args)
    local needs = {}
    needs["http.request_headers"] = tostring(true)
    math.randomseed(os.time())
    return needs
end


function match(args)
    a = tostring(args["http.request_headers"])
    o = args["offset"]
 
    s = a:sub(o)
    d = string.match(s, 'Host: spys.ru')
    print(s)

	if d then
		print("test")
		return 1
	end
 
    return 0
end
Парсер в скрипте работает на ура, но когда чкрипт заканчивает выполнение отправка rst в suricata происходит с задержкой. Хотя скрипт отрабатывает нормально. Можно ли самим скриптом отправлять tcp rst.

 , , ,

ne-vlezay ()

suricata lua tcp reassembly (сборка tcp пакетов при помощи lua скриптов suricata)

В suricata есть поддержка lua-скриптов, а также luajit. Так вот, реально ли с помощью lua-скрипта склеить tcp пакеты для их последующего анализа через этот lua-скрипт. На сколько мне известно, в suricata есть полноценная поддержка lua, а также luajit. Через эти скрипты можно даже запускать программы при совподении трафика с шаблоном. Где можно найти документацию по luajit? Особенно интерисует тема склеивания tcp пакетов.

 , , , ,

ne-vlezay ()

suricata не работает tcp_reassembly

Короче, пытаюсь я заставить suricat'у анализировать tcp/ip поток. Но счётчики правил не растут. Что я делаю не так.
Конфиг:
http://paste.debian.net/442753/
Правила iptables http://paste.debian.net/442754/
Список правил

pass tcp any any -> any any (content: "GET /";content: "Host: www.memo.ru";msg: "TEST was marked!"; nfq_set_mark:0x2/0xffffffff; sid:2455;)

 , , , ,

ne-vlezay ()

Suricata IDS и конструирование pcap файлов.

Если в /var/log/suricata/eve.json посмотреть значения packet и payload при включенных в /etc/suricata/suricata.yaml можно заметить, что packet будет отличаться по части IPv4 Total Length и TCP Flag от такого, что было перехвачено wireshark или tcpdump. В результате если потом собрать pcap файл из того что есть в eve.json: packet + payload ничего хорошего не получится, wireshark будет ругаться.

      types:
        - alert:
            payload: yes           # enable dumping payload in Base64
            payload-printable: yes # enable dumping payload in printable (lossy) format
            packet: yes            # enable dumping of packet (without stream segments)
            http: yes              # enable dumping of http fields
            tls: yes               # enable dumping of tls fields
            ssh: yes               # enable dumping of ssh fields
            smtp: yes              # enable dumping of smtp fields

Я знаю, что Suricata может быть настроена на запись в pcap файлы сразу, но мне интересно есть ли способ побороть эту особенность поведения Suricata при записи именно, в eve.json. И вообще интересен любой опыт и ваши мысли, вдруг кто то сталкивался с подобным.

 

bezopuye ()

разбор netflow через suricata

Что-то сходу не могу нагуглить, можено ли заставить сурикату разбирать отправленный ей netflow вместо самого трафика?

 , ,

Deleted ()

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 ()

Как в linux с помощью iptables собрать пакеты в один

Имеем запрос вида:

nc ya.ru 80
GET / HTTP/1.1
Host: ya.ru

Я прописал тестовое правило в iptables, но увидел, что на счётчике показала два пакета. Как сделать так, чобы всё это представляло один пакет. Или запретить отправлять такого вида пакеты.

cast vel

 , , , ,

ne-vlezay ()