[OPLINTECH] Port Scans from Domain Controllers

[Chad Neeper]

NOTICE:  Lengthy, wordy, confusing, and probably boring reply ahead:

I don't know your knowledge level regarding packet-level communication, so =
I'm just going to blast ahead and hope you (or anyone else) don't take =
offense to anything I say!

Based on the log entries you copied, it looks to me more like what I =
suggested before:  that your firewall is simply blocking a few responses =
to some packets originated from your workstation.

If I'm reading the log right:
In your sample, note the application names. It appears that LSASS.EXE is =
associated with ports 1471, 1473, 1499, 1501, 1524, and 1526. These are =
"high" ports that could be associated with a program that is requesting =
data from a server.=20

Here's a hypothetical example of a situation that would explain your log =
sample:

Let's describe a simplified example of browsing to a web server via HTTP: =
The source packets from your workstation will be in the range of 1024-65535=
. The destination port will typically be the well-known port 80. Let's say =
your workstation sent the request from port 1400 on your workstation to =
port 80 on the web server. The web server will respond to your workstation =
using port 80 as the source and port 1400 as the destination. Now let's =
say that the firewall on your workstation allows all outbound packets but =
denies all inbound packets. The log would show a number of blocked =
incoming packets with a source port 80 from the web server to a destination=
 port of 1400 on your workstation.

Also, it's not uncommon for a requesting service to use more than one port =
when it is requesting data from a server. In our example, the web browser =
might open 10 or more ports either sequentially or randomly on your =
workstation all to request data from the web server on port 80. In our =
example, the log could show a number of blocked incoming packets with a =
source port 80 from the web server to a destination port of 1400, 1401, =
1402, etc (or 1400, 1485, 1688, etc.) on your workstation.

Now let's assume that your firewall is configured to be a little more =
practical: It allows all outbound packets from your workstation. It also =
blocks all incoming packets UNLESS the packet is a response to a packet =
that the workstation sent a little bit earlier (called Stateful filtering).=
 With stateful filtering, the firewall on your workstation will allow the =
browser to send out the request (from source port 1400, 1401, 1485, etc.) =
to the web server (destination port 80) and even though the firewall =
normally blocks all inbound packets, the firewall will make a _temporary_ =
exception for response packets from the web server to whatever port(s) on =
your workstation originally sent the request (port 1400, 1401, 1485, =
etc.). This will only be a temporary exception for a short amount of time. =
After the time expires, the exception will be removed. If the web server =
takes too long to respond to a request, the packet will be blocked when it =
finally gets received by your workstation.

Your log is similar except that in your case the server is LDAP on port =
389 instead of a HTTP server on port 80. If LSASS is using ports 1471, =
1473, 1499, etc. to request data from the LDAP service on your server =
(port 389) your firewall may be blocking some of the responses. My own =
laptop firewall (ZoneAlarm Pro) as well as other firewalls that I monitor =
will frequently block packets like this.

Disclaimers:
* Yes, there are a number of other reasons why responding packets might be =
blocked by a stateful firewall exception.
* Yes, the first paragraph of the hypothetical web browser/server =
communication doesn't pan out the way I implied.
* Yes, this is all over-simplification of what's really happening and I =
left out a lot of details!

Now, if this is all a new sudden development, and nothing has changed, why =
is your firewall suddenly blocking packets? Is this normal traffic that is =
now getting blocked because of an update to the firewall? Is this a large =
quantity of malicious traffic that is now getting partially blocked due to =
excessive quantity? I don't know the normal traffic patterns between your =
workstation and your server so I can't shed any light on that...just more =
questions! This could be perfectly fine and dandy...or it could be an =
indication of something not so pleasant going on.

If you really want to know what's going on at the packet level, you need =
to use a packet sniffer. FWIW, I use Ethereal (www.ethereal.com). It's =
free (open source), works very well, is actively being developed, and has =
already been ported to most common operating systems (and quite a few less =
common ones too!). If you're so inclined, analyzing the traffic on your =
network can really provide a lot of insight into what's going on out =
there. It can also be very useful in optimizing your network traffic, =
finding machines infected with malware, reducing unnecessary load on your =
network, troubleshooting problems and more.


I hope some of this helps at least a little bit.

Chad



---------------------
Chad Neeper
Senior Systems Engineer
Network Response Group
614-481-9400

--  Full LAN/WAN consulting services specialized in libraries and schools  =
--