W2K all accounts lockout from external netbios brute force attack 1

[BA2PC]

I would like to share a recent experience. W2k Web server IIS5 MySQL. netbios (port 135) was enabled by default via WINS. Loads of 680 events auditing logons. Account lockout policies triggered all username lockout including IUSR (anonymous web access).

Disable netbios over TCP/IP in W2k Server ethernet to prevent DoS.

 

[kmcferrin]

Or put the web server inside a DMZ/behind a firewall that blocks all NetBIOS ports (135-139).

Or if you don't have a hardware firewall/DMZ then install a software firewall like Zone Alarm (there are a number of free ones).

Frankly, if you have a web server directly connected to the Internet without some sort of port filtering/firewall to protect it, you're going to have a lot more problems than just people trying to brute force your user accounts over NetBIOS. There are probably a couple dozen other network services that are directly exposed to attack. I would be surprised if your server weren't already compromised.

 

[BA2PC]

The issue I had with a firewall was the outbound FTP and SQL ports changing. I would have to open such a large range of ports for these services that it seems unproductive.

 

[lhuegele]

Why would FTP and SQL ports be changing???

 

[kmcferrin]

I can't see FTP ports changing. Unless you manually configure it to do otherwise, FTP always runs on ports 20 and 21. You might be having issues with active mode FTP which is common with firewalls, but you should be able to use passive mode with no problems.

With SQL it's true that after the initial connection is made on 1433 you are redirected to another port in the dynamic range. However, there are Microsoft KB articles that detail steps to configure SQL to use specific ports instead of randomly selecting one.

But more importantly, why would you be allowing SQL connections over the Internet? Any application (even web based) that is using SQL should be either inside your network or DMZ. If you have a need to directly connect to SQL from a remote site you should be using a VPN connection. Exposing SQL ports to the Internet results in the compromise of a server very quickly.

 

[BA2PC]

kmcferrin Thank you for your excellent insight. Let me give you a better feel for this project.

We have vending machines with PC based ethernet controllers communicating real-time payment approve/deny decisions to a MySQL database on a W2k server with IIS, FTP.

FTP PASV mode is the solution to allow the (non-exisitant) firewall integration, I agree. The VPN for the MySQL server I still cannot reconcile. We intend to make the connection parameters for our database open to a large community of end users who will need database interaction. Won't a VPN insert unnecessary restrictions?

 

[kmcferrin]

It will insert restrictions, but "unnecessary" is debatable. If you are transmitting any sort of confidential information (credit cards, customer info, etc) then some sort of encrypted connection should be used.

Also, I apologize for misleading you on the SQL part, I didn't realize that you were using MySQL instead of MS SQL (though it is in your first post). That may not use 1433 or the dynamic port ranges that SQL uses. However, there are still security issues with leaving MySQL directly exposed.

Back to the problem, you say that these machines have a PC-based ethernet connection. Is it an actual PC running a commercially available OS inside the machine, or is it something else using PC hardware? If it's the former then you should be able to make an encrypted connection happen.

Another possibility would be to put the server behind the firewall in a DMZ and then forward the ports needed for MySQL to the server. If you go that route then you can use an firewall with stateful packet inspection and some sort of anti-malware capability to scan the traffic before it hits the database.

 

[BA2PC]

Just wanted to pop in and give an update.

The server is up and running. I've had to deny SMTP relay and SMTP to just the server's IP address.

We still get plenty of brute force attacks. Right now I am trying to fend off a MySQL brute force "root" attack.

Regards