weixin_39918145
weixin_39918145
2020-11-30 09:05

snort IPS (drop rule ) not droping traffic

I configured snort 2.9.12 and pf_ring ft 7.2 (ndpi 2.4-stable) in IPS mode: PF_RING_FT_CONF=/etc/pf_ring/ft-rules.conf snort -c /etc/snort/snort.conf -l /var/log/snort/ --daq-dir=/usr/local/lib/daq --daq pfring --daq-mode inline -Q -i ens5:ens6 --daq-var fast-tx=1 --daq-var clusterid=10,11 --daq-var bindcpu=1 -A console

root-172-16-3-216:~# cat /etc/pf_ring/ft-rules.conf [shunt] default = 10 tcp = 6

[filter] ICMP = discard

I can see in the console that snort try to drop some traffic: 11/14-18:10:12.376018 [Drop] [] [1:666:0] reject any icmp [] [Priority: 0] {ICMP} 10.0.0.10 -> 8.8.4.4 11/14-18:10:12.384264 [Drop] [] [1:666:0] reject any icmp [] [Priority: 0] {ICMP} 8.8.4.4 -> 172.16.57.247 11/14-18:10:13.377417 [Drop] [] [1:666:0] reject any icmp [] [Priority: 0] {ICMP} 10.0.0.10 -> 8.8.4.4 11/14-18:10:13.385309 [Drop] [] [1:666:0] reject any icmp [] [Priority: 0] {ICMP} 8.8.4.4 -> 172.16.57.247 11/14-18:10:14.378472 [Drop] [] [1:666:0] reject any icmp [] [Priority: 0] {ICMP} 10.0.0.10 -> 8.8.4.4

snort rule: ubuntu-172-16-3-216:~/snort_src/nDPI$ cat /etc/snort/rules/1.rules reject icmp any any <> any any ( msg:"reject any icmp"; sid:666; ) reject tcp any any <> any 80 ( msg:"reject any http"; sid:6666; )

and in dmesg log: [11432.893139] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=0) while adding rule (rule_id=2): discarded [11432.893166] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=1) while adding rule (rule_id=3): discarded [11433.893339] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=0) while adding rule (rule_id=4): discarded [11433.893377] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=1) while adding rule (rule_id=5): discarded [11434.893558] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=0) while adding rule (rule_id=6): discarded [11434.893600] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=1) while adding rule (rule_id=7): discarded [11435.893776] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=0) while adding rule (rule_id=8): discarded [11435.893812] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=1) while adding rule (rule_id=9): discarded [11436.894023] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=0) while adding rule (rule_id=10): discarded [11436.894067] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=1) while adding rule (rule_id=11): discarded [11437.894241] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=0) while adding rule (rule_id=12): discarded [11437.894272] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=1) while adding rule (rule_id=13): discarded [11438.894482] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=0) while adding rule (rule_id=14): discarded [11438.894518] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=1) while adding rule (rule_id=15): discarded [11439.894701] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=1) while adding rule (rule_id=16): discarded [11439.894736] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=0) while adding rule (rule_id=17): discarded [11440.894927] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=0) while adding rule (rule_id=18): discarded [11440.894959] [PF_RING] handle_sw_filtering_hash_bucket:3064 Duplicate found (rule_id=1) while adding rule (rule_id=19): discarded

该提问来源于开源项目:ntop/PF_RING

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

