Linux Netfilter discussions
 help / color / mirror / Atom feed
From: "John A. Sullivan III" <john.sullivan@nexusmgmt.com>
To: Jason Lunz <lunz@falooley.org>
Cc: netfilter@lists.netfilter.org
Subject: Re: ICMP firewalling on today's internet
Date: Mon, 05 Jul 2004 07:58:37 -0400	[thread overview]
Message-ID: <1089028716.26529.6.camel@localhost> (raw)
In-Reply-To: <cc42u4$7bi$1@sea.gmane.org>

On Fri, 2004-07-02 at 12:36, Jason Lunz wrote:
> Antony@Soft-Solutions.co.uk said:
> > You should certainly allow ICMP through if you want traceroute to work, and 
> > you should generally allow ICMP if you want many other things to work.   If 
> > you want to block certain types of ICMP, that's fine (many people do), but 
> > don't block all ICMP.
> 
> Speaking of which, what's the consensus on appropriate ICMP filtering?
> Obviously you don't want to filter everything. But some types of ICMP
> are really archaic, and not of use anymore. (source quench? redirect?
> address mask request? Does anyone use these today? Were they ever in
> widespread use?)
> 
> And common stuff (like echo/echo reply) is abused by various malware,
> and should possibly be rate-limited. 
> 
> But looking down the list of icmp types
> (http://www.iana.org/assignments/icmp-parameters), there are several I'm
> not sure how to handle.
> 
> For a small site's common connection-tracking border firewall, for
> example, how are the following actions?
> 
> ]   0	Echo Reply				 [RFC792]
> 
> legitimate replies should be allowed in by ESTABLISHED (or RELATED?),
> otherwise block in both INPUT and FORWARD.
> 
> ]   1	Unassigned				    [JBP]
> ]   2	Unassigned				    [JBP]
> 
> block in both INPUT and FORWARD, with rate-limited logging?
> 
> ]   3	Destination Unreachable			 [RFC792]
> 
> legitimate replies should be allowed in by ESTABLISHED (or RELATED?),
> otherwise block in both INPUT and FORWARD.
> 
> ]   4	Source Quench			 	 [RFC792]
> ]   5	Redirect				 [RFC792]
> ]   6	Alternate Host Address			    [JBP]
> ]   7	Unassigned				    [JBP]
> 
> block in both INPUT and FORWARD, with rate-limited logging?
> 
> ]   8	Echo					 [RFC792]
> 
> allow both INPUT and FORWARD, but rate-limited
> 
> ]   9	Router Advertisement			[RFC1256]
> ]  10	Router Solicitation			[RFC1256]
> 
> don't know about these. They don't seem to be commonly used.
> 
> ]  11	Time Exceeded				 [RFC792]
> ]  12	Parameter Problem			 [RFC792]
> ]  13	Timestamp				 [RFC792]
> ]  14	Timestamp Reply				 [RFC792]
> ]  15	Information Request			 [RFC792]
> ]  16	Information Reply			 [RFC792]
> ]  17	Address Mask Request                     [RFC950]
> ]  18	Address Mask Reply			 [RFC950]
> 
> do any of these crop up much?
> 
> ]  19	Reserved (for Security)			   [Solo]
> ]  20-29	Reserved (for Robustness Experiment)	    [ZSu]
> 
> probably shouldn't be seeing these.  block in both INPUT and FORWARD,
> with rate-limited logging.
> 
> ]  30	Traceroute				[RFC1393]
> 
> allow outgoing?
> 
> ]  31	Datagram Conversion Error		[RFC1475]
> ]  32     Mobile Host Redirect              [David Johnson]
> ]  33     IPv6 Where-Are-You                 [Bill Simpson]
> ]  34     IPv6 I-Am-Here                     [Bill Simpson]
> ]  35     Mobile Registration Request        [Bill Simpson]
> ]  36     Mobile Registration Reply          [Bill Simpson]
> ]  37     Domain Name Request                     [RFC1788]
> ]  38     Domain Name Reply                       [RFC1788]
> ]  39     SKIP                                    [Markson]
> ]  40     Photuris                                [RFC2521]
> ]  41-255 Reserved				    [JBP]
> 
> no idea about these either.
> 
> So what would a good starting point for a good, but not heavy-handed,
> iptables icmp filter look like? maybe something like this (untested):
> 
> 	iptables -N icmp
> 	iptables -A icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
> 	iptables -A icmp -i $INTERNAL_IFACE -p icmp --icmp-type echo-request -j ACCEPT
> 	iptables -A icmp -i $INTERNAL_IFACE -p icmp --icmp-type 30 -j ACCEPT
> 	iptables -A icmp -j LOG --log-prefix "iptables bad-icmp: " -m limit --limit 10/second
> 	iptables -A icmp -j DROP
> 
> 	iptables -I INPUT -p icmp -j icmp
> 	iptables -I FORWARD -p icmp -j icmp
> 
> Are there more types that should be let through?
> 
> Jason
I vary just slightly from Antony's recommendation that we use no ICMP
rules and trust all RELATED, ESTABLISHED ICMP packets.  I do rate limit
pings in case there is an unusual need for someone to allow echo
requests through.  I do drop broadcast pings.  And then, although I do
not do it in iptables, but rather sysctl, I disable redirects on the
gateway lest I be subject to someone else's compromise of my upstream
router (along with a few other things like allowing source routed
packets).
One certainly wants to allow reply time exceeded for traceroutes and I
believe non-windows stations are able to use source-quench for flow
control although I'm not entirely sure about that - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 



      parent reply	other threads:[~2004-07-05 11:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-30 14:34 traceroute Piszcz, Justin Michael
2004-06-30 14:50 ` traceroute Peter Marshall
2004-06-30 14:57 ` traceroute Antony Stone
2004-07-02 16:36   ` ICMP firewalling on today's internet Jason Lunz
2004-07-04 13:07     ` Antony Stone
2004-07-05 11:58     ` John A. Sullivan III [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1089028716.26529.6.camel@localhost \
    --to=john.sullivan@nexusmgmt.com \
    --cc=lunz@falooley.org \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox