Mailing List Archive

2013/5/13 Alexander Frolkin <avf@eldamar.org.uk>

> Hi,
>
> We're looking to implement IPVS load balancers in front of our web
> servers, and we'd like to have the IPVS directors generate SYN cookies
> in case of a flood, instead of passing them down to the realservers.
>
> I haven't seen much information about this out on the web except this
> page:
>
> http://kb.linuxvirtualserver.org/wiki/IPVS_FULLNAT_and_SYNPROXY
>
> Unfortunately, I can't seem to find any English docs, and, more
> importantly, the patch doesn't apply cleanly to the kernel version we'd
> like to run (3.2.0 on Ubuntu 12.04).
>
> Does anyone know if there's an up-to-date version of the patch floating
> around somewhere? Or maybe there's some other way to make IPVS
> directors generate SYN cookies?
>
> Thanks!
>
>
> Alex
>
>
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
>
> LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
> Send requests to lvs-users-request@LinuxVirtualServer.org
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>



--
Ivan

Écoutez http://youkounkoun-radio.com !
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

> We're looking to implement IPVS load balancers in front of our web
> servers, and we'd like to have the IPVS directors generate SYN cookies
> in case of a flood, instead of passing them down to the realservers.
Hi Alex,

Sorry, but as far as i understand SYN cookies, only the real server can
do that
as the TCP transaction is between client and real server (IPVS does only
DNAT)

But you can also "limit" the VIP to try to prevent SYN flood attacks
(just exemple):

iptables -I INPUT -i eth0 -p tcp --syn -j syn-flood
iptables -N syn-flood
iptables -A syn-flood -p tcp --tcp-flags ALL ALL -m limit --limit
5/minute -j LOG --log-level alert --log-prefix "syn-flood:"
iptables -A syn-flood -p tcp --tcp-flags ALL ALL -j REJECT --reject-with
tcp-reset
iptables -A syn-flood -p tcp -m limit --limit 500/second --limit-burst 5
-j RETURN
iptables -A syn-flood -p tcp -m limit --limit 5/minute -j LOG
--log-level alert --log-prefix "syn-flood-LIMIT(>500/s):"
iptables -A syn-flood -p tcp -j DROP



_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

> We're looking to implement IPVS load balancers in front of our web
> servers, and we'd like to have the IPVS directors generate SYN cookies
> in case of a flood, instead of passing them down to the realservers.

Hi Alex,

Sorry, but as far as i understand SYN cookies, only the real server can
do that as the TCP transaction is between client and real server (IPVS
does only DNAT)

But you can also "limit" the VIP to try to prevent SYN flood attacks
(just exemple):

iptables -I INPUT -i eth0 -p tcp --syn -j syn-flood iptables -N syn-flood
iptables -A syn-flood -p tcp --tcp-flags ALL ALL -m limit --limit
5/minute -j LOG --log-level alert --log-prefix "syn-flood:"
iptables -A syn-flood -p tcp --tcp-flags ALL ALL -j REJECT --reject-with
tcp-reset
iptables -A syn-flood -p tcp -m limit --limit 500/second --limit-burst 5
-j RETURN
iptables -A syn-flood -p tcp -m limit --limit 5/minute -j LOG
--log-level alert --log-prefix "syn-flood-LIMIT(>500/s):"
iptables -A syn-flood -p tcp -j DROP

Hope usefull..
--
Ivan


_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

Hello IPVS Folks,

The special 2.6 kernel Patch against IPVS Syn flood went NOT into upstream
kernels.

From my security Oblogations - that may still an task to investigate if that
may still needed .

Syn Floods , expecialy SNY bind9 RELAY Floods , are the today most used
threads.

Few days ago , i.e the raspberry.org was exactly hit by this with +1GB/s
peak .. see http://www.raspberrypi.org/archives/3935 .
They USE 4 IPVS systems to balance the traffik.

Therefore - for IPVS security Obligations - the SNY Flood traffik should be
stopped at the earlierst point : the IPVS systems its self.

As i said last week and someone agreed here : its TIME for an NEW
Productive STABLE IPVS(adm) release.
Either for sutch network security Concerns.


