PfSense и журналирование

Konstanti

@lucas1 Здр
Не проще использовать tcpdump для таких целей ?
Или из Webgui или из консоли ?
например , из консоли
tcpdump -nettti интерфейс tcp and src адрес хоста
эта команда отловит весь tcp трафик для телефона

или , например , можно упростить себе задачу
tcpdump -nettti интерфейс tcp and src адрес хоста and 'tcp[tcpflags] & tcp-syn !=0'

и запускаете приложение на телефоне и смотрите , на каких портах в этот момент устанавливаются соединения

Не забудьте поменять на нужные значения
1 адрес хоста
2 название интерфейса ( узнать можно командой ifconfig)

pigbrother

@Konstanti said in PfSense и журналирование:

Не проще использовать tcpdump для таких целей ?

Правильнее. Но не проще Если честно - про Webgui просто забыл, а просмотра states может и не хватить.

werter

Помещаю 2 телефона в правило для http _https(80,443) - они не заходят через приложение My.alfabank.

Вкл. до проверки Логирование fw и во время проверки отфильтровать прямо в Логах fw по src ip ваш телефон. Всё.

Зы. Скрин правил fw на ЛАН покажите.

Konstanti

@werter
а смысл ?
Ставим фильтр tcpdump из консоли
запускаем приложение
и voila ))) имеем инициализацию соединения
Проще поймать SYN пакеты tcpdump-ом , их будет совсем немного по сравнению с остальным трафиком .

werter

@Konstanti
Смысл в удобстве, простоте и скорости реализации решения.
Я за CLI , но не в этом случае )

lucas1

@werter
Про tcpdump - тоже забыл, сейчас буду пробовать.

Но до обеда смотрел и states и Status\System\ Logs\Firewall с фильтрацией Src IP - ничего кроме 80, 443 TCP не нашел.

Но выяснилось еще одно обстоятельство - с телефона приложения например skype,telegram, privat24 - работают, а facebook, my.alfabank - нет.

Правила простые.
tcp алиас_all_tcp * * *
tcp Lannet * * 80,443

Оба правила в одной очереди и на одном Gateway.

Konstanti

@lucas1 Должно получиться через tcpdump
Вот , например
для sberbank online что выдало

tcpdump -nettti igb1 tcp and src 192.168.1.42  and 'tcp[tcpflags] & tcp-syn !=0'

00:00:00.000000 00:be:3b:be:df:59 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.42.36334 > 54.243.122.227.443: Flags [S], seq 4204714693, win 65535, options [mss 1460,sackOK,TS val 5242220 ecr 0,nop,wscale 8], length 0
 00:00:00.488637 00:be:3b:be:df:59 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.42.58334 > 172.217.18.206.443: Flags [S], seq 1221189646, win 65535, options [mss 1460,sackOK,TS val 5242269 ecr 0,nop,wscale 8], length 0
 00:00:00.333044 00:be:3b:be:df:59 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.42.33462 > 194.54.14.132.443: Flags [S], seq 4186245391, win 65535, options [mss 1460,sackOK,TS val 5242302 ecr 0,nop,wscale 8], length 0
 00:00:00.000244 00:be:3b:be:df:59 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.42.33464 > 194.54.14.132.443: Flags [S], seq 1934117007, win 65535, options [mss 1460,sackOK,TS val 5242302 ecr 0,nop,wscale 8], length 0
 00:00:00.159932 00:be:3b:be:df:59 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.42.54894 > 54.225.109.150.443: Flags [S], seq 758737305, win 65535, options [mss 1460,sackOK,TS val 5242318 ecr 0,nop,wscale 8], length 0
 00:00:00.861291 00:be:3b:be:df:59 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.42.33464 > 194.54.14.132.443: Flags [S], seq 1934117007, win 65535, options [mss 1460,sackOK,TS val 5242402 ecr 0,nop,wscale 8], length 0
 00:00:00.078988 00:be:3b:be:df:59 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.42.45008 > 172.217.19.234.443: Flags [S], seq 2226790491, win 65535, options [mss 1460,sackOK,TS val 5242412 ecr 0,nop,wscale 8], length 0
 00:00:00.075948 00:be:3b:be:df:59 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.42.60072 > 216.58.213.170.443: Flags [S], seq 4119353519, win 65535, options [mss 1460,sackOK,TS val 5242420 ecr 0,nop,wscale 8], length 0
 00:00:00.522089 00:be:3b:be:df:59 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.42.39194 > 64.233.184.192.7276: Flags [S], seq 412310385, win 65535, options [mss 1460,sackOK,TS val 5242472 ecr 0,nop,wscale 8], length 0

