Suricata

I need to confirm that the following results are the same on FreeBSD, to know if the results are only mac osx related, or mac osx and FreeBSD (or linux with nfqueue..).

Setting up ipfw with:
ipfw add 100 divert 8000 ip from any to any

and the following rules:
drop tcp any any -> any $HTTP_PORTS (msg:"http drop sid 1";content:"dropme";sid:1;)
reject tcp any any -> any $HTTP_PORTS (msg:"http reject sid 2";content:"rejectme";sid:2;)
alert tcp any any -> any $HTTP_PORTS (msg:"http alert sid 3";content:"alertme";sid:3;)

From my browser, connecting to a local http server,
1. http://172.26.0.123/dropme :
- The browser repeat the query multiple times because exceed the timeout getting no response, but also it doesn't close the connection, until the number of retries exceed the limit, showing the following message:
The connection has timed out
The server at 172.26.0.123 is taking too long to respond.
- We get multiple alerts because of the timeout
2. http://172.26.0.123/rejectme :
- The connection is reset, without timeouts, directly. The web server message:
The connection was reset
The connection to the server was reset while the page was loading.
- We get just one alert here.
3. http://172.26.0.123/alertme :
- The web server answer, the page is not found. It doesn't drop/reject the packet, but - We get just one alert here.

Problems with icmp:
It doesn't drop all the packets:
Using the following ipfw rules (I tested it with both):
ipfw add 100 divert 8000 ip from any to any
ipfw add 100 divert 8000 icmp from any to any

and the following rule:
drop icmp any any -> any any (msg:"icmp drop all 8.8.8.8 sid5"; sid:10;)

PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
64 bytes from 8.8.8.8: icmp_seq=2 ttl=252 time=59.636 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=252 time=60.035 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=252 time=58.654 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=252 time=59.244 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=252 time=56.776 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=252 time=59.175 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=252 time=60.757 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=252 time=59.576 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=252 time=58.641 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=252 time=57.345 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=252 time=59.071 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=252 time=59.383 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=252 time=59.432 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=252 time=60.684 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=252 time=59.659 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=252 time=58.560 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=252 time=61.779 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=252 time=58.451 ms
^C
--- 8.8.8.8 ping statistics ---
20 packets transmitted, 18 packets received, 10.0% packet loss
ICMPv4 Packets processed at suricata: 39
alerts generated: 2
So it's not working correctly with icmp.

Fixed dsp ip address:
- With the following rule
drop ip any any > 75.125.225.173 any (msg:"drop by ip sid7";sid:7;)
and ipfw with:
ipfw add 100 divert 8000 ip from any to any
- I query from the browser that address and get answer:
/me waves hand This is not the server you're looking for

Move along...
So it's not working correctly with fixed addresses.

After IPOnlyMatch() is executed, I copy the p->action at flow level. For the next times, the p->action is set as p->action |= fp->flow->iponly_action. Now it works, it drops all the packets. Only 1 alert is generated for each flow (with a dst fixed).

Changing the conditions of the else, to ensure that the flow is set as IPONLY (src or dst).

Patch works updating hours to the correct amount.