TTL patch buggy?

TTL patch buggy?

[John A. Sullivan III]

I noticed a recent post on the netfilter list about the TTL patch being buggy. 
We were planning to make extensive use of it in the ISCS project.  I've
not seen anything recent about such a bug in a google search.  Is there
currently a known problem with this patch? Thanks - 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

Re: TTL patch buggy?

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Fri, Jan 02, 2004 at 10:02:13AM -0500, John A. Sullivan III wrote:
> I noticed a recent post on the netfilter list about the TTL patch
> being buggy.  

Could you please point me to that posting (either message-id or a URL
pointing to the archives?)

> We were planning to make extensive use of it in the ISCS
> project.  I've not seen anything recent about such a bug in a google
> search.  Is there currently a known problem with this patch? Thanks -

I (the author) am not aware of any current problem.

If there are bugs/problems, they should be submitted to
bugzilla.netfilter.org

> John

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: TTL patch buggy?

[John A. Sullivan III]

Ugh!! I'll have to see if I can find it.  I'm sure I deleted it.  It was
just an obscure reference to a bug in TTL but was not specific.  We are
planning to not only use the TTL patch in ISCS to create stealth
firewalls but also to secure communications between internal and DMZ
systems by allowing admins to set TTL on a per service basis to allow
the DMZ <-> Internal flow to only have enough life to live on the site
and not to be set anywhere else on the Internet.  We think this is a
pretty interesting feature and hence are keen on the TTL patch working. 
Thanks for the update - John

On Tue, 2004-01-06 at 13:56, Harald Welte wrote:
> On Fri, Jan 02, 2004 at 10:02:13AM -0500, John A. Sullivan III wrote:
> > I noticed a recent post on the netfilter list about the TTL patch
> > being buggy.  
> 
> Could you please point me to that posting (either message-id or a URL
> pointing to the archives?)
> 
> > We were planning to make extensive use of it in the ISCS
> > project.  I've not seen anything recent about such a bug in a google
> > search.  Is there currently a known problem with this patch? Thanks -
> 
> I (the author) am not aware of any current problem.
> 
> If there are bugs/problems, they should be submitted to
> bugzilla.netfilter.org
> 
> > John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com

Re: TTL patch buggy?

[Henrik Nordstrom]

On Tue, 6 Jan 2004, John A. Sullivan III wrote:

> Ugh!! I'll have to see if I can find it.  I'm sure I deleted it.  It was
> just an obscure reference to a bug in TTL but was not specific.  We are
> planning to not only use the TTL patch in ISCS to create stealth
> firewalls but also to secure communications between internal and DMZ
> systems by allowing admins to set TTL on a per service basis to allow
> the DMZ <-> Internal flow to only have enough life to live on the site
> and not to be set anywhere else on the Internet.  We think this is a
> pretty interesting feature and hence are keen on the TTL patch working. 

Take care to never increase the TTL value however.

There is no technical problems from artificially decreasing the TTL, but 
increasing should never be done unless you are 200% sure on what you are 
doing (and even then you should not).

The TTL target is dangerous in the sense that it allows the packet ttl to
be set freely with no restrictions. But if combined with a "-m ttl
--ttl-gt NEWVALUE" then you should be safe.

