|
Hello,
On Sun, 10 Feb 2013, DjinnS wrote:
> Bonjour,
>
> We are facing several syn flood attacks since the last 2 weeks.
>
> We use IPVS boxes in top of our infrastructure directly after our
> routers. We use IPVS with the option “Netfilter connection tracking”.
> So, our boxes (2 boxes in active/backup) made filtering and
> load-balancing. We use IPVS in NAT mode and a 3.0.36 kernel.
> For the moment, we reduce effects of syn flood attacks with our routers
> (discard traffic). But we are interested by doing this job on our
> firewalls. We see a lot of discussions about these subjects and I have a
> few questions for the community and your experiences with these situations.
>
> First, we know about LVS defense strategies against DoS attack
> (http://www.linuxvirtualserver.org/docs/defense.html). These options are
> disabled for the moment but we think activate them.
> * How to determine the value for /proc/sys/net/ipv4/vs/amemthresh ? Our
> boxes have 4Gb of memories.
Documentation/networking/ipvs-sysctl.txt has some
info. amemthresh is in pages (probably 4096 bytes) but
current calculations are wrong for HIGHMEM systems, we
should care only for NORMAL zone (sort of
free+reclaimable+file). It is used for drop_entry=1/2,
drop_packet=1/2 or secure_tcp=1/2.
Do you have HIGHMEM?
grep High /proc/meminfo
> * In the case of using /proc/sys/net/ipv4/vs/drop_packet in the mode 3,
> how to configure the good value for /proc/sys/net/ipv4/vs/am_droprate ?
This is bad idea. It will drop 1 packet on
every am_droprate packets. Mode 3 is used in case some
tool decides that system is loaded and can react
rapidly by changing drop_packet between 0 and 3.
> * Regarding to /proc/sys/net/ipv4/vs/secure_tcp, we see in the
> documentation (web+man) that we can customize some timeouts. But we
> can't find the following entries in the /proc directory:
>
> /proc/sys/net/ipv4/vs/timeout_close
> /proc/sys/net/ipv4/vs/timeout_closewait
> /proc/sys/net/ipv4/vs/timeout_established
> /proc/sys/net/ipv4/vs/timeout_finwait
> /proc/sys/net/ipv4/vs/timeout_icmp
> /proc/sys/net/ipv4/vs/timeout_lastack
> /proc/sys/net/ipv4/vs/timeout_listen
> /proc/sys/net/ipv4/vs/timeout_synack
> /proc/sys/net/ipv4/vs/timeout_synrecv
> /proc/sys/net/ipv4/vs/timeout_synsent
> /proc/sys/net/ipv4/vs/timeout_timewait
> /proc/sys/net/ipv4/vs/timeout_udp
They are not available anymore. But secure_tcp
still changes the state table for TCP based on
amemthresh.
> As I said before, we use 3.0 kernel. Is there a change about this
> entries ? We just have this entries:
>
> am_droprate
> amemthresh
> cache_bypass
> conntrack
> drop_entry
> drop_packet
> expire_nodest_conn
> expire_quiescent_template
> lblc_expiration
> lblcr_expiration
> nat_icmp_send
> secure_tcp
> snat_reroute
> sync_threshold
> sync_version
>
> We also read discussions about the performance impact of connection
> tracking support. A lot of people recommend to disable connection
> tracking because it’s consume a lot of CPU and memory, especially during
> syn flood attacks. But, after all, connection tracking should help CPU
> by reducing time to look at “accepted connection”. So, do you have
> experience without connection tracking enabled and impact during syn
> flood attacks ? Can we continue to use LB+Filtering on the same box
> without connection tracking enabled ? Or, do we need to just use the
> “raw” table in iptables to bypass connection tracking for destination
> port targeted by these attacks ?
I remember for one discussion. Tim reported
that IPVS works better with conntrack=1 and with properly
tuned netfilter conntracking in case contracking is
required with IPVS:
http://marc.info/?t=134728825000003&r=1&w=2
> Thank you in advance.
>
> Regards,
>
> --
> Guillaume
Regards
--
Julian Anastasov <ja@xxxxxx>_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
