# [PF] Packet speed limit



## IgorGlock (Feb 24, 2010)

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


----------



## DutchDaemon (Feb 24, 2010)

Today you will learn? Ok.

pf.conf(5) - ALTQ

Good luck.


----------



## IgorGlock (Feb 24, 2010)

Yeah...

I don't know how can I do this:






every IP (without rages) only 25kBits


----------



## SirDice (Feb 24, 2010)

http://www.openbsd.org/faq/pf/queueing.html


----------



## DutchDaemon (Feb 24, 2010)

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.*


----------



## IgorGlock (Feb 24, 2010)

existing pc1.conf:

```
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?


```
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
```


----------



## IgorGlock (Feb 24, 2010)

oh... per ip address 25kbit's I can't do this?

maybe with plug-in? :stud


----------



## sniper007 (Feb 24, 2010)

Perfect


----------



## IgorGlock (Feb 24, 2010)

that's only Windoof Paint 

but it's "impossible" ? :stud


----------



## Ruler2112 (Feb 24, 2010)

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.


----------



## IgorGlock (Feb 24, 2010)

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


----------



## Ruler2112 (Feb 24, 2010)

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?



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.


----------



## IgorGlock (Feb 25, 2010)

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


----------



## Ruler2112 (Feb 25, 2010)

```
-------------   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).


----------



## sniper007 (Feb 26, 2010)

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).





You can also order enterprise internet bandwidth 10Gbit. This'll probably help


----------



## IgorGlock (Feb 26, 2010)

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


----------



## DutchDaemon (Feb 26, 2010)

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?


----------



## IgorGlock (Feb 26, 2010)

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?


----------



## DutchDaemon (Feb 26, 2010)

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.


----------



## DutchDaemon (Feb 26, 2010)

Oh, and whatever you may think: "ignoring" doesn't make it go away. The monster is already under your bed.


----------



## IgorGlock (Feb 26, 2010)

I mean if too many packets incoming pf can block/ignore this 

ughh... monsteeer xD 
	

	
	
		
		

		
		
	


	




with block I mean: don't give this packets to my GameServer or Torrent xD


----------



## DutchDaemon (Feb 26, 2010)

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.


----------



## sniper007 (Mar 10, 2010)

> 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.



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?


----------



## DutchDaemon (Mar 10, 2010)

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.


----------



## IgorGlock (May 23, 2010)

HellÃ¶!

I found something...
http://forums.freebsd.org/showpost.php?p=76341&postcount=4


```
set optimization aggressive

ext_if = "em0"

pass in on $ext_if proto tcp from any to any port
  synproxy state (source-track rule, max-src-conn 5, if-bound)
```

My question is: can I use that without "bridge" ?
Or is something wrong?


----------



## expl (May 24, 2010)

While it is not possible to protect your net's hardware from DoS attacks there are methods of minimizing the damage done to your server as a unit by hardening your TCP/IP stack. This will make your server and services much more durable to DoS like attacks. There are quite a few documents on the net regarding stack hardening, google them.


----------



## IgorGlock (May 24, 2010)

yes... but I can protoct my software-server. (TeamSpeak like)

this rule can protect software?


----------



## DutchDaemon (May 24, 2010)

You can protect and rate-limit your ports and your software and your servers all you like. You can still be DDOS'ed and starved of bandwidth though ... which is what everyone's been saying about 25 times now.


----------



## kvi (May 25, 2010)

I'll try to explain. Let's stop thinking about TCP traffic and instead think about waterpipes. 



```
Huge watersource <== waterpipe ==> watersystem handler <== your personal waterpipe ==> your glass
(malicious user)                        (ISP)                                         (your server)
```

Now, it someone from the "huge watersource" decides to fill your waterpipe with his water, he simply does so and there is nothing you can do about it. You can always put a cover to your glass, so it won't fill up, but it won't change the fact that the water has already filled your waterline before it hits the cover. Only way to stop that user from filling your waterpipes is to ask the handler (ISP) to stop directing water to your pipes from that user. There is no other way. (back to computers: if somebody sends you IP packets and fills you bandwidth, you can either "drink it" or "let it go to waste")

And about those Apache and torrent: what you CAN do, is decide how much water you send from your "glass" to your pipes. That is why apache, ftpd, etc. can put a limit for the user - they just won't send more then told to. And about the torrent: I think that was already explained earlier. 

And hopefully someone can possibly explain my idea even simpler


----------



## DutchDaemon (May 25, 2010)

I'm afraid someone will ask whether a tap interface or a bridge would help to stem the flow.


----------



## dennylin93 (Jun 2, 2010)

DutchDaemon said:
			
		

> 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.*



I've always wondered why it isn't possible to limit incoming traffic with PF. It is because of implementation difficulties or something similar?

Wget can limit the download speed with --limit-rate though.


----------



## DutchDaemon (Jun 2, 2010)

Application-based rate/speed-limiting works because there's communication ('an understanding') between the applications/protocols on both ends. PF is just a raw packet-filter that can do no more than produce messages and errors to slow the other side down; it has no means of communication with the sending applications/protocols in a specific way.


----------



## teohhanhui (Jun 14, 2010)

DutchDaemon said:
			
		

> Application-based rate/speed-limiting works because there's communication ('an understanding') between the applications/protocols on both ends. PF is just a raw packet-filter that can do no more than produce messages and errors to slow the other side down; it has no means of communication with the sending applications/protocols in a specific way.



Is there no way to perform such rate limiting other than at the client? How does a download manager perform rate limiting of HTTP/FTP downloads when the servers don't have such a mechanism (AFAIK)?


----------



## DutchDaemon (Jun 14, 2010)

Downloading is done by your application. It can influence how it uses the underlying network, e.g. by manipulating how and how often it requests partial simultaneous downloads and size ranges (e.g. HTTP/206). It can also just use dirty and wasteful tactics like sending tcp resets upstream.


----------



## teohhanhui (Jun 14, 2010)

So it seems like the need for inbound traffic management never occurred to the designers of these protocols and we're stuck without any practical solution?


----------



## kvi (Jun 14, 2010)

It's not really the designers fault. After all, you can shout the sender to stop, but there is no way to force him to do so. Atleast I can't figure out how it would be (even theoretically) possible to force someone to stop sending you data.


----------



## teohhanhui (Jun 15, 2010)

kvi said:
			
		

> It's not really the designers fault. After all, you can shout the sender to stop, but there is no way to force him to do so. Atleast I can't figure out how it would be (even theoretically) possible to force someone to stop sending you data.



That's what I would like to find out. Is there a well documented way that you could ask them to slow down? Whether they will abide by your request is another matter, but would it not be feasible for some form of bandwidth negotiation to take place before/during the transfer?


----------



## kvi (Jun 16, 2010)

That is usually handled on software level when needed (between client & server or client & client). I think it could lead in quite a mess if all the routers world wide would have to negotiate speedlimits and monitor each connection. There can be quite many routers between the server and client. After saying that, I must admit that Im no expert in this matter.


----------

