I will be on vacation from November 12 through November 26. If you need assistance before then, please contact Mark Miller at 659-4343.
>>> "Firewalls @
GreatCircle .
COM" 11/15/97 03:00 >>>
Firewalls-Digest Saturday, November 15 1997 Volume 06 : Number 542
In this issue:
Re: Hijak detection
Frontend for TCPDUMP sniffer :)))
Firewalls-Digest V6 #541 -Reply
See the end of the digest for information on subscribing to the Firewalls
or Firewalls-Digest mailing lists and on how to retrieve back issues.
----------------------------------------------------------------------
Date: Sat, 15 Nov 1997 00:34:28 -0600 (CST)
From: Jason Keimig <jkeimig @
idir .
net>
Subject: Re: Hijak detection
> > The duplication is not as severe as you would see with a hijacked session.
> >You will generally see several hundred ACKed packets thrown around for each
> >new packet introduced by the hijacker.
>
> It seems to me that an expert attacker would have no problem in taking over
> the session without producing a couple of hundred of unexpected ACKed packets.
The point was that the attacker himself does not participate in the ACK food
fight. Its a result of the two valid endpoints that are in a desynced
state: one is trying to tell the other what its idea of the current state
the connection should be. A dropped packet is the only way to end this
spat, given reliable network stacks on an unreliable medium.
> > This is true if you look at only a single ACK on one side of the stream. If
> >you compare the ACKs from both sides, you can see the side that has been
> >spoon-fed data by the attacker as their ACK # will be higher than the
> >supposedly corresponding SEQ # of the unmolested side. This is due to the
> >fact that the SEQ/ACK pair is based solely on the # of bytes sent/received
> >after the session has been established.
> > This pair is by no means a security mechanism in the purest sense. It is
> >used primary to keep the sides in synch with one another. The fact that
> >it prevents accepting data out of order is really just a security side
> >effect inherent with connection-oriented bitstreams.
> >
>
> If the "good-guy"'s system on the remote side is brought to its knees (via
> a Denial-of-Service attack, etc.), then there is nothing really to compare
What denial of service attacks prevent a host from responding to flows that
are already in a CONNECTED state? Okay, the F00F bug just made the
headlines, but there are a large number of other types of boxes out there
that you just simply can't lock up. Heck, before the F00F storm, what could
you do to lock up x86 boxes with the type of DoS you describe?
> against. Also, it is trivial for seasoned hackers to supply the Sequence
> Numbers as well as pretty much any other info you would expect to find in
> the packets.
The information forgery is a given from the evil side. You simply cannot
get around (as the attacker) what the unsuspecting hosts will spit out onto
a shared medium. Whats the multicast paradigm? "Anybody can send, receivers
just selectively ignore." So here, the receiver (monitor) "decides" to
listen everybody.... what's an attacker to do?
- -Jason
------------------------------
Date: Sat, 15 Nov 1997 06:51:01 +0100
From: Guido Stepken <stepken @
edina .
xnc .
com>
Subject: Frontend for TCPDUMP sniffer :)))
Dan Stromberg wrote:
>
> Where's the GUI for tcpdump?
>
> In article <3468070E .
2E70CC81 @
edina .
xnc .
com> you write:
> <Bob Hauck wrote:
> <>
> <> In article <Pine .
BSF .
3 .
96 .
971108175621 .
1632B-100000 @
tasam .
com>,
> <> Security Adm <security @
tasam .
com> writes:
> <>
> <> > I am sorry but I had to through this in... for a skewl project I went to
> <> > the BVA(gov't vertan agency of some kind) an I got to work with a 30,000
> <> > dollar packet sniffer. Why the hell they spent 30 grand on it I don't
> <> > know, but this is where our money is going to.
> <>
> <> We have a "30,000 dollar packet sniffer", an HP Internet Advisor.
> <> There's more to it than just sniffing though.
> <>
> <> This particular box can decode just about every protocol known to
> <> man (TCP, IPX, SNA, AppleTalk, etc etc), it can speak most
> <> flavors of ethernet and things like V.35 and RS-232 as well. You
> <> can hook it directly to a T1 (built-in CSU/DSU) and decode frame
> <> relay packets, evaluate timing, etc. The whole right-hand side
> <> of it is covered with jacks for plugging in various types of
> <> media.
> <>
> <> In short, it does a *lot* of things besides sniff packets. This
> <> box is more of a general-purpose LAN and WAN evaluator tool. 99%
> <> of the time you don't need it, but the 1% is worth thousands of
> <> billable dollars <g>.
> <
> <Oh, TCPDUMP seems to be able to do more (there is a GUI even for it :))
> <, e.g. ISDN.
> <
> <regards, Guido Stepken
http://www.cs.uit.no/~sveinarr/XTcpdump/
http://ftp.sunet.se/ftp/pub/security/tools/net/tcpshow/
And, besides the new tcpdump versions, also have a look at the
uncocumented feature "-D" in older tcpdump versions. With it you can see
login passwords running across the screen :) They found this feature to
be too dangerous. I made my own new tcpdump version with ISDN and "-D"
and i love it.
It's free, it's better - its LINUX
------------------------------
Date: Sat, 15 Nov 1997 02:48:43 -0500
From: BRAD LOWE <LOWEB @
yankeegas .
com>
Subject: Firewalls-Digest V6 #541 -Reply
I will be out of the office until Friday, November 21st. If you need support prior to that date please contact the Help Desk at 639-4357 (they can page me if necessary). Thank you.
------------------------------
End of Firewalls-Digest V6 #542
*******************************
To unsubscribe from Firewalls-Digest, send the following command
in the body of a message to "Majordomo @
GreatCircle .
COM":
unsubscribe firewalls-digest
If you want to subscribe or unsubscribe an address other than the
account the mail is coming from, such as a local redistribution list,
then append that address to the command; for example, to subscribe
"local-firewalls":
subscribe firewalls-digest local-firewalls @
your .
domain .
net
A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "firewalls-digest"
in the commands above with "firewalls".
Compressed back issues are available for anonymous FTP from
FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN"
is the volume number, and "MMM" is the issue number).
|
|