--
Mit freundlichen Grüßen / Best Regards
Horst Venzke ; PGP NET : 1024G/082F2E6D ; http://www.remsnet.de
Legal Notice: This transmittal and/or attachments may be privileged or
confidential. It is intended solely for the addressee named above. Any
review, dissemination, or copying is strictly prohibited. If you received
this transmittal in error, please notify us immediately by reply and
immediately delete this message and all its attachments. Thank you.


Gesendet: Dienstag, 14. Mai 2013 um 00:09 Uhr
Von: "Ivan Havlicek" <ivan@modulix.org>
An: lvs-users@linuxvirtualserver.org
Betreff: Re: [lvs-users] IPVS SYN-cookies
> We're looking to implement IPVS load balancers in front of our web
> servers, and we'd like to have the IPVS directors generate SYN cookies
> in case of a flood, instead of passing them down to the realservers.
Hi Alex,
Sorry, but as far as i understand SYN cookies, only the real server can
do that as the TCP transaction is between client and real server (IPVS
does only DNAT)
But you can also "limit" the VIP to try to prevent SYN flood attacks
(just exemple):
iptables -I INPUT -i eth0 -p tcp --syn -j syn-flood iptables -N syn-flood
iptables -A syn-flood -p tcp --tcp-flags ALL ALL -m limit --limit
5/minute -j LOG --log-level alert --log-prefix "syn-flood:"
iptables -A syn-flood -p tcp --tcp-flags ALL ALL -j REJECT --reject-with
tcp-reset
iptables -A syn-flood -p tcp -m limit --limit 500/second --limit-burst 5
-j RETURN
iptables -A syn-flood -p tcp -m limit --limit 5/minute -j LOG
--log-level alert --log-prefix "syn-flood-LIMIT(>500/s):"
iptables -A syn-flood -p tcp -j DROP
Hope usefull..
--
Ivan
_______________________________________________
Please read the documentation before posting - it's available at:
[1]http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to [2]http://lists.graemef.net/mailman/listinfo/lvs-users

References

1. http://www.linuxvirtualserver.org/
2. http://lists.graemef.net/mailman/listinfo/lvs-users
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

Le 14/05/2013 08:51, Horst Venzke-Fa Remsnet Ltd a écrit :
> Therefore - for IPVS security Obligations - the SNY Flood traffik should be
> stopped at the earlierst point : the IPVS systems its self.
It is a view that I do not share.
I prefer to use the solution to "limit" at the IPVS IP server and use
the SYN Cookies on the real servers.
Maybe I'm wrong, but I prefer distribute the attack on the real servers
rather than take the risk of dropping the IPVS directorhimself.
As the only way is to rewrite something which permit to do the SYNPROXY
for kernel 3.x series, perhaps you should find another way to obtain
this result. If there is a high risk of DoS in your case, perhaps
putting some equipments to manage that before the IPVS server should be
another good solution.

Best regards
--
Ivan
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

Hello Ivan,

OK, i explain my View more.
I had that Issue allready an at Big Iron EU customer - they still use 2.6
Longterm Kernels due that the patch not into 3.x .

Well with LVS-NAT the Real-Servers are BEHIND the IPVS at allmost second
network with route via IPVS ..
( up to spec by Standard LVS-NAT Howto´s )

So the SNY traffik PASSED the LB servers to real AND BACK
The real servers Over-FLOOD the LB (IPVS ) systems with traffik amounts they
not shuold.
And exacly for that the 2.6x SYNPROXY IPVS patch was made years ago.

In fackt - SNY Flood Traffik got not generated by Realservers due that
SYNPROXY by LB systems using IPVS-NAT
Modern Comercial Driven LB´s behave so today( like IBM´s i.e ) .

Right --- the realservers shuold handel allmost the traffik.
But for LVS-NAT its an issue due the traffik AMOUNT passes the Interfaces
and keeps the LB systems tooo quickly busy.

This issue not apply for LVS-DR and LVS-TUN , as the outbound traffik back
commes directly by REAL servers to the requested client(s).
And Right , to have an Firewall ( Cluster..) in front of an Webfarm , are
allways an Major solution .

