* RE: traceroute
@ 2004-06-30 14:34 Piszcz, Justin Michael
2004-06-30 14:50 ` traceroute Peter Marshall
2004-06-30 14:57 ` traceroute Antony Stone
0 siblings, 2 replies; 6+ messages in thread
From: Piszcz, Justin Michael @ 2004-06-30 14:34 UTC (permalink / raw)
To: Peter Marshall, netfilter
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: traceroute
2004-06-30 14:34 traceroute Piszcz, Justin Michael
@ 2004-06-30 14:50 ` Peter Marshall
2004-06-30 14:57 ` traceroute Antony Stone
1 sibling, 0 replies; 6+ messages in thread
From: Peter Marshall @ 2004-06-30 14:50 UTC (permalink / raw)
To: Piszcz, Justin Michael, netfilter
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: traceroute
2004-06-30 14:34 traceroute Piszcz, Justin Michael
2004-06-30 14:50 ` traceroute Peter Marshall
@ 2004-06-30 14:57 ` Antony Stone
2004-07-02 16:36 ` ICMP firewalling on today's internet Jason Lunz
1 sibling, 1 reply; 6+ messages in thread
From: Antony Stone @ 2004-06-30 14:57 UTC (permalink / raw)
To: netfilter
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* ICMP firewalling on today's internet
2004-06-30 14:57 ` traceroute Antony Stone
@ 2004-07-02 16:36 ` Jason Lunz
2004-07-04 13:07 ` Antony Stone
2004-07-05 11:58 ` John A. Sullivan III
0 siblings, 2 replies; 6+ messages in thread
From: Jason Lunz @ 2004-07-02 16:36 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ICMP firewalling on today's internet
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
1 sibling, 0 replies; 6+ messages in thread
From: Antony Stone @ 2004-07-04 13:07 UTC (permalink / raw)
To: netfilter
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: ICMP firewalling on today's internet
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
1 sibling, 0 replies; 6+ messages in thread
From: John A. Sullivan III @ 2004-07-05 11:58 UTC (permalink / raw)
To: Jason Lunz; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-07-05 11:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.