Maximum connection time

ronaldlees

ronaldlees

What is the best way to limit maximum internet connection time on FreeBSD?

I know there are server/app specific ways to do this, but I mean to do it across the board, in/out, but not tied to any application, server or otherwise?
 
What exactly do you mean by "limit maximum internet connection time"?
 
Idle connections? Or do you actually want to kill active connections after a set amount of time? The latter is going to be tricky, and I'm quite sure your users won't appreciate downloads being killed when they're at 80%.
 
SirDice said:
Idle connections? Or do you actually want to kill active connections after a set amount of time? The latter is going to be tricky, and I'm quite sure your users won't appreciate downloads being killed when they're at 80%.
Click to expand...

Yes, I mean the latter interpretation (it doesn't matter if they're active). Due to circumstances, the users won't normally have a cutoff problem...
 
getopt said:
Some routers have a feature that cuts Internet connection after a defined idle time. An appropriate naming would be minimum connection time.
Then there might be a need to cut connections i.e. avoiding higher connection fees, when a given download budget is consumed.
Click to expand...

Like a FreeBSD router?
 
Well, you could simply set the interface down. That will surely kill off any and all connections.
 
SirDice said:
Well, you could simply set the interface down. That will surely kill off any and all connections.
Click to expand...

How would I tie it to connection start time? Anyway, really don't want to disconnect other users ... maybe something not so drastic?
 
Care to explain the goal you would like to achieve by that? I somehow suspect an xy-problem here, but nevertheless, think about some implication first:
  1. What exactly is a connection here? Only TCP? What about applications using UDP (like e.g. openvpn), do they get unlimited time?
  2. What about idle connections? Do you need to notify the endpoints about the closed connection? This may be crucial for some kinds of applications.
  3. If the motivation to do this is some kind of abuse, what would you do about some really unexpected tunneling like, e.g. through DNS lookups?
 
Zirias said:
Care to explain the goal you would like to achieve by that? I somehow suspect an xy-problem here, but nevertheless, think about some implication first:
  1. What exactly is a connection here? Only TCP? What about applications using UDP (like e.g. openvpn), do they get unlimited time?
  2. What about idle connections? Do you need to notify the endpoints about the closed connection? This may be crucial for some kinds of applications.
  3. If the motivation to do this is some kind of abuse, what would you do about some really unexpected tunneling like, e.g. through DNS lookups?
Click to expand...

I view any kind of resource protection scheme as an onion. So, security and abuse matters would be included in that. There are many ways to do resource protection / exploit protection / DDOS protection and so forth. I'm just adding another layer to the onion. There's really no reason for a connection to my server to run into hours, for instance. So, I wouldn't allow such a thing. It would be very convenient if this protection were non-specific to any particular application (outside of things associated with the system pretty directly). Then it'd be an easy onion layer to add, and unlikely to cause trouble. Maybe there's not a very good way to do it. I looked at the various throttling mechanisms, but they seemed not to cover it.

Yes - it'd be for all types of traffic.
 
Zirias has some good points, especially when it comes to UDP and ICMP. Both are connection-less protocols. It's going to be extremely difficult to differentiate between, for example, two UDP packets sent 10 seconds apart but are actually the same "connection" or two UDP packets sent 10 seconds apart but are different "connections". Even if both situations have the same source and destination IP and ports.
 
SirDice said:
Zirias has some good points, especially when it comes to UDP and ICMP. Both are connection-less protocols. It's going to be extremely difficult to differentiate between, for example, two UDP packets sent 10 seconds apart but are actually the same "connection" or two UDP packets sent 10 seconds apart but are different "connections". Even if both situations have the same source and destination IP and ports.
Click to expand...

My goal would still apply generally to UDP and to everything else, as well. I agree, it'd be difficult to implement with UDP (probably that's why it's a favored protocol for mischief). But, I'd settle for TCP at the moment. Most of the intentional server stuff would be TCP.
 
What are my choices for deep packet inspection on FreeBSD?

OPNSense, relayd?

This is a little bit of a fishing expedition, I have to admit. But, I've been bugged for a long time about certain things that have been traditionally "difficult" to deal with, and beg me to activate my willful ignorance mode ...
... good points, especially when it comes to UDP and ICMP. Both are connection-less protocols. It's going to be extremely difficult to differentiate between ...
Click to expand...

Of course UDP has been defined as "connection-less" in terms of the network stack not handling the connection details (other than eth+src/port/dest/port). But, the application handles the other connection details, in anything other than a singleton app, so there is a "connection" according to the application. Botnets are often handled with UDP "connections" - and I can imagine a scenario where a low bandwidth UDP trojan copied the contents of my hard drive over a period of days, weeks, or months, over its "application connection" ...

Anyway, not trying to be confrontational, just thinking about things that in the past I may have "willfully ignored."

It looks like OPNSense has some knobs to turn in order to monitor connection time and application (deep packet) info. I'm completely unfamiliar with it. My arbitrary maximum "connection" time was only an example of the kinds of knobs I'd like to have on my panel.
 
It looks like you're really looking for an IDS/IPS solution. In that case you may want to check out security/snort. It has been the de facto standard IDS solution for years. Personally I'm not a big fan of IPS, IDS yes, but not IPS. The reason is that it's easy to get false positives, which means you're killing valid connections, or false negatives, i.e. your not detecting the bad stuff and you get a false sense of security.
 
SirDice said:
It looks like you're really looking for an IDS/IPS solution. In that case you may want to check out security/snort. It has been the de facto standard IDS solution for years. Personally I'm not a big fan of IPS, IDS yes, but not IPS. The reason is that it's easy to get false positives, which means you're killing valid connections, or false negatives, i.e. your not detecting the bad stuff and you get a false sense of security.
Click to expand...

I always thought about security/snort as an IDS. I didn't even know it could also be IPS by using its inline mode. Looking at an article on inline mode, it seems not to have all the knobs I might want on my panel, but does have some of them. Thanks!
 
You must log in or register to reply here.
Back
Top