20条回答

  • weixin_39918145 weixin_39918145 5月前

    see attached... pf_ring.pcap.gz

    点赞 评论 复制链接分享
  • weixin_39964528 weixin_39964528 5月前

    I guess you were using pfcount with -u without -v, I just pushed a fix for that. I replayed your pcap using pfsend at high rate, and this is the outcome on my machine: - This is the pfcount output without filtering (pfcount -i eth0) Actual Stats: [3'849'501 pkts rcvd][1'000.04 ms][3'849'343.17 pps][3.36 Gbps] - This is the pfcount output with filtering (pfcount -i eth0 -u 1) Actual Stats: [714'699 pkts rcvd][1'000.04 ms][714'667.55 pps][0.48 Gbps] (This leaking traffic is ARP)

    点赞 评论 复制链接分享
  • weixin_39918145 weixin_39918145 5月前

    this is exactly the reason I asked you to login to my env from the beginning.. the fact its working on your env and not working on my no surprising for anyone.. I dont really have something to do with this kind of situation beside stop the testing of PF_RING and move to different product...

    点赞 评论 复制链接分享
  • weixin_39964528 weixin_39964528 5月前

    please note that filtering is working with your traffic (what is leaking is ARP traffic which is not supported by hash rules), the fix I pushed is for pfcount for injecting the correct tuple (packet parsing was disabled). Please let me know if you want to check it to see if you are still able to reproduce it (I am not against connecting to your machine if needed).

    点赞 评论 复制链接分享
  • weixin_39918145 weixin_39918145 5月前

    syslog.gz I reloaded pf_ring.ko with higher debug level and rerun the scenario, please see the attached syslog file Thanks

    点赞 评论 复制链接分享
  • weixin_39964528 weixin_39964528 5月前

    it seems you can safely ignore those warning (you should no longer see them if you update to latest code, they have been moved to debug level 1 now), it happens when snort inserts multiple rules for the same tuple.

    点赞 评论 复制链接分享
  • weixin_39918145 weixin_39918145 5月前

    , I dont have issue with the warnings.. I have issue with the fact that snort instruct drop action and pf_ring dont drop the traffic... I added the warnings as debug info for the issue (snort and pf_ring integration dont work) Thanks,

    点赞 评论 复制链接分享
  • weixin_39964528 weixin_39964528 5月前

    I noticed that the filtering api in snort was missing some new field, I recommend you to update both the library (recompile the daq) and the pf_ring kernel module (I pushed some patch). Please let me know, thank you.

    点赞 评论 复制链接分享
  • weixin_39918145 weixin_39918145 5月前

    need to recompile snort and nDPI also?

    点赞 评论 复制链接分享
  • weixin_39964528 weixin_39964528 5月前

    You do not need to recompile Snort, the DAQ is enough. You need to recompile nDPI yes, to make sure it is in sync with PF_RING.

    点赞 评论 复制链接分享
  • weixin_39918145 weixin_39918145 5月前

    I recompiled the following: * pf_ring kernel (kernel folder) * pf_ring lib (userland/lib folder) * pf_ring snort daq (userland/snort/pfring-daq-module)

    still looks like snort try to instruct drop and traffic still flows... its possible that snort drop action only drops the traffic from the daq and not from the ring itself?

    点赞 评论 复制链接分享
  • weixin_39918145 weixin_39918145 5月前

    if its possible I suggest we perform a quick live session to debug this, it will rapid the process..

    点赞 评论 复制链接分享
  • weixin_39918145 weixin_39918145 5月前

    please ignore the comment about wrong module.. (i deleted the comment), the issue still exists, the snort instruct drop but traffic flows..

    点赞 评论 复制链接分享
  • weixin_39964528 weixin_39964528 5月前

    , as double check, please try running "pfcount -i eth0 -v 1 " vs "pfcount -i eth0 -v 1 -u 1", the second command inserts filtering rules for each received packet, this to make sure that filtering is working with your kernel module. Also, could you try removing the fast-tx option to see if it makes any difference?

    点赞 评论 复制链接分享
  • weixin_39918145 weixin_39918145 5月前

    the first execution looked OK no errors...

    when running the second command (with the rule insertion), I got the following errors: sudo pfcount -i eth0 -v 1 -u 1 > pfcount.2.log

    Adding hash filtering rules Dumping statistics on /proc/net/pf_ring/stats/27670-eth0.4 pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed pfring_handle_hash_filtering_rule(1) failed

    "========================= Absolute Stats: [21 pkts total][0 pkts dropped][0.0% dropped] [21 pkts rcvd][2'454 bytes rcvd] ========================="

    in additional Im attaching 2 log files of the execution pfcount.2.log pfcount.1.log

    点赞 评论 复制链接分享
  • weixin_39964528 weixin_39964528 5月前

    some pfring_handle_hash_filtering_rule failure is expected in case the application sets multiple rules for the same session (this happens due to queued packets), besides that, do you see that filtering is working? (you should notice a few received packets with respect to the pfcount without -u)

    点赞 评论 复制链接分享
  • weixin_39918145 weixin_39918145 5月前

    no there is same packet count with both executions... no need in some env var for passing the app the location of the flow table rules?

    点赞 评论 复制链接分享
  • weixin_39964528 weixin_39964528 5月前

    Please provide "cat /proc/net/pf_ring/info"

    点赞 评论 复制链接分享
  • weixin_39918145 weixin_39918145 5月前

    PF_RING Version : 7.2.0 (7.2.0-stable:7106e9f85e5b16fc5de7a28edb919cd450d72198) Total rings : 0

    Standard (non ZC) Options Ring slots : 4096 Slot version : 17 Capture TX : Yes [RX+TX] IP Defragment : No Socket Mode : Standard Cluster Fragment Queue : 0 Cluster Fragment Discard : 0

    点赞 评论 复制链接分享
  • weixin_39964528 weixin_39964528 5月前

    your configuration looks fine, I ran pfcount with -u using the same configuration and it is working for me. Are you able to provide some pcap data (a few packets) to try to debug this issue in our lab?

    点赞 评论 复制链接分享