Port 139 and 445 Intrusion on PIX V6.1

[steveb2004]

A small business client has a PIX 515 w/V6.1. It is configured with an inbound static mapping to a Windows 2000 web/application server. There is a Port 80 conduit from "any" and ftp / telnet conduits from our office IP only.

The Server has been the target of a series of automated brute force attacks against the ASPNET account and the local admin account from IP address's that originate on every continent if they are real.

Running Window 2000 Network Monitor shows the first communication is initiated from the internet and goes on for about 2 hours on Ports 139 and 445. If I run an external port scan it confirms that only Port 80 is exposed. We have broken the external connection on the PIX as a test to confirm that the traffic was actually from the internet and it is.

How can Port 139 and 445 traffic be initiated from the internet?

If you think CISCO support is the solution, please say so.

Thanks

[jmia]

Hi,

You'll find relevant info on port 139 and 445 here:

http://www.grc.com/port_139.htm

http://www.grc.com/port_445.htm

I'd recommend that you also upgrade your PIX to v6.3 and move away from conduits to ACLs !

You can also probe your network from www.grc.com and choose 'Shields Up' to test both of those mentioned ports and see what comes up.

Let me know how you get on.

Jay

[steveb2004]

I scanned the site with nmap and GRC over the weekend and only port 80 was exposed. Is there a known exploit of PIX 6.1 that involves Microsoft Netbios and Directory Services ? . . . because that appears to the problem.

[cscott]

It is very possible, especially if the server is running IIS, that the server was exploited through port 80 and opened an outbound connection on port 139 and 445. You could write an outbound ACL to deny 139 and 445, that should effectively kill whatever traffic you're seeing. If you can do ACL's on your border router that is sitting in front of the PIX, go ahead and block 139 and 445 inbound on the router. This way if there is some kind of a hole in the PIX, the 139 and 445 traffic will be killed at the router and will not make it to the PIX. If the server is going outbound on it's own using 139 and 445, the hit counts on your outbound ACL will be incremented on the PIX, and you'll know the server is the cause.

The server is likely compromised however, your best bet would be to start from scratch and rebuild the server completely.

I'd also suggest moving away from conduits. I believe 6.3 is the last version that will support conduits, so if you have any plans of moving to 6.3+ you need to start using ACL's.

If the traffic is in fact being initiated from the internet and making it through the PIX without being permitted by either a misconfiguration or a conduit/ACL, then I would call TAC. They can help you find a misconfiguration, and if it's a security issue they dont know about, they need to check other versions of the PIX OS to see if they are vulnerable too.

[steveb2004]

Thans for the reply. Because this was a daily occurance, I was able to capture frame-by-frame the attack and the first frame of communication with these remote sites was always an inbound port 139 query followed by port 445 queries. I was looking for outbound initiated traffic caused by a worm, but our anti-virus can find no worms - and the traffic was definitely inbound.

By shutting down port 80 the attacks have stopped, but that doesn't really explain how the inbound-inititated Port 139/445 traffic gets through the PIX.

Port 80 may have just been a method of discovery since we don't respond to anything else on this IP.

We will upgrade the IOS and reconfigure with ACL's. We inherited the conduits and everything was OK until recently.