Dear All,
As a security measure I have install AIDE and made the crons send me reports. Do you guys feel that I should also install fail2Ban too? Or is there anything else I should add up to my AIDE to further harden my system?

No idea at all, whether you should add fail2ban without knowing a bit more about the threats that you are exposed to. Fail2ban (there are several comparable programs, but f2b is probably as good as any of them) is valuable when you think that there are external sources of threat that may be making repeated attempts to compromise your security by 'trying the door handles'. You may not be in that situation.

Dear Salasi,
Let me share a bit of my history on attach. Before this I was attack using a bot net they managed to compromise my system via the phpMyAdmin. So I have now rename it to something different and also using .htaccess. In addition I also have AIDE. But I still notice a lot of IP address trying random links on my webserver too.So what is your idea then? There might other threat which I am not aware either too.

I'd like to suggest a complete re-think of your security. Aide is a nice tool, but it doesn't appprevent attacks or cracks, it simply tells you what has changed if one happens (very nice to have after an attack, I wish more people in this forum had it running). Similarly for fail2ban, it does it's thing, but absent a full security approach, it won't help much by itself.

Anyway, you say that phpMyAdmin was the attack vector and that you renamed it to something else. I would suggest that at very least, that is unlikely to have done anything useful. If someone compromised your machine, you need to understand not only how they got in, but what else they may have done to give themselves a back-door into your system. So you either need to start in and do a full analysis of your existing machine to try and find out what happened (and then likely face a full re-install) or if you've been messing around in the machine, you might just do a full re-install after coming up with an overall security approach. Normally going straight to re-install is a bad idea, but if the machine in question has had a number of things done to it post crack, evidence of the crack may be gone.

So questions you should be asking yourself are:

1) Are all methods of access locked down except for those you've deliberately allowed?
2) Do you have a schedule for patching and upgrading ALL software on the system?
3) Since you're running PHP, is PHP locked down as tightly as possible?
4) Do you have a way to understand if an attack has occurred? (AIDE is a decent way to do this).
5) Do you have a response methodology you would follow if you find evidence of a breach? Changing the name of the phpMyAdmin files doesn't count.
mea
So salasi is right, without knowing a whole lot more about the overall situation, advice on fail2ban is pretty meaningless. Fail2ban really doesn't do much beyond keeping your log files less cluttered. It doesn't improve the security of the underlying systems, so if your web server is insecure, adding fail2ban isn't going to make it more secure.

1 members found this post helpful.

Dear Hangdong,
Ok let me explain what I done for one.
1.Are all methods of access locked down except for those you've deliberately allowed?
I trying to use the key method to login rather then the normal password. Secondly planning to build up VPN and only go through. So what else I am lacking here?

2.Do you have a schedule for patching and upgrading ALL software on the system?
I try to run yum update on a weekly basis

3.Since you're running PHP, is PHP locked down as tightly as possible? Currently I am locking it using .htacces method.

Please go give me your feedback where I am lacking and need to improvise. I am running apache webserver too. For that I have disbable indexing too.

Those sound reasonable, but I'm worried about your use of the future tense here. It sounds like you haven't implemented them yet, and if you do, implementing them on a compromised system doesn't get you anywhere. Have you cleaned up from the previous intrusion, and if so, how? Also, I was speaking very broadly in my "method of access". I don't just mean logging into the system, I mean all internet facing services like SSH, web server, FTP, etc. Anything facing the internet is vulnerable, and unless you know what they are and have them locked down, they are a threat.

Again, seems reasonable, but you probably need to add some sort of lookout for security patches that might need to be installed more quickly.

That really doesn't address some of the problems that can occur with PHP. Here are a couple of decent (if somewhat dated) articles to get you going:

http://aymanh.com/checklist-for-secu...-configuration
http://www.sk89q.com/2009/08/definit...ity-checklist/

Dear Hangdong,
Yes this is a new clean machine. Freshly install with centos 6.2. I was looking through your first article. I get most of it except for this. How this works where to put this in the httpd.conf file is it?

My apologies, I had completely missed this thread where your crack was diagnosed.

As for the filesmatch location here is the documentation and essentially it can go anywhere in httpd.conf. I keep mine near the <Directory> section since they do similar things. By the way, I'm not sure that example is right. Whenever i use filesmatch, I use a regular expression to limit what it is filtering. for example, I this is the default example that is usually in httpd.conf:

[CODE]
<FilesMatch "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</FilesMatch>
[\CODE]

This prevents any file starting with .ht from being viewed. In the example in the article the example should have been something like "\.php~".

Sorry, I have been away from this thread a bit, and it looks to have moved on; please be aware that some of my comments may have passed their 'sell by date'.

