|
more apache/php
|
2011-09-12, 12:30 PM
Yes to the former. I'd get mod_ssl working and have https:// sites showing up first. IDS are "outside" of Apache, and unless you have a "working apache" first it will be difficult for the IDS to detect attempted intrusions. Furthermore, if mod_ssl works yet breaks once you configure your IDS, you know it's your IDS at fault.
2011-09-13, 06:12 AM
Quote:Yes to the former. I got https:// sites working using this guide Will add it to my documentation: https://feedmebits.nl I did this last part too but didn't check if it worked without doing it. That should be safe to open up right cuz 443 is the ssl port you are opening up on the server?: iptables -A INPUT -p tcp --dport 443 -j ACCEPT /sbin/service iptables save iptables -L -v
2011-09-13, 08:47 AM
I took a look at mod_security. I'll think I'll try installing that first and see how it goes. And then maybe try installing a IDS. I tried installing suPHP a while ago and you have to install it from source and then configure it.. And when I did that I was not even able to reach my site again because it messed up my php. the whole website looked strange and I wasn't able to undo it. I'll just get mod_security working first and then decide from there.
2011-09-13, 10:58 AM
Quote:I tried installing suPHP a while ago and you have to install it from source and then configure it..It's in the RPMForge repos. I just added it to CentOS 6 with a quick "yum". Quote:And when I did that I was not even able to reach my site again because it messed up my php.No, it didn't. suPHP parses the PHP and runs it within a user context according to the config file, rather than runs it in Apache's context - it does nothing to "mess up" the php. What you WILL have found is that suPHP - by default - does not take kindly to relaxed permissions, which Apache tolerated. A common complaint about suPHP is that when first installed, all sites "break" - when it simply means that all the website content previously owned by "apache" or "httpd" now needs to be owned by "marten" and all files set to permissions 644. The suPHP config file also contains a directive for suPHP logging - the contents of this logfile often reveals why suPHP won't parse your website code. Generally it boils down to one of several things:
However, this comes at a price: the overhead of parsing your code is longer and more processor-intensive, so many people drop suPHP in favour of standard mod_php. If you are the only user of that box then it's not too much trouble to not bother using it. For my server, I have several users and each has an issue when they upload files and they're owned by "admin1:site1" so "www-user" can't write content into them. Using suPHP fixed that issue for me (and prevented an exploited site overspilling into another one)
2011-09-13, 11:43 AM
That makes it more understandable for me :)Will have a go at mod_security and mod_suphp then and then work on IDS and after I have that setup I'm going to work on a backup plan. Will post how installing/configuring of mod_security goes.
2011-09-14, 07:02 AM
I have mod_security installed now using this guide . I'll have to take a look at the documentation for a more customized configuration, although I did take a glance at it and seems a bit confusing. Will have more time for that later. But seems that the default configuration should be active :)
2011-09-14, 10:49 AM
The info is surprisingly simple, just that there's a lot of it. It helps to draw out a diagram of how the files relate and which you should be looking at. The rulesets are somewhat more complex, but in general you either download a new ruleset from a website or find that a workaround is published on the vendor's website when their web application (think phpwiki, xoops, phpBB, etc) breaks - which amounts to instructions on how to disable a specific ruleset (or add a file to bypass it). It's rare I've had to create a new rule... I think I just disabled/enabled the ones provided.
2011-09-14, 05:40 PM
Quote:The info is surprisingly simple, just that there's a lot of it. It helps to draw out a diagram of how the files relate and which you should be looking at. Well I'll just leave it at default then and if I have any problems check it out on google :) Ran into something strange again. I was trying to remove an application through yum, then I cancelled and when I ran it again it said it was still in use by another program yum. So I killed all the yum process and then I wasn't able to use yum anymore. So I'd thought I'd reboot my server and somehow port 22 wasn't reachable from outside but my hosting provider could ping it. So I do a reinstall cuz I couldn't do anything. Got mysql, php, en apache installed then I configured as I had and restarted apache. It said it failed because apache couldn't find my FQDN. I have servername set in my virtual domains, so that can't be it. I tried editing /etc/hosts and /etc/sysconfig/network, then restarting networking services. Didn't work, I then rebooted to see if my FQDN would change and it's changed name. set to webserver.feedmebits.nl. I tried to start apache, but this time I just get failed to start with no error message. I checked my /var/log/httpd/error.log. Nothing, interesting, just this No such file or directory: httpd: could not open error log file /var/log/httpd/websites/feedmebits.nl/error.log I'm kind of confused and have checked all apache settings and network settings. And strange thing is before I didn't have a FQDN either and apache would mention it but I was able to start apache. I'll keep trying/looking but about tried everything I came across on google.
2011-09-14, 07:27 PM
I figured out the problem. I made a very tiny typing error I over looked every time. and my FQDN is set now. strange thing is. I got all the permissions set right now and my template installed. But now I have like a pink bar going across my template which I didn't have before. Don't quite get that.
2011-09-14, 07:28 PM
Quote:The info is surprisingly simple, just that there's a lot of it. It helps to draw out a diagram of how the files relate and which you should be looking at.Did you check that /var/log/httpd/websites/feedmebits.nl/error.log is a valid path? |
|
« Next Oldest | Next Newest »
|