Harald: What do you think about making the patch civilised and restricting
the TTL to be set to lower values only eleminating the need of the above
safeguard match? (simply change "new_ttl != iph->ttl" to "new_ttl < 
iph->ttl")

Regards
Henrik

Re: TTL patch buggy?

[John A. Sullivan III]

On Wed, 2004-01-07 at 11:16, Henrik Nordstrom wrote:
> On Tue, 6 Jan 2004, John A. Sullivan III wrote:
> 
> > <snip>.  We are
> > planning to not only use the TTL patch in ISCS to create stealth
> > firewalls but also to secure communications between internal and DMZ
> > systems by allowing admins to set TTL on a per service basis to allow
> > the DMZ <-> Internal flow to only have enough life to live on the site
> > and not to be set anywhere else on the Internet.  We think this is a
> > pretty interesting feature and hence are keen on the TTL patch working. 
> 
> Take care to never increase the TTL value however.
> 
> There is no technical problems from artificially decreasing the TTL, but 
> increasing should never be done unless you are 200% sure on what you are 
> doing (and even then you should not).
> 
> The TTL target is dangerous in the sense that it allows the packet ttl to
> be set freely with no restrictions. But if combined with a "-m ttl
> --ttl-gt NEWVALUE" then you should be safe.
> 
> Harald: What do you think about making the patch civilised and restricting
> the TTL to be set to lower values only eleminating the need of the above
> safeguard match? (simply change "new_ttl != iph->ttl" to "new_ttl < 
> iph->ttl")
> 
> Regards
> Henrik

Thank you very much but could you please explain this a bit more.  Oskar
Andreasson's tutorial explicitly mentions doing this, i.e., incrementing
TTL and we thought it was a good idea.  We certainly want to change our
ways if this is dangerous.  Here is the excerpt from the tutorial:

The --ttl-inc option tells the TTL target to increment the Time To Live
value with the value specified to the --ttl-inc option. This means that
we should raise the TTL value with the value specified in the --ttl-inc
option, and if we specified --ttl-inc 4, a packet entering with a TTL of
53 would leave the host with TTL 56. Note that the same thing goes here,
as for the previous example of the --ttl-dec option, where the network
code will automatically decrement the TTL value by 1, which it always
does. This may be used to make our firewall a bit more stealthy to
trace-routes among other things. By setting the TTL one value higher for
all incoming packets, we effectively make the firewall hidden from
trace-routes.
-- 
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 

Re: TTL patch buggy?

[Antony Stone]

On Wednesday 07 January 2004 7:04 pm, John A. Sullivan III wrote:

> On Wed, 2004-01-07 at 11:16, Henrik Nordstrom wrote:
> >
> > The TTL target is dangerous in the sense that it allows the packet ttl to
> > be set freely with no restrictions. But if combined with a "-m ttl
> > --ttl-gt NEWVALUE" then you should be safe.
> >
> > Harald: What do you think about making the patch civilised and
> > restricting the TTL to be set to lower values only eleminating the need
> > of the above safeguard match? (simply change "new_ttl != iph->ttl" to
> > "new_ttl < iph->ttl")
> >
> > Regards
> > Henrik
>
> Thank you very much but could you please explain this a bit more.  Oskar
> Andreasson's tutorial explicitly mentions doing this, i.e., incrementing
> TTL and we thought it was a good idea.  We certainly want to change our
> ways if this is dangerous.  Here is the excerpt from the tutorial:
>
> The --ttl-inc option tells the TTL target to increment the Time To Live
> value with the value specified to the --ttl-inc option. This means that
> we should raise the TTL value with the value specified in the --ttl-inc
> option, and if we specified --ttl-inc 4, a packet entering with a TTL of
> 53 would leave the host with TTL 56. Note that the same thing goes here,
> as for the previous example of the --ttl-dec option, where the network
> code will automatically decrement the TTL value by 1, which it always
> does. This may be used to make our firewall a bit more stealthy to
> trace-routes among other things. By setting the TTL one value higher for
> all incoming packets, we effectively make the firewall hidden from
> trace-routes.

The whole point of the TTL field in IP headers in the first place was to avoid 
routing loops (small or large).

TTL gets decremented by every router a packet passes through, so that 
eventually after passing through some (larger than is reasonable for a normal 
journey) number of routers, the packet gets discarded.   In normal 
circumstances this does not happen, however when it does happen it is 
important that it happens correctly.

If you ever increase the value of TTL on a packet's journey through a router, 
then a routing loop involving that router will not be detected unless the 
number of other routers involved in the loop is at least as many as the 
amount you have increased the TTL by.

Therefore I would suggest that leaving TTL as it is (ie: not decrementing it, 
but not incrementing it either) on its way through a router is just about 
acceptable (and this will prevent the machien from showing up in traceroutes, 
which I understand is the requirement here?), but incrementing it so that its 
value on leaving a machine is any higher than it was on arriving at the 
machine is a Very Bad Idea(TM).

IMHO & YMMV, etc...

Antony.

-- 
This is not a rehearsal.
This is Real Life.

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

Re: TTL patch buggy?

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

On Wed, Jan 07, 2004 at 05:16:51PM +0100, Henrik Nordstrom wrote:
> Harald: What do you think about making the patch civilised and restricting
> the TTL to be set to lower values only eleminating the need of the above
> safeguard match? (simply change "new_ttl != iph->ttl" to "new_ttl < 
> iph->ttl")

No. The most common use of the TTL target is to re-increment the ttl to
64 at the gateway.  This is for br0ken ISP's that don't allow you to use
a router behind your DSL line.  They check if the TTL is one of the
commonly-used values (32,64,128).. .if it is an odd number, they drop
the packet.

Yes, it is dangerous.  That's why we didn't put it in the stock kernel.
But still, it has valid uses :(

> Regards
> Henrik

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: TTL patch buggy?

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

On Wed, Jan 07, 2004 at 02:04:36PM -0500, John A. Sullivan III wrote:
> Thank you very much but could you please explain this a bit more.  Oskar
> Andreasson's tutorial explicitly mentions doing this, i.e., incrementing
> TTL and we thought it was a good idea.  We certainly want to change our
> ways if this is dangerous.  Here is the excerpt from the tutorial:

Well, as indicated in my last emai:

1) it is dangerous to increment the TTL
2) still, there are vallid uses.

In gerneral, incrementing packets heading towards your internal network
shouldn't be a problem.  If people want to hide their internal network
structure from traceroute, they have two options:

a) drop all packets that have a ttl < number_of_hops_in_internal_net
b) increment the TTL by number_of_hops_in_internal_net

