Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

In linux, considering this use case:

1.  User initiates http request for webpage to remote server
2.  Remote server answers request and sends packets

Is there any reference to the user who started the process that made the request to the remote server on the incoming packets the remote server sends?

I'm trying to figure out a way to filter ingress traffic so I can rate limit on a per user basis rather than just rate limiting the entire system.

share|improve this question
    
I think you need to tell us a bit more about what's behind your 'rate limiter', how the users connect through it etc. –  Iain Jun 27 '14 at 19:51
    
@Iain basically I just want to limit a given users network bandwidth so they can't eat up all the system resources. I accomplished this with egress traffic already, but been racking my brain trying to figure out how to do it with ingress traffic. So far it looks like using an imq or ifb mirroring will work, but either way I still need a way to link incoming packets to a given user. –  Rooster Jun 27 '14 at 19:57
    
You didn't answer my question. –  Iain Jun 27 '14 at 19:57
    
@Iain The linux kernel is the rate limiter in this instance? IE. linux tc –  Rooster Jun 27 '14 at 20:00
2  
You shouldn't rate limit ingress. You have no control over when, or how fast that data comes in (unless you're in control of the router). All you can do is drop ingress, which makes the situation worse since it will force the sender to retransmit. –  Matthew Ife Jun 27 '14 at 20:10

4 Answers 4

Yes, you can use the Ident protocol to identify the user at the source.

Well, you used to be able to. Nowadays the only people who expose ident servers to the Internet at large are IRC users who want a funky nickname.

Oh, and people who've misconfigured their systems.

share|improve this answer

This is not achievable natively within the TCP/IP protocol, because... well, that's just not how the protocol works - it doesn't have a concept of users, and is designed to just transfer data between devices.

The way this is generally done (rate-limiting a specific remote user) is through the use of sessions (layer 5 in your OSI networking model, which is 1 or 2 layers higher than TCP/IP). You assign something unique to each user, like a cookie or a token, so that you can correlate individual sessions to specific users, which you can then pass to your rate-limiter (as opposed to just an IP address, which is the simple way of doing it).

share|improve this answer
    
I'm actually trying to limit a local user who might decide to download a 100 GB file from affecting another users ability/speed to download a more normal size file. Would using a session layer technique work for that as well? –  Rooster Jun 27 '14 at 20:05
6  
@Rooster Perhaps you should ask THAT question instead of this one? –  voretaq7 Jun 27 '14 at 20:11
4  
@Rooster After asking that question, go look up the X-Y problem. –  MikeyB Jun 27 '14 at 20:14
    
looks like trickle might do this. tecmint.com/… On a side note I hate the X any Y problem. Sorry for exposing you all too it here. –  Rooster Jun 27 '14 at 20:25

Traffic shaping for your users isn't a bad idea, but you're going about it in the wrong way - specifically, you're insisting on trying to shape inbound traffic. This quote comes from the Linux Advanced Routing and Traffic Control HOWTO

With queueing we determine the way in which data is SENT. It is important to realise that we can only shape data that we transmit.

With the way the Internet works, we have no direct control of what people send us. It's a bit like your (physical!) mailbox at home. There is no way you can influence the world to modify the amount of mail they send you, short of contacting everybody.

[...]

If you have a router and wish to prevent certain hosts within your network from downloading too fast, you need to do your shaping on the inner interface of your router, the one that sends data to your own computers.

As voretaq7 and MikeyB have said in their comments on Hopeless Noob's answer, you have decided to accomplish underlying task X by method Y, and you're asking us all about method Y. Sadly, method Y is the wrong way to accomplish task X. This is leading to unproductive answers and general frustration.

There are usually reasons why things are the way they are, and in free software, those methods are rarely related to marketing or other irrelevancies; they are often (though by no means always) related to facts and reality. So, sit down and read about the methods provided to achieve what you're trying to achieve, and then work out how to use those methods to solve your particular problem.

