Wireshark-users: [Wireshark-users] Firewall ACL rules
From: Priscilla Oppenheimer <po@xxxxxxxxxxxxx>
Date: Sun, 20 Apr 2008 09:40:32 -0700
Hi Group,

Any thoughts on this?

I think some of the Firewall rules that Wireshark composes are strange. Wireshark sometimes makes assumptions about what you're doing with the rules that don't agree with how most people would think about the problem?

For example, a device is using Nessus to scan my network. The goal is to use Wireshark to build a Netfilter firewall rule to deny all inbound traffic on the eth0 interface from the scanning device. The scanning device is

I know Netfilter (iptables) reasonably well. I've also checked with other iptables users and they agree with me that the rule should be:

iptables -A INPUT -i eth0 -s -j DROP

Wireshark composes this rule:

iptables -A INPUT -i eth0 -d -j DROP

That can't be right unless what you're trying to block is traffic back to the scanner and eth 0 is on the side of the possible responder.

By the way, for comparison's sake, Wireshark gets it right for other types of firewalls. It says a Cisco standard ACL (which is based on source addr only) is this:

access-list NUMBER deny host

For Cisco extended, where source address comes first, it also gets it right:

access-list NUMBER deny ip host any

For ipfw, it gets it right:

add deny ip from to any in

Also, iptables is good for this related situation where we want to block the scanner specifically from sending to ports 0 and 443. These rules are right:

iptables -A INPUT -p tcp --destination-port 0 -j DROP
iptables -A INPUT -p tcp --destination-port 443 -j DROP

But it gets squirrelly again if you include port numbers with Cisco extended ACLs, for what it's worth.

Thanks for any insights!

Priscilla Oppenheimer
"If the brain is a computer, then it is the only one that runs on glucose, generates 10 watts of electricity, and is manufactured by unskilled labor." -- David Lewis