Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: servers

  • TimThumb and the Pseudo (D)DoS Effect

    TimThumb and the Pseudo (D)DoS Effect

    Over the course of a day, my server rebooted httpd twice. That’s not a common thing for me, as after days and hours of work, I managed to finegal my server into a semblance of stability so it could handle massive loads. At first I thought it was due to my traffic spike of an increase of about 1500% (no I did not screw up a decimal place there, my traffic went from a couple hundred to nearly 4000 in one day). Then I thought that couldn’t be right, because my traffic had actually mellowed out by the time I was crashing.

    So I went to my emails and pulled up the Apache Status log and noticed that 70% of the calls to my site were GETs to pages like this:

    /wp-content/themes/newsworld-1.0.0/thumb.php?src=/g0../0d1.
    /wp-content/themes/DeepFocus/tools/timthumb.php?src=/g0../0
    /wp-content/themes/TheProfessional/tools/timthumb.php?src=/

    Thumb Wrestling And thanks to that massive spike in traffic, my server was slowing down to the point that HTTP was becoming unresponsive and it had to reboot itself. In short, the TimThumb exploit was causing my server to behave like it was under a Denial of Service Attack, even though I don’t use TimThumb! My server was able to handle this, but if I’d been back on my old Shared Server, I’d probably have not gotten a text from the server at 11pm saying “Man, we had to reboot, but it’s okay now. Can I have a beer?”, but instead woken up to ‘Dude, where’s my website!?’ And this is with having a fantastic web host who cares and takes the time to help me out.

    Normally this is where I’d tell you what to do if you’ve been infected via the TimThumb exploit, but Cleaning Up the TimThumb Hack covered it pretty well. Just remember this, if you have been infected, you must reset all your passwords. This is true of any and all hacks. As soon as someone has access to meddle with files on your server, you could be hurt worse than you know. At the very least, you need to read the post “Technical details and scripts of the WordPress Timthumb.php hack” by the guy who ‘fixed’ TimThumb.

    What I wanted to do here was sort out how to block people who were looking for timthumb.php files (I can’t block thumb.php as I use that filename elsewhere). Reading up on Perishable Press’s Stupid .htaccess Tricks it’s clear we can do this:

    # prevent viewing of a specific file

 order allow,deny
 deny from all

    That should simply block access. An .htaccess block is a pretty simple way to reduce your server load, because people are getting punted before they get very far into things. Still, it’s something I have to install on each account on my server. Right now they’re just hammering ipstenu.org, and this is not the only domain on my server. This is, by the way, the same problem with using a plugin like WordPress Firewall. It’s a fantastic idea, if all you have is one account on a server. Protect yourself.

    I don’t. I run a VPS, and I have four domains here which I should be protecting. It’s easy enough to make that change on all four, plus two other external servers, but is that the best use of my time? I say no. I think I should automate as much of this as I can. What I really want is to say ‘If you’re looking for timthumb.php, then the odds are you’re looking for security vulnerabilities, and you need to just die in a fire.’ Or at least firewall block them. Seeing as I already have CSF on my server, it was logical for me to start there.

    Ice Blocks floating in the lake - Sarah OhBlocking an IP is easy, and I can do it via command line or GUI. Auto-detecting a URL though, is more complicated. Part of me thinks that, much like I can auto-block someone who tries to log in with any ID 10 times in a row, I should be able to add in a file pattern somewhere. Turns out you can’t, at least not the way I wanted. Instead, you have to do it differently.

    TimThumb’s exploit scanner isn’t actually a DDoS Attack, but it acts like one. A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make your site unavailable. Basically they hit your site with so much traffic that it’s incapable of its job: serving up webpages to happy readers! That’s why I call this a pseudo (D)DoS attack. The goal of the scanner is to see if you’re using Timthumb and, if so, to be evil. It’s not really distributed (i.e. multiple computers at once), though because of the number of people running the exploit scanner, it can seem that way. The side effect is that your site is hammered and can’t do what it wants. Which leads us to Connection Tracking.

    CSF has a tool called ‘Connection Tracking’ which lets you limit how many times a specific IP can hit your site at once before they get tossed to a shit-list. I set this to 300, and told it to only scan ports 80 and 443 (because I need to have unlimited FTP, and sometimes I log in from different IPs – yes, my home IP is on the whitelist).

    Connection Tracking. This option enables tracking of all connections from IP addresses to the server. If the total number of connections is greater than this value then the offending IP address is blocked. This can be used to help# prevent some types of DOS attack.

    Care should be taken with this option. It’s entirely possible that you will see false-positives. Some protocols can be connection hungry, e.g. FTP, IMAPD and HTTP so it could be quite easy to trigger, especially with a lot of closed connections in TIME_WAIT. However, for a server that is prone to DOS attacks this may be very useful. A reasonable setting for this option might be around 300.

    Setting this up is a little less obvious for the new person. Go to WHM > Plugins > ConfigServer Security & Firewall and look for “Firewall Configuration”
    CSF Firewall Configuration

    Click on the button, look for CT_LIMIT and change it to 300.
    CT_LIMIT settings

    Scroll down, click ‘Change’ and then restart CSF.

    Now, you could put this as low as 100, or as high as you want, but I did some reading and 300 seems like something not too likely to trip innocent people up, but just enough to catch the bad guys. I may way to lower this to 200 or so, but I know that a lot of people come to one part of my server for the image gallery, and they tend to open lots of pages at once. I don’t want to hurt them. The other thing to keep in mind is how short is the block time. The IP block is set for 30 minutes, which isn’t much at all, but it could be just enough to make the transient DDoSers go away. ETA: As of February 2012, I’ve actually lowered this to 50, and it’s made a world of difference! My day to day CPU is a little higher, but the number of spikes that caused outages has dropped.

    I’m not doing this to stop the people who want to bring my server to its knees. I’m doing it to stop the people who are ‘scanning’ for exploits. A true DDoS is hard to block because as soon as I block it, I have to defend against it again and again. CSF would be like a sump pump in your flooded basement, always running until it burns out the motor. It comes from too many sources, and for the little guy (i.e. me), I may just have to shut things down for an hour and wait it out. But these scanners, well, I can block them with this trick, and not hurt my server doing so!

  • Backup Where You Belong

    I’ll make it quick: At the end of the day, there’s only one person who’s responsible for your backups, and that’s you.

    Here’s the deal. WordPress does not have a 100% backup everything tool. Neither does Drupal nor Joomla.(All three of the big guys have plugins that can do this, don’t worry, I’ll get to that in a minute.) In fact, I don’t know of any app on the web that does. Even though Google says “You own your data!”, if you use their tool to download everything, it’s not in a form you can just slap back on the web. Their backups remain tied to themselves. You get the data, but then you have to parse it.

    This brings up a bigger question, though. What is the point of a backup? In a worst-case world, your backup is to save your bacon for when you screw something up. It’s to restore from a crisis or to roll back a bad change. So why aren’t these sorts of things built into applications?

    When you think about it, they’re not built into any application. From Microsoft Word to your favorite Twitter app, if an upgrade breaks something, there’s no ‘roll back’ option. You can uninstall and reinstall, but most of the time that means you have to reconfigure all your favorite settings.(This is actually why I try to make as few special config changes as possible.) Yes, in Microsoft Office, you can save your ‘document’ in total, but that isn’t a direct analog to Web Publishing, because there’s far more than ‘just’ your book, there’s all those settings and preferences. If you’ve ever tried to copy someone’s preferences and settings from one computer to another (and you’re not on a Mac, who makes that shockingly easy) you know what I mean.

    The best backup tools are things like Microsoft’s cloud backup, or Apple’s Time Machine. Both make a massive copy and then incremental updates to your entire computer. They are, as we say, OS (Operating System) backups. All your documents, all your applications, all your settings, are backed up. No individual application has ever bothered with this so why should a web app?

    The argument goes that you should be able to pick up your web app and put it down on another server via exporting. I can think of one app off the top of my head that can do that: Cpanel. I’ve never tried it myself, but I’ve been told it works pretty well. Still, Cpanel actually falls under the weird realm of operating systems, as it’s really a server management tool. It’s where you logically expect to see things like your backup tools, db access, etc etc and so on and so forth.

    In short, it’s the right place to see your backups made.

    How do you backup a webapp?

    Step 1) Backup ALL the files on your server.
    Step 2) Backup all your databases.

    That’s kind of it. For most well written apps (WordPress, Drupal, etc) to ‘restore’ these backups, you just copy them back up. For the database stuff, you may need to make a second database and edit your files to point to that DB instead of the original, but it’s pretty fast. Professionally, we have one-click rollbacks installed on databases, but even then, we tend to go ‘Oh, that didn’t work.’ and rename the NEW DB (databasename_date_BAD) and re-upload the old one. Why? Because it works. When the DBs are too big, we have incremental backups and rollbacks set up. Files ditto (actually for files, we ALWAYS have step one ‘make a copy of the old folder structure…’ and the rollback is just renaming things).

    We rarely rely on the applications themselves to perform these tasks for one simple reason: They’re BAD at it.

    I’ve always been an advocate of the right tool for the right job. A web app is good at its job. A backup tool is good at its job. The two may cross, but there’s nothing wrong with using a backup tool to make backups and a writing tool to write. I don’t use any plugins on my apps to make backups, I do it via the tools built into my server that are, expressly, for making backups. Ditto my computers at home. I know what the right tool is, and I use it.

  • Hack’n’Slash Security

    I was intending on a totally different post, but, well, this came up instead.

    Recently, WordPress, my preferred blogging software, has been under attack by both hackers and critics. There were actually three attcks that all got lumped into one so I’ll try and break this down. If you’re of the ‘Too long! Didn’t Read!’ variety today, you can get by with knowing this: If your WordPress install is not secure and if your web host is not secure and if YOU do not follow security practices, then you will be hacked. Period. Security relies on you, your web host and your web apps all being sensible about the whole thing to be effective. Remember, it’s okay to ask for help!

    Also go read Hardening WordPress right now.

    Okay, so security.

    Back in Feburary/March, there was a sudden influx of users complaining their sites had been hacked by inii.info, whereby the hack was to edit the wp-blog-header.php and change it so any time a search engine bots visited your site, they went to inii instead. This matters because search engine bots collect information about your site and use it to rank your website against all the other sites about a given topic. There was a second hack where a file named ... (yes, three periods) had even more redirect code in it. And it was heavily encoded so you couldn’t read it without decoding.

    The reason I call this a Media Temple hack was that it seemed to be prevalent to Media Temple installs. While at first people jumped the gun and said ‘It’s WordPress!’ Media Temple came out with a detailed Q&A about the matter and the attack appeared to affect ALL webapps via compromised passwords. If Media Temple ever revealed what happened, I’m not aware of it, but it wasn’t just WordPress that was affected. They ended up changing DB passwords for every webapp, from Drupal to vBulletin.

    In early April, there was another rash of hacks, this time targeting Network Solutions. This time, it looked like a clear cut case of database changes. WordPress, like most PHP/SQL apps out there, uses a database to store all its information. In this instance, the database entry for the site’s URL was changed from (for example) https://ipstenu.org to an iframe link I’m not reproducing here.

    At the same time, there was a ‘Pharma’ hack, where links with ‘pharma’ in them were slipped into your site, in a rather genius fashion. Chris Pearson has a decent explanation on the matter, but I feel he’s barking at the wrong car for part of it.

    Chris and Media Temple and Network Solutions and a horde of people on Twitter and forums every where jumped up and said “AHA! It’s a WordPress hack!!!111!” Which … well, yes, but not exactly. As the very wise Andrea_r put it, there’s a difference between attacking WordPress installs and targeting WordPress installs.

    An analogy if you please. There’s a rash of break-ins in a small town. The houses that are broken into are all bungalows. People shout ‘Aha! It’s a problem with bungalows not being secure!’ The police look into the matter and find out that in every house broken into, the bathroom window was left open. Now, is this the fault of the builder, who designed bungalows to have a window people could fit in through or is this the fault of the residents who didn’t close and lock their windows?

    If you said ‘It’s a little of each!’ then thank you, you can stay after class and clean the erasers.

    Security depends on many things, but to the topic at hand, server security is a tripod, and relies primarily on these three legs:

    • The Web Host is responsible for making sure the sever itself is up to date with the latest patches etc, and that the server is configured in a safe way.
    • Web-apps are responsible for not unleashing needless insecurities to the system.
    • The end-user we pray to the flying spaghetti monster that they’ve not done something to violate security out of ignorance.

    To understand how these hacks all worked, yes all of them, you have to look at the perfect storm. This is what had to happen in order for all these accounts to be compromised:

    1. Someone saved their wp-config.php file in a way that it was readable by the free world.
    2. Someone scanned for and found that file.
    3. The user was using their ID and Password, rather than creating a DB user just for the blog.
    4. That account had read access to other accounts on the same server
    5. The malicious user used the account to scan for other wp-config.php files, even if they were saved securely and compromised their accounts/databases as well.

    That’s a lot of wrong on one box. With most webhosts, you’re on what’s called ‘Shared Hosting’ which means a whole mess of people are on the same server, each with their own ID and password. Much like if multiple people have IDs on a desktop PC, the inherent security of the server does not allow Joe to look at Jane’s files, unless she saves them in a public space. Alas, one a couple sites, this was not the case. SO Joe, who saved his wp-config.php file with 777, and used his server ID and password to access his database in that file, was compromised. And once the hacker had Joe’s information, he scanned the entire server and hurt everyone.

    Ouch.

    But wait, doesn’t that mean it’s WordPress’ fault for saving passwords in the wp-config.php file in a way a hacker can read them!? Well, yes, it’s certainly WordPress’ ‘fault’ but you have to realize that doing so is an accepted risk of most PHP/SQL webapps, in that for the SQL DB to be read, the password to that database must be kept in clear text (i.e. not encrypted). This is in the wp-config.php file.

    Okay, so it’s Joe’s fault for saving his file in a readable fashion? Somewhat. By having their wp-config.php file set so that anyone can read it (bad permissions – 777 for example), Joe put himself at risk. This IS NOT a flaw in web-app or the ISP, it’s just … well, ignorant (unless the ISP is forcing the file to be 777 to run WordPress, at which point it’s their fault, and yes, there’s an ISP that does that!). In addition, I know a lot of people who, instead of making a DB user for their blog, will put their server ID and password in that file, which means once it’s been read, ANYONE can log into that server as them. I suspect this is done from ignorance as well. By the way, your server ID and password is the same as your FTP user ID and password in most cases.

    Back to WordPress, shouldn’t they check for that? Maybe. But it’s not that easy, since there are a lot of different ‘acceptable’ security settings for that file, and it all depends on the server. Maybe one day WordPress will figure that out, but right now they tell you to make it secure.

    What about the web server? They are responsible for making sure that if Joe User set his WP config file to 777, and put their server ID/Password in there, the worst they can do is shoot themselves in the foot by preventing them from reading anyone else’s user directory. Limit the destruction on a per-user basis. There are a lot of Shared Hosts out there with lax security policies, which makes this more prevalent than I’d like.

    Hopefully that made sense.

    All of these hacks seem to be looking for people with wp-config files that can be read, logging into the account as the user (or the database user), and either adding files that edit the database, editing the database, or both editing the database and adding the fake plugin files.

    Once your server is insecure, because of compromised IDs and Passwords, you have to go back to zero, reset ALL your passwords, scan your PC for viruses, and be careful. Remember, if they have your password, they can do everything you can do.

    Good luck out there. Be smart, be secure, be safe.

    Edited to add…
    Also check out Mark’s well written post about how your security? Is your responsibility. Because dude, is SO is.

  • But If, Baby, I’m The Bottom, You’re The TOP

    Earlier this month I talked about how my server was acting wonky and how I fixed it using, among other tools, TOP.

    This week I was chatting with a fellow about CPU usage and his site. He runs a rather large WordPress blog and the database is about 500 megs. As a comparison, this site, with about 500 posts, is under 5 megs, and my big site, with thousands of posts, comments, and a forum, is 10 megs. The biggest site I run on my server is 850 megs (just down from 910 after some clean up). The difference between his site and mine is that his is slow and he knows it. As we discussed ways to speed it up, I had some thoughts on WordPress and how, at a certain point, you’re going to need to dig into the guts of your server and learn TOP.

    The ‘problem’ with most ‘How do I make my WordPress site run faster?’ tutorials, as I’ve seen it, is they address surviving the digg effect. That is, they talk about how to deal with having a high volume of traffic on your site and, for the most part, you can make it with just adding caching plugins.

    Once your site gets ‘big’ or ‘popular’ you’re going to have to move off shared/cloud hosting and over to your own server. For most of us, the first step is a VPS (Virtual Private Server). Shared Hosting means ‘You have an account on a server with a hundred other people.’ It’s great for small sites, inexpensive and easy to use. The problem is you could have terrible neighbors, who use up all the CPU. Think of it like those old New York apartments where someone’s a jerk at 5am and uses up the hot water so you, at 7am, have none. Yeah, it’s kind of like that. That’s the day you think ‘I want a house!’

    Only, well, we’re not all up for houses just yet. A house would be a dedicated server, where it’s just you. Cloud hosting, which I touched on earlier, would be the college dorms of webhosting. It has a lot of benefits for the really small sites, and actually some for large sites, but I’m not sold of their overall usefullness yet, so I’ll talk about them some other time. What I want to talk about are Virtual Private Servers, the condo-sub-leasing (or rent-to-own maybe) of website hosting, and how the new VPS user should really get on TOP of things (sorry, bad pun) to make their lives easier.

    TOP. Well ‘top’ really. Unix commands are generally all lower case like that.

    The top command is a system monitor tool that outputs a list of processes. Have you ever seen Task Manager in Windows? It’s kind of like that tab for ‘Processes’ that you look at and run away from. The default view of top is by percentage of CPU usage and the “top” CPU users are listed. See? The name made sense. You can also see how much processing power is being used, memory hogs and other cool things. Most modern Unix-systems let you sort the list, colorize it, etc, though you have to be command line savvy.

    Here’s what top looked like for me about an hour ago.

    top - 12:44:44 up 126 days, 23:13,  1 user,  load average: 0.12, 0.17, 0.17
