03-01-2013 02:33 AM - edited 03-11-2019 06:08 PM
Hi Everyone,
We have an FTP server that sits in our DMZ. This Server has a DMZ interface and an external interface. When trying to access the server from the internet on its external address i am getting alot of Duplicate SYN attacks. They seem to be coming all from the same source and port to the same destination and port.
As part of the testing i first took out any references to the FTP server in my Access rules on the ASA. I then tried to FTP to the server from an outside internet connection and as expected get the following in the log:
4 | Mar 01 2013 | 10:23:18 | 194.80.130.xx | 46867 | 78.24.112.XX | 21 | Deny tcp src outside:194.80.130.XX/46867 dst outside:78.24.112.XX/21 by access-group "outside_access_in" [0x0, 0x0] |
I then highlighted this entry and created an access rule for it (but changed the source port to any rather than a specific one). When i then try and FTP to the server i get lots of SYN attacks which says the following:
4 | Mar 01 2013 | 10:27:29 | 194.80.130.XX | 46973 | 78.24.112.XX | 21 | Duplicate TCP SYN from outside:194.80.130.XX/46973 to outside:78.24.112.XX/21 with different initial sequence number |
I am not sure why I am getting duplicate SYN attacks. I have similar servers in the DMZ that do the same thing and they seem to be working fine. I am pretty sure this is not actually a DOS attack. I also have spoken to the team who manage the server and they have confirmed that the external IP is setup correctly on the server (its not that the external IP does not exist and just loops).
There is also NAT'ing setup on the ASA that NATs the dmz IP to the external IP and vice versa.
I have also noticed that whenever i create a new rule on the outside interface on my ASA it automatically adds the same descripton from another rule on the outside interface. What does this mean? Why could it be copying a description from anothe rule?
Your advice would be much appreciated.
03-01-2013 02:56 AM
Hi,
Regarding the same description appearing with every ACL rule I would guess that you are using ASDM to configure the ACLs and are using copy/paste to make new rules and as a result it copies the old rules description also.
I am not sure about the Duplicate SYN reason. I have not really had to deal with similiar problems myself.
Could it be possible that the initiating host is sending several TCP SYN because it never receive the TCP SYN,ACK from the server.
Maybe the routing is off at the actual server (even though you have been told it its configured correctly). Im just wondering as you mention that the server has 2 NICs. maybe the default route is pointing to wrong NIC at the moment. (Not the one facing your firewall)
- Jouni
03-01-2013 04:44 AM
Hmm,
Actually I kinda wonder why both the source and destination interface is "outside"
Could you also share the NAT configuration
- Jouni
03-01-2013 08:28 AM
Ok so sorry the FTP server actually just has one NIC with its DMZ address on it. I then assign an external address for it and then NAT that external address to its DMZ address statically configured on the FTP server.
NAT configuration is as follows:
17 (outside) to (DMZ) source static any any destination static csdpr1ft-ext csdpr1ft-dmz
translate_hits = 248, untranslate_hits = 248
csdpr1ft-ext is the external address 78.24.112.XX
csdpr1ft-dmz is the dmz address statically configured on the server.
03-01-2013 08:33 AM
Hi,
That doesnt show the whole NAT configuration. For that you would have to use "show run nat" and "show run object id
I personally wouldnt configure a simple Static NAT in such a complicated way (atleast to my eye)
The basic Static NAT that I configure in the firewalls I manage is
object network SERVER
host 10.10.10.10
nat (DMZ,outside) static 78.24.112.xx dns
access-list OUTSIDE-IN permit tcp any object SERVER eq 21
I guess you configuration might/should work also but it just seems a bit wierd to configure it in that way.
- Jouni
03-04-2013 05:25 AM
I have simplified the NAT and just done a Network Object NAT and translated its DMZ address to the external address. This still has not changed anything, however i am pretty confident that the NAT'ing is fine.
03-01-2013 01:53 PM
This might be related to a routing issue on the outside, will need captures to confirm.
Maybe you can share the output of the "show local
03-04-2013 05:31 AM
The output of show local whilst running the test is as follows:
sh local 10.200.23.xx (DMZ IP)
Interface Outside: 290 active, 459 maximum active, 0 denied
Interface management: 0 active, 1 maximum active, 0 denied.
Interface dmz: 13 active, 254 maximum active, 0 denied.
Interface Inside: 12 active, 19 maximum active, 0 denied.
Interface failover: 1 active, 2 maximum active, 0 denied.
03-04-2013 05:39 AM
Hi,
Can you take the "packet-tracer" test to simulate a connection coming from the Internet?
packet-tracer input outside tcp
For example.
Just to see if it shows anything special related to this.
I still find it strange that it lists the "outside" as both source and destination while it should list destination as "dmz".
- Jouni
03-04-2013 08:18 AM
Output from packet-tracer to outside address 78.24.112.xx
It seems as though the NAT to the DMZ address is just not working. I have set a NAT rule up "before network object NAT" rule and also set a simple object NAT, but still getting the error.
Phase: 1
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit object-group DM_INLINE_SERVICE_7 any object csdpr1ft-ext
object-group service DM_INLINE_SERVICE_7
service-object tcp destination eq ssh
service-object ip
service-object tcp destination eq ftp
Additional Information:
Phase: 2
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 3
Type: INSPECT
Subtype: inspect-ftp
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect ftp
service-policy global_policy global
Additional Information:
Phase: 4
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 26135657, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
Action: allow
03-04-2013 08:23 AM
Hi,
When you configure the "Network Object Net" for the Static translation did you remove the existing Section 1 NAT for the same DMZ server?
Did you check the "packet-tracer" output with just the Network Object NAT
If you NAT configuration doesnt happen to be huge would there be a chance to have a look at it?
- Jouni
03-04-2013 08:42 AM
Hi,
Yes I removed the Section 1 NAT and just had the object network NAT in there.
Checked the packet trace and its the same outcome as the one I have posted. Seems to be OK if i trace to its outside address, however if i do a packet trace to its DMZ address it just drops at Access rule.
Sure, do you require the outcome of sh run nat?
03-04-2013 09:36 AM
Hi,
If you have a Static NAT configuration for the server on the ASA and are testing/simulating traffic coming from the "outside" you naturally always use the public NAT IP address.
The private/local/real IP address doesnt give the right result in this case.
Was the previous output using Real IP or Public IP as the destination? Doesnt seem to be doing any NAT in the previous output (no UN-NAT phase) so it doesnt look right.
The output of "show run nat" might be in some cases enough. If you have alot of objects their content cant naturally be seen with just "show run nat". If you dont have a huge NAT configuration we might not need the "object" configurations.
- Jouni
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide