Steve's Security Blog | @northvein

I don't think I'd had chance to get my seat warm on Monday when I was approached by our service support function who were getting inundated with details about a 'virus' doing the rounds at via email which, when opened, forwarded itself to everyone in the user's address book. I don't normally get involved with desktop issues but I'm always happy to help and eager to understand risks both technically and from a wider business perspective. It seemed our endpoint anti-virus 'solution' had a 0% first-time detection success rate and by this time it had already managed to sneak past our 3rd party email security gateway. I set about acquiring a copy of the offending payload and decided that it would make a good candidate for a 'blind taste test' to run past a few online sandboxes. If you're not familiar with the concept, sandboxes are controlled environments within which you can run un-trusted programs and capture details about how they behave.

I let the honeypot run for 98 days in total. Looking back, I don't know why I didn't let it run for exactly 100 but I suspect it had something to do with me moving house around that time. I took note of my observations as I shut it down and grepped and awked my way through the logs to produce summary stats. The first observation I recall making was the disparity between the number of connections to the site on the domain name vs. the number of connections to the site on the IP address. You'll find (regrettably) that a lot of websites will still serve you content if you connect on the IP address. It's a good idea to disable this functionality and simply present a generic error. This way, you'll eliminate a lot of your exposure to automated scanning, and the figures below corroborate this: Connections to site via domain vs. via IP address Lets not forget that my honeypot was set up in such a way that, in theory at least, there could be no possible legitimate

Honeypots are currently in vogue with lots of security researchers writing about how they can be used to profile adversaries and detect emerging threats. I ran a Wordpress honeypot last year for little more than three months as a little exercise in setting up, running and then monitoring the results produced by these invaluable security tools. I decided that as a first attempt, I'd use it to attempt to assess the average level of technical capability of those individuals or parties that seek to identify and exploit common web applications. Anyone who reviews the logs of any website, big or small, can tell you that these kinds of attack form a huge percentage of the 'background' noise of the internet. I never really intended to share the details or results of this exercise but I've since changed my mind and hope that if you too have considered setting up and running your own that my 'notes' might encourage you to do so. As soon as I started playing around w

I've always been a fan of OpenDNS. Even before they switched to being a  security outfit, I used them for content filtering in the office and at home. If you're not familiar with their offering I'd recommend visiting their website and taking a look for yourself. OpenDNS.com Earlier this year, a colleague overseas got in touch to let me know he'd put OpenDNS in at a few office locations based in other countries. The good news was that change had been seamless and that OpenDNS had instantly started to spot malicious DNS requests originating from both sites. The bad news was that he had no way or idea of working out which desktops or servers were making the bad requests as he had almost no visibility on those networks and no body on site able to help.  OpenDNS Dashboard Activity Summary Having your public DNS alert you to malicious requests originating from an office or country is a bit like having a smoke alarm on the 40th floor. Sure, it lets