Other What ICMP packets do you allow with your firewall?

I use pf and I only allow echoreq and unreach.
Code:
icmp_types="{echoreq,unreach}"
pass log inet proto icmp all icmp-type $icmp_types

I have traffic that I don't care for and I am consider shutting down icmp.

What is your policy? I will lose ping but that is not essential and I can enable it when needed.
 
I won't block ICMP, nor have any objection doing otherwise, but if you're going to deal with ICMP6(4), consider to add 'timex' and 'paramprob' types to your 'icmp6_types' (if any) rule too. Nothing more to add there, but traceroute(8), which I presume – based upon your comment about ping(8) – you won't need that either.

More at: 'timex' and 'paramprob' types: icmp6(4), and also icmp-paramprob ICMP type field in pcap-filter(7)
 
Poul-Henning Kamp wrote the default rules for the packet filters a long time ago. They were basic, but sound.

Worth a good read: /var/db/etcupdate/current/etc/rc.firewall.

I note that ICMP Source Quench (type 4) has since been deprecated by RFC1812, and should be ignored.

Filtering "fragmentation-needed" (ICMP type 3/4) traffic is a BAD idea. So you can't just ignore ICMP.

The complete list of ICMP message types is here.
 
I have a few sysctls although i don't know what they are good for,
Code:
net.inet.icmp.drop_redirect=1             
net.inet.tcp.icmp_may_rst=0
net.inet.icmp.icmplim=50

net.inet6.icmp6.rediraccept=0

With IPFW i allow all outgoing IPV6,
Code:
cmd="/sbin/ipfw -q add"   # Set rules command prefix
$cmd 04040 allow icmp from any to any out via $pif keep-state
 
I have a few sysctls although i don't know what they are good for

sysctl(8) provides descriptions for all it's variables when using the -d option:

Code:
> sysctl -d net.inet.icmp
net.inet.icmp: ICMP
net.inet.icmp.maskrepl: Reply to ICMP Address Mask Request packets
net.inet.icmp.stats: ICMP statistics (struct icmpstat, netinet/icmp_var.h)
net.inet.icmp.icmplim: Maximum number of ICMP responses per second
net.inet.icmp.error_keeptags: ICMP error response keeps copy of mbuf_tags of original packet
net.inet.icmp.tstamprepl: Respond to ICMP Timestamp packets
net.inet.icmp.bmcastecho: Reply to multicast ICMP Echo Request and Timestamp packets
net.inet.icmp.quotelen: Number of bytes from original packet to quote in ICMP reply
net.inet.icmp.reply_from_interface: ICMP reply from incoming interface for non-local packets
net.inet.icmp.reply_src: ICMP reply source for non-local packets
net.inet.icmp.redirtimeout: Delay in seconds before expiring redirect route
net.inet.icmp.log_redirect: Log ICMP redirects to the console
net.inet.icmp.drop_redirect: Ignore ICMP redirects
net.inet.icmp.maskfake: Fake reply to ICMP Address Mask Request packets
net.inet.icmp.icmplim_output: Enable logging of ICMP response rate limiting
 
I have in mine ipfw.conf:
Code:
# permit some ICMP

$cmd 02300 allow icmp from any to any icmptypes 0,3,4,11   in  recv
$external_if

$cmd 02350 allow icmp from any to any icmptypes 0,3,4,8,11 out xmit
$external_if

$cmd 02400 allow ipv6-icmp from any to any icmp6types 133,134,135,136,137

# deny ICMP

$cmd 02505 deny log icmp from any to any in recv $external_if
 
OK can I change the focus some here. It looks like I am stuck with icmp. FreeBSD boxes are not a problem.
The problem is appliances like Virtiv PDU. It uses ICMP and I see it transiting the firewall to the internet.

What should I do? Restrict individual boxes to local_net with rules? That has been my approach so far.

Refined Question: How to deal with promiscuous local devices using icmp
 
The problem is appliances like Vertiv PDU.
If an appliance sends whatsoever from LAN to Internet I would clarify what it exactly does and learn the reason why and when it does so. Sending data "home" to the vendor might be a function or just data collecting. If you care about what is going on you need to learn about it. It may be a configurable feature.

If a vendor keeps silent about the behavior of it's product, you need to investigate yourself.

This starts with the IP address where traffic is going to.
Does the IP belong to the vendor?
Is it a well known IP like 8.8.8.8 for testing the default route and the like?
At what times and how often? (Does it look random or like a cron job)
Is it related to a state of the box? (I.e. during booting the device, or when providing a service?).

Another approach (black box analysis) is first to watch and later filter what you suspect. When filtering watch carefully the log files and the behavior of your appliance. This needs to be done over a reasonable long time (i.e. minimum a month up to three months).

If other readers than Phishfry got appetite for doing some analysis you could start analyzing your home-automation or Internet-TV i.e with tcpdump(1) before tailoring firewall rules. :)
 
diizzy I noticed your list of 'Martians' varies from mine and I wonder.
I call mine bogons:
Code:
bogons="{0.0.0.0/8, 20.20.20.0/24, 127.0.0.0/8, 169.254.0.0/16,172.16.0.0/12, 192.0.2.0/24, 192.168.0.0/16, 224.0.0.0/3,255.255.255.255,240.0.0.0/4}"

Have I gone too far? I gather it's not enough to include just class A,B,C addresses? Where does this madness end?
 
I have these for IPFW,
Code:
# Deny all inbound traffic from non-routable reserved address spaces
$cmd 03000 deny all from 192.168.0.0/16  to any in via $pif #RFC 1918 private IP
$cmd 03010 deny all from 172.16.0.0/12   to any in via $pif #RFC 1918 private IP
$cmd 03020 deny all from 10.0.0.0/8      to any in via $pif #RFC 1918 private IP
$cmd 03030 deny all from 127.0.0.0/8     to any in via $pif #loopback
$cmd 03040 deny all from 0.0.0.0/8       to any in via $pif #loopback
$cmd 03050 deny all from 169.254.0.0/16  to any in via $pif #DHCP auto-config
$cmd 03060 deny all from 192.0.2.0/24    to any in via $pif #reserved for docs
$cmd 03070 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster interconnect
$cmd 03080 deny all from 224.0.0.0/3     to any in via $pif #Class D & E multicast
I see you block microsoft :)
 
Thank You. The comments help explain the madness.

Have to read on that
I have not read it , but here it is,
 
RFC 5735 seems relevant too:
 
This one too. Is there a great DHCP server in the cloud? What historically uses that?
Lots of reading,
 
So an IETF bogons list would be more like this?
0.0.0.0/8
10.0.0.0/8
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.0.0/24
192.0.2.0/24
192.88.99.0/24
192.168.0.0/16
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4
240.0.0.0/4
255.255.255.255/32

So only 20.20.20.0/24 is on my bogon list but not IETF.

New and improved bogons:
bogons="{0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 192.168.0.0/16, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4, 240.0.0.0/4, 255.255.255.255/32}"
 
Back
Top