Tag: security

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=/

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.

Blocking 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”

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

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!
6 September, 2011
TimThumb, Heroism and FUD

FUD is “Fear, Uncertainty and Doubt” and it’s a tactic used by people to scare you and make you jump into a decision that benefits them. This decision may not be a bad decision, but it’s not strictly to your own benefit, but theirs. Keep that it mind, it matters.

Recently it was discovered that there was a massive vulnerability in TimThumb (TimThumb is an image editing tool for your webapps). It had an honest-to-god Zero Day Vulnerability. I don’t use the code, and I don’t put it on any site I run, so I knew I was pretty safe. Still, I ran searches for timthumb.php on my entire server, made sure it was clean, and moved on.(Not relevant, I recently changed all my passwords on all my sites, and my servers, because I realized I’d used the same ones for about 6 years.)

The exploit primarily affected WordPress installs, because it was developed for WordPress in the beginning, but since then has grown to be used by many other apps, like Drupal and Joomla and even home-grown ones. It’s insanely cool, but it’s always had weird little problems (which is probably why it’ll never be included in the core code of those apps). Getting it to work at all on MultiSite was a pain, and when someone wrote a how-two, we gave her Tim Thumbs up!(Bad joke. BAD bad bad joke. Sorry.)

Certain people leaped into action. VaultPress, which runs a backup service for WordPress users, sent out emails to everyone who had TimThumb. Then they went the extra mile and fixed 712 possible exploits for you. (I know some people got shirty about it, since they didn’t want VaultPress editing their data. That isn’t the point here.) They jumped up and said ‘We must fix things for people’ and did it. This was, indeed, Matt’s vision for VaultPress.

But then this other thing happened, and I’ll quote Matt:

It could have gone a lot of ways, but the incident brought out the best in the community. The core team sprang into action searching through the theme directory to inoculate any themes that contained the dangerous code. Community blogs quickly got the word out about the problem so people were aware of it. Mark Maunder, who originally discovered and broke down the problem, created a fork of the code called WordThumb that rewrote TimThumb from the ground up. Forking is not usually ideal because it fragments the market for users but Mark soon connected with Ben Gillbanks, long-time WordPress community member, and they’ve teamed forces to release TimThumb 2.0, a collaboration that exemplifies Open Source at its finest. An updated plugin should be in the directory shortly.

Let me explain. There was a problem with a popular tool that is used both in themes and on its own plugin (and probably others). Mark found the problem, fixed it, and then re-wrote the tool. Then, after Matt commented on his site that Forking is a last-resort, even though this was a ground-top rewrite, Mark agreed and talked to the TimThumb guy and together they fixed everything. And now they’re a team. No one made any money off that process. People just did the right thing to make the web safer for all of us! (Okay, that’s not the point either, but it needed to be made.)

All of this was done in a way that the public knew about the problem without getting into an “OMGWTFBBQ!!!11!?” panic. Was there some fear? Yes, because you knew there was a problem and there was a possibility it could affect you. Was there uncertainty? Of course! Again, could it affect you? Was there doubt? And this here is where we have a win for the Open Source community. There wasn’t. It was a straight up ‘This is what’s wrong, this is how to fix it.’

In so many ways, that’s how every business should work. It could have been better, certainly, but when I compare this to how I get security alerts for our servers at work, I see nothing but room for improvement. Right now, one person has the job to look for vulnerabilities that are published about anything we use. If she sees one, she opens a ticket and says ‘Fix this ASAP!’ The problem is, to use a recent example, ownership of the fix. We had a vulnerability with .NET, but as I read the whole doc, I sorted out that it only happened if your server was configured in a certain way so as to make a security hole. Another quick check and I saw the server team had their own ticket ‘Fix this hole.’ So I closed my ticket and said ‘Will be resolved with Server Ticket 1234567.’ My ticket was reopened and I was told I did it wrong. This was a problem with my application (I don’t ‘own’ .NET, I happen to be on the team who brought it into the company, however). I pointed out it wasn’t that .NET was vulnerable, that it was the server. They didn’t care. My ticket has to be open until the problem is resolved, no matter what. In the end, I turned off the feature that might, possibly, be vulnerable and got chaff for not doing it right.

When you compare that to the beautiful simplicity of Open Source communities, it makes you wonder how anything actually gets done? We’re so afraid (fear) of being wrong or doing the right thing without the right approvals, we let the process hamstring us from fixing the problem. We don’t know (uncertainty) what the right thing is anymore, so we do nothing. And in the end, we’re not sure (doubt) if we’re of any use at all. (I think my premature grey came from this job, and if I leave, the first thing I’m doing is dying my hair neon blue.) Plus, to make matters worse, they told the entire company about the security hole, so everyone knows, and they can see we didn’t close the tickets. It’s a mess.

But really that’s not what FUD is about. Nor is it what this post is about. Neither way is perfect, and both are flawed in different ways.

You see, what Open Source nailed in one was that we should be aware of the dangers, and work together to make it better, not feed the fires and run around terrified about what’s going on. A little fear is a good thing. It clears the arteries and is good for your heart. If you’ve never had a moment where the blood drained out of your face because you made a mistake, you’re not trying hard enough. We all live with uncertainty and doubt, too, and inherently these are not bad things. What is wrong is allowing them to have complete control over your actions to the point of inaction or consistently making the wrong choice that you know is wrong.

Make the right choices. If a bread stick is on fire in the toaster, take it out and make that extra step to sort out who put it in there. Treat everyone as a team member, a fellow hero. You see, if we give in to FUD, we cripple ourselves, much like corporate america does every day with miles of red tape. But if we don’t, if we accept our fear and move forward, we can get past it and make better products for everyone. And that’s a great goal.

If you think you, or a friend, may have been hacked, please go to Sucuri and run the free scan for your website.

19 August, 2011
Understanding Zero-Day

If you run a website or work with computers much at all, you’ve heard the term ‘Zero-Day Exploit’ and you probably had no idea what that meant.

At its heart, a “zero day” attack or exploit is one that happens before any of the developers are aware of it. It’s pretty straight forward, in that the attacks take place in that window of opportunity between code release and code patch. Logically, you’d think that all exploits are ‘zero day’ because a programmer would never release a product with known vulnerabilities. Right?

Wrong.

We already accept the fact that human beings are not perfect and thus, by extension, neither is our code. We cannot make every product work on every setup, otehrwise there wouldn’t be browser and OS wars. Keeping that in mind, we have to accept the fact that there will always be security holes in code. And sometimes we developers are well aware of them, but consider them acceptable risks. This means that when a vulnerability is plastered as a zero day, the question becomes ‘By whose calendar is this a zero day exploit?’

If you found a zero-day flaw in a product, the ethical thing to do is privately communicate with the product developers ‘Hey, if I do this, I can get access to THAT.’ At that point, the product developers should take the time to craft a fix and quietly push it out to everyone. The public often isn’t told about this until the patch is written and available, and even then, details are withheld a few days so that, during the critical time it takes everyone to upgrade, people aren’t exploited further. This also allows people to apply one patch instead of 17, as multiple fixes can be wrapped up into one install.

Of course that’s a perfect world scenario. There are multiple cases of exploits being announced in the wild before a fix has been made. Sometimes it’s a case of an over enthusiastic reporter, but also sometimes the people who report the bug get mad at how long it takes to fix it, and release the information in order to speed up the process. There are unprintable words for those fools, and the fact that they can’t understand how they’re making the situation worse is sad.

By its nature, an exploit no one knows about is the one you can’t protect yourself from. That’s why vulnerability disclosure is such a touchy subject. Sometimes the fixes are really easy, but more often they’re not. Like a vulnerability exploit in your car is the gas tank. Anyone can walk up, unscrew your fill cap, and pour in anything they want. That they don’t has more to do with the fear of retribution than anything else, but they certainly could. Also vulnerable? Your mail. I can’t tell you how many times I see the mailman leave the cart on the sidewalk while she goes in to deliver our mail. Someone could steal the mail, but rarely does that happen.

In 2008, there a DNS cache poisoning vulnerability was discovered.(ZDNet – Has Halvar figured out super-secret DNS vulnerability? by Ryan Naraine | July 21, 2008, 2:12pm PDT) The details of the exploit itself are inconsequential to this story. When the vulnerability was discovered, the folks ‘in charge’ asked for a thirty-day embargo where no one would ask about it or talk about it, to allow the code to be patched and deployed. This radio-silence would end with a news release and explanation. This did not work as well as one might have hoped. (ZDNet – Vulnerability disclosure gone awry: Understanding the DNS debacle by Ryan Naraine | July 22, 2008, 7:09am PDT) People accused the organizers of performing a bit of media hacking (i.e. social hacking) and spinning the news to make a bigger impact for themselves. Essentially, they claimed there were no altruistic reasons to keep the lid on the issue.

When you seen a report of a zero-day exploit, the important thing is not to panic. Firstly, check to see if there’s already a patch. Secondly, remember that just because you’re vulnerable does not mean someone’s spiked your gas tank. Thirdly, accept reality for what it is and know that you’ll be impacted at least once in your life, and that’s okay.

If you know how to recover from this, you’re better off. But that’s another topic.

1 July, 2011
WordPress: EU Compliance
ETA: Please check out Trac #19622 – There will be a new way to do this in WP 3.4

Before I get into this, you do not need to do anything to WordPress to comply with the EU cookie law. The legal whoo-hah is clear: Third party cookies (and cookies which track data across multiple sites) are the only ones they’re talking about. MultiSite installs are, technically, one site, all owned and managed by one person, so it’s fine. Google.com, gmail.com and anything else registered to Google would also be fine internally.

But if you’re dead set on this…. Let me explain first.

For WordPress, if someone comments on your blog, cookies are stored on their computer that store three things: name, email and website. Even then, they’re only put in when the user enters then. That would entail implicit agreement to having cookies put on your computer, wouldn’t it? Even if you have no idea what cookies are? That certainly is a problem. People don’t know what cookies are, why they’re on their computers, and what they can do. But is that the responsibility of website owners to educate? Certainly, you can easily add a checkbox to your comment for that says ‘save cookies,’ have it link back to an explanation about what’s going on, and make it required.

It would be pretty easy to flip WordPress around to not save cookies for non-logged in users.

First you change your KEYs and SALTS in the wp-config.php (you can get new ones at http://api.wordpress.org/secret-key/1.1/wpmu/salt). This will force all users to log back in.

Next you change your registration/login page to alert people to the cookies. There are plugins for this, and on BuddyPress you can edit your theme’s template page for registration easily. By having the login/registration page say ‘hey, you’re gonna get cookies if you log in!’ you’re now in compliance with EU law!

Finally you slap this your header (or functions or a mu-plugin file), to delete cookies on every single page you visit, which will prevent cookies from staying on people’s computer ONLY if they’re not logged in:
```
<?php if ( !is_user_logged_in() ) { wp_clear_auth_cookie(); } ?> 
```
One could go even further, making a check-box to permit cookies or not, though that would be far more complicated to track. This very basic way of making the code you own compliant is enough to get you through the day and keep the enforcers off your back.
19 May, 2011
On the EU Cookie Law
ETA: Please check out Trac #19622 – There will be a new way to do this in WP 3.4

I’m going to be bold and tell you that the new EU law, that goes into effect in the UK on May 25th, is going to be impossible to track and enforce, it’s being handled backwards, but besides that, it’s actually a pretty good idea.

For most people outside the EU, we have no real idea about what’s going on, so here’s a short recap. As of May 25th, a change to the EU law will require businesses to request permission from visitors to their websites before they can store information about their identity, history and preferences via third-party cookies. You can read the whole details in the proposal or Directive 2002/22/EC on universal service and users’ rights relating to electronic communications networks and services. Those links are full of legalese.

Now, I do want to point out that this only affects people who live in the EU. Arguably, it also only affects people who host sites in the EU, and you may be able to skirt around it by hosting in the US or Canada, but that’s a lawyer conversation. Basically, if you live in the EU and have a website that acts as a business, you’re kind of screwed. If you just have a blog with 100% personally controlled content and cookies that only come from your domain, you’re fine. The cookies, including the kind WordPress drops on your site, are not the kind they’re talking about. If your cookie is only tracking information used on your site (login information, recent comments, etc), you’re fine. If the cookie comes from someone else (like Google Analytics or Project Wonderful), then you need to explicitly tell the visitor and obtain their consent.

This is done for a pretty good reason, when you get down to it. When you go to a restaurant and pay with your credit card, you trust that neither the credit card company nor the restaurant are going to turn around and give your personal information to some other company who uses it for their own purposes. Legally, they have to ask you for permission to use your info, and that’s why sometimes they ask for your zipcode when you’re checking out at a store (and also why you’re totally allowed to say ‘no’ when they ask). Third-party cookies, that is those put down by someone other than the domain you’re visiting, should also be ‘agreed’ to. The EU argues that just visiting a site with Google Ads does not constitute consent.

Item #66 in the directive:

Third parties may wish to store information on the equipment of a user, or gain access to information already stored, for a number of purposes, ranging from the legitimate (such as certain types of cookies) to those involving unwarranted intrusion into the private sphere (such as spyware or viruses). It is therefore of paramount importance that users be provided with clear and comprehensive information when engaging in any activity which could result in such storage or gaining of access. The methods of providing information and offering the right to refuse should be as user-friendly as possible. Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user. Where it is technically possible and effective, in accordance with the relevant provisions of Directive 95/46/EC, the user’s consent to processing may be expressed by using the appropriate settings of a browser or other application. The enforcement of these requirements should be made more effective by way of enhanced powers granted to the relevant national authorities

That’s a pretty hefty thing to get through, but it clearly spells out that third party cookies are when they’re on about. And in that, they’re right. There should be transparency to all this. We should know when we’re being tracked around the internet. But they’re wrong in making this the sole responsibility of the website owners. This is not to say that, as a website owner, I’m not responsible for the cookies my site puts down. And this is not to say that, as a website owner, I’m shouldn’t tell people how cookies and personal information I collect are used on my site. But to say that the ‘solution’ is for me to alert you with “Hi, the EU says I have to tell you about cookies and make sure you’re okay with them on your computer.” or not to use things like Google Ads, Facebook Like buttons, or Twitter integration is unenlightened.

The issue is not that I, as website owner, am using third party services, and it’s not even that I’m using those services in an ‘hidden’ way (I use Google Analytics on this site, which you can’t easily tell unless you look at my source code). The issue is that those services are using cookies to track you between sites. But it’s easier to go after you than it is to sort out how to go after them, at the end of the day.

Arguably, this is also being done to protect the website owners. If a visitor agrees to have the cookies, then you’re not longer on the hook if they complain. How are they going to (1) verify that (a) you did ask first and (b) they did consent, and (2) enforce this at all? The only way this can be enforced is if someone (or a program) goes to every single website hosted in the EU, or owned by someone who lives in the EU, and checks them for cookies without explicit consent. This could be automated, and emails could be automagically sent out to the site-owners, who would in turn have to look at their software and ads and deduce what’s making the cookies. Already, the UK has said they know companies won’t meet the May 25th deadline and don’t plan to enforce the law yet.

Let’s say that they decide they will enforce the law. How can they verify that a cookie for your site is on someone’s computer? WordPress saves cookies in the name of wordpress_verylonghashkey, where your HASH key is specific to your install. Now they do show up as ‘from’ the website domain.tld but they can be forged. The easiest way is to copy cookies from one computer to another (I just did that when I moved everything from my old desktop to the new laptop). Another way is to take the information I have in my cookie, and tweak it to apply it to someone else’s site. That way requires a lot more savvy, more information than I’m providing here, obviously, and it’s incredibly hard, but it can be done.

If they only rely on cookies that show up when your site is visited, they have to come up with a way to verify that it’s your site that put down the cookies and the visitor agreed to have the cookies put down. They have yet to explain how they’re going to be checking sites, which means you, as a site owner, still have no idea exactly what is and is not illegal to do. Sort of hard to protect yourself against an unexplained law, and it’s worse when you remember that “ignorance of the law is no excuse.” That should cut both ways. Ignorance in creating the law is no excuse.

There’s already a way for users to stop cookies from being stored on their computers. Every browser out there has a way to turn off cookies. Most have a way to say ‘Don’t allow third-party cookies.’ If that’s not enough, Don’t Track Us has plugins for most browsers that let you block tracking plugins.

To make this work, the EU needs to explain how they’re going to determine if you’re in violation of the law, and how they will enforce it. They also need to take this to the streets and tell the third-party cookie makers to stop. There are ways that third party tools can work around this, and one of which could be to tell people when they log in to FaceBook “We reserve the right to use your login credentials and other account information stored in cookies on other sites.” After all, the cookie belongs to FaceBook! Or we could just not use cookies at all for that sort of thing. But that has to change at the source of the matter, the third-party, and many of them don’t tell people that their cookies are used in such a way.

As it stands, this law won’t be enforceable, it won’t be understandable, and it will cause more hassle with the wrong people without protecting anyone at all. It’s still a great idea, but it’s just not going to work this way. All they’d done is made a law to tell people that their hot coffee is, indeed, hot.

Further Reading
9 May, 2011
Stopping Stalkers
We’ve all been there. One day you’re out enjoying the net, and the next you have a complete and total turd making your online life hell! What do you do? There are a lot of answers to this, but really it boils down to two types of reactions. You have to change your behavior, and you have to change your online accessibility.

Changing your behavior is pretty obvious. Once someone starts abusing you online, calling you names, or just angry-ing up your blood, walk away. This is the hardest thing in the world, but do it. Most idiots will stop once you stop feeding them, which is why we always say ‘Don’t feed the trolls.’ When people go past your garden variety gnome moron, however, and start harassing you (and you know there’s a difference), you need to do more than just change how you react. Basically you need to stop making the problem worse. If you’re angry, you log off, walk away and grow the hell up, or you deal with the shit-storm you created.

On the technical side of things, there’s a lot you need to do. If you’re on Facebook, Twitter, MySpace or any public forum with this person, you block them. If they evade the block by making new accounts, report them. Most sites have a policy about this, and the more you have to report them, the more likely they’ll get banned. Always remember to mention ‘I blocked this guy because as he was harassing me. Now he made to do it again.’ This will take a lot of doing, and a lot of arguing, but it will get things done. Block them on IM, Skype, everything you can think of that they might have.

Once you’ve taken care of them on sites outside your control, let’s look at your site, which is the meat of this post.

If you have a stalker, you want them to stop being able to contact you, right? If you have a blog, block their email in the comment blacklist. Just turf ’em. You don’t need to see them. If the harassment is bleeding into real life, I would moderate them instead, since you might need the comments for later proof in a legal case, but the effectiveness of that is in doubt right now (it’s too easy to fake that stuff). Make a note of the IP address and block that as well.

In fact, block the IP from your server via .htaccess:
```
order allow,deny
deny from 123.45.6.7
deny from 012.34.5.
allow from all
```
If you have a firewall on your server, toss the IP in there as well. This servers two purposes. Most importantly, you no longer have to deal with nasty comments, but also, you are no longer feeding the troll, because the troll can’t get in. Of course, this isn’t perfect, as most of us use multiple IPs because our addresses, even with high speed, will change. This will only become more and more futile as we get into IPV6. In fact, you may recall I once said Don’t block IPs. When I said that I was talking, specifically, about spammers and bots. Blocking them by IP is futile. But blocking your stalker? Actually effective in certain cases, because some stalkers aren’t very technical. Alas, it’s only some. When you have a smart stalker, who knows how to use proxy servers to their benefit, you have to start learning tricks like How to Block Proxy Servers via htaccess.

This won’t stop everything, of course, and I generally spend a bit of time with my firewall (I use CSF), activating the Real Time Block Lists (RBLs) and adding in certain countries to my block list using CC_Deny. I don’t like doing that, but sometimes you have to. I’m a pretty big advocate of Bad Behavior which, while it runs via PHP, can be instrumental in stopping bots. That helps me sort out proxy servers, since once you understand how Bad Behavior works, you can check its logs and weed out the proxy servers. Grown up Geek’s post on How We Block Proxies, Bots, Scrapers, Trolls & Assholes is an invaluable resource here.

This also doesn’t stop email, and I personally filter all of mine on the server level. This does mean I keep the emails on my server, but again, this is something useful to have if these things ever go to lawyers. If you use IMAP, generally it’s okay to keep the emails up on the server, but it’s also a good idea to save them as .eml files to your computer, as they store all the data needed to trace back the emails. Most of us never need this, but the CYA is worth it.

When things start to spill over into your ‘real’ life (or at least your physical world), don’t be afraid to go get a lawyer. Yes, this will cost money, but if you’ve done all this and can use it to prove this person is escalating their behavior, a good lawyer will know how to get you a restraining order. If you’re not being stalked today, lucky you! I would strongly suggest you do a few things in advance, though! You already know not to put anything out on the net if you don’t want it found, but I would also say that if you registered a domain, consider making your registration private. That will hide your address and phone number. If they’re calling your phones, the phone company can block them, and it’s definitely worth your while to ask them to do so. Peace of mind is part of the reason, but the other is that if you ever end up in court, you can show them the phone company records.

A word of legal advice, here. The courts recently ruled that an IP address is not a person. This means that even if you have a bunch of emails and comments and whatever from a specific IP, that alone won’t be just cause for a warrant to break the door down. That’s a good thing for most of us, and means you’ll have to do detecting the old fashioned way.
5 May, 2011

Tag: security

TimThumb and the Pseudo (D)DoS Effect

TimThumb, Heroism and FUD

Understanding Zero-Day

WordPress: EU Compliance

On the EU Cookie Law

Stopping Stalkers