Critch on ModSecurity…
Matt Critcher, our server admin, posted this on his blog the other day about ModSecurity and I thought that it was worthwhile to repost. We implemented ModSecurity a while back and hardened all of our servers to help guard us against a lot of the threats that are out there today. Looking back it was probably one of the smartest things we ever did. Over the years I have worked with a lot of server administrators, but I have never worked with one that has as good a grasp of ModSecurity as Matt.
From a Developers perspective ModSecurity can be a little frustrating on the front end because it will by nature shutdown or cause some elements of your applications to “break” until you get ModSecurity configured correctly and all of these core functions added as includes, but trust me, once you get everything configured correctly it sure does help you sleep better at night knowing that some hacker in India isn’t setting up a rootkit on your server through a hole in one of your applications.
Like Matt says in his post, Security is an ongoing thing, and part of that ongoing process also has to include keeping all of your open source software patched and up to date. Here’s Matt’s post:
Since I’m back, I’ve got a few days worth of log files to dig through. A couple of years ago an old legacy PHP script Pleth was running wasn’t very secure, but was critical to the operations of a particular customer. It got hacked (well, they used it to upload a C99Shell) a couple of times before the vendor released an update. Scouring the internet for a solution, I learned of Mod Mod Security, an application firewall of sorts. It runs as a module in your Apache configuration and uses a set of user-configurable rules files to detect and prevent a number of attacks against a website. The rules list has a huge community backing, and people have written rules for about every vulnerability out there. Open Source is good no? Anyway, as I was digging through those files today it kinda shocked me to see just how much stuff mod_sec blocked. The internet is a dangerous place…..
Among the same lines, you can further protect your server by making a few small php.ini changes as well. Look for the line in yours that says
1: disable_functions = "........and make sure you add
1: shell_exec,escapeshellargto the list there. This will prevent PHP from operating as a shell, which you really don’t need anyway (well, you shouldn’t in my opinion). There’s about a million different things you can actually disable, but some of them are needed.
Another PHP trick is open_basedir, which is a php configuration directive that sorta "jails" the scripts to whatever directories are listed in the open_basedir directive for that particular domain.
From the manual page:
When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it’s not possible to avoid this restriction with a symlink.
It’s not the most friendly option on the planet, but it does work and takes a bit of careful configuration to get it working right. For a site that might be considered risky, it’s worth the effort.
Just don’t be fooled into thinking that these fixes are the end-all-do-all. Security is a never-ending process. PHP is just one aspect of it.
Mod Security is good for you! | www.mcritch.com
Central Arkansas Refresh Meetup
In case you missed David Kincade’s post on The Arkansas Project this morning, we are going to have our first Central Arkansas Refresh Group Meetup this next Tuesday, February 24, 2009 at Starbucks (9401 Rodney Parham Road, Little Rock, AR) this next week.
We plan on hooking up around 6:00 or so and kind of setting the stage for this unique group. If you are interested in the meetup, here’s a link to our Facebook Event Page:
A couple weeks back I posted about this little group of Central Arkansas technology enthusiast types that Cotton Rohrscheib, area web guru/tech wizard/blogger/NASCAR fan, is looking to launch for networking and education purposes. Remember that?
Well, good news: We’ve set the inaugural meet-up for Tuesday, Feb. 24 at 6 p.m. in Little Rock, at the Starbucks on 9401 N. Rodney Parham Road. (A location somewhat arbitrarily arrived at because several of the interested parties may be coming from Conway and it has reasonably ready access to I-430. We may find another venue for future gatherings, once we have a better sense of who’s attending.)
This inaugural meeting will help us to develop a fuller organizational sense of who’s actually interested, what kind of topics we want to explore, how frequently we want to meet — mostly a ‘get to know you and swap ideas’ session to determine how we can make this a constructive venture for all involved.
You don’t necessarily have to be a hands-on tech wizard programmer type to join up — maybe you’re a blogger or an avid social media user or a chronic Internet porn consumer or just an all-purpose nerd with an abiding interest in the Web and technology issues. That’s fine; the more the merrier. Though probably the fewer the chronic Internet porn consumers, the better. I mean, a couple would be OK, but let’s not go overboard.
Go to our Facebook group page to get involved (or if you’re a hold-out who refuses to get on Facebook, just show up Tuesday).
Facebook | Central Arkansas Refresh Community
Just another update regarding the Central Arkansas Refresh Community, tonight Nick Brewer and I setup a group page on Facebook for those of you that might be interested in attending our meetups. To join the group click here. Once we get some members in the group we will primarily do most of our communication through Facebook regarding meetups, locations, discussion topics, guest speakers, etc.
Be sure to signup if you are interested. This should be an excellent opportunity for us to share ideas and stay on top of emerging technologies that are out there.
Facebook | Central Arkansas Refresh Community
Using ModRewrite
Let’s say you have just re-designed a website and during the process you were forced to change some filenames in the new site from what they were in the existing website. For example, about.htm is now called about.php in the new site structure. Normally you would be forced to endure having a dead link in Google until your new filename get’s crawled or updated from your sitemap.xml. This can sometimes take weeks if not longer.
A quick way around this is to use the ModReWrite Engine to “re-route” filenames to new filenames. This also comes in handy if you have a lot of external websites or clients that link back to specific pages in your website. To setup ModRewrite Engine, simply create or edit your .htaccess file to have the following sample code: (of course change this to match your filenames, etc.)
1: Options +FollowSymLinks
2: RewriteEngine On
3: RewriteRule ^index.html http://www.yourwebsite.com/index.php
4: RewriteRule ^directory_name/index.html http://www.yourwebsite.com/directory_name/index.php
Apache 301 Redirect
I could have sworn I had posted some basic Apache Functions and Mod Rewrite’s on here a long time ago but today when I actually drew a blank and couldn’t remember how to do a 301 they were nowhere to be found so I am going to create a new category on here for Apache and re-post a few that I use frequently so that I can refer back to them.
This is a simple 301 redirect. Let’s say you build a new website inside a new directory such as <cms> and you are now ready to go live w/ the website but you don’t want to lose your SEO benefit or be penalized for restructuring your site, you can use a 301 redirect to accomplish this. It’s very simple, see sample code below:
1: Redirect 301 /index.htm http://www.yourwebsite.com/directory/filename.htm
