[OPLINTECH] Port Scans from Domain Controllers
Chad Neeper
CNeeper at nrg92.com
Thu Apr 28 19:27:40 EDT 2005
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.
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 --
More information about the OPLINTECH
mailing list