и сразу видно , на каких портах было соединение
Соответственно , все остальные приложения были закрыты

werter

@Konstanti said in PfSense и журналирование:

00:00:00.522089 00:be:3b:be:df:59 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.42.39194 > 64.233.184.192.7276: Flags [S], seq 412310385, win 65535, options [mss 1460,sackOK,TS val 5242472 ecr 0,nop,wscale 8], length 0

Это не Сбер. Это что-то родное гугловское.

@lucas1

Оба правила в одной очереди и на одном Gateway.

О какой очереди речь? Вы там не во Floating rules правила для ЛАН рисуете?

Konstanti

@werter возможно
но

werter

@Konstanti
64.233.184.192 проверьте

ТС ~~с дуру~~ начнет порт 7276 открывать на fw, а оно не надо.

Konstanti

@werter у тс альфабанк. А вывод tcpdump для примера

lucas1

@Konstanti
Tcpdump помог. Телефонное приложение My.alfabank использует еще tcp 8243.

На LAN интерфейсе очередь CBQ, с subqueues..
Правила на LAN.

Разобраться еще немного "мешал" Snort. - срабатывали блокировки его exploit - правил.

Поэтому, Чтобы не начинать новую тему, хочу спросить какую методику эксплуатации Snort посоветуете.

Я сделал так.

Административные компьютеры и некоторые сервера в Passlists - сразу исключить из блокировок.
Сразу блокировок много - постепенно помещаю те, которые можно отключить - в SUPRESS list.
Их становится меньше. И обращений разблокировать "девайсы" тоже.
Где лучше смотреть описание exploits? Чтобы определить, что с ними делать - оставить или нет.
Постепенно "ненужных" срабатываний уже нет. И Snort настроен на действительно необходимые блокировки exploits.

Или надо по другому?

werter

@lucas1

Или надо по другому?

Надо. Пользуйте Suricata.
Почему ? Да хотя бы потому , что Сурикат поддерживает МНОГОЯДЕРНЫЕ CPU (умеет мультипоток). В отличие от Snort.

На LAN интерфейсе очередь CBQ, с subqueues..

Поищите про Codel. Прямо на форуме. Намного новее и толковее.

lucas1

@werter

Пока остановился на такой конфигурации PfSense.

Предполагаю, что другие IPS также имеют изначально несколько десятков тысяч правил.

Поэтому и интересует, кто и как эксплуатирует IPS с точки зрения исключения, включения, отключения exploit - правил, как определять категорию: приблизительно по заголовкам правил или где-то еще дополнительную информацию по правилу.

werter

@lucas1

кто и как эксплуатирует IPS с точки зрения исключения, включения, отключения exploit - правил, как определять категорию: приблизительно по заголовкам правил или где-то еще дополнительную информацию по правилу.

Не знаю как Снорт, но Сурикат прямо в вебке пишет, что и почему он заблочил. Там же можно и вкл\выкл правило, по к-ому он отработал.

В "лоб", вкл. ВСЕ правила и в процессе экспл-ции IPS постепенно откл. те, к-ые по вашему мнению не нужны\ ложно отрабатывают.

renat_kaa

@lucas1, на мой взгляд самый лучший сценарий - отправить журнал на удаленный сервер через Remote Logging Options и там уже настраивать объем, архивацию и цикличность.

dragoangel

Совет:
Если pfSense имеет достаточно места на storage, ставьте Syslog-ng пакет, и пишите в него. Я так храню логи HAProxy