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.
--
With best regards,
Paul.
England,
EU.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
