From: Joel Newkirk <netfilter@newkirk.us>
To: George Peverill <gpeverill@ns.sympatico.ca>,
netfilter@lists.netfilter.org
Subject: Re: I have to become a bandwidth Nazi , Netfilter useable.
Date: Sat, 1 Mar 2003 10:19:00 -0500 [thread overview]
Message-ID: <200303011019.00158.netfilter@newkirk.us> (raw)
In-Reply-To: <000201c2dffa$8ad18480$0c05a8c0@Sherby>
On Saturday 01 March 2003 08:57 am, George Peverill wrote:
> I am running a small network (about 10-12 machines) with a linux
> gateway machine providing http/ssh/vpn(pptp)/firewalling/NAT
> Recently we've had someone that loves to hog bandwidth a tad (ie:
> downloading movies at 150-200k/s) while we slave away
> with the remaining 50k/s or so of bandwidth. I was wondering and I
> think its possible) if I could remedy this without resorting
> to compilicated QoS / CBQ crap. Basically is it possible to write a
> rule that'd say drop 25% or maybe 50% of all packets going to his
> machine from the gateway? (nasty yes agreed)
>
> -internal interface is eth0 (192.168.0.x)
> -external interface is eth1
>
> Is it possible to do it based on his IP (which is known lets say
> 192.168.0.55 for example sake) or his MAC address which is known.
Match in FORWARD chain (BEFORE any ACCEPT rules) with "-d 192.168.0.55",
and also possibly with "-p tcp --dport <portnumber>" with the port that
the traffic goes to, or "--sport" with the port the traffic comes from.
(this depends on the p2p app he's using) You can use the limit match to
specify a fixed number of packets in a specified period of time, but not
a percentage. You'd need to figure out how many packets per second to
set as a maximum.
You may find that DROP doesn't help much, though, as it's likely his p2p
client will just keep requesting data, and the source will just keep
pumping it through as fast as it's able to. You might be better served
by Arnt Karlsen's favored approach - the TARPIT target from
patch-o-matic, or my favorite - whack him on the head with a keyboard.
It also might help to use the similar dport/sport+sourceIP+limit approach
to restrict how many requests his p2p client can send out in a given
timeframe, as well as upload traffic. (many p2p clients force, or
strongly encourage [IE by limiting download to 4x upload] allowing
uploads from the client)
> Any help would be greatly appreciated. I dunno how this can be done
> but im sure someone might be able to figure it out , would have to be
> done in the PREROUTING where SNAT is done wouldnt it ?
No, this is filtering and should be done in the filter table, in this
case the FORWARD chain.
j
next prev parent reply other threads:[~2003-03-01 15:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-01 13:57 I have to become a bandwidth Nazi , Netfilter useable George Peverill
2003-03-01 15:19 ` Joel Newkirk [this message]
2003-03-01 15:34 ` Kelly Setzer
2003-03-01 17:50 ` Arnt Karlsen
2003-03-01 15:38 ` Kelly Setzer
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=200303011019.00158.netfilter@newkirk.us \
--to=netfilter@newkirk.us \
--cc=gpeverill@ns.sympatico.ca \
--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