network mystery

From: network-questions@excite.com
Date: 03/27/02


Date: 27 Mar 2002 00:24:38 -0000
From: <network-questions@excite.com>
To: incidents@securityfocus.com


('binary' encoding is not supported, stored as-is)

Here is the situation. Over the weekend, some
strange packets started showing up on my LAN. The
packets were captured by one of my IDS systems
which monitor outbound traffic. Analyzation of the 4
packets over the weekend, revealed that 2 of them
were generated using eEye's Retina (at least the
payload of the packet is consistent with Retina), and
the other 2 packets were created by Solarwinds IP
Network Browser (again the payload of the packet
was consistent with that of this tool). This is not what
is unusual. What is unusual is that the source
address is a public address, located in various parts
of the world (The US, France, Belgium, etc), and not
one of our private space addresses. The destination
address is always 192.168.1.70. 192.168.1.70 does
not exist on my network (we don't use this IP scheme
anywhere). The reason why the outbound sensor
detected this is because the core router is setup to
forward all packets it doesn't have a route to, to the
firewall and ultimately the Internet.

My network is a class B environment, but only a small
range of hosts are on the network, roughly 1000
devices (in the local LAN). There are 2 other
gateways; one of which is a WAN connection to other
offices, and the other is a collection of various
vendors who need access to our internal LAN for
various reasons. Most of the systems are running
W2K SP2, although there are various *nix systems
(AIX, Solaris, etc.) for various needs.

I have set up sniffers and sensors on the various
VLANs; including our WAN and vendor connections.
The traffic has happened several times on Monday
and Tuesday. But of course not on the vlans that
were being monitored. Most of the traffic is
generated between the hours of 2 am to 6:30 am,
and then again starting about 4:30pm until about
11pm. However the times are not consistent, nor is
there a discernable pattern. The volume of the traffic
is low. However since the weekend, the number of
packets that have been recorded have increased, but
I should mention that the traffic to date over the past 4
days has been less than 30 packets.

However, the traffic is different than what was
recorded over the weekend. All the traffic over the
weekend was ICMP echo-requests. There has only
been 1 ICMP packet since then, and it was a plain
vanilla ICMP packet with no payload (type 8). All the
other traffic recorded is TCP, with only the SYN flag
set, and the payload is empty. The traffic is destined
for port 80. The source port is random, between
3000 and 4500.

I have checked everything I can think of, from
verifying the times of VPN sessions to having every
single hard drive in the entire network scanned
searching for either eEye or Solarwinds. They are all
negative. My current pursuit is find a way to grab the
MAC address. At least if I have the MAC, and I can
check each VLAN's switch and trace the machine
back. I am still working on this. But, other than
having one of the sniffers locate which VLAN the
activity is coming from, I can think of no other choice
available to me.

Since I am posting this to incidents, I should state
that there is absolutely no sign of an intrusion, of
course, that doesn't mean much. :)

I have tried to speculate what tool could cause this.
Its a tool which spoofs its address (or at least
appears to), but always has the same destination.
So it would never expect a response to be returned to
it (assuming its spoofed). It generates ICMP packets,
that are either standard vanilla packets, Solarwinds,
or Retina. It generates TCP packets, to port 80 only,
but again, always to the same IP. There are no
payloads (other than the first 4 packets captured over
the weekend). And the destination address is a
private space address which is not used anywhere
on my network.

The only other thoughts I have is that perhaps this is
a malfunctioning file sharing tool (akin to Grokster,
KaZaA, etc.) The time of day, would be consistent
with someone who comes into work early (and stops
downloading), and then resumes the downloads
when they leave for the day. I can't confirm this yet,
nor can I explain how and/or why a file sharing tool
would act in this way.

Can anyone please offer some insight? Can you
think of anything else I can do? Has anyone seen
activity like this before? Any help, as always, is
greatly appreciated.

-md

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com



Relevant Pages

  • Re: [opensuse] SuseFirewall IPv4 vs IPv6
    ... # network security threats. ... # Opening ports for LAN services in the external zone defeats the ... # this setting only works for packets destined for the local machine. ... # If the protocol is icmp then port is interpreted as icmp type ...
    (SuSE)
  • Re: Ethernet issue: works one way but not another
    ... packets transmitted, 5 packets received, 0% packet loss ... (This is when connected directly to internet through ... FBSD, I have been working with BSDI at the isp I work for for the last ... As for my network topology, I have an internal network that goes ...
    (freebsd-questions)
  • Re: Update: UDP 770 Potential Worm
    ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
    (Incidents)
  • Re: IDSIPS that can handle one Gig
    ... especially with 64-byte UDP packets. ... There are plenty of network IPS's ... IDS/IPS devices through use of fragments. ... Find out quickly and easily by testing it with real-world attacks from ...
    (Focus-IDS)
  • 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)