[PF] Packet speed limit

I

IgorGlock

Hello all together!
;)

Today I will learn how can I set traffic speed limit for port TCP 27015 :stud

google can't help me and handbook too...
If this plug-in for pf "ignore" packet it's okey/good!

example:
TCP: 27015 = max 25kBit's
 
Yeah...

I don't know how can I do this:
2sanfc1.png


every IP (without rages) only 25kBits :)
 
You can't limit incoming traffic, only outgoing traffic (either originating locally, or as a response to incoming traffic (return traffic)). You can't limit based on random incoming IP addresses. Please read the documentation.
 
existing pc1.conf:
Code: 
table <german> persist file "/etc/german"
block in quick proto { tcp udp } from ! <german> to any port { 27015, 3306, 1337 }
pass out

is that right?

Code: 
table <german> persist file "/etc/german"
block in quick proto { tcp udp } from ! <german> to any port { 27015, 3306, 1337 }
queue [B]port { 27015 }[/B] bandwidth 25Kb
pass out
 
You cannot limit incoming traffic because by the time pf/ALTQ knows the limit has been reached, the data has already traversed your internet line and is at your box. (Otherwise, it wouldn't be there to trigger the rule.) I believe you are able to put a limit incoming traffic with ALTQ (not sure because I've never tried), but there's no point and it'll do nothing of use.

Outgoing traffic, because it's passing through pf/ALTQ before it leaves your box. This can be effective at throttling the incoming by limiting the speed at which ACKs are sent to the sender, but it's by no means certain.

Also, google can ALWAYS help... you just need to know how to ask it nicely. ;) :e Go to google.com/bsd and search for ALTQ, then start reading. :)
 
okey :)

and how can I block incoming packets from DDoS (or DoS)

not SSH attacks I mean if one CrazyMonkey like to broken my gameserver... if he send too many packets how can I block then?

sorry I'm from germany and I can't speak english very good but ...learn :D
 
IgorGlock said:
and how can I block incoming packets from DDoS (or DoS)

not SSH attacks I mean if one CrazyMonkey like to broken my gameserver... if he send too many packets how can I block then?
Click to expand...

You can't at your box - that's why DOS attacks are so hard to prevent. Once the packets get to your system, they've already taken up the bandwidth required to get there, therefore even if you blacklist the offending IPs at your firewall, there's nothing preventing them from flooding your box and saturating your connection. Blacklisting prevents them from exploiting a security hole in a specific piece of software, but does not stop them from sending packets to your box. Most attackers will move on to another system if they do not get a response, but if somebody is determined to DOS your system in such a manner (targeting you personally), you cannot stop it locally. Your ISP would need to block them upstream from your system in this case.
 
but if I connect with PuTTY(Remoute-Console) to wrong port my machine block that! Or if many (not 999999) packets over 25kBit's come in (~100kBit's) my machine can block that? But pf can't do that :r ... plug-ins or some software for FreeBSD?

:f
 
Code: 
-------------   A    ------------   B   ------------
| Malicious |------->| Your ISP |------>| Your Box |
|   User    |        ------------       ------------
-------------

If a packet goes from a malicious user, it goes through the internet to your ISP via link A. Link A is most likely huge and not going to be easily saturated. Your ISP routes it to your box over link B. You have pf configured to block connections from another country or limit the rate at which packets come in - pf will happily discard the packet without complaining. However, the packet has already traversed link B, from your ISP to your machine. Even if pf drops the packet at the firewall, it does not change the fact that it has already used some of the bandwidth from your ISP to your machine. Because of this, there is no way for you, at your machine, to stop a remote attacker from flooding your box with packets, saturating link B, and DOSing you. It does not matter what software, plug-ins, etc are loaded on your machine because by the time your machine gets the packet, it's too late - the bandwidth has been used. When you try to connect to the wrong port with putty, packets have traveled over link B and used some of your bandwidth - even though the connection was blocked, a packet was sent requesting the connection be established and then a refusal packet sent back to the sender. (Or nothing is sent back and the connection times out if you have a blackhole-like policy for blocks.) You can see evidence of this if you have your machine set up to log blocked connection requests and look in your logs.