Both ways make sure that the TTL never expires on a router in the
internal network.

Where 'a' would interrupt traffic, and 'b' would make sure traffic
passes.

Also, sometimes ISP's try to detect if you are running a router/gateway
behind your DSL line by checking for well-known TTL values.  In this
case, setting the TTL 

The most dangerous cases of incrementing the TTL are:

a) incrementing the TTL of transit traffic (not close to sender or
receiver)
b) incrementing the TTL of multicast traffic
> John A. Sullivan III

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: TTL patch buggy?

[John A. Sullivan III]

On Wed, 2004-01-07 at 14:35, Harald Welte wrote:
> On Wed, Jan 07, 2004 at 02:04:36PM -0500, John A. Sullivan III wrote:
> > Thank you very much but could you please explain this a bit more.  Oskar
> > Andreasson's tutorial explicitly mentions doing this, i.e., incrementing
> > TTL and we thought it was a good idea.  We certainly want to change our
> > ways if this is dangerous.  Here is the excerpt from the tutorial:
> 
> Well, as indicated in my last emai:
> 
> 1) it is dangerous to increment the TTL
> 2) still, there are vallid uses.
> 
> In gerneral, incrementing packets heading towards your internal network
> shouldn't be a problem.  If people want to hide their internal network
> structure from traceroute, they have two options:
> 
> a) drop all packets that have a ttl < number_of_hops_in_internal_net
> b) increment the TTL by number_of_hops_in_internal_net
> 
> Both ways make sure that the TTL never expires on a router in the
> internal network.
> 
> Where 'a' would interrupt traffic, and 'b' would make sure traffic
> passes.
<snip>
Thanks to all of you for such insightful replies.  As I synthesize them,
I see some problems and a possible solution.
1) Incrementing does create the possibility of routing loops although
this is minimal for end points.
2) Dropping packets with ttl < number_of_internal_hops may be safer but
requires a knowledge of the internal environment and incurs an overhead
with every internal change.
3) sysctl seems to provide no way to simply not send ttl expired
messages
4) If the goal is simply to hide the firewall, could one just drop all
packets where ttl == 1.  These packets would never make it only the
internal network anyway; it does not require incrementing ttl and 
requires no knowledge of the internal network.  I assume that, since one
can prevent the ttl expired from being sent by incrementing, that
netfilter will grab and drop the packet before the ttl expired
notification is sent.  Is there a problem with this approach?
-- 
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 

Re: TTL patch buggy?

[Ramin Dousti]

On Wed, Jan 07, 2004 at 02:04:36PM -0500, John A. Sullivan III wrote:

> 
> Thank you very much but could you please explain this a bit more.

The whole TTL concept is meant to deal with the routing loops. Just
imagine what happens if there is a routing loop between your gateway
and the ISP's upstream router. The packets would be bouncing back and
forth forever (until your gateway is rebooted) and the throughput
of your bandwidth would drop to +-zerro.

