Topic: SynFlood traffic on port 443 (HTTPS)

[Brenno]

Folks,

I'm running 6.0 final in server-only behind a SnapGear firewall.  Lately, my SnapGear firewall records have been showing SynFlood entries similar to the following:

klogd: SynFlood: IN=ppp0 OUT=eth0 SRC=209.183.XXX.XXX DST=193.1.X.XXX PROTO=TCP SPT=2059 DPT=443

(Above was edited and abbreviated... the destination port is always 443 but the source port is random.)

The net effect of these SynFlood entries is that WebMail is not working due to the traffic flood on the port.  The really odd thing is that the SynFlood entries are only coming from my 3 satellite offices which use WebMail - never from a completely random  outside source.

Because the flooding is coming from "legitmate" sources, I can't block the IP at the firewall level or they won't have WebMail access at all.

Any thoughts on this?  Could this be related somehow to the use of WebMail itself?

[CharlieBrady]

The net effect of these SynFlood entries is that WebMail is not working due to the traffic flood on the port.

No, I think it's more likely that webmail is not working because the Snapgear is blocking it.

Any thoughts on this?

What's snapgear's definition of "SynFlood"? I suspect you've just got a lot of (legitimate) https traffic from your satellite sites.

Could this be related somehow to the use of WebMail itself?

Yes.

[Brenno]

Charlie,

I used the port forwarding rules in the SnapGear to move all port 443 traffic to the SME server, and that worked wonderfully for quite some time.

Once I noticed the SynFlood traffic coming from my satellite offices, I moved them from WebMail to Outlook Express using IMAP over SSL.  Strangely, I still see SynFlood traffic coming from those IPs.

Unfortunately, documentation on the SnapGear has always been thin, but I did just find this after a little hunting:

Code: [Select]

If SynFlood or Flood appears repeatedly in the system log, it means the SnapGear is receiving more than 5 incoming connections per second, and believes it is being attacked. For security, it then ignores any additional incoming connections.

There was also a fix listed for it, so I'll try that and see if it solves the problem.  It might just be that WebMail by nature entails a lot of separate HTTPS requests which are mistaken for threats.