Edit: trickle isn't working with the network stack at all; it gets involved far earlier than that by intercepting calls to glibc's networking code for dynmically-linked binaries that use TCP as a transport mechanism.

That doesn't prove that traffic-shaping can be used on inbound traffic, it proves there are other approaches to limiting network throughput than working directly with the kernel's network stack. You could also do what you want with an authenticating proxy, eg squid which can do per-user bandwidth quotas.

Let me be clear: I'm not saying that what you want is impossible. I'm saying I don't believe you can or should do it with inbound traffic-shaping.

Both squid and trickle actually make voretaq7/MikeyB's point: that if you had asked how to achieve what you actually want done, you would have got much better answers.

share|improve this answer
    
the problem I'm having accepting that this isnt possible, is three fold. 1, that guide says that the things imq can do or ifb mirroring can do aren't possible. 2, its about linux 2x when the current linux kernel is at 4x(basically). 3, the trickle tool does almost exactly what I want thus disproving everything. +1 for indulging me though. –  Rooster Jun 28 '14 at 7:30

If the iptables rules are applied on the host where the client is running, then you can make use of the owner module. This only works with outgoing packets, so you'd need to use CONNMARK target to store information from outgoing packets which you need when processing incoming packets.

That approach does not work, if the packets are traveling over a network link between the client and the firewall. Around 15 years ago, I heard about a research project trying to extent the IP packets on the LAN with information, which would allow the firewall to apply rules similar to the owner module. I don't think the implementation ever got used in any real production environment.

Sticking with already deployed protocols, the ident protocol the answer from @MikeyB may be the only option. Unfortunately having the firewall do extra communication in order to process a packet is not a good option. Having to buffer a packet such that the fate of the packet can depend on packets received at a later time, may require a fundamental design change in the packet filtering. Also you are going to have added latency due to needing a couple of roundtrips to communicate with the ident daemon. You also have to take care to avoid cyclic dependencies, because you are making packet forwarding (i.e. the IP layer) depend on the ident protocol, which is running on top of TCP.

The extra latency may be avoidable, if by the time the SYN packet from the client is forwarded, the ident communication is initiated. Then it it will likely have completed before the final ACK of the TCP handshake. However initiating ident communication that early will make the firewall very vulnerable to SYN-flooding from the LAN side. Initiating ident communication later will make the attack marginally harder while still having a chance of completing ident communication before the first data packet need to be forwarded. However you are putting the protection against a SYN-flood from your LAN in the hands of random servers on the Internet. A host on your LAN could easily collude with a host on the Internet to perform a flood, which is difficult to protect against. This may not be a new problem though, any stateful firewall could be vulnerable to such attacks.

It is important to keep in mind, that in every situation, the administrator of the host where the client is running decides, if user information will be available to you or not. So you have to be prepared to handle situations in which user information is not available to you.

share|improve this answer
1  
Even if applied on the host where the client is running, -m owner is only valid in the OUTPUT and POSTROUTING chains, so it probably won't be much use for identifying inbound traffic for a local user. –  MadHatter Jun 28 '14 at 7:03
1  
@MadHatter Good point. It makes sense that incoming packets are not associated with a socket, as the rules being applied could change which socket is ultimately going to receive the packet. But if connection tracking is used, the packet will be matched with a connection before the filter chains are applied (if a matching connection exists). So how come you can't use owner in those cases? –  kasperd Jun 28 '14 at 7:22
    
I'm not sure, since I didn't write the code! But my understanding is that netfilter's connection tracking is purely synchronicity-based; ie, if a packet with the right source address, destination port and protocol arrives shortly after one in the other direction with the matching destination address, source port and protocol, it is considered a match. No lookup into the bits of kernel space that deal with process owners and sockets is needed in such a case, so that information might not be available to/from the existing tracking mechanism. –  MadHatter Jun 28 '14 at 8:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.