Now if you anticipate no routing loop (which is extremely unlikely
in the current architecture of how the ISP's do business) you should
be fine. However, these routing loops could happen when people start
mixing the TTL-increments with MIRROR:

http://www.netfilter.org/security/2001-08-22-mirror.html

Ramin

Re: TTL patch buggy?

[Ramin Dousti]

On Wed, Jan 07, 2004 at 07:18:26PM +0000, Antony Stone wrote:

> The whole point of the TTL field in IP headers in the first place was to avoid 
> routing loops (small or large).

Absolutely.

> 
> TTL gets decremented by every router a packet passes through, so that 
> eventually after passing through some (larger than is reasonable for a normal 
> journey) number of routers, the packet gets discarded.   In normal 
> circumstances this does not happen, however when it does happen it is 
> important that it happens correctly.
> 
> If you ever increase the value of TTL on a packet's journey through a router, 
> then a routing loop involving that router will not be detected unless the 
> number of other routers involved in the loop is at least as many as the 
> amount you have increased the TTL by.

Good point. I like the formulation :-)

> Therefore I would suggest that leaving TTL as it is (ie: not decrementing it, 
> but not incrementing it either) on its way through a router is just about 
> acceptable (and this will prevent the machien from showing up in traceroutes, 
> which I understand is the requirement here?)

All that said, I believe there is no harm in incrementing the TTL for the
inbound packets __iff__ one's network is not that deep and most definitely not
a transit network.

Ramin



> but incrementing it so that its 
> value on leaving a machine is any higher than it was on arriving at the 
> machine is a Very Bad Idea(TM).
> 
> IMHO & YMMV, etc...
> 
> Antony.
> 
> -- 
> This is not a rehearsal.
> This is Real Life.
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 

Re: TTL patch buggy?

[Henrik Nordstrom]

On Wed, 7 Jan 2004, Ramin Dousti wrote:

> Can you explain (b) a bit more, Harald? Multicast traffic is being
> dealt with by the routers in exactly the same way as the unicast
> traffic with regards to the TTL (as far as I understand it).

Yes, but the difference is that multicast does actually use the ttl to 
limit the scope of how wide the traffic is distributed, as opposed to most 
other protocols just using the ttl to kill forwarding loops.

Regards
Henrik

Re: TTL patch buggy?

[Henrik Nordstrom]

On Wed, 7 Jan 2004, Ramin Dousti wrote:

> Can you explain (b) a bit more, Harald? Multicast traffic is being
> dealt with by the routers in exactly the same way as the unicast
> traffic with regards to the TTL (as far as I understand it).

Yes, but the difference is that multicast does actually use the ttl to 
limit the scope of how wide the traffic is distributed, as opposed to most 
other protocols just using the ttl to kill forwarding loops.

Regards
Henrik

Re: TTL patch buggy?

[Ramin Dousti]

On Wed, Jan 07, 2004 at 08:35:47PM +0100, Harald Welte wrote:

> The most dangerous cases of incrementing the TTL are:
> 
> a) incrementing the TTL of transit traffic (not close to sender or receiver)
> b) incrementing the TTL of multicast traffic

Can you explain (b) a bit more, Harald? Multicast traffic is being
dealt with by the routers in exactly the same way as the unicast
traffic with regards to the TTL (as far as I understand it).
Or did you mean by "multicast traffic", the IGMP messages?

Appreciate the explanation.

Ramin

Re: TTL patch buggy?

[Ramin Dousti]

On Wed, Jan 07, 2004 at 03:07:22PM -0500, John A. Sullivan III wrote:

> <snip>
> Thanks to all of you for such insightful replies.  As I synthesize them,
> I see some problems and a possible solution.
> 1) Incrementing does create the possibility of routing loops although
> this is minimal for end points.
> 2) Dropping packets with ttl < number_of_internal_hops may be safer but
> requires a knowledge of the internal environment and incurs an overhead
> with every internal change.
> 3) sysctl seems to provide no way to simply not send ttl expired
> messages
> 4) If the goal is simply to hide the firewall, could one just drop all
> packets where ttl == 1.

