PHP Developers Network

I don't think so. It'll probably only log bad keys, but with password authentication disabled most scripts won't bother continuing with trying to connect.


It's lightweight. Might as well keep it around. And there are other things it can watch too.

Thanks requinix. I was thinking about if after I asked the question. I turned it off and will leave it off over night to see if any "Failed password" messages come through. If not I guess that 100% answers the first question. Then in the morning I will empty the IP storage file I created called "IP.Blacklist" and turn fail2ban back on to see if it loads it up with any ip addresses. If any go in this (or if they show in the iptables) then it is doing something. If this happens I will search for the IP addresses in the secure file and see what those messages are. Actually I guess it will get the wrong user ID messages (I saw about 3 of those over about an hour). I will see if there are the only ones. Right now I am starting Putty with a script and the script asks me if my IP address has changed. I did this because I was running fail2ban with an infinite ban time (negative number). This removes any chance of getting locked out due to my IP address changing at the same time the script messes up (which it is not going to do very often if ever). So I guess I will do what you say, leave it and learn and report back what I find. In the mean time I will chug away at the rest of my list but probably with a little less concern now.

I have the results of turning off fail2ban while key authentication is in effect and SSH port is still set to 22. It flushed the iP tables to remove all the fail2ban IP addresses and these messages are coming in now even though I have the key authentication set.
Not just one message but thousands of them over and over for the same IP address (not good) as opposed to when fail2ban is running and I get maybe 1 every 3 hours. Celauran said changing the SSH port will reduce the log size. So I will turn fail2ban on again (with it loading the IP addresses from the IP.Blacklist file) to cut down on the logging then once I get the port 22 changed to a high unusual number I will try turning off fail2ban again to see what happens. I will report back the results.

Port 22 is the default SSH port and root always exists, so that combo is going to get hammered forever. With root logins disallowed and password authentication disabled, they won't get it but it's still a lot of noise in your logs making find real incidents more tedious.

_________________
Supported PHP versions No longer supported versions

Thanks Celauran. I am learning there is lots to know about security and it may never end as software improves. Your comment "makes finding real incidents more tedious" makes me think of my security list I am slowly poking away at. My list is a prioritized based upon a 1 man shop with no one else having access to my computers. Next week I will be spending 4 hours a day working on the pending stuff. After that 2 hours a day as I start to market the website. The extract below is part of a spread sheet that allows me to find the source of the item fairly quickly for when I finally get a chance to work on it. It may be of interest to other beginners like myself. There are probably some duplicate entries.

