# Maximum connection time



## ronaldlees (Mar 23, 2016)

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?


----------



## SirDice (Mar 23, 2016)

What exactly do you mean by "limit maximum internet connection time"?


----------



## ronaldlees (Mar 23, 2016)

SirDice said:


> What exactly do you mean by "limit maximum internet connection time"?



Just a hard limit on how long any connection can last.


----------



## SirDice (Mar 23, 2016)

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


----------



## ronaldlees (Mar 23, 2016)

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



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


----------



## ronaldlees (Mar 23, 2016)

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.



Like a FreeBSD router?


----------



## SirDice (Mar 23, 2016)

Well, you could simply set the interface down. That will surely kill off any and all connections.


----------



## ronaldlees (Mar 23, 2016)

SirDice said:


> Well, you could simply set the interface down. That will surely kill off any and all connections.



How would I tie it to connection start time?  Anyway, really don't want to disconnect other users ... maybe something not so drastic?


----------



## zirias@ (Mar 23, 2016)

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:

What exactly _is_ a connection here? Only TCP? What about applications using UDP (like e.g. `openvpn`), do they get unlimited time?
What about idle connections? Do you need to notify the endpoints about the closed connection? This may be crucial for _some_ kinds of applications.
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?


----------



## ronaldlees (Mar 23, 2016)

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:
> 
> What exactly _is_ a connection here? Only TCP? What about applications using UDP (like e.g. `openvpn`), do they get unlimited time?
> What about idle connections? Do you need to notify the endpoints about the closed connection? This may be crucial for _some_ kinds of applications.
> 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?



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.


----------



## SirDice (Mar 23, 2016)

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.


----------



## ronaldlees (Mar 23, 2016)

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.



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.


----------



## ronaldlees (Mar 23, 2016)

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



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.


----------



## SirDice (Mar 24, 2016)

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.


----------



## ronaldlees (Mar 24, 2016)

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.



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!


----------