You can hide the firewall and the internal network if you reset the
TTL of these packets to the max (255) and drop the outbound ICMP
port unreachable (in case of UDP traceroute) and ICMP echo-reply
(in case of ICMP traceroute). But again, make sure you're not transit
and no-one inside is playing with stuff like MIRROR.

Ramin


> These packets would never make it only the
> internal network anyway; it does not require incrementing ttl and 
> requires no knowledge of the internal network.  I assume that, since one
> can prevent the ttl expired from being sent by incrementing, that
> netfilter will grab and drop the packet before the ttl expired
> notification is sent.  Is there a problem with this approach?
> -- 
> 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 
> 

Re: TTL patch buggy?

[Ramin Dousti]

On Wed, Jan 07, 2004 at 09:54:05PM +0100, Henrik Nordstrom wrote:

> On Wed, 7 Jan 2004, Ramin Dousti wrote:
> 
> > Can you explain (b) a bit more, Harald? Multicast traffic is being
> > dealt with by the routers in exactly the same way as the unicast
> > traffic with regards to the TTL (as far as I understand it).
> 
> Yes, but the difference is that multicast does actually use the ttl to 
> limit the scope of how wide the traffic is distributed, as opposed to most 
> other protocols just using the ttl to kill forwarding loops.

Absolutely. For a sec I forgot all about the dense mode. Thanks, Henrik.
However, I still don't see any "danger" about this. It might not be
desirable but not dangerous, as multicast forwarding has a builtin mechanism
against the loops.

Ramin

> Regards
> Henrik

Re: TTL patch buggy?

[Henrik Nordstrom]

On Wed, 7 Jan 2004, Ramin Dousti wrote:

> Absolutely. For a sec I forgot all about the dense mode. Thanks, Henrik.
> However, I still don't see any "danger" about this.

The danger is in if you forget about this and set the TTL on multicast as 
if it was normal traffic. You then allow this multicast traffic to be 
distributed widely outside your network even if the originator had taken 
care to make sure distribution is not allowed far beyond the local 
networks.

Regards
Henrik

Re: TTL patch buggy?

[Henrik Nordstrom]

On Wed, 7 Jan 2004, Ramin Dousti wrote:

> Absolutely. For a sec I forgot all about the dense mode. Thanks, Henrik.
> However, I still don't see any "danger" about this.

The danger is in if you forget about this and set the TTL on multicast as 
if it was normal traffic. You then allow this multicast traffic to be 
distributed widely outside your network even if the originator had taken 
care to make sure distribution is not allowed far beyond the local 
networks.

Regards
Henrik

Re: TTL patch buggy?

[Cedric Blancher]

Le mer 07/01/2004 à 22:38, Ramin Dousti a écrit :
> You can hide the firewall and the internal network if you reset the
> TTL of these packets to the max (255) and drop the outbound ICMP
> port unreachable (in case of UDP traceroute) and ICMP echo-reply
> (in case of ICMP traceroute).

Avoiding traceroutes can't be easily done by blocking consequences, as
they are numerous. I mean you can do a traceroute using TCP as well (see
tcptraceroute tool), or even using applications requests on UDP, such as
a DNS request (useful to traceroute microsoft.com DNS server), or
anything else that can trigger a valuable target response. In thoses
cases, you really can't block final answer as it is a valid one.

Moreover, if blocking echo-reply is no arm, blocking ICMP errors can
have really bad side effects. If we look a bit closer, a well configured
firewall should not let a packet destined to a closed UDP port go
through... Letting conntrack deal with ICMP error is to me the best
deal.

If you really want to prevent traceroute based discoveries, you just
should raise packets TTL so they don't expire within your network for
normal operations. So you'll add 2, 3, maybe 4 to the TTL, but not more.
Resetting TTL to 255 is far too much if a loop appears.
If you want to prevent discovery based on the TTL of packets you send,
reset TTL for outbound traffic to a default value such as 64.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread! 

Re: TTL patch buggy?

[Ramin Dousti]

On Thu, Jan 08, 2004 at 09:02:06AM +0100, Cedric Blancher wrote:

> Avoiding traceroutes can't be easily done by blocking consequences, as
> they are numerous. I mean you can do a traceroute using TCP as well (see
> tcptraceroute tool), or even using applications requests on UDP, such as
> a DNS request (useful to traceroute microsoft.com DNS server), or
> anything else that can trigger a valuable target response. In thoses
> cases, you really can't block final answer as it is a valid one.

