• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Server hacked, but always was updated PLESK 7.5.3

In terms of performance, no not at all, it can handle way more than what we've added so far. The rules themselves are under very heavy development at the moment, so there are updates every day.
 
Wow .. never heard of this mod_security.

I looked into it .. and it's just what i need !

This should be standard in distro's like Fedora, CentOS etc ..

Even a Plesk Module for this would be thinkable !!
 
Is there a mod_security RPM maintainer somewhere around ? Like dag.wieers.com or freshrpms do for other packages ?
 
Also Fedora Core 2 compatible ?

Ok that's great .. i'll check out your site.

Never knew about your business history .. just checked out some of your sites. Impressive !

PS. Send me some vulnerabilities about the Whitehouse ;)
 
Yep, the white house was a great place to work. (Phone calls were the best... me: 'Hi this is scott, from the executive office of the president' them: 'President of what company?', me: 'THE president' them: 'of WHAT company', me 'Of the United States.... <pause>.... of America'. Fun stuff) Didn't pay very well at the time, but I'd go back.


On the RPM front, I currently make rpms for rh9, 3es (and clones, centos, whitebox, tao), fc1/2/3. I'll add 4ES and FC4 soon.
 
Haha .. great story.

About the RPM of mod_security .. where can i find it ? I cannot find it on your site ..

And i suppose they work on Apache 2 ?

Thanx !!
 
maybe a bit off topic, but, if I use the rules at gotroot.com, then "Site preview" won't work.. cause it give this error:

UNIQUE_ID: ty6V4VTq@yYAAEtsCtQAAAAG
Request: ip...... - - [27/May/2005:01:23:56 +0200] "GET /?previous_page=dom_ctrl HTTP/1.1" 500 515
Handler: (null)
----------------------------------------
GET /?previous_page=dom_ctrl HTTP/1.1
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Host: domain.com
mod_security-message: Access denied with code 500. Pattern match "^$" at HEADER
mod_security-action: 500

HTTP/1.1 500 Internal Server Error
Last-Modified: Tue, 14 Jan 2003 02:11:39 GMT
ETag: "30802c-203-580becc0"
Accept-Ranges: bytes
Content-Length: 515
Connection: close
Content-Type: text/html


Any ideas if there is a good fix for this?
 
You'll want to post this at gotroot.com, I'm not personally working on the mod_security rules right now (2 kernels, and glibc are enough thanks!).
 
Hey ART,

Do you recommend installing your ASL before Plesk, or can it safely be installed on and existing RH9/Plesk 7.5.x running server?

And are there any gotcha's to look out for?
 
You can install it either before or after PSA. When we run our tests, we've tested it out installed first, upgraded after, and upgraded alongside of PSA (assuming a yum environment, where yum update gets both ASL and PSA updates at the same time).
 
If it is of any help, I would say that ART's ASL channel (grsec kernel, mod_sec etc) is utterly fantastic. As Scott has said, the multi-level approach works very well. You have mod_security and dos_evasive as the first line of defense. Then, if something escapes the net, the modified grsec kernel and associated bits and bobs should catch it and keep you safe. I cannot recomend this solution highly enough.

The annual subscription fee for ALS is modest (thank heavens) and overall offers 100% value for money.

If you do not have the time or the skill to do it yourself, ASL is therefore a life-saver. I use it very succesfully with Plesk (you can install before or after - it doesn't matter. All that happens is that you get a different kernel and some added bits and bobs, and some additional modules for Apache get installed. It does not change your distribution or require you to re-install anything).

BUT BE WARNED: There is no such thing as "install and forget" security. It must be updated regularly. And whenever you update something, there is always the potential for a problem to crop up. A new mod_security rule or whatever may cause problems for a particular client or web page. You need to monitor things. It is also sensible to have a test system (such as a spare PC running Linux of best of all something like VMWare running Linux) to do test installs of updates etc, to see if you can identify any obvious problems before updating your live servers.

It is also very useful to have console access to your live servers in order to quickly be able to reboot to an older kernel or a non-grsec kernel should it be required.

Also be warned that if your server has any strange non-standard software running on it (for example my Dell 1650s have Dell's OpenManage software), the grsec kernel can cause problems. It depends on the software really. OpenManage, when combined with the Dell DRAC III card, does some strange things with LKMs and hardware and grsec doens't seem to like it much. So I normally run with OpenManage not running and boot from the grsec kernel. And if I need to do some remote diagnostics or whatever, I just boot with the non-grsec kernel and enable the diagnostics. Reading through the grsec forums and mailing lists, this type of issue does not seem to be common though, so you probably won't need to worry about it.

Faris.
 
I just installed mod_security... it's a very nice module, thanks for the tip!
 
Yes... only the mod_security so far. I installed it on RHEL3 update 5. I'm very interested in ASL, but since I'm not a Linux guru and I don't want to break RHN and PLESK support I don't dare to take it. All the websites on the server are under my control and I do an internal and external security scan every day. All server packages are constantly kept up2date. The firewall (iptables) is very tight.
I check all the used scripts (mainly php) for vulnerabilities. What more can(should) I do?
Only thing that ever happened was a DoS attack, how can I prevent that?
 
Back
Top