Re: strange network traffic

From: Robert Synak (
Date: 09/05/02

From: "Robert Synak" <>
To: <>, "'Johan De Meersman'" <>, <>
Date: Thu, 5 Sep 2002 13:10:55 -0700

Maybe not so wise to not have a firewall and trust a third party lurker to
disrupt traffic, given root can be sometimes gained with a single packet,
such as with MSDE: "an attacker can send a single UDP packet to port 1434
on the machine running MSDE and overflow a buffer gaining control of the
process' path of execution", from, about Microsoft MSDE

----- Original Message -----
From: "Steven Schullo" <>
To: "'Johan De Meersman'" <>;
Sent: Thursday, September 05, 2002 8:12 AM
Subject: RE: strange network traffic

> Hash: SHA1
> It would seem logical that an IDS can be configured to perform this
> task.
> Steven Schullo, CISSP, MCSE, CCNA
> Dallas Infrastructure
> - -----Original Message-----
> From: Johan De Meersman []
> Sent: Wednesday, September 04, 2002 9:16 AM
> To:
> Subject: Re: strange network traffic
> On the not having a firewall issue, there is an alternative solution:
> it
> is possible to have a parallel firewall instead of an inline one, ie.
> one that isn't the gateway, but just resides in the same segment as
> the
> other computers. While the possibilities are a bit different from the
> traditional one, it too can be a quite effective tool, and I'll try
> to
> explain the basics of how this works.
> When computer A wants to get a TCP connection to computer B, the
> following happens:
> A sends SYN to B
> B sends SYN/ACK to A
> A sends ACK to B
> -> connection established, following packets have neither SYN nor
> ACK set
> When either wants to terminate the connection, it sends a FIN
> packet, to which the other side should respond with another FIN
> packet. A rude alternative is to sent RST and just drop the
> connection.
> Now, the parallel firewall wil sniff all packets on the segment, and
> follow any traffic. If it detects a connection attempt or an ongoing
> connection that isn't allowed, it will spoof FIN and/or RST packets
> for
> both sides, thus effectively ending the connection. Simple, but very
> effective :)
> The big advantage of this is that it doesn't require any change at
> all
> on your network. It also allows easy monitoring and management of
> connections.
> Some downsides is that it doesn't work for UDP, ICMP (ping) or other
> non-structured connections, it's not capable of dropping packets (=
> hiding open ports), doing NAT or otherwise changing packets before
> they
> leave the network.
> I don't know any software that does this from the top of my head, but
> have a look at google and/or and I'm sure you'll find
> something
> useful.
> C Boening wrote:
> >We are experiencing some network activity which has me baffled. I am
> >relatively new to network security so I hope I won't get flamed too
> >bad . Here's what's going on:
> >About 2 months ago our sniffer (commview) started capturing traffic
> from
> >
> > as coming from our network. We have no such ip address.
> >All routers, switches, servers, annexes, printers , wireless,...
> >have been checked
> >hands on. No such IP asigned to any of our devices. The packets
> >coming from this ip contain the nbstat command. They are sent to
> >several of
> our
> >
> >servers only. Server responds with an answer to nbstat (the usual
> >stuff). 192 ip then sends traffic to several outside ip's, ie
> >doubleclick, uunet, and others. What could cause this traffic and
> >where could it possibly come from? Another sniffer, Capsa, shows
> >192 as
> >belonging to our intranet. We do not have a firewall (yes, I know,
> >but it's not up to me or my dept head), except for a couple which we
> >run on individual pc's . Purchasing a firewall at this time is not
> >an option. Can somebody help me out?
> >
> >
> - --
> Public GPG key at .
> Version: PGP 7.0.4
> iQA/AwUBPXd0VXG92AMJgCiGEQLesgCggbJ/u7+KDPPGeKYb6IMbw0HeEjoAn2Mu
> gtb5w35j2XF8ObhFuaeSVPVQ
> =/ZiC