From: Arnt Karlsen <arnt@c2i.net>
To: netfilter@lists.netfilter.org
Subject: Re: Tux and netfilter
Date: Mon, 7 Jul 2003 01:47:51 +0200 [thread overview]
Message-ID: <20030707014751.276c32c5.arnt@c2i.net> (raw)
In-Reply-To: <20030706211403.GA9350@thanes.org>
On Sun, 6 Jul 2003 23:14:03 +0200,
Marek Habersack <grendel@caudium.net> wrote in message
<20030706211403.GA9350@thanes.org>:
>
> The counter values are the real ones. I would use the iplimit matcher,
> but I don't want to use connection tracking since that would hose the
> machine pretty quick. All of the above actions have the effect that
> the machine is reachable, interaction is good, but tux is practically
> 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.
> 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?
> 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?
> net/ipv4/tcp_tw_reuse = 1
>
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
next prev parent reply other threads:[~2003-07-06 23:47 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 [this message]
2003-07-07 0:02 ` Marek Habersack
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=20030707014751.276c32c5.arnt@c2i.net \
--to=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