ASA5505, SYN attack, ISP and IPS module

[tato386]

Our 5505 is currently being hit by a SYN attack from surprise, surprise, China.  The attack easily brings down the 5505 by hitting the 10,000 connection limit of the box.  I am currently using the shun command to try to mitigate the problem but it is not much help.  It converts the 10,000 connections into 12-15k dropped packets per second which doesn't crash the box but pretty much makes it unusable. 

I have seen some examples on using service policies to set connection and embryonic limits but I don't think they will work for me because the attacks come from several IPs and use several different ports.  The attacks don't seem to be pinpointing any particular server or service.  Seems like just basic DoS of our service.  Besides, the feedback from people who have tried this doesn't seem too convincing.

So I have two questions:

1) My ISP is unwilling and/or unable to do anything.  They suggest I email the abuse mailbox from the offending ISP.  Just for grins, I did send an email and it promptly came back marked "mailbox full" which is quite funny I thought.

2) Will adding the IPS module help here?  I am hoping that the processing of the dropped packets would move to the module and leave the main processor of the ASA free to do its usual NAT and firewall functions.

Any and all advice is welcome.

Thanks,
Diego

[Julio Carvajal]

Hello Diego,

Well the ISP should be way more useful than this, I mean on this particular scenarios they will have to stop sending this traffic to your link because you are pretty much consuming a lot of traffic on this ofensive and useless traffic,

I would encourage you to go with them and explain them they SHOULD help on this scenarios, that's why you are paying dude.

Now regarding the MPF config, there is an option when you set the maximum connections (it will trigger the SYN cookie DoS prevention) and you will do it as a global value, no per client. So even if they change the IP address if you have reached the maximum amount of connections. bump the SYN Cookie will start doing it's job

Remember to rate all of the helpful posts

Julio Carvajal

[tato386]

The ISP isn't too worried because for some reason the attack does not saturate the pipe.  We are using a 10MB MetroE and it stays fairly lightly loaded.  I think these are just many small packets that don't have much affect on BW.

I should mention that the attacks are mostly hitting the IP of the ASA itself.  The SYN preventention is not working well for me. I have set maximum connection per client at 1000 and embryonic connections at 1000.  I routinely see 2000 connections to the ASA yet no IP is shunned automatically.  I have to add them manually.

I am still hoping adding the IPS module can help me with deal with this but don't want to invest $$$ for something that won't address this particular concern.

Thanks,

Diego

[sokakkar]

Hello Diego,

As far as IPS module in ASA is concerned, it is going to inspect only the traffic which is allowed by ASA i.e. through the box traffic. So, if traffic is destined to ASA interface, IPS module won't help much in this case. However, if interface IP is used for port forwarding on ASA to allow inbound services like access to web servers etc and that port is being attacked making traffic through the box, IPS can inspect that traffic.

But again, if attacker decides to bump the rate of connection (so many powerful tools available), the n/w device can still end up in unusable state (coz resources will eventaully get exhausted), so again as Julio mentioned, best way is to get ISP to drop this traffic at their end. May be its not BW consuming but it is still an attack and should be pointed to null by ISP.

-

Sourav Kakkar

[tato386]

After working a bit more on this it turns out my diagnosis was incorrect.  The _source_ of the 10,000+ connections was the PAT address of the ASA.  It was _not_ the target as I was thinking because I was misreading the ASA info.  So we were not getting attacked.  It looks like we were being used to launch attacks.  Further investigation found a compromised machine on the LAN with hacking tools installed.  When the PC was taken offline and fixed the problem dissapeared.

Usually the FIRST thing I do in these situations is to check the PAT table to look for infected PCs.  In this case the PAT table looked normal.  So I quickly discarded an infected PC on LAN as the problem.  When I saw the huge number connections between Chinese IPs and the outside interface of the ASA I assumed we were being hit and I overlooked the fact that the source and targets were pointing to outgoing connections not incoming.

So now I have a different question:  How is it that a host on the LAN is able to establish 10,000 plus connections to outside IPs _without_ showing up on the PAT table? 

Thanks,

Diego

[Julio Carvajal]

Hello Diego,

Interesting enough

The information have to be there, it's just that you are not reading properly the information ( use the command that I provide below)

Yeah, you missunderstood the ASA Information.

So the internal user knew what he was doing ? he was using some Pen-test tools..

One useful command for you

show local-host detail connection  tcp 1000  ( will show the hosts ip address with users that have more than 1000 TCP connections)

[sokakkar · Accepted solution]

Hi Diego,

As Julio mentioned, info has to be there. Do you have the 'show xlate' when the issue was seen? In such cases, along with xlate table, you can check connection for hosts making unusual number of connections (show connection count/show connection all). Here are few useful commands in such scenarios:

show local-host connection udp 100-10000          << Gives host with total UDP connections b/w 100-1000

show local-host connection tcp 100-10000          << Same info for hosts making TCP connections

show local-host connection embryonic 100-10000    << hosts with 100-1000 embryonic connections

Change the range as per need.

-

Sourav

[tato386]

I used the only two methods I knew of at the time.  I would do "show xlate" from the command prompt and also used the ASDM screen at Monitoring > Properties > Connections.  The "show xlate" did not show any info at all pointing to the compromised host.  The ASDM showed the connections from PAT of ASA to outside IP but again, nothing from the host.

If it happens again I will use the commands you guys suggested.  Maybe it was the "embryonic" connections that would not show with the methods I used.

Hopefully it won't happen again but if it does I feel better equipped to handle the situation with more efficiency.

Thank you guys very much,

Diego

[Julio Carvajal]

Hello,

Sure f you do not have any questions please mark it as answered

Regards