Firstly, you have to remember that your first post in this thread gave absolutely zero details about the situation that this box finds itself in (was it a workstation? a server? was it a box exposed directly to the internet?), and so it was impossible to give much advice about what was appropriate for that situation.

OK, given that your box is exposed to the internet, fail2ban isn't a bad idea at all, but the question is whether this is the only thing that you should do and what it will do with the attacks that you are actually seeing.

Have you been through any formal hardening procedure for this box?

So, how I interpret this is:

• by 'random links', you mean that they are trying to access URLs that do not exist; these are not 'links' in the 'the box has a number of links that point to nothing' sense; that, of course, should never be the case, but it does sometimes happen with complex CMSs, or with manual website creation, when the housekeeping hasn't been done adequately (ok, it can also happen if the site has been re-organised and search engines haven't kept up to date - I take it, if this was the case, you'd have known all about it, and made some comment)
• assuming that your website isn't doing anything to cause this, if a lot of IP addresses are probing 'random' addresses on your site, that is a cause for concern. One or two is probably normal, particularly the odd probe that tries a small number of URLs and then goes away. More than that, and you seem to have been seen as an easy target, or something else, like 'dangling links' is wrong.
• If these accesses are really coming from a wide range of addresses, something like fail2ban will do little to help; it'll ban the ones that have been active recently, but they aren't, primarily, the new ones that are about to try accesses next. That's not say that it is bad, it just might not help as much as you would like.

When you look at what these probes are trying, do they look like cross-site scripting attacks?

I don't know phpMyAdmin well (played with it once, don't know anything else), but one of the disadvantages with these 'easy admin' widgets is that they are susceptible to security issues; it is absolutely vital to keep up with security issues on whatever admin widget(s) you use.

It should be easy enough, on any Linux distro, to keep apps up to date (although the details will vary, distro to distro), you just have to make the time to keep on top of it. (In your present situation, this is probably unnecessary emphasis, but, for anyone else who comes across this thread later, you have to make the time to keep on top of it, and whatever that entails (testing changes, etc).)

That's always a problem; there might be threats that you don't know anything about, until it is rather later than you would like. I'm not sure that there is any good advice, other than 'follow the best practice guides' (look at the security stickies in the very site).

It would be nice to be able to tell you 'just do x, and you'll be fine for all time'; this isn't possible, and its why security is a process and not an act.

Dear Handong,
Ok let me explain what I understand. I mean deny this access files with .ht from any where right? Then what is satisfy all? So if I put \.php~ like then how will my user be able to access my files? IS it that they cant view the source but can execute the files?

So when you say you keep near directory is this place. U mean just below this configuration is it?

Dear Salasi,
No I have not been any been through any formal hardening procedure for this box? Any tips or good links for me to do a checklist on hardening it? The random test is trying to access trying to access URLs that do not exist. What do you mean by cross-site scripting attacks? So based on you experience what is your best advice for me to move on further hardening my server.

The "Satisfy All" directive means that all of the directives in that section must be met. As opposed to the Satisfy Any directive that means at least one of the directives must be met. It is logical AND vs OR.
That will do.

Let's not lose the forest for the trees here, that was meant as an example. Most of what I wanted you to look at was the php.ini configuration. The filesmatch stuff can be useful for further locking down files, but you need to think through what you do, and do not, want to allow access to. In particular you might think through some of the permissions in the directories that your webserver has access to. Here is a couple examples of what I'm talking about:

http://www.devshed.com/c/a/Apache/Se...ons-in-Apache/
http://www.linuxhomenetworking.com/w...ons_And_Apache

I guess what I'm saying is that security is a process, not a bunch of rules and configurations that you slap into place without thinking them through.

This is something that everyone running a web server has to live with. Essentially they are looking for known exploits on poorly configured servers.

Dear Hangdong,
Those 2 links looks very informative give me sometime to digest them first before I get back here. Thank you so much.

Hardening scripts:
I have used Bastille before now, but it doesn't seem to get much development these days; Gnu Tiger has also been recommended around here, so I think I'd look at that next time. In fact, there is a thread here about hardening a server, and while this is quite a long thread, it is also quite thorough (not all will be applicable to you, but its a good read, honest).

Cross site scripting? Or maybe here.

You mention that you are running Apache; there is an Apache hardening guide around (eg, here), too, although the details probably vary slightly by version, so it is probably best if you search for the most appropriate one (or, maybe the pdf here - sorry about the idiot URL -dogpile not being very co-operative, and its a bit old).

I haven't read the links provided, but I do know that best practice is not to use .htaccess file if at all possible; instead put those directives in the main cfg file eg https://wiki.apache.org/httpd/Htaccess