Tasks:  91 total,   1 running,  90 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0% us,  0.0% sy,  0.0% ni, 100.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    524288k total,   358248k used,   166040k free,        0k buffers
Swap:        0k total,        0k used,        0k free,        0k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
15616 nobody    15   0 94540  65m  20m S  1.0 12.8   0:00.27 httpd
12261 ipstenu   16   0  1908 1012  780 R  0.4  0.2   0:00.30 top
[...]
28630 root      16   0  107m  86m 1096 S  0.0 16.8   1:06.30 /usr/sbin/clamd

    I wanted to point out clamd, which has been the bane of my existance. Thing won’t DIE. I ended up going in to /etc/exim.conf and manually commended out the clamd line (and restarted the service) to finally get it gone.

    But top, as you can see, has a freakishly large amount of information. My server is doing fine, at this point, so I don’t have a whole lot to show you. What you can see right away is that I can tell, with a glance, what’s going on. I could see, though and at this point I have a ‘nobody’ process. That just means someone’s accessing my website. No, really! That’s good! The CPU and memory usage seem high, but they vanish in a second. Basically, someone rang my doorbell and for that brief moment, electricity was used. The next thing I see is the top command, which is run by me (hi!) and down the line is that idiot, clamd.

    I actually scan top a lot at work these days, trying to understand what’s causing issues. It’s good for ‘right now!’ things, but not so much if I want to see what started a strange spike a couple hours (weeks) ago. For that you need a whole mess of tools.

  • Sucking Clams, Kosher Style

    ClamAV is an tool that you put on your server and it detects malicious software. In short, it’s a server virus scanner and most servers use it to scan email for viruses. Now those of you who use stuff like McAffee and Norton and other virus scanners for your email, you may not know that servers also scan for that stuff as well, and try to kill the emails before they ever get to you! Yeah, think about how many emails with viruses you get. Personally, I’ve never had a problem with viruses and not because I use a mac. It’s because I pay attention to the content and context of an email before I open any attachments.

    But this is about ClamAV and server-side scanners.

    The story starts with my twice a week check of my server. I like to keep tabs on what it’s doing, how it’s doing, what’s going on, etc etc. I was a little surprised to see my server load spiked. Server load is sort of how you know how hard your server is working. A high load means its looking at a lot of work. A low load is ‘better’ but you have to admit that you’re going to have SOME load, so you may as well figure out what’s a good load for you. I’ve had problems with WordPress and right now I’m using WP Super Cache (See “I take it back. WP-Super-Cache is a Super Hero” from September 2009).

    The point is, I know that a spike like this is okay:

    That spike there was when I ran a small upgrade. You’ll notice how after the moment, it drops back down and has a happy nice day? That’s how things are supposed to work. A spike with traffic and then everything’s happy again. Great.

    So what does this mean?

    Yeah, I took a look at that, paled, and asked myself ‘What in the four hells is going on!?’ I did the logical thing and looked at the date and time. Noon on Monday I’d made a change to the firewall, moving from the perfectly acceptable, though harder to manage (no GUI), APF Firewall to CSF. That move was a TEENY bit on the spur of the moment, as I wasn’t having any problems with APF per se, but I was being hit up by a lot of spammers and my usual attacks of http:BL and Bad Behavior weren’t cutting it. They’re front end fixes to the ongoing spam problem, alas. I hate spammers.

    Worried that my new firewall was ‘bad’, I started to Google if CSF caused high server loads. And found nothing. So I went back to the beginning and checked top. Top is a unix command that you use to see what’s using up resources on your server. It’s like Task Manager for Windows, but it’s a lot more informative. Top lets you see details and sort and basically when you want to find out what ran off with the spoon and killed your server, baby, I’m the bottom and log on to top. Top showed me, interestingly enough, that ClamD was using between 70 and 90% of my resources. On a slow week, like the net generally has for entertainment sites between Christmas and New Years, that’s not really a problem. There’s not a lot going on with the sites I host right now, the extra CPU usage wasn’t a problem. Come back on January 20th, though, now that’s a problem.

    But the thing of it is, back in September, I optimized my server and I remember reading on multiple places that ClamAV and ClamD use up a lot of resources and people turn them off. So I did.

    Isn’t that much nicer?

    The real question, at the end of the day, is if having ClamAV turned off causes more problems than having it on? So far, no one’s breached my servers, though that’s a function of my firewalls, and SpamAssassin seems to be taking care of the spam emails, which is where most viruses come from in my experience, unless the server’s hacked, at which point I’m kind of screwed anyway. But what I find myself wondering now is if it’s dangerous to not be using ClamAV or what. And I don’t have an answer to that yet.

  • You’re not the boss of me

    After having my domains on three different servers for a long time, I mathed it out that it’d cost me the same to put ’em all on one VPS (virtual private server). After calling up my ISP (the fanfreakintastic LiquidWeb) they had me all moved over without me having to fuss! Combine two shared accounts into one VPS? Sure, done. I suspect my next bill will look … weird, but that’s okay. I’m sure that even if it’s all messed up, I can call them and get it sorted out.

    The first thing I did was make sure everything was running and then I left it alone for a day. Did anyone notice? No? Good, the fix was in!

    Then I started fiddling. I didn’t know a lot about VPS, having only mucked about with a RedHat distro before, and LiquidWeb provided me with cPanel and WHM, which I’d never used before. They also had the very familiar shell world for me to jump into. Google being what it is, I quickly found a VPS Optimization Guide that gave me some ideas to start.

    What I’ve Done So Far
    My memory usage, with one beefy site and two baby sites, was hitting 50% which, in my mind, was bad. Now the beefy site runs off WordPress which is known to have these issues. My CPU was barely passing 0.01 (yes, that’s right) though, so that was good. My first thought was to try WP-Super-Cache again, except last time I did that, CPU went through the roof and stayed there. Also, you lose dynamic feeds etc (unless you use AJAX) and I’ve heard great things about WP-Super-Cache but the fact that it’s not a locked in part of WP has always made me wonder as to it’s viability. If it really was that good, or the only solution, it would be built in. Not to knock it, but I consider it only one option.

    While I know I need to optimize WP, my first stab was to optimize the server. Except that I didn’t. I switched from Zend to APC. Now, I’m not really sure if that was the best thing to do. I find a lot of people clamoring that APC is better and since I’d had weird issues with Zend before (outright borking MediaWiki if not configured specially), I decided to give APC a shot. If someone has info on some benchmarks or a good link to why APC is better than other PHP cache tools, I’d like to see them.

    Then I removed Clamd (and ClamAV). Yes, I know it’s virus scan software, but I’ve never actually seen it catch anything. What I run on the server, and what my ONE (yes one) resold client will run, aren’t going to get caught by it. We run the same stuff. So call it a calculated risk. I also turned off EntropyChat (never gonna use it), MailMan (resource hog), Analog Stats and Webalizer (leaving AW stats, though personally I use Woorpa and Google for stats). Gave the server a bounce after all that and my memory dropped from the 50-th percentile to the 30s. I consider that a success.

    My only issue is that my phpinfo page looks weird… No idea what happened there.