Mailing List Archive

Hello,

On Wed, 22 Nov 2000, joern maier wrote:

> Hi there,
>
> maybe anyone of you can help me. I got some Problem protecting my VS
> from
> SYN - flood attacks. Somehow the drop_entry mechanism seems not to work.
> Doing a SYN-Flood with 3 clients to my VS ( 1 director + 3 RS ) the
> System
> get´s unreachable. -> a single Server (one of my RS) "DoSed" by those
> clients
> stays alive.

You can't SYN flood the director with 3 clients only. You need
more clients. As alternative, you can download "testlvs" from the web
site. What shows ipvsadm -Ln under attack? How you activate drop_entry?
What shows "cat drop_entry" ?

> Set-up:
>
> all RS have tcp_syncookies enabled (1) the tcp_max_syn_backlog is set to
> 128
>
> after booting the director is set drop_entry var to 1 (echo 1 >
> drop_entry)
> (I have to do this all the time I reboot the director => is the
> drop_entry var
> not stored somehow ?)
> before compiling the Kernel I set the table size to 2^20 my Director has
> 256 MB of
> memory and no other applications are running so that should be o.k.

You don't need such large table, really.

> did I miss anything ?
>
> I'm using ip tunneling and lc scheduling if this is important
>
> I`m thankfull for any help I can get
>
> Joern


Regards

--
Julian Anastasov <ja@ssi.bg>

Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 22 Nov 2000, joern maier wrote:
>
> > Hi there,
> >
> > maybe anyone of you can help me. I got some Problem protecting my VS
> > from
> > SYN - flood attacks. Somehow the drop_entry mechanism seems not to work.
> > Doing a SYN-Flood with 3 clients to my VS ( 1 director + 3 RS ) the
> > System
> > get´s unreachable. -> a single Server (one of my RS) "DoSed" by those
> > clients
> > stays alive.
>
> You can't SYN flood the director with 3 clients only. You need
> more clients. As alternative, you can download "testlvs" from the web
> site. What shows ipvsadm -Ln under attack? How you activate drop_entry?
> What shows "cat drop_entry" ?
>

I dowloaded testlvs and flooded my System with it. With two clients, my
LVS
gets to a denial of service, allthough when I´m doing "cat drop_entry"
it still
shows me a "1". ipvsadm -Ln shows me:

192.168.10.1:80 lc
192.168.1.4:80 Tunnel 1 0 33246
192.168.1.3:80 Tunnel 1 0 33244
192.168.1.2:80 Tunnel 1 0 33246

during the flooding attack the connection values stay around this size.
Using the SYN-Flood tool with which I tried it before, ivsadm shows me
this:

192.168.10.1:80 lc
192.168.1.4:80 Tunnel 1 0 356046
192.168.1.3:80 Tunnel 1 0 355981
192.168.1.2:80 Tunnel 1 0 356013

so it shows me about ten times as many connectios as your tool. I took a
look
at the packets, both are quiet similar, they only differ in the
Windowsize
(testlvs has 0, the other tool uses a size of 65534) and sequence
numbers (o.k.
checksum as well)

I am activating drop entry like this:

- I switch on my computer (director) and start linux with the LVS Kernel
- I type cd /proc/sys/net/ipv4/vs
- I type echo 1 > drop_entry
- then I run the lvs scripts rc.lvs_tun on the director


what did I miss ?


> > Set-up:
> >
> > all RS have tcp_syncookies enabled (1) the tcp_max_syn_backlog is set to
> > 128
> >
> > after booting the director is set drop_entry var to 1 (echo 1 >
> > drop_entry)
> > (I have to do this all the time I reboot the director => is the
> > drop_entry var
> > not stored somehow ?)
> > before compiling the Kernel I set the table size to 2^20 my Director has
> > 256 MB of
> > memory and no other applications are running so that should be o.k.
>
> You don't need such large table, really.
>
> > did I miss anything ?
> >
> > I'm using ip tunneling and lc scheduling if this is important
> >
> > I`m thankfull for any help I can get
> >
> > Joern
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
> Send requests to lvs-users-request@LinuxVirtualServer.org
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users

Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 23 Nov 2000, joern maier wrote:
>
> > > You can't SYN flood the director with 3 clients only. You need
> > > more clients. As alternative, you can download "testlvs" from the web
> > > site. What shows ipvsadm -Ln under attack? How you activate drop_entry?
> > > What shows "cat drop_entry" ?
> > >
> >
> > I dowloaded testlvs and flooded my System with it. With two clients, my
> > LVS
> > gets to a denial of service, allthough when I´m doing "cat drop_entry"
> > it still
> > shows me a "1". ipvsadm -Ln shows me:
> >
> > 192.168.10.1:80 lc
> > 192.168.1.4:80 Tunnel 1 0 33246
> > 192.168.1.3:80 Tunnel 1 0 33244
> > 192.168.1.2:80 Tunnel 1 0 33246
>
> May be you run testlvs with 100,000 source addresses.
>
> > during the flooding attack the connection values stay around this size.
> > Using the SYN-Flood tool with which I tried it before, ivsadm shows me
> > this:
> >
> > 192.168.10.1:80 lc
> > 192.168.1.4:80 Tunnel 1 0 356046
> > 192.168.1.3:80 Tunnel 1 0 355981
> > 192.168.1.2:80 Tunnel 1 0 356013
> >
> > so it shows me about ten times as many connectios as your tool. I took a
> > look
> > at the packets, both are quiet similar, they only differ in the
> > Windowsize
> > (testlvs has 0, the other tool uses a size of 65534) and sequence
> > numbers (o.k.
> > checksum as well)
> >
> > I am activating drop entry like this:
> >
> > - I switch on my computer (director) and start linux with the LVS Kernel
> > - I type cd /proc/sys/net/ipv4/vs
> > - I type echo 1 > drop_entry
>
> May be you need to tune amemthresh. 1024 pages (4MB) are too
> low value. What shows "free" under attack? You can try with 1/8 RAM size
> for example. You know what is the main goal of these defense strategies:
> to keep free memory in the director. Nothing more. They are activated
> according to the free memory size. The packet rate is not considered.
>
> So, 1,000,000 entries created from the other tool occupy
> 128MB memory. You have 256MB :) Boot with mem=128MB or set amemthresh
> to 32768 or run testlvs with more source addresses (2,000,000). I'm
> not sure if the last will help if the other tool you use does not
> limit the number of spoofed addresses. But don't run testlvs with
> less than -srcnum 2000000. If the setup allows rate > 33,333 packets/sec
> LVS can create 2,000,000 entries that expire for 60 seconds (the
> SYN_RECV timeout). Better not to use the -random option in testlvs
> for this test.
>
> So, you can test with such large values but make sure you
> tune amemthresh in production with the best value for your director.
> The default value is not very useful. You can test whether 1/8 is
> a good value (8192 for 4K page size).
>

