Quote:
Originally Posted by pkearney
Hi Fidget,
have a look at this thread, eUKhosts are having a little competition with a laptop as a prize...
New Toshiba Laptop Contest
My memory usage has been creeping up since the reboot (current around 75%). I now have CSF installed (funny to see all the people trying to logon with dodgy usernames  ).
What is the best way to configure it so it can kill large memory tasks, similar to the way you have it?
I haven't upgraded cpanel yet, as I want to leave a little time between changes on the server to iron out any problems introduced (for example had trouble FTPing after installing CSF and support hsd to open the Passive FTP ports to get it working again).
Thanks again
Paul |
Hi Paul
I suspected that memory usage would creep up. Its not unusual.
Getting CSF installed and functional is the next big step. Configuring passive FTP is a must and it seems that you and support have done that (its not as simple as just setting ports in CSF, you also need to setup your ftp conf file to use the passive port range - anyway, all done).
I am assuming that you have CSF running and haven't run into any problems where you have been blocked from your own machine. If you do get blocked, and CSF is not running in testing mode, you'll have to change IP address to get back in (depends how you connect to the net on how you would renew your IP address, broadband users generally speaking and disconnect and reconnect to get a new IP address, although some providers such as BT keep yoru IP address assigned to you for a few hours which can be a right pain). Anyway, if you do get blocked, set CSF to testing mode and set the testing interval to 10 or 15 minutes, that will allow you back in after that interval has passed, you'll have to restart CSF though. Its only when you are completely happy and wont get inadvertently blocked that you can confidently remove the testing mode in CSF.
In terms of monitoring and preventing excessive resource usage, this is going to get more detailed and perhaps take quite a bit of explanation. Time is the enemy here, but we'll try this bit by bit...
First scroll down to the
LF_DAEMON setting, and make sure it is set to
1, this turns on the Login Failure Daemon which you appear to have already done.
You mentioned log in failures, so let's ensure that we block those who unsuccessfully try to log in as they could eaily be of ill intent ...
LF_TRIGGER - I have this set to
5 as I will use that number of failures on all log in attempts to any service monitored by CSF. I have found it to be a reasonable setting and have only seen two false positives so far this year. Both times the user was very apolagetic and understanding of the need to block failed log in attempts.
LF_TRIGGER_PERM - I have this set to
1, this permanently blocks the IP address fromw here the failed logins originated. This gives me the option of manually removing the block (from the Firewall Deny IPs list accessible from the main CSF page).
LF_SELECT - I have this set to
0 so anyone who gets blocked for a failed log in to any monitored service wont get into the server full stop, until I unblock them that is.
The following settings are all set to 1 as I want to make sure that all log in failures are blocked. This may worry some of you, but I personally think its a perfectly reasonable setting to use. As I said I run a very busy
VPS Hosting here and genuine log in failures really are pretty rare. So I have these
all set to 1 ...
LF_SSHD
LF_SSHD_PERM
LF_FTPD
LF_FTPD_PERM
LF_SMTPAUTH
LF_SMTPAUTH_PERM
LF_POP3D
LF_POP3D_PERM
LF_IMAPD
LF_IMAPD_PERM
LF_HTACCESS
LF_HTACCESS_PERM
LF_MODSEC
LF_MODSEC_PERM
LF_CPANEL
LF_CPANEL_PERM
Now let's get to script, user process and resource tracking and what we are going to do with them. Scroll down to
LF_SCRIPT_ALERT, I have this set to
1 because I want to know if any users are sending large amounts of email via any of their scripts.
LF_SCRIPT_LIMIT sets the amount of emails that can be sent by a users' script before LFD sends a warning email to me. You can make your own choice here, but given that you are a bit short on resources, let's set it to
50 (that's the amount per hour that will result in a warning email to you, nothing blocked yet though).
The next setting
LF_SCRIPT_PERM will stop the script from sending any more emails if the limit set in
LF_SCRIPT_LIMIT is reached. I have this set to 0 as I don't have any abusers at present and I don't want to completely upset those who do use scripts to send emails. If you find that you have someone who is being unreasonable then you can set this to automatically prevent their script from running until you manually allow it to again.
Now let's scroll down to
LF_INTERVAL, this is the period in time which LFD checks for log in failures (seems like we are back tracking a bit but I am trying to follow the order in which the settings are in CSF's configuration). I have this set to
300 (seconds, which is 5 minutes).
Next
LF_EMAIL_ALERT and
LT_EMAIL_ALERT, I have these both set to
1 so that I am informed of the log in failures, those emails will also tell me if the IP address(es) concerned are blocked (which they will be from my settings above).
Next we move to email logins, we don't want anyone consuming resources by checking email too frequently (I've had a case of someone checking their email accounts every second and gave the appropriate advice).
LT_POP3D and
LT_IMAPD are both set to 60, as I said I have only had one case where this was triggered so I have found this to be a very reasonable setting.
RT_RELAY_ALERT,
RT_AUTHRELAY_ALERT,
RT_POPRELAY_ALERT,
RT_LOCALRELAY_ALERT - I have all these set to
1 as I want to track mail relaying. My mail server is not an open relay, but I want to have an element of control over local relaying (by users) and the facility to block their relaying if it hits a certain limit. So,
RT_RELAY_LIMIT,
RT_AUTHRELAY_LIMIT,
RT_POPRELAY_LIMIT,
RT_LOCALRELAY_LIMIT are all set to
50 at the moment, so anything more than 50 emails being relayed by a user within an hour will result in a block. The next settings are for the block interval as I don't want to permanently block relaying for any user as yet -
RT_RELAY_BLOCK,
RT_AUTHRELAY_BLOCK,
RT_POPRELAY_BLOCK,
RT_LOCALRELAY_BLOCK are all set to 3600 (this is the time in seconds for which the user will be blcoked from relaying any more email). A word on the above settings, I have used these for some time, some of my users' scripts have often been blocked temporarily because they have exceeeded the limits I set, but this really does cut down on resource usage. I've seen big increases in resource usage when a script has placed a lot of emails (around 100) in the mail queue. I haven't had any complaints about this, and if I did I would explain the need to ensure fair usage of resources by any script.
The next block of settings are important and will prevent access from known bad sources ...
LF_DSHIELD and
LF_SPAMHAUS are both in use by me, and both have a setting of
86400 seconds (once per day) which means that the lists are updated daily (any interval less than that is not necessary as the lists are only updated daily anyway). Then the
LF_DSHIELD_URL should show
http://feeds.dshield.org/block.txt and
LF_SPAMHAUS_URL should show
http://www.spamhaus.org/drop/drop.lasso - these are simply the addresses from which the known bad IPs are read.
I don't use CSF to monitor connection tracking as it is a bit resource intensive compared to other methods which I use in place of this (we'll talk about those later if you want), so
CT_LIMIT is set to
0.
I definitely use process tracking, so
PT_LIMIT and
PT_INTERVAL are set to
60 and
PT_SKIP_HTTP is set to
1 to reduce any false positives. These settings wont stop anything as yet, but they will let you know of any suspicious processes that warrant a closer look. You can then look into them and make your own decisions later.
User process tracking (this is what we talked about previously) is defintiely a must, so
PT_USERPROC is set to
1 so that we have the opportunity to track and block any user process that uses an unreasonable amount of resources. With my settings I see perhaps 3 or 4 blockages per day on one user who I know to be running a secure script, but this prevents my resources being eaten up while their script runs. So, I have
PT_USERMEM set to
100 (the value set is in mb) which is okay for me on a
VPS Hosting-03, I'd recommend that initially set this to 50 and if you see a lot of blocks, then consider whether you should allow more resource usage.
PT_USERTIME is set to
180 (seonds) which is the interval after which an email would be sent (and the next option would block or not after that interval). This setting is okay for me, but you may want to initially set this a bit lower, to say
120.
PT_USERKILL is set to
1 as I want to preserve my resources and stop any excessive usage, this kills the process.
)
Linear Mode