Finished:
Restrict File and Directory Access
Secure SSH - Disable Protocol 1 and use only Protocol 2
use secure Sftp rather than ftp (WinSCP says it is using SFTP at the top)
do not give users shell accounts on your system
Use Firewall To Restrict Outgoing Connections (not needed).
make sure you log all PHP errors to a log file
PHP A Note About Setting Up Correct File Permissions
Disable FTP login
Restrict loging attempts (
put no.login at the end of password entries (try FTP)
firewall block SSH from everything except your home computer
Secure SSH - Limit User Logins (not needed if only root + secure user)
run yum update often
strong bash root password
strong mysql root password
upload files (only allow image files)
disabled unused services. Check using htop
firewall only allow ports 80, 22 (25 is for mail so it is blocked)
Fail2Ban to Prevent Password Attacks on SSH
Database input (sanitize all inputs) sql injection
Utilize strong (mixed case, alpha-numberic, long) passwords on accounts that are necessary.
Don't run a GUI if you don't need one and never leave a GUI running while the server isn't being used for an interactive console session.
Be wary of third-party content providers.
log all php errors
set maximum upload size
use chown and chmod to minmize access to a bare minimum
control PHP post size
Secure SSH - use strong passwords
Secure SSH - Disable root login
Hide apache version: ServerSignature Off
Hide apache version: ServerTokens Prod
Hide apache list if the index.php is missing
Secure SSH - Use Public/Private Key Authentication & disable passwords

Pending in the order I was planning on working on it:
Secure SSH - Use a Non-Standard Port - Determine ports used with 'netstat -tulpn'
Virtual box to improve the backup system I have.
Reviewing logs: /var/log/messages.log (create a script to speed this up)
Reviewing logs: /var/log/daemon.log (create a script to speed this up)
Reviewing logs: /var/log/auth.log (create a script to speed this up)
Check your shell´s command history (e.g. /root/.bash_history)
reduce PHP information leakage
Limit PHP Access To File System
check for large log files on a regular basis (find out why)
Install Suhosin Advanced Protection System for PHP
system errors go to root's email. Read them.
Free software to help: Dnssy - checks all your DNS settings
Free software to help: Logwatch - Analyses logs and sends a daily digest to the administrator
Enable Postfix Postscreen to prevent email spam without damaging performance or risking false positives
Disabling Dangerous PHP Functions
PHP User and Group ID
.htaccess (to prevent images going out to reduce bandwidth)
Apache - Limite size of uploads to your LeadSheets directory
Keep software up to date
hide apache version
minimize loadable PHP modules
turn off remote PHP code execution
Use TCP wrappers (tcpd) to run Internet-related daemons and properly configure the hosts.allow and hosts.deny files to restrict access.
Free software to help: Mxtoolbox - checks your mail server every 15 mins, alerts when down or blacklisted, can also "port scan" your firewall
PHP #24 Watch Your Logs & Auditing
Restrict email connections
Apache - Keeping apache up to date
Apache - disabling unused modules
Apache - run apache as a separate user and group (must change permissions for this in your script called SetWebPermissions)
Apache - restrict access to certain directories
Apache - Use mod_security and mod_evasive Modules to Secure Apache
Apache - Disable Apache’s following of Symbolic Links
Apache - log independently of your OS logging (more detail)
sea-surf attach
reduce PHP modules
disable allow_url_include
Enable SQL Safe Mode (this was used for the differential backups)
PHP resource control (maximum execution time)
Session Path - session.save_path
Keep PHP, Software, And OS Up to Date
PHP Use Linux Security Extensions (such as SELinux)
PHP Install Mod_security
Run Apache / PHP In a Chroot Jail If Possible
#25 Run Service Per System or VM Instance
#26 Additional Tools
A Note About PHP Backdoors
List users with this command 'cut -d: -f1 /etc/passwd'
Apache - turn off server side includes
Check last logged in users (e.g. Run lastlog
find files modified between x and y minutes ago
new entries in crontab
Try a Google site: search to see what's indexed.
use google webmaster tools
PHP Fastcgi / CGI - cgi.force_redirect Directive
Apache - Protect DDOS attacks and Hardening (only if attacked)
configure PHP to disable the eval statement
 Write Protect Apache, PHP, and, MySQL Configuration Files
read the google online security blog
By default, email reports of any system problems will be sent to user "root". You can read them by going to Webmin > System > Users and Groups > root and clicking the "Read Email" button. It's usually more convenient to forward them to an external email address. You can configure this by going to Webmin > Servers > Postfix Mail Server > Mail Aliases, selecting Create a new alias and setting Address to "root" and your email address in "Alias to", "Email address".
read this http://www.sans.org/reading-room/whitep ... files-2074
check for any XSS (cross-site scripting)
If you install a forum (new software) keep the software up to date
Secure SSH - Filter SSH at the Firewall
Apache - Enabling encrypted SSL connections
use your hosting company blog or forum or just email them
Log off of server consoles when they're not being used. This is especially important for Internet-connected systems.
Fail2Ban to Prevent Password Attacks on Apache (not just SSH)
Don't use common names for groups that are given high levels access (ex: "admins").
delete users that are not needed
encrypt sensitive data
If Installing web sites
If Adding email users
Reduce Apache logging of image files (does not seem to get logged)

Still going through the list, but that's a pretty risky proposition. What if your IP changes? What if you're out of town and something needs immediate attention? You're now locked out of your own machine. Disallowed root access and RSA key authentication should suffice here.

_________________
Supported PHP versions No longer supported versions

Webmin gives root access to your machine over HTTP. I cannot recommend that.

_________________
Supported PHP versions No longer supported versions

Thanks Celauran, Regarding "firewall block SSH from everything except your home computer" I never actually did that. I was working with fail2ban, thought of that idea then realized the IP could change then thought of a static IP address at $5.00 a month. I guess I left it in the list because I was considering the static IP address as a much simpler idea for a while. I was also concerned about the fact that the IP address blocks that fail2ban creates come up so slow when I enter the "iptables -L" command. I was also thinking fail2ban it might be slowing down the machine if it runs every second to read those logs. So this triggered that idea. Maybe it is good I left it in the list so anyone else who is new at this is made sensitive to the danger.

I guess now it is all about reducing the log size. From what you say it seems that changing the SSH port to a high number will help reduce the log sizes and eliminate the need for fail2ban. I have it in my list to roll the logs to keep them small in size and auto-purge them. In the past (15 years ago) I could very easily write a (bash/sed/awk) script from memory to filter out all the junk from the logs to speed up analyzing them. I knew all sed/awk commands from memory including all regular expressions. Unfortunately these days I can't do that and if this website takes off I won't have time to learn it again either.