[prev in list] [next in list] [prev in thread] [next in thread]
List: dragonidsuser
Subject: Fw: [Dragonidsuser] TCP Snipe in a switch environment.
From: "Jason George" <list-dragon () lists ! resourcechain ! com>
Date: 2003-03-26 20:09:59
[Download RAW message or body]
For some reason, the contents of my post are getting filtered... let's try it \
again...
Ok, let's try to clear up the mechanics of this once and for all. I expect that \
others will chime in with details to support and/or refute some of my assumptions. \
I'm going to more of a pure electronic engineering approach (this will modify the \
perspective of "open" and "closed" failure. An open switch passes nothing. A closed \
switch passes current.) It's lunchtime so I'm going to make this fast... :-)
Taps - these are layer 1 devices, not layer 2. They duplicate the Manchester coding \
used on the wire from the input ports to the mirror ports. These are active devices \
because they require power to operate. They have failure mode of "closed", which \
implies that they will still pass traffic unimpeded should power be lost. Unless \
taps have more brains than I've been led to believe, they don't care about any layer \
2 framing.
Spans - these are logical layer 2 concepts. They duplicate the buffered memory of \
specifically-designated switch ports onto another designated destination port. The \
contents of these memory locations are Ethernet frames. I have a hard time believing \
that a modern intelligent multi-service switch is not going to reject or not have \
hard time with anything other than Ethernet framing being passed through the internal \
Layer1->2 interface. Spans could fail open or closed. When the logical \
configuration of span breaks, either no traffic will pass or some non-expected \
traffic pattern between ports will result. Most of the time, people will probably \
see the former rather than the latter. Spans can be uni or bi-directional. \
Personally, I don't see a lot of practical use in a corporate environment for spans \
that allow traffic injection. In fact, they are probably more of a liability.
Injecting packets - I haven't actively used the snipe functionality within Dragon, \
but there are only so many ways to put a packet on the wire... My version of the \
short form of the long story is that you can craft a packet and push it directly \
through the IP stack or you can craft a packet and jam it as directly to the wire as \
possible through libpcap. If we choose the first option, we can use extra attributes \
of the system's IP stack to help push the packet along... routes, traffic policies, \
etc. If we use the second option, we need to consciously add extra information as \
much as possible to get the packet from A to B, otherwise the packet will end up \
being framed and put on the wire with a relative effectiveness of the local collision \
domain. How is that packet supposed to know the intended target is 5 router hops \
away? It doesn't. And it might not even know how to get to the local next-hop if \
you force it out an interface that doesn't even have IP bound to it. If we have a \
one-way span or tap at the end of the "dumb" Ethernet interface, we have, in effect, \
a diode that prevents back-flow into the source. Even if we could craft that packet \
with enough extra info, we have a blockage at best Layer 2 and at worst Layer 1. Not \
a very effective plan to craft packets by hand without any extra ability to get it to \
a smart next-hop if there are layers lower in the OSI stack that are going to impede \
things.
As a result, it only makes common sense to source the packets from the management \
interface and not from the sensing interface. Providing there is no strong policy \
enforcing egress for packets of a certain IP address on that management interface, \
it's quite trivial to build your own IP packets and to push them through to their \
far-end destination. I don't believe that the majority of system architects are \
going to go out and try to re-invent the wheel when there are proven techniques for \
masquerading that are out there. There are also practical limitations enforced \
_below_ layers 3 and 4, depending on your architecture and implementation. Why build \
a product that will only work in certain operating conditions? That doesn't make any \
sense. The logical out is to design something that doesn't have to worry about such \
things because the level of abstraction is set appropriately (a.k.a. you are going to \
have the most flexibility pounding snipe packets out the management interface).
I can still think of a number of ways to source snipe packets from the sensing \
interface, though. My point is that these are not practical.
I strongly suggest that people go out and compile a copy of Nemesis and experiment on \
their own. This will really help people understand the practical boundaries that \
come with "sniping technology" http://www.packetfactory.net/projects/nemesis/
On the other hand, there are people out there who are waaaaay smarter at this than \
this guy. Dragon's snipe technology may operate in a different manner, but practical \
bounds would limit the "how".
Please feel free to comment...
--Jason
Jason George, P.Eng
Consulting somewhere in Canada...
PS - anyone going to CanSecWest 2003 in another 2 weeks? contact me offline at <jbg \
at masterplan dot org> for beer information... :-)
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.3315.2870" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV> </DIV>
<DIV><FONT size=2><FONT size=2>
<P><FONT face=Arial>For some reason, the contents of my post are getting
filtered... let's try it again...</FONT></P>
<P> </P>
<P><FONT face=Arial>Ok, let's try to clear up the mechanics of this once and for
all. I expect that others will chime in with details to support and/or
refute some of my assumptions. I'm going to more of a pure electronic
engineering approach (this will modify the perspective of "open" and "closed"
failure. An open switch passes nothing. A closed switch passes
current.) It's lunchtime so I'm going to make this fast... :-)</FONT></P>
<P><FONT face=Arial>Taps - these are layer 1 devices, not layer 2. They
duplicate the Manchester coding used on the wire from the input ports to the
mirror ports. These are active devices because they require power to
operate. They have failure mode of "closed", which implies that they will
still pass traffic unimpeded should power be lost. Unless taps have more
brains than I've been led to believe, they don't care about any layer 2
framing.</FONT></P>
<P><FONT face=Arial>Spans - these are logical layer 2 concepts. They
duplicate the buffered memory of specifically-designated switch ports
onto another designated destination port. The contents of these memory
locations are Ethernet frames. I have a hard time believing that a modern
intelligent multi-service switch is not going to reject or not have
hard time with anything other than Ethernet framing being passed through the
internal Layer1->2 interface. Spans could fail open or closed.
When the logical configuration of span breaks, either no traffic will pass or
some non-expected traffic pattern between ports will result. Most of the
time, people will probably see the former rather than the latter. Spans
can be uni or bi-directional. Personally, I don't see a lot of practical
use in a corporate environment for spans that allow traffic injection. In
fact, they are probably more of a liability.</FONT></P>
<P><FONT face=Arial>Injecting packets - I haven't actively used the snipe
functionality within Dragon, but there are only so many ways to put a packet on
the wire... My version of the short form of the long story is that you can
craft a packet and push it directly through the IP stack or you can craft a
packet and jam it as directly to the wire as possible through libpcap. If
we choose the first option, we can use extra attributes of the system's IP stack
to help push the packet along... routes, traffic policies, etc. If we use
the second option, we need to consciously add extra information as much as
possible to get the packet from A to B, otherwise the packet will end up being
framed and put on the wire with a relative effectiveness of the local collision
domain. How is that packet supposed to know the intended target is 5
router hops away? It doesn't. And it might not even know how to get
to the local next-hop if you force it out an interface that doesn't even have IP
bound to it. If we have a one-way span or tap at the end of the "dumb"
Ethernet interface, we have, in effect, a diode that prevents back-flow into the
source. Even if we could craft that packet with enough extra info, we have
a blockage at best Layer 2 and at worst Layer 1. Not a very effective plan
to craft packets by hand without any extra ability to get it to a smart next-hop
if there are layers lower in the OSI stack that are going to impede
things. </FONT></P>
<P><FONT face=Arial>As a result, it only makes common sense to source the
packets from the management interface and not from the sensing interface.
Providing there is no strong policy enforcing egress for packets of a certain IP
address on that management interface, it's quite trivial to build your own IP
packets and to push them through to their far-end destination. I don't
believe that the majority of system architects are going to go out and try to
re-invent the wheel when there are proven techniques for masquerading that are
out there. There are also practical limitations enforced _below_ layers 3
and 4, depending on your architecture and implementation. Why build a
product that will only work in certain operating conditions? That doesn't
make any sense. The logical out is to design something that doesn't have
to worry about such things because the level of abstraction is set appropriately
(a.k.a. you are going to have the most flexibility pounding snipe packets out
the management interface).</FONT></P>
<P><FONT face=Arial>I can still think of a number of ways to source snipe
packets from the sensing interface, though. My point is that these are not
practical.</FONT></P>
<P><FONT face=Arial>I strongly suggest that people go out and compile a copy of
Nemesis and experiment on their own. This will really help people
understand the practical boundaries that come with "sniping technology" <A
href="http://www.packetfactory.net/projects/nemesis/">http://www.packetfactory.net/projects/nemesis/</A></FONT></P>
<P><FONT face=Arial>On the other hand, there are people out there who are
waaaaay smarter at this than this guy. Dragon's snipe technology may
operate in a different manner, but practical bounds would limit the
"how".</FONT></P>
<P> </P>
<P><FONT face=Arial>Please feel free to comment...</FONT></P>
<P><FONT face=Arial>--Jason</FONT></P>
<P><FONT face=Arial>Jason George, P.Eng</FONT><FONT face=Arial></FONT></P>
<P><FONT face=Arial>Consulting somewhere in Canada...</FONT></P>
<P> </P>
<P><FONT face=Arial>PS - anyone going to CanSecWest 2003 in another 2
weeks? contact me offline at <jbg at masterplan dot org> for beer
information... :-)</FONT></P>
<P> </P></FONT></FONT></DIV></BODY></HTML>
_______________________________________________
Dragonidsuser mailing list
For help please follow the below instructions.
You can make subsciption adjustments via email by sending a message to:
Dragonidsuser-request@enterasys.com
with the word `help' in the subject or body (don't include the quotes), and you will \
get back a message with instructions.
You must know your password to change your options (including changing the password, \
itself) or to unsubscribe. If you forget your password, don't worry, you will \
receive a monthly reminder telling you what all your enterasys.com mailing list \
passwords are, and how to unsubscribe or change your options.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic