Archive for the ‘Uncategorized’ Category

Cisco ASA and Passive FTP

Tuesday, March 2nd, 2010

After installing a Cisco ASA 5505 on our network and setting it to inspect FTP (much like the PIX fixup command), passive FTP stopped working when connecting to some remote servers. It turns out the ASA was blocking the responses to a PASV request if the remote FTP server was a Microsoft IIS server behind NAT. It seems the Cisco is trying to prevent a very out of date and useless distributed denial of service (DDoS) attack that could be initiated when using passive FTP data transfers. It comes to this conclusion because the IP address advertised in the PASV response (the IIS server’s internal IP address) is in fact different from the public IP address which the Cisco observed during the FTP connection. When the Cisco sees this it instantly drops the connection claiming it detected a bounce attack.

What’s the solution? I can only figure a few:

  1. Cisco please create an option that will allow users the ability to disable checking for FTP bounce attacks! This is the best route to fixing this. FTP bounce attacks are ancient and almost every FTP client out there ignores the IP address octets in the response to a PASV request which makes this attack out of date. Another reason for this being the best solution is most FTP connections are initiated by users who know what they’re doing and only connect to trusted FTP sites.
  2. Cisco could also check if the IP address octets are within the registered address ranges of internal IP addresses. If it detects that the address is an internal IP then it should let the response through. The whole object of a bounce attack is to flood a server somewhere with thousands of connection requests. It is not feasible to imagine that you can flood an internal IP without the help of the entire internet. For a server with an internal IP address to be denial of serviced it would take an entire company with thousands of computers to all access this malicious FTP site at the same time to DoS their own internal server… Highly unlikely.
  3. Plead to Microsoft to add an option for specifying the external IP address within IIS. IIS has been around years without this option so I doubt they’re considering this anytime soon. In which case you could choose a different FTP server.
  4. Use a firewall comparable to a Cisco ASA or PIX that will monitor your server FTP connections (using fixup or inspect) and replace any private IP addresses with public IP addresses.
  5. Disable fixup or inspect FTP on your ASA or PIX and just use passive FTP. This is the route I chose. Ofcoarse you can no longer use active FTP when you do this! I decided that I did not care to use active FTP as passive is preferable anyway.

LT. Col Anthony Shaffer New Interview

Saturday, January 9th, 2010

I would like to say – on the off chance that LT. Col Shaffer ever sees this – that his testimony in front of congress was one of the most heroic efforts I have ever seen in my lifetime. LT. Col Shaffer literally threw himself on a grenade set to destroy his career in the hopes that the American people would hear what he had to say. The sad part is that most people missed this.

Anyway, years later here is an awesome interview where he is able to disclose even more information.

Part 1

Part 2

Part 3

Background on Able Danger

Odd Case Of Windows…

Tuesday, December 8th, 2009

I just got back from a 6 hour adventure. One of my servers seems to have caught something like swine flu or more appropriately as I’m learning to call just “Windows”. It seems the network cards have all but died. Windows sees them, but after spending 4 hours trying to get any of the three NICs to work, I finally gave up by pulling the server out of the rack and driving it back to the office for a vaccination, er reformat.

This server had one job, to run a service I wrote and on top of that it was completely cut off from the internet. Initially I thought: “hmm maybe a virus that slipped in the network form another host?”. No such luck. If that had been the case I could have destroyed it in a matter of minutes and been on my way home. I’m bashing my head about this as this program would take about 2 weeks to rewrite for Linux. Should I allocate my time to rewriting this code that has run for over a year with no problems just to get around Windows? It’s a tough call. Maybe after a reformat, I’ll find out all the NICs really are dead…

Update:
There I go bashing Windows. I suppose I was just a little bit too tired writing this at 6 in the morning. After getting the server back to the office I plugged in an ethernet cable on all interfaces and wouldn’t you know it, they all work. Which means, I’m an asshole and Windows is the best after all. It’s now time to now look into the network equipment or cables.