On Sun, 2011-08-21 at 05:46 -0700, Craig White wrote:
I'm going to present another view of what I think is a larger picture.
What you seem to want to do is to block host access (TCP possibly UDP) based upon certain GET/POST activities on your web server.
Yes, in this instance the annoying attacks of 200 attempts to break-in via phpmyadmin for example or the stupid pratts suffixing a correct web page name with things like ...login and ... forgotten_password ... and execute and ...sql... etc. I don't want that crap.
Thus you are attempting to create a curtain based upon things that have already failed and eventually you will get a huge IPTABLES filter that will slow up all traffic while parsing the rules.
Yes create a curtain but wrong about 'huge'. Attempts are done via compromised IP addresses around the world by the same person or a group of like-minded people. It is my intention to delete the contents of the temporary iptables table often to prevent it becoming a liability.
I could probably achieve this by having two temporary tables (for blocked IP addresses) and after a week or two delete the contents of one table and than at another interval delete the contents of the second table. This would provide a useful overlap and ensure an IP blocked today is not 'freed' tomorrow when a temporary table's contents are deleted.
Persistent offenders would have their IP address or their IP block, if a data centre, permanently stored in another table (3web).
I would suspect that this would also be the same system that is also the web server - thus you will slow down the very system you want to be fast. The entire predicate is reactive. You would also need to have a system to expire those rules after a period of time.
I can do a cron at a regular interval to flush the first temporary table and a second cron job to flush the second temporary table. So not too much effort involved.
It's all a waste of energy focused on giving you satisfaction that you are at least doing something to block script kiddies.
It is a good programming and learning Linux exercise. I gain personally from doing it. The ultimate objective is a smooth running system although I am certain there will be other issues arising.
You should spend the time protecting the server with good system administration... SELinux, which you state 'you are not using at the moment' is a prime example.
Yes you are correct. May have a look at it in a week or two. In the past SELinux seems to stop things running which is not what I want.
You should ensure that known attack vectors (first place to look is the very common php programs like phpmyadmin) are either not in use or at least always kept up to date and secured via access controls.
PHPmyAdmin is definitely not available to the public. Absolutely not. That was one of my very first priorities. I do not follow the /var/www convention for locating public web pages. Every hosted web site is a virtual site and entrance through the front door (the server's IP addresses) is blocked and monitored.
The security issues you should be worrying about are not the things that are getting logged - that's just a record of things that already didn't work.
I have introduced additional logging on things that work as well as do not work.
It is the things I am unaware of that present a danger. That is why I try to block everything and specifically permit authorised things through the firewall. Obviously I am still learning and SELinux needs some experimentation after I discover exactly how it works and the logic behind it and the Linux 'labelling'.
Your /etc/sudoers is uppermost in my thoughts.
Thank you.