Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Marek Habersack <grendel@caudium.net>
To: Arnt Karlsen <arnt@c2i.net>
Cc: netfilter@lists.netfilter.org
Subject: Re: Tux and netfilter
Date: Mon, 7 Jul 2003 02:02:34 +0200	[thread overview]
Message-ID: <20030707000234.GD9350@thanes.org> (raw)
In-Reply-To: <20030707014751.276c32c5.arnt@c2i.net>

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

On Mon, Jul 07, 2003 at 01:47:51AM +0200, Arnt Karlsen scribbled:
[snip]
> > clogged (it's configured to accept 50k connections, keep alives are at
> > 1000 since setting
> 
> ..1000 seconds???  Shave off a zero or two, you should be able to serve
> any valid traffic within 5 seconds.
They are not 1000 seconds - 1000 keepalive slots tux keeps active around.
After there are more than that, it starts killing connections in the LRU
order.

> > them to 0 makes tux close any connection immediately, no logging
> > etc,). Apache sits on port 81 and when accessed directly it works
> > fine, that's good enough, but I'd like to do more. And here I come to
> > the real question I want to ask to the list. Is it possible and if
> > yes, then how, to redirect the offending packets from within tux to
> > the TARPIT chain? 
> 
> ..does your TARPIT traffic cost _you_ anything?
A little bit, a tiny bit. Works better than a DROP, actually. And it has the
added advantage that it ties resources of the attacker somewhat.

> > net/ipv4/icmp_echo_ignore_broadcasts=1
> 
> ..also possible to lie and say the box is a crashing, 
> or hung dead wintendo.
> 
> > fs/file-max=70000
> > fs/dir-notify-enable=0
> > net/ipv4/tcp_keepalive_time=30
> > net/core/rmem_max=262143
> > net/core/rmem_default=262143
> > net/core/wmem_max=262143
> > net/core/wmem_default=262143
> > net/ipv4/tcp_sack=0
> > net/ipv4/tcp_timestamps=0
> > net/ipv4/tcp_syncookies=1
> > net/ipv4/icmp_echo_ignore_all =1
> > net/ipv4/icmp_ignore_bogus_error_responses = 1
> > net/ipv4/tcp_syn_retries = 1
> > net/ipv4/tcp_synack_retries = 1
> > net/ipv4/tcp_keepalive_probes = 1
> > net/ipv4/tcp_keepalive_intvl = 10
> > net/ipv4/tcp_max_syn_backlog = 64
> > net/ipv4/tcp_low_latency = 1
> > net/ipv4/tcp_abort_on_overflow = 1
> > net/ipv4/ipfrag_time = 30
> > net/ipv4/tcp_fin_timeout = 10
> > net/ipv4/tcp_max_orphans = 2048
> 
> ..why so many?  Most of these would come from "google", no?
That's not a lot... Well, the ones that come from "google" constitute
perhaps 1/3 of the total. And I still have to think about the legit clients.

regards,

marek

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2003-07-07  0:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-06 21:14 Tux and netfilter Marek Habersack
2003-07-06 23:47 ` Arnt Karlsen
2003-07-07  0:02   ` Marek Habersack [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030707000234.GD9350@thanes.org \
    --to=grendel@caudium.net \
    --cc=arnt@c2i.net \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox