0

About a week ago we moved the application from one server to another (from Windows Server 2008 to Windows Server 2008 R2, different DCs, but same company). There are 12 websites on this server, but they're all very low traffic sites (<200 hits per day).

Ever since we moved I noticed that the security log under Events -> Windows Logs -> Security is filled with packet drops. Most are trying to access port 25, 17, or some seemingly random port > 1024; it's rather spread out. Some come from reputable companies like Constant Contact (IP 208.75.123.132 for example), some from companies I personally didn't hear about, like Cogento 38.96.220.83, but that seem reputable. There are of course random IPs that don't point to anything in particular. All these ports are blocked and/or not used.

There are so many of these entries (about one or two per second on a guestimated average) that the log fills up in about a day and half. With the previous server, hosting the same sites, I could go back over two months.

Did I inherit (with the move) an IP that was used for who-knows-what and now all these services are connecting to me expecting the old services, or is there something else going on?

Any thoughts? Thanks!

EDIT: I should have mentioned this, the entries in the event logs are all "Event 5152 - The Windows Filtering Platform has blocked a packet."

EDIT2: Here's an article that touches on exactly the same problem I experienced. The important piece is to disable the auditing of dropped packets using auditpol, but also that it takes quite a bit of time until you get to see it work, unless you reboot immediately. I'm not sure why it works this way, but it definitely threw me off.

EDIT3: What the article leaves out, for Windows 7 / Server 2008 R2, you need to go to Local Security Policy -> Local Policies -> Security Options -> and enable "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings." By default it should be enabled, but in my case the "not defined" option didn't work, I had to manually enable it; more information here. A restart is required.

pbz
  • 199
  • 1
  • 4
  • 12
  • 1
    Why is your server directly exposed to the internet? – joeqwerty Oct 01 '11 at 21:42
  • It's a web-server, so it has to. – pbz Oct 01 '11 at 21:43
  • 1
    Really? It should only be exposed on port 80 and it should be behind a firewall. If it were, you wouldn't be seeing the events in the log that you are seeing. – joeqwerty Oct 01 '11 at 21:45
  • That's what it's doing. The entries in the log are notifications from Windows Firewall that those packets have been dropped. I'll update the question to point this out. – pbz Oct 01 '11 at 21:46
  • Here's what I'm saying: If this is a web server (and the web sites all run on port 80), and the server is behind a firewall that only allows traffic destined for port 80 to reach the server, and traffic destined for ports other than port 80 are reaching the server... then you have a problem with your firewall. – joeqwerty Oct 01 '11 at 21:50
  • My understanding is that the firewall (software, not a hardware firewall) is blocking these requests and logging every single attempt in the security branch of the events viewer. I used grc.com to test these ports and only the right ports are open, so nothing goes through. – pbz Oct 01 '11 at 21:55
  • Right, that's bad. You're letting every bot in existence hammer on your server by not having it behind a perimeter firewall. That's why your logs are filling up. It's only a matter of time before irreversible damage is done. My advice: put a purpose built firewall at the perimeter (ingress/egress point) of your network and configure it to only allow traffic destined for port 80 to reach the server. – joeqwerty Oct 01 '11 at 22:17
  • Servers are hammered by bots with or without a firewall. There's nothing listening on those ports anyway. The firewall stops those attempts, but even without a firewall they wouldn't be successful. – pbz Oct 02 '11 at 00:04
  • No they're not. You've got the entire server exposed, not just a single port. You're asking for trouble by not having the server behind a perimeter firewall (I'm posting these comments only with the best intentions). At the very least you should run the Security Configuration Wizard on the server to harden it. – joeqwerty Oct 02 '11 at 00:09
  • Hardware firewall is out of the budget right now. We have been running other servers in this configuration (without a hardware firewall) for years without problems -- I guess you could argue we were lucky. We run penetration/vulnerability tests all the time. – pbz Oct 02 '11 at 01:12

2 Answers2

2

Have you seen this article?

The Windows Filtering Platform has blocked a packet

or I just found this paragraph

I found the issue to be a buried gpo setting under the Default Domain Policy. Computer Configuration, Policies, Windows Settings, Security Settings, windows firewall with Advanced Settings, domain profile, logging. Click Customize and set log dropped packets and log successful connections to No.

you should also be blocking all but port 80,443 through your firewall :)

Christian
  • 796
  • 3
  • 13
  • 31
  • I'll look into it, thanks. We don't have a domain, hopefully this will work without one. – pbz Oct 01 '11 at 21:59
  • as far as i can tell its just the logging settings under the firewall which is on by default. you can set it manually for domain, public and private. probably best to do it for all three. and as Lucas wrote, its probably just general Internet traffic bouncing off your server. – Christian Oct 01 '11 at 22:02
  • I disabled the logging of dropped packets (not sure how I didn't notice that settings before), but it doesn't look like it's working (although I did get a "450 - A Windows Firewall setting was changed" event)... investigating... – pbz Oct 01 '11 at 22:08
  • Doing it from the GUI didn't seem to work, but this did the trick: "netsh firewall set logging droppedpackets=disable" It did complain that the command is deprecated, but it worked. Thanks! – pbz Oct 01 '11 at 22:14
  • http://blogs.technet.com/b/instan/archive/2009/01/08/the-windows-filtering-platform-has-blocked-a-bind-to-a-local-port.aspx – Christian Oct 01 '11 at 22:17
  • excellent. but you should now take the load off your server and move the firewall to your network firewall – Christian Oct 01 '11 at 22:18
  • Not sure if needed, but based on the article you linked to I also ran: auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:disable /failure:disable – pbz Oct 01 '11 at 22:41
  • @pbz: OK, so to "resolve" the issue you turned off firewall logging. The attempts are still hitting your server but you're no longer bothered by having them show up in the log. No offense, but good luck keeping that server in one piece. – joeqwerty Oct 01 '11 at 22:45
1

Welcome to the internet, probably your ip is in a range of known high speed computers with a very nice network setup. You get scanned and tried out. I had the same on one of my servers, can't do much against it, normally when the potential hackers see there is no response, they give up after a while.

You can always try to actively reject instead of dropping, see if it helps.

Lucas Kauffman
  • 16,880
  • 9
  • 58
  • 93