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 192.168.1.141.
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 192.168.1.141/32 -j DROP
Wireshark composes this rule:
iptables -A INPUT -i eth0 -d 192.168.1.141/32 -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 192.168.1.141
For Cisco extended, where source address comes first, it also gets it
right:
access-list NUMBER deny ip host 192.168.1.141 any
For ipfw, it gets it right:
add deny ip from 192.168.1.141 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
and
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
http://www.priscilla.com
"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