The only way that I am aware of to stop your link from being saturated by a user from the internet is to contact your ISP and have THEM stop routing traffic from certain IP(s) to your box, therefore having the packets never travel over link B. This will most likely break functionality for many sites/services, plus will almost certainly be a billable request for your ISP (if they're willing to do it at all).
 
Ruler2112 said:
The only way that I am aware of to stop your link from being saturated by a user from the internet is to contact your ISP and have THEM stop routing traffic from certain IP(s) to your box, therefore having the packets never travel over link B. This will most likely break functionality for many sites/services, plus will almost certainly be a billable request for your ISP (if they're willing to do it at all).
Click to expand...



You can also order enterprise internet bandwidth 10Gbit. This'll probably help :p
 
Apache can have traffic/bandwith limit... 1IP-Adress 500kBit why I can't use this feature for other port?

FTP in/outcoming bandwith can I set too...

^ very bad english :-(

or I have other idea! How can I set max connections limit every 1IP :stud ;)
 
Apache and FTP serve traffic to the outside world == upload bandwidth, dude ... and that's where you're king. If you allow me to upload to your FTP server ( == your download bandwidth) and I decide to blast 10 Gbps your way, there's nothing you can do except take down your FTP or yelp down the phone to your ISP. Has it sunk in yet?
 
yes I understand ... but if you blast to port 999 100kBits I can do something? I mean if you attak with low bandwith... of yourse I can block it witch some firewall! But I don't know how :-/

my firewall can't fight vs 10GBits but if you "exceed" my normal "25Kbits" bandwith how can I "ignore" your packets?
 
You can't block incoming traffic based on bandwidth. Even if you use something like ipfw pipes, you will just scream to the people sending you data "Not so fast! Back off!", and it's up to them to recognise and obey it. If their applications have no such logic or they don't care, the traffic will just continue or even increase (retransmits, retransmits of retransmits, etc.). The only way you can control bandwidth in both directions is if you own the application that uses the bandwidth, e.g. a bittorrent client with upload/download limits. And it only really works because the bittorrent protocol has built-in logic to 'slow the other side down' by actions like 'snubbing' and 'throttling'. This logic is not present in many other applications and protocols, or it is simply not implemented, or the other side is malevolent to begin with.
 
Oh, and whatever you may think: "ignoring" doesn't make it go away. The monster is already under your bed.
 
I mean if too many packets incoming pf can block/ignore this :p

ughh... monsteeer xD
devilgrin.gif


with block I mean: don't give this packets to my GameServer or Torrent xD :p
 
Your torrent client can limit bandwidth itself, like I explained, and it usually does so very well.

The problem is not that we do not know what you mean, but that you don't know what we mean.

The only way to even approximate what you want would be to put a bridge between the Internet and the server running your services (so an extra server in between), and running ALTQ on both interfaces.

Then you can limit upload traffic on the external interface (to the Internet) and upload traffic on the internal interface (to the server/LAN) based on e.g. IP address, source/destination port or protocol, but it will still be a 'hollow victory' by simply dropping traffic that has already arrived, probably causing more traffic because of all of the retransmits this will cause.

If you want to try this: happy reading. It complicates your initial question by 2^16 headaches. and now you're climbing Mount Everest without even your shorts.

DD out.
 
Note that queueing is only useful for packets in the outbound direction. Once a packet arrives on an interface in the inbound direction it's already too late to queue it -- it's already consumed network bandwidth to get to the interface that just received it. The only solution is to enable queueing on the adjacent router or, if the host that received the packet is acting as a router, to enable queueing on the internal interface where packets exit the router.
Click to expand...

What about this approach:

Limit upload with setting queueing on external interface (INTERNET)

Limit download with setting queueing on internal interface (LAN)

would it work?
 
That's what I addressed in the post before yours, I think. You're still dropping packets that have already been accepted from the outside. It just prevents overloading the LAN, but at a cost. Your bitbucket gets warm.
 
You must log in or register to reply here.
Back
Top