All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.