traceroute based on application specific characteristics is, IMPV,
easier to prevent as one should know what applications are running internally
and who should have access to them. If its a public service, then,
it does exist and everyone is aware of it. To prevent the visibility
of the intermediate hops, increasing the TTL and/or blocking the ICMP
TTL exceeded is the solution.

> Moreover, if blocking echo-reply is no arm, blocking ICMP errors can
> have really bad side effects. If we look a bit closer, a well configured
> firewall should not let a packet destined to a closed UDP port go
> through...

Very good point.

> Letting conntrack deal with ICMP error is to me the best deal.
> 
> If you really want to prevent traceroute based discoveries, you just
> should raise packets TTL so they don't expire within your network for
> normal operations. So you'll add 2, 3, maybe 4 to the TTL, but not more.
> Resetting TTL to 255 is far too much if a loop appears.

Yes. but the original question was, "what if one doesn't know the depth
of the internal network".

> If you want to prevent discovery based on the TTL of packets you send,
> reset TTL for outbound traffic to a default value such as 64.

Yes, Harald had a comprehensive email, outlining different scenarios and
what to do in each case.

Ramin

> 
> -- 
> http://www.netexit.com/~sid/
> PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
> >> Hi! I'm your friendly neighbourhood signature virus.
> >> Copy me to your signature file and help me spread! 

Re: TTL patch buggy?

[Cedric Blancher]

Le jeu 08/01/2004 à 17:25, Ramin Dousti a écrit :
> Yes. but the original question was, "what if one doesn't know the depth
> of the internal network".

Sorry, I missed that very point. My mistake.
In this very case, it's a bit tricky to play with TTL ;)

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread! 

Re: TTL patch buggy?

[Ramin Dousti]

On Thu, Jan 08, 2004 at 08:14:14AM +0100, Henrik Nordstrom wrote:

> On Wed, 7 Jan 2004, Ramin Dousti wrote:
> 
> > Absolutely. For a sec I forgot all about the dense mode. Thanks, Henrik.
> > However, I still don't see any "danger" about this.
> 
> The danger is in if you forget about this and set the TTL on multicast as 
> if it was normal traffic. You then allow this multicast traffic to be 
> distributed widely outside your network even if the originator had taken 
> care to make sure distribution is not allowed far beyond the local 
> networks.

OK, agreed. But in general when multicasting private data, meant only
for the local nets, one must not rely on the TTL (set by the originator)
to limit the distribution. And I'm sure a well-guarded corporation
doesn't do that.

Now I'm going to shut up and learn from you, gods of the linux tcp/ip
security subsystem.

Thanks again for sharing the knowledge.

Ramin

> Regards
> Henrik

RE: TTL patch buggy?

[bmcdowell]

Cedric wrote:
>If you want to prevent discovery based on the TTL of packets you send,
>reset TTL for outbound traffic to a default value such as 64.

I agree.  This is most useful for making it a tad more difficult to detect which OS you've chosen.

Also, incrementing the TTL is useful for obscuring NAT, as mentioned earlier.  This is helpful for HoneyPots where a single box/service is covering more than one IP/port.

For the interested, I can submit my own setup as an example.


Bob

Re: TTL patch buggy?

[Antony Stone]

On Friday 02 January 2004 1:13 pm, John A. Sullivan III wrote:

> I noticed a recent post on this list about the TTL patch being buggy.
> We were planning to make extensive use of it in the ISCS project.  I've
> not seen anything recent about such a bug in a google search.  Is there
> currently a known problem with this patch? Thanks - John

I think you may find the developers' list a better place to get a response to 
this sort of question.

Regards,

Antony.

-- 
You can spend the whole of your life trying to be popular,
but at the end of the day the size of the crowd at your funeral
will be largely dictated by the weather.

 - Frank Skinner

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

TTL patch buggy?

[John A. Sullivan III]

I noticed a recent post on this list about the TTL patch being buggy. 
We were planning to make extensive use of it in the ISCS project.  I've
not seen anything recent about such a bug in a google search.  Is there
currently a known problem with this patch? Thanks - 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