СБОР и АНАЛИЗ
Разное
- на практике чащк всего tcpdump используется для съема, wireshark для анализа, scapy для редактирования и создания с нуля, tcpreplay для stateless проигрывания, но в статье описано много разных инструментов, включая альтернативные
- курс “Wireshark: Packet Analysis and Ethical Hacking: Core Skills” на GNS3. В целом базовый (уровень CCNA), но есть интересные вещи – например, тут увидел полноценную эмуляцию VoIP с sofphone/call manager в среде GNS3
-
как любые дебаг утилиты, захват трафика лучше запускать в режиме записи в файл, а не в режиме вывода на экран т.к. чаще всего именно формирование вывода является наиболее стрессовым по нагрузке на cpu, а не запуск захвата трафика/debug как таковой.
- примеры дампов трафика с атаками
- изначально проект Wireshark назывался Ethereal
- идентификация данных о хосте на основе pcap (из dhcp, nbns, http, kerberos)
- упражнения по анализу трафика с атаками
- пример выдачи IP по DHCP с работой ARP
- много разных дампов можно найти тут
https://wiki.wireshark.org/SampleCaptures
https://packetlife.net/captures/
- Альтернативы *nix tcpdump на оборудовании security вендоров, все они, включая tcpdump представлены на крутом сайте tcpdump101.com, который позволяет создавать фильтры (конструктор фильтров) в GUI:
- fw monitor – CheckPoint
- packet capture (capture-traffic, capture) – cisco
- diag sniffer – fortigate
- Альтернатива tcpdump в Windows – windump. Так же есть tcpdump for Windows. windump по командам почти полный аналог. Из явного отличия – работать нужно строго по ID, а не имени интерфейса из вывода “windump.exe -D”
- Не используем русский интерфейс т.к. мануалов и статей намного больше англоязычных, чем каких либо других
- Легко можно экспортировать информацию из дампа открытого в Wireshark в csv/excel с сохранением строк/столбцов, что может пригодиться при аналитике
Go to File -> Export -> File and select a file name and "CSV" for Save as Type. That way you will get all rows exported exactly as displayed in the packet list. You can also give Wireshark ranges if you don't need all of the rows.
-
Wireshark по умолчанию кладет весь дамп в оперативку. Дамп 6GB – будет 6GB занято в оперативке.
-
НО такие объемные дампы лучше не делать, а использовать функционал по созданию каждые N-пакетов/секунд/байт нового файла в Output настройках Wireshark (настраивается перед стартом захвата).
- Так же в output настройках можно
- задать отключение сбора дампа(ов) после N-пакетов/секунд/байт.
- включить резолвинг IP адресов в DNS имена (как по умолчанию у tcpdump)
-
Analyze -> Expert Info. Очень удобно понять были ли duplicated ack/retransmissions и прочие проблемы (см. раздел Notes).
tcp.analysis.retransmission
tcp.analysis.duplicate_ack_frame
- При анализе задержек в pcap всегда надо учитывать, что задержка со стороны клиента может быть простым “thinking time”, а не фактической задержкой клиентского приложения
-
Wireshark показывает Checksum Ethernet только в случае, если его сохранила сетевая карта, а это редко. Пример дампа с наличием CRC/FCS – eth-crc-fcs.pcap. Поэтому, смотря в дамп трафика Wireshark:
- можно думать, что конец фрейма одинаковый у фреймов с одинаковым payload, но разными SRC/DST адресами, но по факту он отличается т.к. checksum фрейма отличается (напр. различие в окончании фрейма ярко видно в пакетном конструкторе Ixia IxExplorer)
- можно некорректно рассчитывать размер фрейма – нужно прибавлять 4 байта к тому, что видим в Wireshark (4 байта чаще всего представляются в виде 8ми hex символов, сгруппированных по два)
Из канала Chris Greer интересное о перехваченном tcpdump или wireshark (о специфике TCP в отдельной статье l4/tcp):
0) по IP TTL полю в перехваченном дампе в общем случае можно понять где он собран с точки зрения сети – на клиенте, сервере или промежуточном устройстве. Смысл в том что зачение поля в IP TTL имеет двоичную разрядность и чаще всего равно 64/128/256 (раньше разные ОС использовали разный IP TTL и даже были нестандартные значения типо 62, сейчас все чаще стеки в целом работают очень похоже и в том числе для IP TTL используют 64). Если пакет имеет подобный ttl – вероятнее всего он перехвачен на клиенте или менее вероятное – сервер в одном бродкаст домене/кто то подменяет поле (напр. Web proxy корпоративный) или пройдено столько хопов, что значение случайно стало «нужное».
1) по полю IP TTL в ответах от сервера (при перехвате на клиенте и наоборот) можем понять в скольких роутинг-хопах от нас находится сервер путев добавления к текущему IP TTL значения, ближайшего до 64/128/256. Возможны исключения (как в примере выше), но маловероятны. А на промежуточном устройстве можно понять в скольких хопах от него сервер/клиент.
2) хорошо иметь дамп с двух сторон – клиента и сервера, т.к., например, то, что мы считаем «проблемой» сервера может быть проблема на промежуточном устройстве
WIRESHARK
Wireshark может:
- Wireshark может расшифровать зашифрованные данные, если дать ему нужную ключевую информацию (например, дав ему пароль от Wi-Fi для WEP/WPA сети, IPsec, SSL/TLS-сессии).
https://habrahabr.ru/company/billing/blog/261301/
http://costiser.ro/2016/07/07/overlay-tunneling-with-openvswitch-gre-vxlan-geneve-greoipsec/
Here is the full packet capture, but of course, as it's IPsec, you will only see the outer IP header (192.168.56.11 and 192.168.56.12), while the payload (GRE/ETH/IP/ICMP) is encrypted and you only see ESP information. But if you use Wireshark, you can provide the keys and it will decrypt it for you.
- Найти пароль в протоколах, не использующих шифрование (telnet, snmp, http, SIP/RTP, etc). Причем по follow tcp stream можно посмотреть весь текстовый обмен – красным отправленные данные, синим полученные (дубли для некоторых т.к. сервер подтверждает прием от клиента символов).
- Собрать телефонный VoIP звонок из stream
- Можно посмотреть задержку в stream
- Собрать файл из stream SMB/FTP/HTTP/DICOM/etc – в wireshark можно экспортировать из payload пакеты, в том числе потенциально опасные в виде исполняемых файлов (exe, dll, etc)
- Собрать страницу из HTTP пакетов (follow TCP stream)
- Легко посмотреть задержку между пакетами – delta time.
In Wireshark Preferences / Appearance / Columns you can add a new column of type Delta time. With this new column and wise capture filtering you should be able to do what you want.
- В Wireshark есть выгрузка object из дампов – можно картинки просмотренного сайта выгрузить, страницы html
- Можно искать запросы к определенным URL (можно и в tcpdump, но проще куда в акулке)
-
В wireshark можно добавить вывод информации geoip, что позволит сразу в дампе видеть страны/ASN
-
В wireshark можно добавить вычисление fingerprint ssl с использованием JA3 (подробнее о ja3 в security)
- Продуманный интерфейс: Сразу можно посмотреть и HEX и ASCII репрезентацию данных, отсортировать пакеты, увидеть проблемы по цвету, отфильтровать вывод и прочпроч
Wireshark не только с точки зрения удобства использования лучше tcpdump, он считается и намного более мощным инструментом в сравнении с ним, особенно когда идет вопрос в анализе уровня приложений (поддержка более 2к протоколов, даже таких как USB/Bluetooth/Zigbee). Так же использует libpcap. Кроме того у Wireshark есть консольная утилита tshark (terminal-shark), которая часто позволяет обойтись без tcpdump вовсе (сори, tcpdump), но при больших нагрузках (гигабит и более фреймами 64 байта) нужно учитывать, что tshark хуже по производительности в сравнении с tcpdump. Например, можно использовать фильтры, аналогичные wireshark в консоли.
tcpdump is a command line utility, while wireshark has a powerful graphical interface. While tcpdump understands some application-layer protocols, wireshark expands on this with a much larger complement of protocols understood.
Фильтры
Фильтры бывают двух видов:
- display filters – применяемые на уже захваченный трафик, чаще всего используются именно они
- capture filters – применяемые при перехвате трафика, используются при больших объемах данных или заведомо зная, что мы ищем в трафике. Синтаксис capture filters отличается от display filters, но соответствует синтаксису tcpdump.
Очень полезная вещь, которая позволяет не знать синтаксис:
- apply as a filter – применяешь нажав ПКМ по информации из полей пакетов или по самому пакету в brief view. Причем
- можно выбрать как подпадания (Selected), так и все записи, которые отличаются от нашей (Not Selected)
- можно дополнять фильтр другими полями, используя между выражениями булевую логику (and/or selected, not/or selected)
- conversational filter – позволяет показать только взаимодействие двух участников на каком-либо уровне адресации. Очень удобно. К примеру, находим все пакеты между 15.1.1.2 15.1.1.1 с использованием номеров портов 11451 и 179.
- drag and drop (новые версии) – тянешь любое значения из поля любого пакета и тебе просто показывается синтаксис (можешь дотянуть до фильтра или просто узнать, что нужно вводить в нем)!
# GENERAL/MISC
dhcp # user insted bootp nbns # netbios http.request or !(ssdp) # вместо or можно использовать || kerberos.CNameString kerberos.CNameString and !(kerberos.CNameString contains $) # вместо and можно использовать && http.request.uri matches "q=example"
tcp.srcport==8000
# ADDR
ip.addr == 192.168.0.0
ip.src == 192.168.0.0
ip.dst == 192.168.0.0
ipv6.addr ip.addr == 192.168.0.1 or not tcp.port in (80 25)
eth.addr == ff:ff:ff:ff:ff:ff
# NETS
ip.src==192.168.0.0/16 and ip.dst==192.168.0.0/16 # traffic inside LAN (между сетями)
# CONTENT
frame contains "HTTP/1.1 200 OK"
frame contains 06:03:55:1d:0e:04 # CONTENT (данные любого уровня во фрейме)
udp contains 81:60:03 # данные в UDP (поиск делается как в header, так и в payload)
tcp contains 03:00:00
or
tcp.payload == 03:00:00
not (frame contains "!0123456789!") and frame.len == 519 # булева логика (boolean or/and/not)
# IP
ip.flags.mf == 1 or ip.frag_offset gt 0 # фрагментированные пакеты (fragmented ip packets)
# TCP
tcp # оставляем только фреймы, в которых инкапсулирован TCP
tcp.port == 3389
tcp.window_size == 0 && tcp.flags.reset != 1 # TCP buffer full - source is instructing Destination to stop sending data
tcp.window_size_value != 2497
# TCP FLAGS
tcp.flags.syn == 1
tcp.flags.reset == 1
tcp.flags.fin == 1
# TCP EXPERT WINDOW
expert.message == "Out-Of-Order segment"
expert.message == "Duplicate ACK (#1)"
tcp.analysis.retransmission
tcp.analysis.duplicate_ack_frame
# HTTP
Http.time > 1 # смотрим задержки ответа по HTTP
# BGP
bgp.open.identifier # смотрим open сообщения с полем BGP identifier в нем
bgp.update.path_attribute # смотрим update сообщения с полем path_attribute в нем
# OSPF
ospf.area_id = 0.0.0.0
# SSH
not port 22 # полезно для отброса управляющего коннекта
# ICMP
icmp # полезно для просмотра только icmp пакетов (ping)
# WIFI handshake
# в дампе должны быть все четыре сообщения eapol key (Message 1-4 to 4)
# тут есть sh скрипт по извлечению https://miloserdov.org/?p=1047
# напр. wlan.addr==28:28:5D:6C:16:24
wlan.fc.type_subtype == 0x08 || wlan.fc.type_subtype == 0x05 || eapol && wlan.addr == BSSID
# TSHARK example (Y - display filter)
tshark -r dump.pcap -Y "(ip.src == 172.17.0.2)"
tshark -r dump.pcap -nn -e ip.src -e eth.src -Tfields | grep ^172. | sort -u # извлекаем уникальные связки SRC & DST IP с адресацией 172.x.x.x
Профили (profiles)
Можно создать разные профили под разные задачи – default_with_time_diff, Multicast, VOIP, RIP/OSPF/BGP/etc. В профилях будут уникальные настройки интерфейса – zoom, расположение панелей, шрифты (размер, цвета), можно добавить уникальные столбцы (тот же timediff только в отдельном профиле).
RTT
statistics -> tcp stream graph -> round trip time
VoIP
- sngrep это утилита для анализа SIP/VoIP трафика в консоли Linux сервера.
- Wireshark очень полезен для диагностики VoIP.
Заходим в контекст Telephony, выбираем VoIP Calls. Видим звонки успешные и не очень. Так же видим и активные звонки.
Выбрав звонок и нажав на Flow Sequence можно посмотреть наглядно весь процесс согласования.
А по Play Streams можно даже прослушать звонок (если он успешен и поддерживается кодек, как тут G.711A), через встроенный в акулу RTP player. Круто!
Разговор в VoIP состоит из двух unicast RTP потоков – один от src до dst, второй от dst до src. По analyse можно посмотреть детальные данные (max jitter, RTP packets, lost, etc) по каждому потоку.
Пример дампа с разговором (из курса GNS3 Wireshark: Packet Analysis and Ethical Hacking: Core Skills). Для прослушивания RTP потока нужно сделать decode as по одному из UDP пакетов разговора и выбрать протокол RTP для интерпретирования.
Время
В настройках просмотра можно выбрать формат времени – например, не на основе старта снятия дампа, а реальное время с датой.
Статистика
В разделе statistics можно узнать кучу разных вещей (только часть):
- общая статистика по файлу, эту статистику можно получить используя консольную утилиту capinfos от Wireshark:
- дата/время первого и последнего пакета
- размер дампа
- количество пакетов
- время съема трафика
- средний pps, packet size, bits/s
Установка:
apt install wireshark-common
capinfos -z /home/user/*.pcap # average packet size
capinfos /home/user/test.pcap | tail -n 1 # dump packet count
# capinfos dump.20130621.cap
File name: dump.20130621.cap
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: Linux cooked-mode capture
Number of packets: 2000
File size: 2065933 bytes
Data size: 2033909 bytes
Capture duration: 43 seconds
Start time: Fri Jun 21 17:45:06 2013
End time: Fri Jun 21 17:45:49 2013
Data byte rate: 46968.49 bytes/sec
Data bit rate: 375747.94 bits/sec
Average packet size: 1016.95 bytes
Average packet rate: 46.19 packets/sec
- распределение по протоколам в protocol hierarchy, причем можно посмотреть на эти данные в самом дампе, применив стандартный Apply as a filter в статистике
- по размерам пакетов в packet lengths
- найти top talkers в endpoints (MAC, IP4/6, UDP, TCP)
- проанализировать взаимодействие между хостами по объему трафика в conversations (MAC, IP4/6, UDP, TCP)
- проанализировать взаимодействие между хостами по передаваемым сообщениям (транзакциям), сохраняя их последовательность в flow graph. Очень удобно, что используя стандартный фильтр можно посмотреть конкретное взаимодейтсвие (в статистике прожать “Limit to display filter”) – к примеру ниже отфильтрованное взаимодействие только по DHCP.
tcpdump
- tcpdump по практике является самым производительной утилитой – в сравнительных тестированиях с wireshark, tshark, windump только он смог захватить 64 byte frame на 1G line rate (порядка 1.5 МЛН PPS)
- производительность tcpdump можно повысить правильной конфигурацией
- запись в файл, не на экран
- увеличение размера буфера
- использование фильтров для пакетов – чем меньше захватываем ненужного, тем больше можем захватить нужного
- -p/–no-promiscuous-mode отключение promiscous mode
- использование фильтров захвата (ниже примерыф) напр. захватываем только TCP трафик
- использование nice для повышение приоритета процесса
- использование ramdisk для запись в RAM, а не HDD/SSD
# mkdir /tmp/ramdisk
# mount -t tmpfs -o size=1000m tmpfs /tmp/ramdisk/
# nice --adjustment=-10 tcpdump -s 1514 -i eth2 -w /tmp/ramdisk/ecg_sniffer_eth2_20180321.pcap
-
- snaplen (чем меньше, тем лучше) – tcpdump поддерживает захват только части пакета, что увеличивает его производительность и уменьшает накладные расходы по памяти для хранения дампов. К примеру, можно захватывать только 96 байт пакета IPv4 или 114 байт пакета IPv6 (snaplen, -s) и таким образом получить захват всех header без большей части payload (в средней реальной сети). Кроме того можно дополнительно обработать перехваченный трафик утилитой TraceWrangler (подробнее и альтернативы в разделе анонимизация ниже), которая удалит payload в том числе из пакетов, которые его содержат.
tcpdump -i eth0 -s 98 -w traffic.pcap # IPV4
tcpdump -i eth0 -s 114 -w traffic.pcap # IPV6
tcpdump -i eth0 -s 50 -w traffic.pcap # SRC+DST+PROTO
Both tcpdump and tshark/dumpcap use the "-s" option to limit the amount of data captured (snap length).
It is better to capture with at least "-s 94" for IPv4 or "-s 114" for IPv6 and then post process the trace file with tracewrangler to remove the data above TCP without damaging the TCP header then to capture with a smaller snaplen.
I was in the same situation and I solved it by adding -s 96. In this example i'm using 96 to be "almost" sure that I would capture 100% of ethernet+ip+(icmp || udp || tcp) header values.
tcpdump -ieth0 -s96 -w traffic.dump 'ip or icmp or tcp or udp'
If you just need Time, Source, Destination, Protocol. It work for me using
tcpdump -i $INTERFACE -n -s 50
- tcpdump – по сути консольная версия Wireshark/Tshark. Дампы tcpdump, кстати, читаются легко Wireshark, что делает его очень полезной утилитой
- tcpdump может не запускаться при записи дампа в файл, если использовать расширение отличное от pcap (потенциально проблема из-за SE Linux)
tcpdump -w 5345345.pcap
tcpdump: listening on enp7s0, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump -w 5345345.cap
tcpdump: 5345345.cap: Permission denied
tcpdump -w 5345345.test
tcpdump: 5345345.test: Permission denied
- tcpdump поддерживает BPF фильтры, захватывая копию необходимого трафика из ядра системы
-
tcpdump (да и wireshark) может дропать трафик при большом объеме. Главное узкое место – скорость ЖД. Сделал несколько генераций одного трафика. В первом pcap меньше данных и нет всех пакетов если открыть в Wireshark. При этом все пакеты пришли по назначению во все итерации.
-rw-r--r-- 1 root root 830277116 янв 01 10:29 test_1.pcap
-rw-r--r-- 1 root root 830356104 янв 01 10:33 test_2.pcap
-rw-r--r-- 1 root root 830356104 янв 01 10:44 test_3.pcap
-rw-r--r-- 1 root root 830356104 янв 01 10:56 test_4.pcap
-rw-r--r-- 1 root root 830311550 янв 01 10:59 test_5.pcap - Полное или частичное отсутствие пакетов в дамп-файле при наличии их в GUI выводе может говорить о потерях пакетов на уровне жесткого диска – у меня при подобных симптомах наблюдался дефицит памяти
bash-4.2# tcpdump -n -i eth3 -w test.pcap
tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
258673 packets captured
258673 packets received by filter
0 packets dropped by kernel
А в дампе по факту 0 пакетов.
bash-4.2# tcpdump -r test.pcap
tcpdump: truncated dump file; tried to read 4 file header bytes, only got 0
- Tcpdump работает на почти любые типы интерфейсов, которые идентифицируются системой (не DPDK): sub интерфейсы, bridge интерфейсы, туннельные интерфейсы и даже loopback
tcpdump -n -i eth1.855
tcpdump -n -i bridge0
tcpdump -n -i utun0
tcpdump -n -i lo0
- Tcpdump может при старте не показывать какое-то время наличие пакетов на интерейсе, особенно если не отключен DNS resolve через -n
tcpdump -i enp2s0 -n
- При передаче файлов с дампами по сети, всегда нужно учитывать, что Wireshark/tcpdump не ужимают дампы, а после сжатия обычным zip/rar файл может весить в десятки раз меньше (gzip c 800MB до 50MB, 7z c 800MB до 20MB).
tcpdump использует open source libpcap библиотеку. Показывает (STDOUT) по умолчанию данные в terminal. Может писать в файл дамп или читать из файла. По умолчанию показывает brief информацию в удобном для человека формате – IP адреса там например через точку или по умолчанию он даже делает reverse lookup (PTR) или номера портов подменит на сервисы, но конечно все равно не так удобно как Wireshark.
Tcpdump is a popular, lightweight command line tool for capturing packets and analyzing network traffic.
tcpdump требует прав админа для запуска. Минимум ему нужно скормить название ip интерфейса через опцию -i (узнать его можно через ifconfig/ip link). По результату будет показана статистика. По умолчанию будет показана базовая инфа – layer 3 protocol, source, and destination addresses and ports, TCP details, like flags, sequence and ack numbers, window size, and options.
Head's up that tcpdump does require root or administrator privileges in order to capture traffic, so every command must begin with sudo. At a minimum, you must specify an interface to listen on with the -i flag. You may want to check what the primary network interface name is using ip link.
~$ tcpdump host 8.8.8.8 tcpdump: no suitable device found ~$ sudo tcpdump host 8.8.8.8 [sudo] password for <user>: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
Опции (подробнее в man tcpdump):
-U # отключаем буфферизацию дампа в пользу "записывать сразу"
-D # смотрим список интерфейсов на которых возможен захват
-i [if] # название прослушиваемого интерфейса, сразу после интерфейса можно указать еще что-то, например port 80, тогда вывод будет фильтроваться сообщениями только port 80 на этом интерфейсе -e # показать MAC адреса (ethernet адреса) в выводе -n # не резолвим IP в FQDN, номера портов в сервисы -w [filename.pcap] # сохраняем захваченное в binary файл -r [filename.pcap] # читаем файл (можно без прав sudo), причем можно указывать те же опции, что при обычном захвате (-v для большего вывода, -n для фильтрации, etc) -v # более детальная инфа (details of the IP header, like time-to-live, IP ID number, IP options, and IP flags) -x # показываем raw data (payload) -X # ASCII вид данных
-c # выход при получении определенного количества пакетов, особенно полезно когда трафика ожидается большое количество или когда мы переживаем за состояние системы из-за работы tcpdump
Есть поддержка фильтров, как базовых, так и довольно сложных (напр. L4). Возможна комбинация фильтров (см. usage).
vlan [N] - фильтруем по номеру VLAN (при наличии SVI)
|src|dst| host [ip] - указываем чтобы в содержимом был IP (DST/SRC), можно управлять будет он SRC|DST или оба (без опций)
|src|dst| network [ip/prefix] - указываем чтобы в содержимом был трафик определенной сети, можно управлять будет он SRC|DST или оба (без опций)
port [N] - TCP/UDP port
portrage [N-N] - TCP/UDP portrange
greater [N] - указываем размер пакета
timeout [N] <command> - запуск только на определенное время
tcp[tcpflags] == tcp-syn - пример L4 фильтра
and|or|not - можно комбинировать филтьтры булевой логикой (boolean)
Usage:
# СПИСОК интерфейсов
# sudo tcpdump -D
1.enp7s0 [Up, Running]
2.any (Pseudo-device that captures on all interfaces) [Up, Running]
3.lo [Up, Running, Loopback]
4.enp8s0 [Up]
5.nflog (Linux netfilter log (NFLOG) interface)
6.nfqueue (Linux netfilter queue (NFQUEUE) interface)
7.usbmon1 (USB bus number 1)
8.usbmon2 (USB bus number 2)
9.usbmon3 (USB bus number 3)
10.usbmon4 (USB bus number 4)
# БАЗОВЫЙ ЗАХВАТ $ sudo tcpdump -i eth0 20:44:29.087535 IP linux-instance.c.qwiklabs-gcp-c7fbce528931fd28.internal.ssh > test.net.54895: Flags [P.], seq 419056:419280, ack 4961, win 285, length 224 20:44:29.103033 IP test.net.54895 > linux-instance.c.qwiklabs-gcp-c7fbce528931fd28.internal.ssh: Flags [P.], seq 4961:5025, ack 402400, win 1020, length 64 1951 packets captured 2001 packets received by filter 50 packets dropped by kernel
# ЗАХВАТ только заданное количество секунд
$ sudo timeout 5 -n host 1.1.1.1 and port 80 and greater 1000
# ЗАХВАТ с завершением по получению хоть одного пакета
$ sudo tcpdump -c 1 -n host 1.1.1.1 and port 80 and greater 1000
# ЗАХВАТ только TCP-SYN трафика определенного хоста (src & dst)
$ sudo tcpdump -n host 1.1.1.1 and tcp[tcpflags] == tcp-syn # ЗАХВАТ В PCAP $ sudo tcpdump -i eth0 port 80 -w http.pcap # This starts a capture on our eth0 interface that filters for only HTTP traffic by specifying port 80. The-wflag indicates that we want to write the captured packets to a file namedhttp.pcap$ curl example.com $ ls -lh http.pcap -rw-r--r-- 1 root root 9.3K Feb 19 21:16 http.pcap $ tcpdump -r http.pcap -nv # Note that we don't need to usesudoto read packets from a file. Also note that tcpdump writes full packets to the file, not just the text-based analysis that it prints to the screen when it's operating normally. For example, somewhere in the output you should see the html that was returned as the body of the original query in the other terminal # С ФИЛЬТРАМИ на DNS 8.8.8.8 ~$ sudo tcpdump -i eth0 -vn host 8.8.8.8 and port 53 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 21:02:36.484819 IP (tos 0x0, ttl 64, id 32534, offset 0, flags [none], proto UDP (17), length 68) 10.0.0.2.40596 > 8.8.8.8.53: 64482+ [1au] A? example.com. (40) 21:02:36.486077 IP (tos 0x0, ttl 115, id 11509, offset 0, flags [none], proto UDP (17), length 84) 8.8.8.8.53 > 10.0.0.2.40596: 64482$ 1/0/1 example.com. A 93.184.216.34 (56) Host 8.8.8.8 specifies that we only want packets where the source or destination IP address matches what we specify (in this case 8.8.8.8). If we only want traffic in one direction, we could also add a direction qualifier, like dst or src (for the destination and source IP addresses, respectively). However, leaving out the direction qualifier will match traffic in either direction. Next, the port 53 portion means we only want to see packets where the source or destination port matches what we specify (in this case, DNS). These two filter statements are joined together with the logical operator "and". This means that both halves of the filter statement must be true for a packet to be captured by our filter. $ dig @8.8.8.8 A example.com ; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8 A example.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64482 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 6385 IN A 93.184.216.34 ;; Query time: 1 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Feb 19 21:02:36 UTC 2019 ;; MSG SIZE rcvd: 56 # читаем файл $ tcpdump -r <file> # читаем файл и фильтруем вывод только udp пакетами $ tcpdump -r <file> udp
packetdump
Сбор и сохранение в компрессированном pcap с ротацией каждый час.
packetdump -i eth0 -G 3600 -w foo-%y%m%d-%H%M%S.pcap.lz4
Читаем последние логи для интерфейса:
packetdump collected-info-eth1 dump_text.txt
This is a high-speed (10gig) packet-sniffer that compresses packets as it writes to disk. I wrote it because the packet logging features of tcpdump are slow, but extra special slow when attempting to compress files after they've been written uncompressed to the disk when rotating files.
Python + pyshark
подробнее в python.
Редактирование
PYTHON + SCAPy
Самый удобный способ когда нужно сделать более чем одно действие по изменению сетевых дампов. Легко можно сделать даже непростые операции, например, заменить все сетевые (MAC, IP, PORT) адреса в дампе на другие, IPv6 header на IPv4. Замена IPv6 header на IPv4 подразумевает извлечение payload, создание IPv4 header, добавление в него payload, пересчет checksum и length (см. в HEX EDITORS).
Подробнее в python поиском по scapy.
HEX READER and WIRESHARK
Извлекаем из записанных byte файлов вывод для сопоставления с Wireshark.
hexdump -C aggregated.bytes # получение вывода like Wireshark Hex Dump
xxd -b aggregated.bytes # в бинарном виде
hex editors
Самый хардкорный 🙂 способ изменения дампов. Подразумевает и пересчет checksum, тут может помочь tcprewrite.
К примеру, c помощью hex editor ipv6 header заменить на ipv4 не так просто (особенно, в сравнении со python + scapy):
1) изменяем hex строку. Много разных способов, хорошо с gif описано тут.
https://hexed.it/
vim
:%!xxd # преобразуем в hex данные и превращаем vim в hex editor
2) после изменения нужно использовать pcapfix (причина однозначно непонятна, возможно, разрушается структура при экспорте)
pcapfix -d test.pcap
[+] CORRECTED Packet #1 at position 24 (1566304697 | 904775 | 74 | 74).
[!] This corruption seems to be a result of an ascii-mode transferred pcap file via FTP.
[!] The pcap structure of those files can be repaired, but the data inside might still be corrupted!
[+] SUCCESS: 1 Corruption(s) fixed!
3) IPv6 header меняется от пакета к пакету, даже с учетом совпадения адресов SRC/DST – flow label в пакетах дампа зачастую разный, payload length так же разный; поэтому при массовой замене нужно заменять в HEX с помощью regexp
4) IPv4 header должен иметь корректный total length от IPv4 header + payload; т.е. при каждой замене нужно корректировать total length для каждого пакета, иначе пакет будет отбрасываться еще на уровне ядра ОС (Linux, Windows)
15:38:17.904775 IP 7.7.7.7.49474 > 192.168.0.1.8000: Flags [S] [bad hdr length 40 - too long, > 32]
[Malformed Packet: TCP: length of contained item exceeds length of containing item]
5) Checksum может не пересчитываться tcprewrite с segmentation fault (помог запуск tcprewrite на другой VM)
# tcprewrite --fixcsum --infile=test.pcap --outfile=test_new.pcap
Ошибка сегментирования
И все это нужно делать для всех пакетов в дампе.
tcprewrite
Хороший, хотя и базовый, редактор дампов.
- Usage
- Ставится совместно с последним tcpreplay (apt-get install tcpreplay)
- Если воспроизвести корректно дамп с icmp request (dst ip) хост, на который прилетит трафик, может ответить icmp reply. Аналогичное справедливо и для любых других серверных приложений.
Change MAC
tcprewrite --enet-dmac=2c:56:dc:72:08:39 --infile=UDP_original.pcap --outfile=UDP_changed_dst.pcap
Change IP
Можно менять по net/mask, если не использовать опцию -fixsum, то чексумма может не пересчитаться.
tcprewrite --srcipmap=127.0.0.1:7.7.7.7 --dstipmap=127.0.0.1:192.168.0.1 --infile=test.pcap --outfile=test_without_loo.pcap
tcprewrite --fixcsum --dstipmap=0.0.0.0/0:172.17.0.2 --infile=UDP_changed_dst.pcap --outfile=UDP_changed_dst_mac_ip.pcap
tcprewrite --fixcsum --srcipmap=0.0.0.0/0:172.0.0.2 --infile=UDP_changed_dst_mac_ip.pcap --outfile=UDP_changed_dst_mac_ip_src_ip.pcap
bittwist/bittwiste
Хорошие, но старые утилиты для воспроизведения/генерации трафика (bittwist) и редактирования pcap (bittwiste). Bittwiste не поддерживает IPv6.
This removes (-D) the frame IP-, UDP- and GTP-Header. Result: The encapsulated IP header will be the new frame IP header ;-) Maybe you'll have to adjust the number of stripped bytes for your environment (IP Options).
bittwiste -I gtp-u.pcap -O gtp-stripped.pcap -D 15-54
Может помочь удалить лишние инкапсуляции
802.1Q VLANs, MPLS, GRE and PPPoE, L2TP,VXLAN
./stripe -r mpls-frames.cap -w clean-frames.cap
dsniff
старая хакер-утилита, по сути “wireshark” который показывает только payload открытых протоколов в перехваченном трафике и вычленяет оттуда явки-пароли.
WireEdit
Хороший продукт для редактирования pcap. У самого Wireshark была beta с возможностью edit, но видимо дальше беты не зашло.
С помощью WireEdit в пару кликов можно поменять любые поля (в том числе массовые замены) и пересчитать checksum. Требует лицензию (высылают на почту при регистрации, сейчас с этим стало сложнее).
Продукт развивается, пример добавлений в новом релизе:
--------------------------------
11/01/19 WireEdit 2.10.54
--------------------------------
1)* DOCSIS 3.1 support added. Needs more work, usable as is.
2)* VRRP support added.
3)* Mobile Core (SS7, GTP, GSM MAP, DIAMETER, etc.) support added.
SPLIT PCAP
Разбиваем крупный pcap на несколько дампов по 100 MB (tcpdump).
sudo tcpdump -r ~/3.pcap -w /tmp/new3.pcap -C 100
Разбиваем крупный pcap на несколько дампов по миллиону пакетов (editcap).
sudo editcap -c 1000000 ch5.pcap out.pcap
editcap + mergecap
Поменять order пакетов можно с помощью editcap + mergecap. Сначала с помощью edit создаем pcap с отдельными пакетами из необходимого дампа, потом merge’им с помощью mergecap.
https://stackoverflow.com/questions/12741079/how-to-edit-wireshark-pcap-to-change-the-order-of-packets
editcap -r in.pcap tmp1 2-3
editcap -r in.pcap tmp2 1
editcap -r in.pcap tmp3 4-6
mergecap -w out.pcap -a tmp1 tmp2 tmp3
Воспроизведение
pfsend
pfsend позволяет создавать большую нагрузку в сравнении с tcpreplay без кастомизаций (netmap, preload). Основан не на netmap/DPDK, а на pfring.
pfsend -i zc:eth1 -n 0 -f test.pcap
Tcpreplay
- По практике если нужен рigh performance – TRex может быть более производителен, в том числе на пакетах небольшого размера (в тесте это чуть более 100 байт). В данном случае возможно была проблема с разной версией драйверов для сетевых карт (пример ниже для X710) – TRex мог использовать более актуальные драйвера в сравнении с netmap.
- 1 gbps tcpreplay + netmap
- 5 gbps TRex (ideal dump repeat), 10 gbps (not ideal dump repeat)
- Размер пакетов важен, но это очевидно 🙂
Q: Why doesn't Tcpreplay send traffic as fast as I told it to?
Usually this occurs when trying a pcap of small packets.
- Про promiscuous режим можно почитать тут. Хотя мне не понадобилось его включение. Чаще всего сетевые утилиты, снимающие трафик с интерфейса, его включают сами.
Tcpdump start/stop
[ 1691.019004] device eth0 entered promiscuous mode
[ 1699.783211] device eth0 left promiscuous mode
-
- (tcpdump/bmon-nload/ifconfig) Трафик может не фиксироваться на интерфейсе в счетчиках и соответственно в утилитах bmon/nload, которые строят графики на основе счетчиков. Причина отсутствия счетчиков может быть не отсутствие трафика, а необходимость перевода интерфейса в promisc режим. Проверить можно tcpdump – он это делает автоматически.
# ifconfig [interface] promisc
# ip link set [interface] promisc on
8: enp5s0f0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether d4:5d:64:bd:89:13 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1/16 scope global enp5s0f0
alid_lft forever preferred_lft forever - Основной недостаток – stateless. Полноценного TCP нет.
- Есть fragroute движок, по умолчанию отключен – с его помощью можно сфрагментировать пакеты проигрываемого дампа трафика перед отправкой в сеть в соответствии с конфигурацией fragroute.conf
# cat fragroute.conf
ip_frag 24 new
order random
dup random 10
-
По практике Tcpreplay при проигрывании pcap в петле (loop) даже в случае ограничения собственной производительности и/или канала (line rate) всегда генерирует ожидаемое количество пакетов – т.е. гарантируется проигрывание всех пакетов из pcap с повторением в соответстии с количеством loop, несмотря на то, что заданная целевая скорость не гарантируется.
-
Tcpreplay по умолчанию (без указания скорости проигрывания) стремится повторить pcap с точки зрения задержек между пакетами и уложить все за время снятия дампа!
Wireshark
Measurement
Captured
Packets 1585
Time span, s 130.900
Average pps 12.1
Average bytes/s 5691
TCPREPLAY
tcpreplay -i enp3s0f1 --preload-pcap --netmap test.pcap
Switching network driver for enp3s0f1 to netmap bypass mode... done!
File Cache is enabled
Actual: 1585 packets (744982 bytes) sent in 130.90 seconds
Rated: 5690.9 Bps, 0.045 Mbps, 12.10 pps
Successful packets: 1585
Описание:
tcpreplay - Replay network traffic stored in pcap files
tcpreplay is a tool for replaying network traffic from files saved with tcpdump or other tools which write pcap(3) files.
Использовать легко:
tcpreplay -i eth0 sample.pcap
# performance (так же смотри ниже - объем и taskset)
tcpreplay -i eth0 --topspeed --preload-pcap sample.pcap# можно указать, что работать нужно с максимальной скоростью генерации (по умолчанию не с максимальной, а на той, на которой записан pcap с сохранением тайминга между пакетами) и выгружать pcap в RAM для ускорения (по практике прирост может быть до трех раз или не быть вовсе)
tcpreplay -i eth0 -p 669642 --preload-pcap sample.pcap # можно указать конкретный pps
# loop, duration
tcpreplay -i eth0 --loop=1000 sample.pcap # повтор воспроизведения
tcpreplay -i eth0 --loop=1000 --duration=100 sample.pcap # повтор воспроизведения, но не более 100 секунд
# directory
tcpreplay -i eth0 --topspeed --loop=1000000000000 *cap* # воспроизводим все дампы в директории с максимальной скоростью (без предварительной загрузки в RAM)
# settings
tcpreplay --listnics # команда может не показывать по факту интерфейсы, которые может использовать. В моем случае была бесполезной (как promiscuous режим).
# version (как собрана утилита)
# tcpreplay -V
tcpreplay version: 4.3.1 (build git:v4.3.1) (debug)
Copyright 2013-2018 by Fred Klassen <tcpreplay at appneta dot com> - AppNeta
Copyright 2000-2012 by Aaron Turner <aturner at synfin dot net>
The entire Tcpreplay Suite is licensed under the GPLv3
Cache file supported: 04
Not compiled with libdnet.
Compiled against libpcap: 1.8.1
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Packet editing: disabled
Fragroute engine: disabled
Injection method: PF_PACKET send()
Not compiled with netmap
performance tuning results
4.5KB-HTTP.pcap
Производительность с netmap & preload-pcap: 4768.55 Mbps
Производительность без netmap: 2434.93 Mbps
Производительность без netmap & preload-pcap: 2079.60 Mbps
44KB-HTTP.pcap
Производительность с netmap & preload-pcap: 8055.77 Mbps
Производительность без netmap: 4473.61 Mbps
Производительность без netmap & preload-pcap: 3435.65 Mbps
dump size
Не только preload/nemap помогают увеличить создаваемую нагрузку, но даже простое уменьшение дампа. Причем прирост после уменьшения может быть больше чем прирост от использования preload. К примеру – уменьшил дамп с 3GB до 300MB (аналогично и для 100MB) – прирост нагрузки в 5 раз. Добавил preload-pcap – прирост в 6 раз (по сравнению с первоначальной нагрузкой).
Rated: 167814425.8 Bps, 1342.51 Mbps, 118685.07 pps
Rated: 552510175.3 Bps, 4420.08 Mbps, 390921.39 pps
Rated: 750648600.3 Bps, 6005.18 Mbps, 531111.74 pps
объем памяти
Причем на множество файлов tcpreplay открывает их все сразу – для preload в таком случае нужен большой объем оперативной памяти. Прирост при этом в генерируемой нагрузке не факт, что будет высокий.
tcpreplay -i enp3s0f1 --topspeed --loop=1000000000000 --preload-pcap *pcap
Rated: 291740421.8 Bps, 2333.92 Mbps, 590406.88 pps
tcpreplay -i enp3s0f1 --topspeed --loop=1000000000000 *cap
Rated: 214934733.2 Bps, 1719.47 Mbps, 427457.74 pps
процессор и сетевая карта
Производительность генерации может быть так же увеличена за счет использования более производительного процессора и сетевых карт (напр. Intel X710 вместо Intel X520). В реальных тестах прирост до +30, несмотря на то, что обе сетевые карты 10G capable.
Кроме того на практике на производительность очень значительно может влиять драйвер сетевой карты – на старых драйверах X710 (i40e) производительность была до 2 раз ниже в сравнении с актуальными драйверами в совокупности с периодическим зависанием netmap.
разные cpu и количество процессов tcpreplay
Из интересного в контексте performance так же
- Taskset/affinity/pinning двух процессов tcpreplay по разным ядрам CPU зачастую увеличивает суммарную нагрузку т.к. tcpreplay процесс работает только на одном ядре CPU. Так же на практике даже однопоточный tcpreplay может работать более производительно при использовании pinning (до 5 раз!) и медленнее без него. Но бывало и обратное для других дампов, когда pinning приводил к деградации в сравнении с “без pinning”, хотя и негативное влияние не настолько значимо – до -30%, а не нескольких раз.
- tcpreplay netmap - 850 Mbps
- tcpreplay no netmap - 400 Mbps
- tcpreplay no netmap multiple process (one cpu) - 200 Mbps
- tcpreplay no netmap multiple process (multiple cpu) - 550 Mbps
Since tcpreplay is not multi-threaded, SMP or dual-core processors won’t help very much. However, other processes can run on the other CPU(s).
Turn off hyperthreading (HT) if your CPU supports it.
# Можно напрямую указать конкретный CPU (affinity), range или list (man taskset --cpu-list 0-2,6)
taskset --cpu-list 1 /root/redkin/tcpreplay-master/src/tcpreplay -i enp3s0f1 --topspeed --loop=1000000000000 --duration=600 --preload-pcap /root/redkin/test.pcap &
taskset --cpu-list 2 /root/redkin/tcpreplay-master/src/tcpreplay -i enp3s0f1 --topspeed --loop=1000000000000 --duration=600 --preload-pcap /root/redkin/test.pcap &
- Параллельный запуск нескольких tcpreplay без контроля ядер (“на удачу”) taskset/affinity на одном интерфейсе так же, соответственно, может увеличивать генерируемую нагрузку – напр. запуск 10 instance приложения может иметь суммарную производительность незначимо выше (в среднем менее 10%) в сравнении с запуском 1 instance netmap (а в тестах выше netmap вообще выигрывал). Запустить же несколько процессов с netmap не получится – запущенный процесс с netmap не позволит другим получить доступ к сетевой карте.
tcpreplay 6 сессий - tcpreplay с netmap (mbps)
3262 2811
2940 2711
2613 2808
10091 9688
10129 9689
10347 9677
10397 9842
10293 9842
10744 9841
tcpreplay-edit с fuzzing
- fuzzing так же возможен на базе tcpreplay-edit, scapy, isic
Может падать с segmentation fault (segfault) на какие-то дампы/каких-то сборках, так же как tcprewrite.
Запуск простейший, поддерживаются те же опции, что в “обычном” tcpreplay и дополнительные, например нужные нам fuzz-seed и fuzz-factor.
- fuzz-seed – seed value для рандомизации (random seed/repeatable random по аналогии с isic, TRex, Ixia IxNetwork)
- fuzz-factor – сколько пакетов подпадает под fuzzing (с единицей каждый пакет). При fuzz-factor=1 скорость генерации уменьшается (может в несколько раз!) т.к. утилите приходится менять каждый пакет.
./src/tcpreplay-edit -i eth0 --topspeed --loop=100 --fuzz-seed=1 --fuzz-factor=1 *
tcpreplay с netmap
Для high performance можно использовать tcpreplay с netmap (хотя и при большом кол-ве прорцессов производительность может быть выше netmap). Производительность в таком случае до line rate, что делает инструмент сопоставимым с commercial traffic generators на “обычных” сетевых картах.
--netmap
Write packets directly to netmap enabled network adapter.
This feature will detect netmap capable network drivers on Linux and BSD systems. If detected, the network driver is bypassed for the execution duration, and network buffers will be written to directly. This will allow you to achieve full line rates on commodity network adapters, similar to rates achieved by commercial network traffic generators. Note that bypassing the network driver will disrupt other applications connected through the test interface. See INSTALL for more information.
This feature can also be enabled by specifying an interface as 'netmap:<intf>' or 'vale:<intf>. For example 'netmap:eth0' specifies netmap over interface eth0.
По практике netmap дает вполне ощутимый прирост в генерации на 20-30% на 10G сетевых картах – напр. с 6 GBPS до 8-9. На 1G NIC может быть даже деградация, поэтому зачастую нет смысла на них использовать netmap.
As an aside, usually netmap is not required for GigE, especially with latest enhancements to checksum algorithms in 4.1.1. With some drivers such as e1000e I find it actually slows things down. It comes into play with 10GigE speeds and higher.
Сборка netmap.
https://github.com/luigirizzo/netmap
cd netmap-master
chmod -R 777 *
./configure
# alternate actual Intel X710 Drivers ./configure --select-version=i40e:2.17.4
make
sudo make install
cd tcpreplay-master
chmod -R 777 *
./configure --with-netmap=/path_to_netmap_dir/netmap-master
make
sudo make install
src/tcpreplay -V
Запуск tcpreplay с netmap.
Для запуска требуются установленные в ядро драйвера netmap (netmap.ko) и сетевой карты (напр. ixgbe.ko, igb.ko, igb_uio.ko, e1000e), иначе будет ошибка. Загружаем в ядро драйвер с помощью insmod.
Fatal Error: failed to open device eth0: Unable to determine the running netmap version.
sudo insmod netmap.ko
sudo insmod ixgbe.ko
Можно так же проверить lsmod, ls /dev/netmap. Просмотреть путь до всех модулей ядра/драйверов можно используя awk + xargs.
# lsmod | grep netmap
netmap 221184 14
# ls /dev/netmap
/dev/netmap
# awk '{ print $1 }' /proc/modules | xargs modinfo -n | sort
Выгрузить драйвер можно с помощью rmmod и modprobe.
rmmod netmap
modprobe -r netmap
Получить информацию о модуле (например, Linux kernel, на которой был собран модуль) можно с помощью modinfo. Модуль сильно зависит от ядра, поэтому по умолчанию не запустится на другом ядре. В теории может помочь функция -f для insmod, но по факту у меня она к успеху не приводила – были ошибки некорректного формата. В таком случае нужно пересобирать модуль для нового ядра.
modinfo netmap.ko
filename: /home/user/netmap.ko
license: Dual BSD/GPL
description: The netmap packet I/O framework
author: http://info.iet.unipi.it/~luigi/netmap/
alias: pci:v00001B36d0000000Dsv*sd*bc*sc*i*
alias: pci:v00001B36d0000000Csv*sd*bc*sc*i*
depends:
retpoline: Y
name: netmap
vermagic: 4.19.0-6-amd64 SMP mod_unload modversions
parm: priv_buf_size:int
parm: priv_buf_num:int
Enjoy.
./tcpreplay-master/src/tcpreplay -i eth0 --topspeed --loop=100 --preload-pcap --netmap *cap*
Switching network driver for eth0 to netmap bypass mode... done!
File Cache is enabled
Warning: Unable to send packet: User abort
Actual: 88828775 packets (125603887850 bytes) sent in 123.73 seconds
Rated: 1015128566.9 Bps, 8121.02 Mbps, 717912.70 pps
Statistics for network device: eth0
Switching network driver for eth0 to normal mode... done!
./tcpreplay-master/src/tcpreplay -i eth0 --topspeed --loop=100 --preload-pcap *cap*
File Cache is enabled
Actual: 33439919 packets (47284045466 bytes) sent in 66.10 seconds
Rated: 715276154.4 Bps, 5722.20 Mbps, 505853.00 pps
Statistics for network device: eth0
Анонимизация/anonymization/sanitization
https://www.tracewrangler.com
TraceWrangler is a network capture file toolkit running on Windows (or on Linux, using WINE) that supports PCAP as well as the new PCAPng file format, which is now the standard file format used by Wireshark. The most prominent use case for TraceWrangler is the easy sanitization and anonymization of PCAP and PCAPng files (sometimes called "trace files", "capture files" or "packet captures"), removing or replacing sensitive data while being easy to use.
Комплексные продукты
Moloch – система сбора/анализа/хранения/индексации дампов в формате pcap. Идея – не замена IDS, а максимальная видимость сети (network visibility). Сайт moloch. Использует elasticsearch для поиска в дампах. Может быть использован в Big Data, Forensics. Имеет api. Доступ к дампам на сенсорах может быть через WEB HTTPS или API, есть поддержка шифрования дампов. Проект активно развивается (last release буквально за месяц до написания этого текста). Использует java environment, могут быть проблемы с установкой и работой (удаление файлов).