Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Incidents
[Top] [All Lists]

Re: unusual 1.11.0.0/16 outbound traffic

Subject: Re: unusual 1.11.0.0/16 outbound traffic
Date: Thu, 16 Sep 2004 23:01:01 -0400
Federico Grau wrote Tuesday, September 14, 2004 2:23 PM

We have been seeing an increasing amount of unusual network activity
trying to get out of our internal LAN.  What is most odd about this
traffic is that the traffic is directed to the 1.11.0.0./16 subnet (an
IANA
Reserved subnet, which I believe is to be used for VPNs).

One possibility is that there is VPN activity going on. The client
establishes the tunnel, creates connections to reserved addresses within the
VPN, then disconnects the tunnel while still having connections to resources
on the remote network. Windows would likely generate some of the traffic you
are seeing in that scenario.

While the VPN was running you would not see any traffic to the reserved
addresses because it would all be hidden inside the tunnel. Thus you
probably see no packets with data.

Client machines include several Microsoft operating systems; Windows 98,
Windows 2000, Windows XP.

We have captured outbound traffic using tcpdump, and looked at it
with ethereal.  No packets with "data" appear to be making it out.
The packets we have been seeing include; SMB "Tree Disconnect
Request", SMB "Echo Request", NBNS "Name query NBSTAT"
and some other "failed SMB" packets.

These would all appear to be consistent with a disconnected VPN scenario.

There is not enough information to say whether VPN afterglow is what you are
seeing. You might consider getting full packet captures for a few hours from
one of your machines that is persistently generating the odd traffic to see
what is going on. Capture all traffic, not just traffic to the reserved
addresses. Look at http traffic to see if users are accessing file transfer
services like foldershare, look for VPN on non-standard ports, etc.


<Prev in Thread] Current Thread [Next in Thread>