Re: strange network traffic

From: Robert Synak (robert.synak@ellabean.com)
Date: 09/05/02


From: "Robert Synak" <robert.synak@ellabean.com>
To: <steven.schullo@born.com>, "'Johan De Meersman'" <jdm@operamail.com>, <security-basics@securityfocus.com>
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
http://www.nextgenss.com/advisories/mssql-udp.txt, about Microsoft MSDE
vulnerabilities.

----- Original Message -----
From: "Steven Schullo" <steven.schullo@born.com>
To: "'Johan De Meersman'" <jdm@operamail.com>;
<security-basics@securityfocus.com>
Sent: Thursday, September 05, 2002 8:12 AM
Subject: RE: strange network traffic

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> It would seem logical that an IDS can be configured to perform this
> task.
>
> Steven Schullo, CISSP, MCSE, CCNA
> BORN
> Dallas Infrastructure
> mailto:steven.schullo@born.com
>
> - -----Original Message-----
> From: Johan De Meersman [mailto:jdm@operamail.com]
> Sent: Wednesday, September 04, 2002 9:16 AM
> To: security-basics@securityfocus.com
> 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 sf.net 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
> >
> >192.168.0.2 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 blackhole.pca.dfn.de .
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 7.0.4
>
> iQA/AwUBPXd0VXG92AMJgCiGEQLesgCggbJ/u7+KDPPGeKYb6IMbw0HeEjoAn2Mu
> gtb5w35j2XF8ObhFuaeSVPVQ
> =/ZiC
> -----END PGP SIGNATURE-----
>
>



Relevant Pages

  • Re: Do I Have A Firewalled LAN Run By ISP In Between?
    ... from that host while at host ... running a layer within a layer, with a complex network address translation ... application called "Internet Connection Sharing". ... what those packets are for, ...
    (comp.security.firewalls)
  • Re: Still cant connect to RWW or OWA remotely
    ... No, I don't have a 3rd party firewall, and it's a pretty plain vanilla WinXP ... Connected to the network like the other workstations, ... I could go to any workstation and connect to them just fine. ... match the broadband connection, the two NIC firewall, the remote ...
    (microsoft.public.windows.server.sbs)
  • Re: Workgroup is not accessible.
    ... The only network connection with the ... firewall set was the dial-up connection, ... Even when it accesses the workgroup, ...
    (microsoft.public.windowsxp.network_web)
  • RE: Serious Security Issue in Windows XP SP2s Firewall
    ... file and printer sharing is available for network login from any network (I ... Internet Connection Sharing of the PC has to be disabled." ... Serious Security Issue in Windows XP SP2's Firewall ...
    (Focus-Microsoft)
  • Re: iptables and dhcp
    ... > the same physical network segment as the firewall and the remote DHCP ... You used INPUT and not FORWARD chain ... # This target allows packets to be marked in the mangle table ...
    (comp.os.linux.networking)