Hope you got me more.

--
Mit freundlichen Grüßen / Best Regards
Horst Venzke ; PGP NET : 1024G/082F2E6D ; http://www.remsnet.de
Legal Notice: This transmittal and/or attachments may be privileged or
confidential. It is intended solely for the addressee named above. Any
review, dissemination, or copying is strictly prohibited. If you received
this transmittal in error, please notify us immediately by reply and
immediately delete this message and all its attachments. Thank you.


Gesendet: Dienstag, 14. Mai 2013 um 19:49 Uhr
Von: "Ivan Havlicek" <ivan@modulix.org>
An: lvs-users@linuxvirtualserver.org
Betreff: Re: [lvs-users] IPVS SYN-cookies -> IPVS security patch not 3.x
kernels
Le 14/05/2013 08:51, Horst Venzke-Fa Remsnet Ltd a écrit :
> Therefore - for IPVS security Obligations - the SNY Flood traffik should
be
> stopped at the earlierst point : the IPVS systems its self.
It is a view that I do not share.
I prefer to use the solution to "limit" at the IPVS IP server and use
the SYN Cookies on the real servers.
Maybe I'm wrong, but I prefer distribute the attack on the real servers
rather than take the risk of dropping the IPVS directorhimself.
As the only way is to rewrite something which permit to do the SYNPROXY
for kernel 3.x series, perhaps you should find another way to obtain
this result. If there is a high risk of DoS in your case, perhaps
putting some equipments to manage that before the IPVS server should be
another good solution.
Best regards
--
Ivan
_______________________________________________
Please read the documentation before posting - it's available at:
[1]http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to [2]http://lists.graemef.net/mailman/listinfo/lvs-users

References

1. http://www.linuxvirtualserver.org/
2. http://lists.graemef.net/mailman/listinfo/lvs-users
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

Le 14/05/2013 21:04, Horst Venzke-Fa Remsnet Ltd a écrit :
> So the SNY traffik PASSED the LB servers to real AND BACK The
> real servers Over-FLOOD the LB (IPVS ) systems with traffik amounts
> they not shuold. And exacly for that the 2.6x SYNPROXY IPVS patch
> was made years ago.

I use also IPVS with NAT for some years now. So, I know the hype of SYN
flood...

But, as it is very difficult to prevent some attack like :

# hping3 --data 666 --syn --destport 80 --flood --rand-source IP_POOR_VICTIM

only with SYN cookie, I prefer use another strategy for these issue.
In some words, each IPVS director have iptables rules and act as
Stateful firewall.
The rules concerning NEW connections are limited (number need to be
tuned) by sec.
The goal is to make grow conntrack tables more slowly, combined with a
low TCP time to live :

ipvsadm --set 2 5 5

So under pressure, the ipvs server have time purge his list enough quickly.
After some tests, I add also some hand made scripts to ban by MAC address
to much hurry up clients (tail -f /var/log/kernel.log) :

iptables -A INPUT -i eth0 -p tcp -m limit --limit 15/minute -j LOG
--log-level alert --log-prefix "INPUT:DROP "

For now, it's the best way i've found to deal with this.
In fact, my best advice is to not have ennemy...
I guess that in case of massive attack (some Go/s from multiples sources),
it'll be very hard to not disturb the web service :-(

Well, I'm a poor alone cowboy with my Gentoo, and I agree,
something better should be made !

> Right , to have an Firewall ( Cluster..) in front of an Webfarm ,
> are allways an Major solution .

I'm looking for some feed back about a PfSense cluster, you're welcome ;-)
My 2cts.
--

Ivan Havlicek

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

> It is a view that I do not share.
> I prefer to use the solution to "limit" at the IPVS IP server and use
> the SYN Cookies on the real servers.
> Maybe I'm wrong, but I prefer distribute the attack on the real servers
> rather than take the risk of dropping the IPVS director himself.

In our set-up, we're planning to have multiple directors running
active-active with the traffic spread across them via ECMP routing, and
we will have enough directors to take the load of a SYN flood that maxes
out our Internet link.


Alex


_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users