Duplicate TCP SYN log entries

[Johnny Flanagan]

I have an appliance capturing syslog information from my ASA5520. I am seeing a TON of entries for ASA-4-419002: Duplicate TCP SYN from inside:XXX.XXX.XXX.XXX/##### to inside:YYY.YYY.YYY.YYY/44487 with different initial, with the first IP address logged with several different ports, and the second IP address as the exact same IP/port every time. This happens across a few other FROM addresses as well, with each of them pointing to a single IP/port pair.

What I want to know: How do I get rid of these? Is this indicative of some sort of spoofing or attack? Should I be concerned about some sort of malware on the inside, or is the firewall catching some sort of SYN attack originating from outside? Or is it just something I should ignore as the ASA is doing it's job?

[mopaul]

Hi Johnny,

Firstly, you have landed yourself up in wireless tech zone. This question deserves a posting in the security zone.

Secondly, for the logs you posted above, here are my two cents:-

A duplicate TCP SYN was received during the three-way-handshake that has a different initial sequence number than the SYN that opened the embryonic connection. This could indicate that SYNs are being spoofed.

You may like to do some config as sample below to prevent your network from SYN Flood attack

Create an acl with source any and destination specific to the TO-IP-ADDRESS that you see in the logs above

access-list 100 permit tcp any host

access-list 100 permit tcp any host

class-map c-inside-machine

match access-list 100

policy-map p-inside-machine

class c-inside-machine

set connection conn-max 100

set connection embryonic-conn-max 200

set connection per-client-embryonic-max 7

set connection per-client-max 5

set connection random-sequence-number enable

set connection timeout embryonic 0:0:45

service-policy p-inside-machine interface inside

you can also refer the config below for more details and deeper understanding on the suggested config

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00809763ea.shtml

Regards,

Mo

P.S Please do rate good posts that answers your question to help others finding the similar solution in less time and to avoid duplicacy.

[Johnny Flanagan]

Guess I fat-fingered (clicked?) the discussion group I wanted to send this to. Thanks for the heads-up. It should be in the proper forum now.

I will look at this in the morning. I'm a relative newbie to the Cisco CLI, so we'll see what I can do.

[Johnny Flanagan]

We actually just got that turned off, as it was generating a lot of false positives and restricting valid access. I'll read on it, and see what controls are there to minimize the impact to legitimate traffic.

[Ramraj Sivagnanam Sivajanam]

Hi Bro

If you ask me, I would say someone is doing a sweep attack. Yes, you can stop this with the Cisco’s threat-detection mechanism in your Cisco ASA, by utilizing the “shun” keyword. Please be sure to apply a suitable rate-interval, in order not to block legitimate network traffic. Good luck, bro :-)

For further details on this, please do refer to http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_threat.html

P/S: If you do find this comment useful, please do rate them nicely :-)

[Royal Frazier]

The #1 reason this occurs has nothing to do with scans or attacks or anything like that.  This is normally a routing issue.  Due to firewalls often owning default routes or large bocks of IPs, traffic to non-existant IPs end up at the inside.  If the firewall doesn't own that PRIVATE IP in a DMZ or active VPN session, typically routing sends it back inward where the inner router will loop it back up to 255 depending upon TTL. THIS is almost certainly the cause.

Every instance of mass DUP TCP SYNs I've ever seen were routing blackholes looping simple, singular attempts to initiate a TCP connection to a device that does not exist.

