Jump to content
Welcome to our new Citrix community!

LDAP request cause SYN-ACK Attack on Firewall


Michael

Recommended Posts

Hi,

 

we have a Load Balancing Virtual Server for our LDAP (secure) as SSL_BRIDGE running.

Since this week (we increased the number of Mobile-Phone users) this VS is causing SYN-ACK Attacks on our Firewall. So connection is dropped with message "First packet isn't SYN"

 

MonServiceBinding_xx.xxx.xxx.xx:636_(FMO_ldaps-16)(svc_adcontroller.internal.domain.local_LDAPS): DOWN; Last response: Failure - Probe timed out.

 

Someone any idea howto prevent this? Some setting we can change? 

 

Config from VS:

Listen Priority-

Listen Policy Expression NONE

Redirection Mode IP

Range 1

IPset -

RHI StateP ASSIVE

AppFlow Logging ENABLED

Retain Connections on Cluster NO

 

Persistence  SSLSESSION

Time-out (mins) 2

Backup Persistence NONE

Backup Time-out (mins) 2

IPv4 Netmask 255.255.255.255

IPv6 Mask Length 128

 

Health Threshold 0

Client Idle Time-out 180

Minimum Autoscale Members 0

Maximum Autoscale Members 0

ICMP Virtual Server Response PASSIVE

Priority Queuing

Sure Connect

Down State Flush ENABLED

Layer 2 Parameters OFF

Trofs Persistence ENABLED

Link to comment
Share on other sites

What monitor are your services using, SSL_BRIDGE uses tcp-default by default.  The tcp monitor sends syns, waiting for a syn-ack but with no actual tcp request. Some devices will see too many of those and treat as an attack and not a probe.  Change to ping, or a different monitor type that won't trip up your firewalls.

 

But I also agree, be sure you don't actually want the netscaler to do packet inspection itself so end-to-end ssl might be better than ssl_bridge depending on context.

The monitor type might be the current problem though.

Link to comment
Share on other sites

Sure, Rhonda is right. I didn't think about it. Things would get better immediately if you would use TCP-secure, as this monitor has to complete the TCP handshake and establish a SSL connection, prior to sending the reset. Or even better, the built in LDAP monitor. Don't forget to check the secure checkbox :)

Link to comment
Share on other sites

Thx for your Help to both of you,  i will take a look into this (changing from ssl_bridge to ssl_tcp)  later on. 

 

but for now, it is fixed :-)

Our Firewall-Team found the error on their side. Some wired/wrong Routing-Table.

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...