RE: traceroute

RE: traceroute

[Piszcz, Justin Michael]

Is there a reason why you are doing stuff with the FORWARD chain?
Have you tried enabling ACCEPT for the FORWARD chain and seeing if it
works?

Generally, with the FORWARD chain, over all other chains you need to be
careful on how you use it. If used improperly, you could screw a lot of
things up on the network.

I would recommend trying it without any forward options.
Ie: iptables -P FORWARD ACCEPT

You need the ESTABLISHED,RELATED option for the INPUT chain.

# STEP 9 - ALLOW IN WHAT WE SEND OUT
####################################### $IPTABLES -A INPUT -m state
--state ESTABLISHED,RELATED -j ACCEPT

-----Original Message-----
From: Peter Marshall [mailto:peter.marshall@caris.com] 
Sent: Wednesday, June 30, 2004 10:25 AM
To: Piszcz, Justin Michael; netfilter
Subject: Re: traceroute

I don't get anything (except the name lookup) from traceroute.

When I run a packet sniffer, I see the following (when doing a
traceroute on
www.google.com)

source     destination                 Proto
me           216.239.41.99          UDP            sourceport 1059
destination port 33435
3com       3com                         ARP            who has
<gatewayip>
tell <my ip>
3com        3com                        ARP            <gateway ip> is
at
<mac address>
me           216.239.41.99           UDP          soutceport: 1059
Destination port 33437
......

traceroute to www.google.akadns.net (216.239.39.147), 30 hops max, 38
byte
packets
 1  * * *
 2  * * *

Below are the relavant rules .... tracert is the ip of the box I am
trying
to traceroute form.
The Ip of that box is an internet routable ip addess.

$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
$IPT -A FORWARD -d <tracert box -i eth1 -j net-rh

$IPT -A rh-net -s <tracert box> -j ACCEPT
$IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT


Thank you again,
Peter.

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 10:47 AM
Subject: RE: traceroute


Can you show me your firewall?
Can you paste the blocks you are seeing?
It does not get past the 1st hop, or?
Post an example traceroute?


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 9:29 AM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 2:05 pm, Peter Marshall wrote:

> Hi.  I was wondering what I would need for rules to have traceroute
work
> through my firewall.  (I have a box behind the firewall trying to get
out
> using traceroute).
>
> I have an allow established connections on my forwared chain, and I am
> allowing anything from the source IP of the box in question to leave
... It
> appears that the problem is on the packets comming back in .. but I am
not
> sure what I have to do to fix it ....

Allow RELATED packets as well as ESTABLISHED.

Regards,

Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the
sense of
achievement you get from getting them to work at all. In other words -
and
this is the rock solid principle on which the whole of the Corporation's

Galaxy-wide success is founded - their fundamental design flaws are
completely hidden by their superficial design flaws."

 - Douglas Noel Adams

                                                     Please reply to the
list;
                                                           please don't
CC me.

Re: traceroute

[Peter Marshall]

Why would I use the INPUT chain .. I am doing a trace route from an internal
box to an internet box ... on the other side of my firewall ... I am pretty
sure that is a forwared rule ... is it not ?

Peter

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "Peter Marshall" <peter.marshall@caris.com>; "netfilter"
<netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 11:34 AM
Subject: RE: traceroute


Is there a reason why you are doing stuff with the FORWARD chain?
Have you tried enabling ACCEPT for the FORWARD chain and seeing if it
works?

Generally, with the FORWARD chain, over all other chains you need to be
careful on how you use it. If used improperly, you could screw a lot of
things up on the network.

I would recommend trying it without any forward options.
Ie: iptables -P FORWARD ACCEPT

You need the ESTABLISHED,RELATED option for the INPUT chain.

# STEP 9 - ALLOW IN WHAT WE SEND OUT
####################################### $IPTABLES -A INPUT -m state
--state ESTABLISHED,RELATED -j ACCEPT

-----Original Message-----
From: Peter Marshall [mailto:peter.marshall@caris.com]
Sent: Wednesday, June 30, 2004 10:25 AM
To: Piszcz, Justin Michael; netfilter
Subject: Re: traceroute

I don't get anything (except the name lookup) from traceroute.

When I run a packet sniffer, I see the following (when doing a
traceroute on
www.google.com)

