“Default deny” rules в журнале



  • @Konstanti
    Ставил в правиле All flags и sloppy state - не помогло.



  • @lucas1 Здр
    Вы можете показать pcap файл (захват на lan интерфейсе) , что происходит , когда устанавливается соединение с нужным хостом ?
    И покажите пож правило , которое Вы используете для соединения с нужными хостами (с флагами по умолчанию и Any flags)
    желательно , командой
    pfctl -sr



  • @lucas1
    Попробуйте создать правило и поместить его на верх
    Interface : Lan
    Address family : IPv4
    Protocol : TCP
    Source : X..Y.16.80
    Destination : X.Y.251.132
    Destination port : 443 (или 80)
    Flags : Set PSH
    Out of PSH ACK



  • @Konstanti
    Правило: IP4* source этот хост .16.80, остальное все ALL, т.е. полный доступ в интернет.
    И только по этому правилу пакеты проходят в интернет.
    Флаги Set PSH и Out of PSH ACK - не помогло.
    Кстати Out of - это маска флагов?



  • @lucas1
    Подозреваю это:
    Sometimes log entries will be present that, while labeled with the “Default deny” rule, look like they belong to legitimate traffic. The most common example is seeing a connection blocked involving a web server.
    This is likely due to a TCP FIN packet arriving after the connection’s state has been removed.
    Но заставить пройти закачку не удается.

    Менял например System\Advanced\Firewall & NAT\Firewall Optimization Options
    с Normal на все опции - вообще еще хуже, даже просто интернету.
    И флаги в default deny rules появляются разные. Бывает эти правила вообще не появляются в журнале. Иногда даже проходит несколько процентов закачки.



  • @lucas1 Гадать , что происходит , можно очень долго
    Для первичного анализа желателен pcap файл tcpdump
    и вывод правил командой pfctl -sr
    еще желателен вывод команды ifconfig -m , чтобы видеть настройки сетевых интерфейсов .

    Повторю еще раз , просто так блокировать пакет с флагом P PF не станет . Пакеты через правила файрвола (в настройках по умолчанию) пробегают только один раз , когда проходит первый пакет. В случае TCP это пакет с флагом SYN . Потом уже соединение считается установленным и через правила файрвола пакеты этого соединения не прогоняются.



  • @Konstanti

    Дело в том, что dest хостов много может 10 или больше.
    И блокируются пакеты с разными флагами. Мало того блокировок В ЖУРНАЛЕ может и не быть.

    Через Capture на LAN заметил :

    Z.T.167.25.80 > X.Y.16.80.61628: Flags [.], cksum 0x1c65 (incorrect -> 0x32e5), seq 2890081:2891521, ack 321, win 237, length 1440: HTTP

    15:58:44.146582 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 40181, offset 0, flags [DF], proto TCP (6), length 1480)

    Z.T.167.25.80 > X.Y.16.80.61628: Flags [.], cksum 0x4659 (incorrect -> 0x5cd9), seq 2897281:2898721, ack 321, win 237, length 1440: HTTP

    15:58:44.147002 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 40186, offset 0, flags [DF], proto TCP (6), length 1480)

    Вероятно причина в этом, но как ее устранить.



  • @lucas1 Покажите вывод команды
    ifconfig -m

    или в настройках включите
    7416bf1e-e419-4d96-9383-42d59288a86d-image.png



  • @lucas1
    Если не поможет , то нужен pcap файл
    Явно , что Z.T.167.25 шлет команду на сброс соединения (флаг R или F в пакете) , поэтому и удаляется соединение из таблицы состояний . А хост X.Y.16.80 не знает об этом





  • @lucas1 said in “Default deny” rules в журнале:

    cksum 0x1c65 (incorrect -> 0x32e5)

    pfSense виртуализирована? Если да - hardware checksum offload отключали?
    https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-proxmox.html



  • @Konstanti
    Включение опции Hardware Checksum Offloading частично помогло. Сейчас Default Deny в журнале вообще нет.
    Запустил Wireshark на проблемном сервере.

    13 6.547774 IP.IP.IP.10 216.58.220.100 TCP 66 [TCP Dup ACK 9#2] 55643?80 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=19536649 TSecr=1347876636
    14 8.532081 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP segment of a reassembled PDU]
    15 8.781690 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP Retransmission] 55643?80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=16 TSval=19537208 TSecr=1347876636
    16 9.033636 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP Retransmission] 55643?80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=16 TSval=19537271 TSecr=1347876636
    17 9.453382 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP Retransmission] [TCP segment of a reassembled PDU]
    18 9.537284 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP Retransmission] 55643?80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=16 TSval=19537397 TSecr=1347876636
    19 10.544897 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP Retransmission] 55643?80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=16 TSval=19537649 TSecr=1347876636
    20 10.545286 216.58.220.100 IP.IP.IP.10 TCP 74 [TCP Spurious Retransmission] 80?55643 [SYN, ACK] Seq=0 Ack=1 Win=42540 Len=0 MSS=1402 SACK_PERM=1 TSval=1347883098 TSecr=19536021 WS=128

    Постоянные ошибки Dup, reassembled PDU, Retransmission.
    Не понял почему Capture на самом PfSense такое не показывает.

    Виртуализирован проблемный сервер. Ну как проблемный - с этой частной проблемой.



  • @lucas1 said in “Default deny” rules в журнале:

    216.58.220.100 IP.IP.IP.10

    Показали бы все , проще было бы анализ проводить

    Надо на pf захватить трафик и выгрузить его в виде pcap файла (не хотите его публично выложить , пришлите на почту)
    и ifconfig -m желателен ( в очередной раз повторяю, сразу было бы видно , что и как у Вас на сетевых интерфейсах настроено )
    а почему mss такой маленький ? через туннель какой-то устанавливается соединение ?
    Какие доп пакеты установлены ?
    PfblockerNG установлен ?
    Недавно в англоязычной части форума рассматривали похожий случай , отключили этот пакет ,и все заработало



  • @lucas1 said in “Default deny” rules в журнале:

    Включение опции Hardware Checksum Offloading частично помогло.

    Hardware Checksum Offloading надо выключить. Или вы описАлись?



  • @Konstanti
    Pfblocker и Snort установлены. Snort и DNSBL выкл. - одинаково. IP - еще нет.
    Без Hardware Checksum Offloading checked все выглядит еще хуже.
    Не понял на форуме где найти адрес вашей почты.



  • @lucas1
    Что за железо? Что за гипер исп-ся? У меня на KVM при всех Disabled HW offloading на сетевых проблем НЕТ на 10 PVE.

    Если сервер умеет vt-d\ iommu - на время пробростьте полностью сетевую в ВМ. Если и при этом будет косяк - разбирайтесь с железом.
    ЗЫ. А может ваше железо умеет и SR-IOV - тогда еще проще.



  • @lucas1 said in “Default deny” rules в журнале:

    Без Hardware Checksum Offloading checked все выглядит еще хуже.

    Отключение Hardware Checksum Offloading вообще-то "золотой стандарт" при виртуализации pfSense с практически любым гипервизором.
    Тут регулярно всплывают проблемы связанные с его неотключением, вплоть до не работающего банального port forward.
    Странно, что у вас это не так.

    @lucas1 said in “Default deny” rules в журнале:

    Не понял на форуме где найти адрес вашей почты.

    Ее там нет. Виртуализацию использую, Но для pfSense - реальное железо.
    Главный виртуализатор тут @werter



  • @lucas1 Отключите пакеты и посмотрите , что будет
    Адрес напишу в личку



  • @Konstanti
    Выключал Pfblocker. останавливал Snort - результат тот же.
    Кстати выглядит сейчас так на сервере через Wireshark:

    7008","22.126605","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 6989#9] 52287 > 80 [ACK] Seq=316 Ack=4894561 Win=365568 Len=0"
    "7009","22.126646","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 6989#10] 52287 > 80 [ACK] Seq=316 Ack=4894561 Win=365568 Len=0"
    "7010","22.126795","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5245921 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7011","22.126844","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 6989#11] 52287 > 80 [ACK] Seq=316 Ack=4894561 Win=365568 Len=0"
    "7012","22.126879","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5247361 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7013","22.126923","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 6989#12] 52287 > 80 [ACK] Seq=316 Ack=4894561 Win=365568 Len=0"
    "7014","22.152374","dd.ddd.167.25","X.Y.16.80","TCP","1494","[TCP Out-Of-Order] 80 > 52287 [ACK] Seq=4894561 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7015","22.152499","X.Y.16.80","dd.ddd.167.25","TCP","54","52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
    "7016","22.152549","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5248801 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7017","22.152561","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5250241 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7018","22.152595","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#1] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
    "7019","22.152631","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#2] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
    "7020","22.152659","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5251681 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7021","22.152688","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#3] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
    "7022","22.152724","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5253121 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7023","22.152755","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#4] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
    "7024","22.152847","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5254561 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7025","22.152877","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#5] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
    "7026","22.152924","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5256001 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7027","22.152964","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#6] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
    "7028","22.153021","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5257441 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7029","22.153043","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#7] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
    "7030","22.179272","dd.ddd.167.25","X.Y.16.80","TCP","1494","[TCP Out-Of-Order] 80 > 52287 [ACK] Seq=4911841 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7031","22.179384","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5258881 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7032","22.179417","X.Y.16.80","dd.ddd.167.25","TCP","54","52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
    "7033","22.179456","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5260321 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7034","22.179489","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#1] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
    "7035","22.179531","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5261761 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7036","22.179553","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#2] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
    "7037","22.179645","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5263201 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7038","22.179694","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#3] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
    "7039","22.179779","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5264641 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7040","22.179810","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#4] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
    "7041","22.179883","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5266081 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7042","22.179920","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#5] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
    "7043","22.180017","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5267521 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
    "7044","22.180041","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#6] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
    "7045","22.439852","dd.ddd.167.25","X.Y.16.80","TCP","1494","[TCP Retransmission] 80 > 52287 [ACK] Seq=4927681 Ack=316 Win=30336 Len=1440"
    "7046","22.499467","X.Y.16.80","dd.ddd.167.25","TCP","54","52287 > 80 [ACK] Seq=316 Ack=4944961 Win=345600 Len=0"
    "7047","22.999778","dd.ddd.167.25","X.Y.16.80","TCP","1494","[TCP Retransmission] 80 > 52287 [ACK] Seq=4944961 Ack=316 Win=30336 Len=1440"
    "7048","23.062031","X.Y.16.80","dd.ddd.167.25","TCP","54","52287 > 80 [ACK] Seq=316 Ack=4960801 Win=345600 Len=0"
    "7049","24.019738","dd.ddd.167.25","X.Y.16.80","TCP","1494","[TCP Retransmission] 80 > 52287 [ACK] Seq=4960801 Ack=316 Win=30336 Len=1440"

    На PfSense все вроде correct:

    23:56:42.003041 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 11840, offset 0, flags [DF], proto TCP (6), length 1480)
    DD.DDD.167.25.80 > X.Y.16.80.52287: Flags [.], cksum 0x9954 (correct), seq 1123201:1124641, ack 316, win 237, length 1440: HTTP
    23:56:42.003152 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 11841, offset 0, flags [DF], proto TCP (6), length 1480)
    DD.DDD.167.25.80 > X.Y.16.80.52287: Flags [.], cksum 0x0578 (correct), seq 1124641:1126081, ack 316, win 237, length 1440: HTTP
    23:56:42.003162 76:49:50:73:85:f7 > 00:03:47:98:1b:80, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 1183, offset 0, flags [DF], proto TCP (6), length 40)
    X.Y.16.80.52287 > DD.DDD.167.25.80: Flags [.], cksum 0x9d2d (correct), seq 316, ack 1120321, win 1507, length 0
    23:56:42.003272 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 11842, offset 0, flags [DF], proto TCP (6), length 1480)
    DD.DDD.167.25.80 > X.Y.16.80.52287: Flags [.], cksum 0x3a35 (correct), seq 1126081:1127521, ack 316, win 237, length 1440: HTTP
    23:56:42.003390 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 11843, offset 0, flags [DF], proto TCP (6), length 1480)
    DD.DDD.167.25.80 > X.Y.16.80.52287: Flags [.], cksum 0x5491 (correct), seq 1127521:1128961, ack 316, win 237, length 1440: HTTP



  • @lucas1
    После изменения в guest OS на сервере виртуализации в свойствах сетевого интерфейса режима VirtLO на Intel E1000 все заработало нормально.

    Записи Default Deny в журнале PfSense никак с этим не связаны.

    Checked Disable hardware checksum offloading повлияло на журналирование Alerts Pfblocker DNSBL. Теперь там появляются записи, правда IF и Sourse - Unknown.
    Но и это хорошо.


Log in to reply