Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'd like to set TCP conns to a small limit. This is not included as a flag in the tool. Would it be sensible to lower the ulimit to (eg 200) or maybe limit the ulimit by process?
System limits (including some that are per user or per process) are done with sysctl.
If you run "sysctl -a" on your system you can see the various parameters and values (default or set).
Any "set" value you can see in /etc/sysctl.conf. You can override defaults by setting the parameter temporarily OR by adding to sysctl.conf and running sysctl -p to reread it to make them take effect. Anything you add to sysctl.conf would get set again after a reboot. Look for the tcp and network parameters to see if any approximate what you're trying to do.
A server has to accept a socket-connection request. I don't recall that "ulimit" has anything to do with that. If you want to limit the number of connections, your server has to briefly stop (or delay) accepting them.
I'd like to set TCP conns to a small limit. This is not included as a flag in the tool. Would it be sensible to lower the ulimit to (eg 200) or maybe limit the ulimit by process?
Many Thanks
Aidy
I have to ask...what problem are you trying to solve?
For example: I get thousands (5K-7K) of smtpd connection attempts daily, but I only accept about 10% of them. The rest are rejected by RBLs and my own block list. The blocking is virtually immediate and doesn't seem to put any strain on the server. There is not, AFAIK, any limit on the number of connections. What connections do you want to limit and why?
For example: I get thousands (5K-7K) of smtpd connection attempts daily, but I only accept about 10% of them.
... and you could stop them cold if you used OpenVPN (with digital certificates) as a bastion to all other services, then issue unique certificates to all authorized users of your service.
You will now receive connection attempts only from possessors of valid, non-revoked certificates, and you will know every single one of them by name.
Presto ... the number of unauthorized access attempts drops to zero. And, if you use tls-auth, your server no longer bothers to begin the authorization handshake sequence unless the supplicant first demonstrates that it is in possession of another digital certificate. This alone could save an enormous amount of now-wasted system resources.
Furthermore: your server will disappear from "port scanning" (which is actually "TCP/IP socket scanning") because OpenVPN uses the UDP protocol, which has no "ports" to scan. Unless one possesses the aforementioned initial certificate, the server will not answer and thus cannot be detected at all. The only doorway into your system is now an impenetrable secret door.
Last edited by sundialsvcs; 06-26-2017 at 09:00 AM.
... and you could stop them cold if you used OpenVPN (with digital certificates) as a bastion to all other services, then issue unique certificates to all authorized users of your service.
You will now receive connection attempts only from possessors of valid, non-revoked certificates, and you will know every single one of them by name.
Presto ... the number of unauthorized access attempts drops to zero. And, if you use tls-auth, your server no longer bothers to begin the authorization handshake sequence unless the supplicant first demonstrates that it is in possession of another digital certificate. This alone could save an enormous amount of now-wasted system resources.
Furthermore: your server will disappear from "port scanning" (which is actually "TCP/IP socket scanning") because OpenVPN uses the UDP protocol, which has no "ports" to scan. Unless one possesses the aforementioned initial certificate, the server will not answer and thus cannot be detected at all. The only doorway into your system is now an impenetrable secret door.
I appreciate what you're saying, but I was talking about the smtpd server listening on port 25. The server that receives email for me and my customers. Pretty much has to be available to anyone who wants to try to send email to us...but if the sender is listed in an RBL or has spammed us in the past, they aren't allowed to connect.
Even switching to VPN for the sending smtp connections would be problematic: Would have to issue certificates and change email client configurations for hundreds of email users at dozens of companies.
Part of my blocking process involves fail2ban additions for failed attempts to login on port 587, tho.
One correction to my earlier post, my smtpd server is currently limited to 20 simultaneous remote connections, by the server software [which is qmail]. I've never seen it reach that limit.
...repeating my question to the OP, What problem are you trying to solve by limiting connections?
And, will sundialsvcs's proposal do what you want to do?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.