source     destination                 Proto
me           216.239.41.99          UDP            sourceport 1059
destination port 33435
3com       3com                         ARP            who has
<gatewayip>
tell <my ip>
3com        3com                        ARP            <gateway ip> is
at
<mac address>
me           216.239.41.99           UDP          soutceport: 1059
Destination port 33437
......

traceroute to www.google.akadns.net (216.239.39.147), 30 hops max, 38
byte
packets
 1  * * *
 2  * * *

Below are the relavant rules .... tracert is the ip of the box I am
trying
to traceroute form.
The Ip of that box is an internet routable ip addess.

$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
$IPT -A FORWARD -d <tracert box -i eth1 -j net-rh

$IPT -A rh-net -s <tracert box> -j ACCEPT
$IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT


Thank you again,
Peter.

----- Original Message ----- 
From: "Piszcz, Justin Michael" <justin.piszcz@mitretek.org>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 10:47 AM
Subject: RE: traceroute


Can you show me your firewall?
Can you paste the blocks you are seeing?
It does not get past the 1st hop, or?
Post an example traceroute?


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Wednesday, June 30, 2004 9:29 AM
To: netfilter
Subject: Re: traceroute

On Wednesday 30 June 2004 2:05 pm, Peter Marshall wrote:

> Hi.  I was wondering what I would need for rules to have traceroute
work
> through my firewall.  (I have a box behind the firewall trying to get
out
> using traceroute).
>
> I have an allow established connections on my forwared chain, and I am
> allowing anything from the source IP of the box in question to leave
... It
> appears that the problem is on the packets comming back in .. but I am
not
> sure what I have to do to fix it ....

Allow RELATED packets as well as ESTABLISHED.

Regards,

Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the
sense of
achievement you get from getting them to work at all. In other words -
and
this is the rock solid principle on which the whole of the Corporation's

Galaxy-wide success is founded - their fundamental design flaws are
completely hidden by their superficial design flaws."

 - Douglas Noel Adams

                                                     Please reply to the
list;
                                                           please don't
CC me.

Re: traceroute

[Antony Stone]

On Wednesday 30 June 2004 3:34 pm, Piszcz, Justin Michael wrote:

> -----Original Message-----
> From: Peter Marshall [mailto:peter.marshall@caris.com]
> Sent: Wednesday, June 30, 2004 10:25 AM
> To: Piszcz, Justin Michael; netfilter
> Subject: Re: traceroute
>
> I don't get anything (except the name lookup) from traceroute.
>
> Below are the relavant rules .... tracert is the ip of the box I am
> trying to traceroute form.
> The Ip of that box is an internet routable ip addess.
>
> $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPT -A FORWARD -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> $IPT -A FORWARD -s <tracert box> -o eth1 -j rh-net
> $IPT -A FORWARD -d <tracert box -i eth1 -j net-rh
>
> $IPT -A rh-net -s <tracert box> -j ACCEPT
> $IPT -A net-rh -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

You should allow ICMP packets through your system.

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.

Traceroute works by sending either ICMP "ping" (echo request) packets, or UDP 
packets to high port numbers (which are assumed not to be listening), 
depending on the Operating System of the client doing the traceroute.   In 
both cases the important response is an ICMP TTL exceeded packet, which 
contains the IP address of the router where TTL became == 0.

Remember that firewalling can be a dangerous topic - if you block things you 
don't understand, and therefore don't know that you should allow, some things 
will break.

Regards,

Antony.

-- 
Anything that improbable is effectively impossible.

 - Murray Gell-Mann, Nobel Prizewinner in Physics

                                                     Please reply to the list;
                                                           please don't CC me.

ICMP firewalling on today's internet

[Jason Lunz]

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

Re: ICMP firewalling on today's internet

[Antony Stone]

On Friday 02 July 2004 5:36 pm, 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?

Personally I'm happy with anything which gets classified as RELATED by 
netfilter.   I allow ESTABLISHED,RELATED packets in & out of my firewall, and 
I specify particular TCP & UDP ports (and a bit of ESP) which I want to allow 
through as well - I don't use any ICMP-specific rules.

Regards,

Antony.

-- 
"The future is already here.   It's just not evenly distributed yet."

 - William Gibson

                                                     Please reply to the list;
                                                           please don't CC me.

Re: ICMP firewalling on today's internet

[John A. Sullivan III]

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