that sounds all good to me, but what I´m really wondering about is, why
has the drop_entry variable still a value of 1 => I thought it has to be
2 when
my System is under attack ? To me it looks like LVS does not even think
it´s under attack and therefore does not use the drop_entry mechanism

cheers,
Joern

Hello,

On Thu, 23 Nov 2000, joern maier wrote:

> > You can't SYN flood the director with 3 clients only. You need
> > more clients. As alternative, you can download "testlvs" from the web
> > site. What shows ipvsadm -Ln under attack? How you activate drop_entry?
> > What shows "cat drop_entry" ?
> >
>
> I dowloaded testlvs and flooded my System with it. With two clients, my
> LVS
> gets to a denial of service, allthough when I´m doing "cat drop_entry"
> it still
> shows me a "1". ipvsadm -Ln shows me:
>
> 192.168.10.1:80 lc
> 192.168.1.4:80 Tunnel 1 0 33246
> 192.168.1.3:80 Tunnel 1 0 33244
> 192.168.1.2:80 Tunnel 1 0 33246

May be you run testlvs with 100,000 source addresses.

> during the flooding attack the connection values stay around this size.
> Using the SYN-Flood tool with which I tried it before, ivsadm shows me
> this:
>
> 192.168.10.1:80 lc
> 192.168.1.4:80 Tunnel 1 0 356046
> 192.168.1.3:80 Tunnel 1 0 355981
> 192.168.1.2:80 Tunnel 1 0 356013
>
> so it shows me about ten times as many connectios as your tool. I took a
> look
> at the packets, both are quiet similar, they only differ in the
> Windowsize
> (testlvs has 0, the other tool uses a size of 65534) and sequence
> numbers (o.k.
> checksum as well)
>
> I am activating drop entry like this:
>
> - I switch on my computer (director) and start linux with the LVS Kernel
> - I type cd /proc/sys/net/ipv4/vs
> - I type echo 1 > drop_entry

May be you need to tune amemthresh. 1024 pages (4MB) are too
low value. What shows "free" under attack? You can try with 1/8 RAM size
for example. You know what is the main goal of these defense strategies:
to keep free memory in the director. Nothing more. They are activated
according to the free memory size. The packet rate is not considered.

So, 1,000,000 entries created from the other tool occupy
128MB memory. You have 256MB :) Boot with mem=128MB or set amemthresh
to 32768 or run testlvs with more source addresses (2,000,000). I'm
not sure if the last will help if the other tool you use does not
limit the number of spoofed addresses. But don't run testlvs with
less than -srcnum 2000000. If the setup allows rate > 33,333 packets/sec
LVS can create 2,000,000 entries that expire for 60 seconds (the
SYN_RECV timeout). Better not to use the -random option in testlvs
for this test.

So, you can test with such large values but make sure you
tune amemthresh in production with the best value for your director.
The default value is not very useful. You can test whether 1/8 is
a good value (8192 for 4K page size).


Regards

--
Julian Anastasov <ja@ssi.bg>

Hello,

On Thu, 23 Nov 2000, joern maier wrote:

> > May be you need to tune amemthresh. 1024 pages (4MB) are too
> > low value. What shows "free" under attack? You can try with 1/8 RAM size
> > for example. You know what is the main goal of these defense strategies:
> > to keep free memory in the director. Nothing more. They are activated
> > according to the free memory size. The packet rate is not considered.
> >

> that sounds all good to me, but what I´m really wondering about is, why
> has the drop_entry variable still a value of 1 => I thought it has to be
> 2 when
> my System is under attack ? To me it looks like LVS does not even think
> it´s under attack and therefore does not use the drop_entry mechanism

You are right. You forgot to specify when the LVS to think it is
under attack.

Read again my mail carefully. drop_entry switches automatically
from 1 to 2 when the free memory reaches amemthresh. Show us an evidence
that your free memory is below 4MB.

int ip_vs_amem = nr_free_pages+page_cache_size+(buffermem>>PAGE_SHIFT);
int nomem = (ip_vs_amem < sysctl_ip_vs_amemthresh);


Read http://www.linuxvirtualserver.org/defense.html
I just read it and I see that everything is explained.

> cheers,
> Joern


Regards

--
Julian Anastasov <ja@ssi.bg>