Take one of the destinations, I'll bet it didn't exist when they happened.  A common scenario is how Cisco handles VPN clients on the ASA (happened with concentrators, too).  The VPN Address pool for clients might be 10.1.1.0/24.  However the individual IPs are only routable when a session is active with each IP.  When IPs in the pool aren't active, the ASA doesn't "own" them.  Any traffic for them will be bounced back internally (assuming a rule doesn't block traffic).

Here's a simple test form any desktop

     Telnet  10.1.1.120   9999

Substitute an IP that is being "attacked" with DUP TCP SYNs often.  Mark sure it really isn't alive.  Check your logs after you telnet.  You should get over 500 DUP SYNs over two minutes from that one telnet statement. I believe Telnet will attempt one retry after 60 or 120 seconds.

It is a simple routing blackhole.  It often occurs with unaccounted IP ranges that are inclusive within your routing.

I'm trying a fix here that so far is working.  On a router you would implement a large, less specific NULL route to dump traffic to hosts that aren't connected or routable.  ASAs don't support NULL routes in my reasearch, however...

install a STATIC ROUTE 10.0.0.0 0.255.255.255  to gateway 127.0.0.2

As with anuy NULL route implementation, You'll have to figure out how big or specific the 10.x.x.x can get for your router.  You must be careful.  This will dump anytraffic for any IP that the ASA doesn't have a CONNECTED INTERFACE or a SPECIFIC ROUTE for already through statics or ospf, etc.  Over generalize and you just SHUNNED large swaths of your network.  People will notice.

[cryptonic]

Hi!

Thanks for a great response, I believe you are on to something.

We are having the same problem in our network and was trying to add the static route you mentioned, but get the error

%Invalid next hop address. We have tried it on both the core switch and the ASA with the same error.

Where did you add this route?

//Mattias

[Royal Frazier]

8.3 or 8.4 invalidated the ability to route to 127.x.x.x.

My solution for 8.4 is to route to the outside.   This also works on 8.2, so it is a better solution across versions.  This is what you normally have to do with VPN site-to-site tunnels.  If you aren't used to doing this, then I'll bet you've noticed that the tunnels only seem to come up when the spoke end talks inward to the hub ASA.  This is because small spoke sites tend to route all traffic (even most of 10.0.0.0/8) towards 0.0.0.0.  While hubs have far greater 10.0.0.0/8 population which routes inward by default.

So create a specific route for your VPN pools..

route outside 10.x.x.0   0.x.x.255  to outside default gateway (0.0.0.0)

I've already tested this on a 8.4 and 8.2 ASA and they both work.  The routing blackhole stops.  We've eliminated a few million daily Duplicate TCP SYNs "attacks" with two routes.

[cryptonic]

Perfect! Issue is resolved with the route you suggested. Thanks!

Our VPN-users use the network 10.250.1.0/24 so all I did was to add a static route to our ISP gateway:

route outside 10.250.1.0 255.255.255.0

Now the log-viewer is readable Thanks again!

//Mattias

[deanlawson]

FYI - I just added the following to our ASA to solve exactly this same Duplicate TCP SYN issue:

route outside <our_VPN_pool_network_address> 255.255.255.0 0.0.0.0 1

This worked perfectly.  All of the Duplicate TCP Syn messages have now stopped from this ASA. 

Nice to have a well behaved ASA again.. 

/mischief_managed

[dthomas53]

I know this post is older now, but great info, thanks!

I had a static route on the upstream router for a /24 pointing to the ASA 'outside' interface for which I only had maybe a dozen 1:1 NATs set up on. For any IP without a NAT set up, it of course was routing back up to its gateway (upstream router) and causing a routing loop, which flooded my logs with these TCP SYN errors.

[david.haughn]

Royal Frazier, you are a LEGEND! we need more like you on these boards. please come back!

[Johnny Flanagan]

I haven't abandoned my post, just been swamped with other duties.

When I get a chance here on my side, I'll implement these suggestions and see if it fixes my problems as well. Thanks for all of the info.

[rdmcleod]

in reading this thread, I also see this and tested both a static route of the client pools to the outside router - that worked, but also created an inside interface (we have 2 client pools defined on this box)

!define source object group

object-group network DM_INLINE_NETWORK_8

network-object object RAS-pool1

network-object object RAS-pool2

!define destination object group

object-group network DM_INLINE_NETWORK_9

network-object object RAS-pool1

network-object object RAS-pool2

!deny source to destinaion object groups, permit other

access-list inside_access_in extended deny ip object-group DM_INLINE_NETWORK_8 object-group DM_INLINE_NETWORK_9 access-list inside_access_in extended permit ip any any

so, anything sent to inside firewall/router via inside interface that sees the client pool route back to the ASA will get snubbed since the source appears to be a ASA defined pool address and could not be sourced validly from outside the ASA, therefore it is an invalid packet and should be snubbed

Would be interested in others comments on this approach.

[cscbrannent]

Resurrecting this dead thread - I have the same problem.  We're already routing the user's vpn /24 out to the Internet (external next hop).  

To suppress the syslog message, in the cli, send a no logging message command.

no logging message 419002

According to http://www.cisco.com/c/en/us/td/docs/security/asa/syslog-guide/syslogs/logmsgs.html , 

419002 is Error Message %ASA-4-419002: Received duplicate TCP SYN 3