Today while I just back from my hometown, fire up my machine and login to the #pf in freenode, and there's a guy asking how PF interactively reply to the packets when people try to apply this rule.
block drop in on $NIC inet proto icmp from any to any icmp-type unreach code net-unr
Normally ths rule is just applied so that if anybody who try to probe using icmp will get the message of icmp destination net unreachable. Let's test it out.
block drop in on $NIC inet proto icmp from any to any icmp-type unreach code net-unr
Normally ths rule is just applied so that if anybody who try to probe using icmp will get the message of icmp destination net unreachable. Let's test it out.
Results Comparison
Windows machine
cmd>ping 192.168.0.5
Pinging 192.168.0.5 with 32 bytes of data:
Request timed out.
Reply from 192.168.0.5: Destination net unreachable.
... ... ... ...
Freebsd machine
shell>ping 192.168.0.5
Pinging 192.168.0.5: 56 data bytes
36 bytes from 192.168.0.5: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 b16c 0 0000 2d 01 51a4 192.168.0.4 192.168.0.5
... ... ... ...
--- 192.168.0.5 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss.
Linux machine
shell>ping 192.168.0.5
Ping 192.168.0.5 56(84) bytes of data.
From 192.168.0.5 icmp_seq=0 Packet filtered
From 192.168.0.5 icmp_sqd=1 Packet filtered
... ... ... ...
--- 192.168.0.5 ping statistics ---
21 packets transmitted, 0 received, +19 errors, 100% packet loss and bla bla.
I log the traffic using tcpdump, it seems that freebsd is giving me the exact error message that I supposed received. Basically I don't think this is good rule to be applied, single icmp packet can easily detect the box as firewalling boxen. Windows box is totally been fooled, let's screw script kiddies.
Do you smell Packet filtered?
Do you smell Packet filtered?
No comments:
Post a Comment