I am not going to specifically address the topic of scripted attacks (such as click-jacking, like-jacking, using tools like Selenium, etc) used to game contests. There are just too many variations, and frankly, many of the data analysis concepts here would apply to that scenario as well.

Understand that I Am Not a Lawyer, and am NOT giving you legal advice here. The intended audience for this article is application developers, database architects and product directors, as we discuss some fundamental concepts that must be integrated into your contest application before even a single line of code is written. Many of these concepts can be applied to non-Facebook online contests, but some are Facebook specific.

Also, if you got to this article because you’re trying to learn how to game a Facebook contest, please die in a fucking fire. You are a useless piece of shit, and people like you are what is wrong with the world.

First things first, and a little bit off-topic, if you’re planning on creating a Facebook contest, be sure your contest abides by Facebook’s promotional policy guidelines. They’re a pretty quick read, but failing to read them before deploying a contest on Facebook may result in Facebook disabling your contest for policy violation. You can (and should) read the whole set of guidelines here, but since we’re about to discuss planning your contest app, the ones you really need to be mindful of are:

1. You must not use Facebook features or functionality as a promotion’s registration or entry mechanism. For example, the act of liking a Page or checking in to a Place cannot automatically register or enter a promotion participant.
2. You must not condition registration or entry upon the user taking any action using any Facebook features or functionality other than liking a Page, checking in to a Place, or connecting to your app. For example, you must not condition registration or entry upon the user liking a Wall post, or commenting or uploading a photo on a Wall.
3. You must not use Facebook features or functionality, such as the Like button, as a voting mechanism for a promotion.
4. You must not notify winners through Facebook, such as through Facebook messages, chat, or posts on profiles (timelines) or Pages.

Basically, this means that you can’t use any of the native Facebook platform tools as voting or winning mechanics. You can like-gate an app, requiring the user to like an app or page before being shown the contest sign-up form, but you cannot use the act of liking the app or page as the registration itself. You cannot award points or incentives on a Facebook share, but you CAN award points or incent the conversion. So if your app lets me invite people to your app, you can award me points for every one of my friends that allows the app and participates, but you cannot award me points based on how many people I invite that do not convert to app users or clickthroughs or what have you.

There’s a little bit of nuance to it, but the general rule is just to avoid using the platform for stuff that determines who wins or loses, period. That part has nothing specifically to do with gaming a Facebook contest (or the prevention of gaming a Facebook contest), but it’s pretty important, and will influence some pretty core mechanics in your contest, so don’t gloss over them.

Rule #1 of running a contest: LOG EVERYTHING

Log absolutely everything possible. Require that the user is logged in, and always log their FBID *and* their IP address. Your legal counsel will thank you for it.

You need to be able to run an audit on every action related to potential winning or losing of the contest for your own liability, but also because it is the foundation of putting yourself in a good spot to detect suspicious or fraudulent activity. Seriously.

If ass-wiping influences the contest outcome, you had better be logging every single time the user wipes their ass, complete with IP address, user agent, timestamp, and anything else you can think of that would be specific to that action+session combination. I simply cannot emphasize this enough.

Without extensive logging, you will be left absolutely helpless when a user (or their lawyer) challenges your winner decisions, or when other users claim a specific user is cheating.

Make sure your web server is logging access correctly as well. You may need to correlate your Apache access log to a specific transaction and IP address as well. Test this before your app goes live.

As you analyse your logs, look for inconsistencies in user agent and/or IP address. If their user agent is logged as “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7″ in one log entry and “Mozilla/5.0 (Intel Mac OS X 10_7_2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7″ in the next, something is up. The differences between those two user agent strings is subtle, but it’s there, and there is no legitimate reason for it to change from action to action in the same session.

Rule #2: Get their email address

It seems intrusive, but if your loot is decent, people won’t mind giving it to you. Once they have allowed your application and granted you email permission through the app allow dialog, you can pre-populate the email address field so they don’t even have to type anything in. You’ll need their email address anyway, to notify them if they won, since Facebook doesn’t allow you to use FB Messages to do that.

You want their email address because users creating fake Facebook profiles (each of which requires a unique email address) to generate bogus votes/points/whatever will generally not be terribly creative (or may be using an automated script or service to do it), so you can use the email addresses as a way to detect patterns in participating users that could imply fraudulent activity. If you see 100 new entries, all with the email pattern of firstname1234lastname@hotmail.com, there’s an excellent chance that those entries are bogus.

Brace yourself for the truth

The cost of winning a Facebook contest by cheating is much lower than you probably imagine – and unsurprisingly, there are businesses online that exist for the sole purpose of helping people win online contests. Right now, on a casual Google search, I can find services that will sell me 10 PVA (Phone Verified Account) Facebook accounts for $20. I can buy 100 non-PVA Facebook accounts for $20, if I think the contest won’t do that much checking for fraudulent activity. If you do a search for “facebook contest” on sites like freelancers and microworkers (I will not link to them), you’ll find hundreds of people with Facebook accounts just itching to get paid to help your potential contestants game your contest.

If you’re giving away a trip worth $3,000 and because of the number of participants, it would cost me $20 to win your contest, you are *going* to get gamed. My risk-to-reward-ratio is just too good for me not to do it. I spend $20 and I get $3,000 worth of prizes? Hell yeah.

In one investigation I performed, I saw bids of $30 accepted for people to get 200 people (real people or fake-but-look-real accounts) to vote x times. That means each one of those Facebook accounts is worth $0.15 to the person renting them out. Consider creating accounts at these microjob sites before your contest is over and check it for openings related to your contest.

Additionally, since there are people and services out there that have created Facebook profiles for exactly this purpose, you can’t rely on Facebook profile creation date as a reliable measure. Many of the fraudulent accounts I’ve come across have been around for over a year prior to the contest. They’re also smart enough to make sure these profiles have friends that look legitimate, so it won’t be as easy as looking for FB accounts that are new and have no friend connections.

It gets worse. There are also online sites that encourage users to do like/vote exchanges. “Vote for me for blah, and I’ll vote for you.” This method tends to be slower than simply buying accounts, but it’s also free. Search Facebook for terms like “vote exchange” and you’ll find pages and groups for the sole purpose of gaming contests.

It’s up to you to decide whether a vote/contest exchange falls under your definition of cheating. It absolutely does in my book, but it really depends on how your contest works. Either way, you need to set the definitions of what exactly qualifies as cheating before your contest even starts, because you’re going to run into more gray areas than you probably would have thought.

Rule #3: NOTHING GETS DELETED. EVER.

If users can submit content as part of the contest, make sure you architect your application in such a way that nothing ever gets deleted, either by moderator or by the users themselves. Instead use a database flag to toggle visibility in the app. Log the deletion (timestamp, IP, user agent, who took the action, etc) and tuck it away, but never, ever delete the data.

Doing so insulates you from users saying “I didn’t delete it!” You will have proof that they did, including all the particulars such as what browser they were using and when. This also allows you to recover from content that is accidentally deleted by a moderator. If “deleting” content is simply toggling that boolean database field, it’s easy to toggle it back on if it gets toggled off by mistake.

Rule #4: Know what counts as cheating up-front

This sounds like a no-brainer. Cheating is cheating, right? But if someone didn’t actually pay for votes, and did a vote exchange or spammed forums and Facebook groups to get votes from people who don’t actually care about the program, is that cheating?

What if the Facebook account that’s participating is “real”, but the person only ever uses it for entering contests? Is that a legitimate user to you, or a cheater? You should figure that out ahead of time.

It’s going to be your choice as to what level of detail you disclose your policies on cheating. My recommendation is to be a little vague. While this goes against my standard policy of transparency in everything, if you give the bad guys an explicit set of rules on how you define cheating, they will be sure to tailor their cheating to specifically avoid the things you outline. If you tell me (as a bad guy) that my votes will be disqualified if too many votes come in from the same IP address, I will be sure to use different IP addresses for each vote to make sure I avoid your detection.

Rule #4: Audit, audit, audit and audit some more

Auditing by eyeball isn’t really going to cut it, but if it’s all you’ve got, it’s better than nothing. A better idea would be to set up a series of heuristics programmatically that flag user activity as being suspicious and requiring additional review. Things like the number of unique users coming from a specific IP address, the time of day that you see the most activity, the kinds of email addresses you see associated with the participating users, etc.

Look for patterns that don’t make sense. Examine the Facebook pages of the folks you suspect of cheating. Do they have any wall posts? Any photos? Do they have friends? Click on their friends profiles – do their profiles also have no wall posts and no photos? Look for generic “hot babe” profile photos. Look at the pages and topics the user has “liked”. Do they seem a little too demographically on-point, as if they were created to appeal to a specific contest demographic? Is there a pattern in the things they’re liking? (All contest pages, etc.) This part can’t be automated.

Give yourself the time between the end of the contest and the announcement of the winner to be thorough and audit all of your top contenders. Hold off notifying anyone that they won until you’ve had a chance to comb through this data and you feel confident that it’s legitimate.

You have a cheater. Now what?

When you find someone cheating, how are you going to handle it? Revoke their points/votes/etc? Disqualify them? Whatever your decision, know what you’re going to say to them in advance, because if the stakes are high enough, there’s a good chance they will be loud and public about how you wronged them. Once again I advise not showing too much of your hand.

If you decide to confront them and allow them to offer explanations, hold specifics back. If you user claims, for example, that they got most of their votes from their friends at a high school using their own computer (which would explain the same IP address), but the timestamps on the votes are at 1AM, 2AM, etc, that should raise some eyebrows. If you tell them too much about what you’re basing your decision on, a decent cheater will come up with excuses to explain them that they would have mentioned earlier if the story was legitimate.

It’s rare to find a smoking gun in these cases. Instead, it’s going to require a some judgement calls and a preponderance of evidence. It’s very like you won’t find *one* thing that makes you *sure* someone is cheating. Instead you’ll find a half-dozen things that, when combined, form an equation that just doesn’t add up.

One option, upon finding a cheater, is to disqualify just the votes that seem fraudulent. In the case of a contest where the user submits an entry and other people vote on it to determine a winner, be cautious of disqualifying the entry based on fraudulent activity. Knowing how inexpensive it is to buy Facebook profiles, if I were a particularly bad guy who had also submitted an entry, I might consider spending some money to game my opponent’s entry in a way that was obviously fraudulent to get their entry disqualified.

If I knew you would kick anyone out if you detected any fraudulent behavior on their entry, I might go out of my way to make sure you found some on the other guy’s entry to increase my chances of winning by kicking them out of the running. This technique, similar to joe jobbing in the spam world, isn’t one I’ve seen often, but it’s only a matter of time.

Make a decision and be prepared to stick with it. Feel confident that your decision was the right one, and don’t back down. The bad PR from the folks you disqualify will be better than the bad PR from the rest of the contestants claiming that your contest is rigged or allowed fraud. Your legal department will make sure you have a TOS that basically says that you don’t owe anyone an explanation, and it’s up to your discretion to disqualify anyone for any reason.

Running a (good) contest is an incredibly laborious process. The technical aspects of creating the app are honestly the least complicated, least time-consuming part of the whole thing. Make sure you have the appropriate resources to handle it. If you half-ass it, you will regret it.

Nailed it.

Not quite. Honestly, there is almost no fool-proof way of detecting all fraud activities – partly because some of this fraud is being conducted by actual people, not machines. They’ve invested the time into creating profiles that look real.

You’ll be able to find the ones that do a crap job of it, but a few of the more sophisticated folks will have profiles that have current wall posts about things other than contest spamming. They’ll have photos uploaded, lots of friends, and profiles that weren’t recently created. Fortunately for you, those kinds of profiles tend to be more expensive to buy, since they require more work to upkeep to look legitimate.

Maintaining believability in a friend network that large requires a lot of time, so examining the friend profiles associated with your top contestants is absolutely critical. If you poke around enough, you’re bound to find something that doesn’t fit. Examining their entire footprint on the social graph will give you a much clearer picture than a specific profile.

Also check out:

The site addresses the growing problem of employers monitoring and sometimes even dictating what is acceptable and unacceptable for their employees to say on the employee’s personal Twitter feed.

Naturally, this is also extended to Facebook, G+, etc – but the MTAMO abbreviation seemed most important to the Twitter crowd, since the bio space there is only 160 characters. Including MTAMO in your bio is a heck of a lot shorter than “My tweets are my own”, which is sort of why this site was created.

By changing the sub-domain of the site to your twitter handle, you can personalize the site with your own Twitter follow widget, Twitter picture, and share widget – and link to your personalized version to help other people understand that it’s simply not acceptable for employers to have that level of control over their employees personal lives.

OBVIOUSLY this excludes things like discussing projects for which the employee is under NDA or legally binding agreements. It’s meant more to address employers who wish to censor personal opinions, tone, etc.

Anyway – that’s all I have time for right now. Ramping up to launch phase two of a really cool project for Intel, so things are a little hectic. That said, I’d love to hear your thoughts on MTAMO in the comments after you’ve had a chance to check it out.

Also check out:

Note: this article is long, but that’s only because I’m trying to explain in some degree of detail, and call out specific gotchas that you may run into. I promise you that setting these two up is incredibly easy, and shouldn’t take you more than a twenty minutes or so to have both up and running.

Advanced Policy Firewall (APF) is an iptables based firewall system that’s easy to set up and administer, and works hand in hand with Brute Force Detection (BFD).

BFD is a modular shell script for parsing application logs and checking for authentication failures. It does this using a rules system where application specific options are stored including regular expressions for each unique auth format.

Together, they provide a simple but effective way to handle locking out brute force login attempts. Using APF, you could actually take it a step further and deny ALL SHH requests except those originating from a set of whitelisted IP addresses. This may not be feasible – or a good idea – if you do not have access to a static IP address, however, since you could end up locked out of your own box. We get into restricted whitelisting a little further down the page.

The basic gist is this: Someone tries to brute force their way into your server via SSH. Since they do not actually have a valid username+password combination, the login attempt will fail, assuming you don’t use shitty passwords that can be easily guessed, in which case they login successfully, and you’re pwned. After x failed attempts (where you define x in the configuration file), BFD will automagically tell APF to add the IP address of the offending attacker to the APF blacklist for a certain amount of time (also configurable in the config file). All services will be denied to that IP address, so they will no longer even be able to see your website.

The purpose of this is pretty obvious, but (for those of you who took the short bus in) one of the primary benefits is the ability to easily mitigate automated brute force attacks on your server, where a script is being used to try various combinations of usernames and passwords until they successfully login.

If you think your server is too insignificant for an attacker to bother with, you’re wrong. If you have an IP address that is visible to the rest of the world, you will end up being brute-forced at some point. Whether or not the attack is successful is up to you.

There are other firewall+brute-force-detection combinations out there, including the very popular Fail2ban, that also work very well. I’m not endorsing one over the other, I’m just more familiar with APF+BFD.

Anyway – let’s get to the good stuff. Note that you will need root/sudo access to your server in order to continue.

Setting Up Advanced Policy Firewall (APF)

Before moving forward, it should be noted that you are installing an iptables-based firewall. This means that if you screw something up, you could lock yourself out of the server, deny all traffic to your server resulting in a downed website, etc. Be careful, and don’t make these kinds of configurations on a production machine during peak site traffic hours. To test that your configuration is working properly, you’ll want to have access to SSH from another IP address that you can safely lock out without limiting your ability to administer the server.

1. [root@server]# cd /root/downloads (or any other temporary folder)
2. [root@server]# wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz
3. [root@server]# tar -xvzf apf-current.tar.gz
4. [root@server]# cd apf-9.7-1 (or whatever the latest version is)
5. Run the install file: [root@server]# ./install.sh
6. You will receive a message saying it has been installed.
   Installing APF 9.7-1: Completed.

Installation Details:
Install path: /etc/apf/
Config path: /etc/apf/conf.apf
Executable path: /usr/local/sbin/apf
DShield Client Parser: /etc/apf/extras/dshield/

Now configure the firewall: [root@server]# vi /etc/apf/conf.apf

Make sure DEVEL_MODE="1" is set until you’ve gotten everything working. This will allow you to get back into your server if you cock something up and get locked out, as it tells the script to clear the cron settings every 5 minutes. Once you’ve got APF tested and working as expected, set DEVEL_MODE="0" here.

The majority of the default options in the config can (and should) be left alone unless you know what you’re doing. As you go further into the config file, you’ll see stuff like this:

##
# [Remote Rule Imports]
##
# Project Honey Pot is the first and only distributed system for identifying
# spammers and the spambots they use to scrape addresses from your website.
# This aggregate list combines Harvesters, Spammers and SMTP Dictionary attacks
# from the PHP IP Data at: http://www.projecthoneypot.org/list_of_ips.php
DLIST_PHP="0"

DLIST_DSHIELD_URL="feeds.dshield.org/top10-2.txt"
DLIST_DSHIELD_URL_PROT="http"

All of the above are optional and allow you to implement additional resources such as DShield and Spamhaus to block known spammy or suspicious IPs from being able to access your server. You can leave them off if you’d like (they are off by default) or turn them on for additional protection. (You’ll need to install the DShield scripts, but I’ll get to that in a moment.)

Configuring Ports:

The APF config file will come with some default ports pre-set, but you’ll want to check and make sure everything you need is covered. You will also want to determine whether or not you’re using any uncommon port numbers (for example, for a hosting control panel) that should be added to the configuration file. Please don’t ask me what port numbers your specific hosting control panel uses. I don’t know, but I’m sure Google does.

# Common inbound (ingress) TCP ports
#IG_TCP_CPORTS="22,80,443"
IG_TCP_CPORTS="21,22,25,53,80,443,110,143"

# Common outbound (egress) UDP ports
EG_UDP_CPORTS="20,21,53"

If you restart the firewall and something is down but no errors are thrown, there’s a good chance you missed a port number here. Make sure to account for SSL ports (443) if you’re running an SSL certificate, etc.

Once you’ve made all of your tweaks, save the config file and start the firewall:
/usr/local/sbin/apf -s

If you’re satisfied that everything looks okay and all services are responding as they should, go back into the APF config and change DEVEL_MODE="1" to DEVEL_MODE="0" and flush the firewall: /usr/local/sbin/apf -f

Common APF Commands

Start: /usr/local/sbin/apf -s
Restart (flush and load): /usr/local/sbin/apf -r
Flush: /usr/local/sbin/apf -f
List Chain Rules: /usr/local/sbin/apf -l
Status: /usr/local/sbin/apf -st

Manually Whitelisting/Blacklisting IP Addresses

For the commands below, replace HOST with an IP or FQDN (Fully Qualified Domain Name) and COMMENT with your comments (no spaces) as to why you’re manually allowing or blocking an IP.

Add to allowed hosts (whitelist) and load new rule: /usr/local/sbin/apf -a HOST COMMENT
Add to denied hosts (blacklist) and load new rule: /usr/local/sbin/apf -d HOST COMMENT

To autostart apf on reboot, run this:
[root@server]# chkconfig --level 2345 apf on

To remove it from autostart, run this:
[root@server]# chkconfig --del apf

Using DShield

If you’re interested in using DShield with APF, you will need to install it first from the extras directory:

[root@server]# cd /etc/apf/extras/dshield
[root@server dshield]# ./install
Installation completed.
Binary: /usr/local/sbin/dshield
Config: /usr/local/dshield/dshieldpy.conf
Cronjob: /etc/cron.daily/ds

Warning: Running the binary from command line will send reports to dshield.org;
repeated execution may result in your IP being banned from the service.

Now you can edit the DShield configuration file, including turning on email alerts, database logging and other stuff. Again, leave this alone (or leave it uninstalled) if you’re not sure what you’re doing. Your APF will function just fine without it:
[root@server]# vi /usr/local/dshield/dshieldpy.conf

Setting Up Brute Force Detection (BFD)

First things first, you MUST have APF installed. BFD was written specifically to work with APF, so you have to start with APF and then install BFD.

1. [root@server]# cd /root/downloads (or any other temporary folder)
2. [root@server]# wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz
3. tar -xvzf bfd-current.tar.gz
4. [root@server]# cd bfd-1.4 (or whatever the current version is)
5. Run the install file: [root@server]# ./install.sh
6. You will receive a message saying it has been installed
   .: BFD installed
Install path: /usr/local/bfd
Config path: /usr/local/bfd/conf.bfd
Executable path: /usr/local/sbin/bfd

Now let’s take a look at the configuration file:
[root@server]# vi /usr/local/bfd/conf.bfd

What you’ll see is a short file that starts like this:

# how many failure events must an address have before being blocked?
# you can override this on a per rule basis in /usr/local/bfd/rules/
TRIG="10"

# executable command to block attacking hosts
BAN_COMMAND="/etc/apf/apf -d $ATTACK_HOST {bfd.$MOD}"


These options are pretty straightforward. TRIG is the number of tries a user is allowed before they trip the BFD deny trigger. For PCI compliance or other strict environments, this number is usually pretty low – but it’s important to keep things practical. Security must always be a balance between making things safe and keeping them useable by the people who need to use them. If you had a lockout policy that after one try, a user is locked out for a day, odds are excellent that you’d be crippling your admins/devs. Who hasn’t fatfingered a password? These measures should be as unobtrusive to the users who legitimately need to be there as possible.

The very concept of a brute force password attack is one where the attacker doesn’t have either a valid username, a valid password or both. The odds of an attacker randomly guessing a username and password combination within 10 tries, or 20 tries, or even 100 tries is pretty low. Brute force attacks generally exploit things like default admin passwords, very common passwords (like ’123456′ or ‘password’ or ‘fuckyou’), or they are a more prolonged attack consisting of thousands and thousands of random login attempts. The attacker is literally trying to brute force their way in, since they have no other means by which to access your server that way.

Making the tolerance threshold very low doesn’t keep you safer from a brute force attack and will only serve to frustrate your users and create more work for yourself, since you’ll have to manually release the lock once they’ve boned their password a few times. So keep this number reasonable, and remember what it’s there for, or you’ll be making yourself and everyone who needs to access your server miserable.

Enable Email Alerts

You may or may not want to be alerted when someone has tripped the brute force detection script and has been added to the APF deny rules. If you’re on a frequently hit server, these emails could be overwhelming (or could even arguably help create a denial of service situation) but in general, I find it helpful to leave these on. I have filters set up in my email so they don’t flood my inbox. If you’re using a log analyzer/alert system like Splunk, you probably don’t need to turn on email alerts, but that’s up to you.

Find: ALERT_USR="0" CHANGE TO: ALERT_USR="1"
Find: EMAIL_USR="root" CHANGE TO: EMAIL_USR="your@yourdomain.com"

VERY IMPORTANT! Prevent locking yourself out!

You will want to make sure you’ve whitelisted your own trusted IP addresses pretty early on in this process. If your office has a static IP address or range of IP addresses, you’ll want to add these right away. By whitelisting these IPs, you prevent the possibility of locking yourself out of your own server by fatfingering your own password.

To add IPs to the ignored host list:

[root@server]# vi /usr/local/bfd/ignore.hosts

… and add your own trusted IPs, one per line.

Once you’ve got BFD configured to your liking, start it up!
[root@server]# /usr/local/sbin/bfd -s

Test the System

Once you think you’ve got everything working, try logging in from a non-whitelisted IP. If you have another server with it’s own IP address, for example, you could SSH into that server, and from that server SSH into your now-hardened server, using a username and password combination that you know is not valid.

While doing that, tail the APF logs, so make sure the attempts are being logged and the lockout works as expected:

[root@server]# tail -f /var/log/apf_log

Once you pass the number of attempts specified in the BFD config file, you should see the apf_log record that the offending IP address has been added to the denied hosts file.

Allowing Only Whitelisted IPs to Access SSH

If you’ve got static IP addresses and you want to lock your server down even more, you can skip BFD and simply deny ALL SSH requests coming from unknown IP addresses. This is easy to do, but also easy to forget additional IPs that legitimately require access (remote backup systems, managed hosting company support, etc) so be sure to think through everything that legitimate needs access, and be prepared to tweak the IP list if you discover things you broke.

1. Open the allowed hosts file: [root@server]# vi /etc/apf/allow_hosts.rules
2. Scroll down until after the last comment in the file with the ##
3. Add the following:
   tcp:in:d=22:s=YOURHOMEIPHERE
out:d=22:d=YOURHOMEIPHERE

   The d=22 is the port, since you’re specifically addressing SSH which usually runs on port 22. You can repeat for other services as well to limit other connections by port if you like.

4. Open the denied hosts file: [root@server]# vi /etc/apf/deny_hosts.rules
5. Scroll down until the last default comment ## then below it add the following:

   tcp:in:d=22:s=0/0
   out:d=22:d=0/0

6. Restart APF: [root@server]# /usr/local/sbin/apf -r

You wouldn’t use IP whitelisting restrictions in combination with BFD, since the process of whitelisting your internal IPs will override the BFD protection. In other words, with whitelisting restrictions, any user who isn’t on an authorized IP address won’t even be

Test the System

Testing this one should be pretty easy. Simply try to connect via SSH from any IP address that isn’t one that you whitelisted in step 3 above. What you should see is a connection attempt timeout or connection refusal. Try a new SSH connection from a whitelisted IP and you should get the SSH password prompt.

Two-Factor Authentication

If you really want to lock things down, you may want to consider adding two-factor authentication to your login. SSH keys would be something you have – plus a password as something you know – but for some reason it’s still not possible to require a password with SSH keys (to my knowledge – please correct me if I’m wrong). So instead of two-factor, you end up with a different one-factor (something you have instead of something you know).

Years ago, setting yourself up with true two-factor authentication was prohibitively expensive, so not a lot of smaller folks were doing it. These days, Citrix key fobs are being replaced by a new generation of more affordable and practical tokenless two-factor authentication systems, such as PhoneFactor and DuoSecurity.

Both of these options are pretty cool, and reasonably easy to implement. I’m in the process of setting up a few of our boxes with DuoSecurity (can’t beat the price), with the help of this fantastic tutorial by Jeremy L. Gaddis over at EvilRouters.

Also check out:

Traditionally, these attacks were targeted towards computers running Windows, which was painfully obvious when you visited one of these sites on a Mac, since you would see a Windows Explorer interface in the web browser, instead of Finder.

It was only a matter of time before attackers would expand this technique to include Mac users, especially as Apple continues to gain market share in the personal computer market. We’ve already started seeing more Mac virus proof of concepts, and many Mac users are under the mistaken impression that Macs are more secure than their windows counterpart. Up until fairly recently, it could be argued that Mac users were less at-risk, but Macs have never been more secure. Mac users were less at-risk simply because there were fewer of them. Bad guys tend to be opportunists, and they knew they’d get more bang for their buck by targeting Windows users.

This has arguably resulted in many less-savvy Mac users being given a false sense of security, when the reality is just that there weren’t enough Mac users for most malware authors to bother with. (Notice I said “most”.) As Macs have become more popular, they’re becoming a more financially viable target.

What we’re seeing now are much more sophisticated attacks, where malicious websites deliver content depending on what OS the target is using while on their page.

I recently stumbled across an infected website that displayed a fake anti-virus “scanner” that informed me that my computer was infected and prompted me to download a zip file called anti-malware.zip. You can see the screencast below:

This is a screenshot of the rogue antivirus page:

As you can see, the layout of the infected page is tailored to a Mac, showing what is meant to look like a Finder interface. A fake alert window pops up with the text:

Apple security alert: To help protect your computer, Apple Web Security have detected Trojans and ready to remove them. Spyware is a type of malware that can be installed on computers, and which collects small pieces of information about users without their knowledge.

When a Windows user visits this same infected page, they see a completely different page, tailored to Windows users, displaying a fake Windows Explorer interface:

(Windows screenshot courtesy of Satnam Narang.)

Important to note: According to VirusTotal, the detection of the windows executable version of trojan (named BestAntivirus2011.exe) is very low, which means very few legitimate antivirus programs will currently detect it as malware – only 2 out of 42. At least some email scanners are detecting the Mac version though, as Rackspace rejected my attempt to email it to VirusTotal for scanning and returned it undelivered, stating that a virus had been detected. VirusTotal indicates that 7 out of 42 antivirus programs will detect the Mac version, named MacProtector.mpkg.

If you’re wondering how I came across this page in the first place, I wasn’t researching Mac antivirus – I was googling on the terms “Anime Bleach hollow logo”, looking for a t-shirt with a Hollow skull logo on it from the anime series Bleach. The fourth result on Google displayed a page on a .nl domain, belonging to the Village Council of Molenhoek, Netherlands. (I don’t speak Dutch, so I didn’t realize that right away of course.)

When I clicked on the link, a javascript redirect brought me to a new page hosted on an IP address belonging to Atjeu LLC Website Hosting. With javascript turned off, the source of the page on the Molenhoek website contained the following redirect code:

As you can see, the javascript redirects me to the domain tmfpuion.ce.ms, which has a Romanian IP address. If I access the redirect cgi url directly, I am returned a 404 error coming from UK-owned wolandtraffic.com/default.cgi. The script is checking the referrer header and only forwards the user onto the malware download page if they are coming from Google.

Based on the fact that the Molenhoek website does appear to be a legitimate website, my guess is that the attackers exploited a vulnerability on their website in order to inject the malicious redirect.

The source code of the actual fake antivirus page was a combination of base64 encoded images, javascript and CSS:

Although the increase in Mac-targeted malware isn’t new and some of you may have already encountered this attack in the wild, there have been a few versions of this one going around, called MacDefender, MacSecurity and MacProtector.

Update: Sophos has also posted an update about this issue, specifically with respect to how attackers are using blackhat SEO to poison search engine results on Mother’s Day themed searches.)

Seems most of the bad sub-domains are coming from ce.ms, and some users are reporting particularly high occurrences in Google image search results, according to Brian Krebs.

The social engineering aspect of this kind of attack is the critical piece to understand, as the bad guys are banking on your fear of viruses and malware to trick you into downloading viruses and malware. So as always, never download anything from an untrusted source, regardless of how convincing the page seems to be. If you’re interested in legitimate virus software, stick with well-known names such as Sophos or Kaspersky, but also bear in mind that antivirus is no substitute for common sense, and just because you’re running antivirus software (or you’re on a Mac) doesn’t mean you’re safe.

Also check out:

So the user gets a notification “John Smith has made you an administrator of XYZ page”. The user clicks on the page to see what they’ve just been made an admin of, and the poisoned default page tab kicks on, busting them out of the Facebook site and into a standalone page offering promises of free iPads and various other too-good-to-be-true freebies.

In this particular case, the scammers were using the extremely popular – and from what I can tell, legitimate – application Static HTML IFRAME, which simply allows people to create their own IFRAME tabs to add to their Facebook page without the hassle of creating their own application, hosting content, etc.

The IFRAME page that loads in the Facebook page points to s3.amazonaws.com/statichtmlplus/page/160281910702810.html – so it seems that the Static HTML IFRAME app just saves the content that their users add to their custom IFRAMEs into a static HTML file and serve it accordingly.

In the case of this scam, the IFRAME page hosted by the Static HTML IFRAME app contains another, hidden IFRAME inside of it that forces the browser to redirect to the scam website.

This is a combination of social engineering (taking advantage of the fact that the new administrator will obviously want to know what it is they’ve been made an admin of, thus getting them to look at a page they would otherwise never have found or cared about), and very basic technical jiggery pokery to bust out of the frames and take the unsuspecting admin to a third-party site.

The third party site in this case was a survey/iPad 2 giveaway scam (ipad2-test-and-keep.com), but this method could just as easily be used to serve malware or phishing pages.

Imagine how easily this would flow if if the frame-buster page instead took the user to a page that looks just like the Facebook login page. They think they’ve somehow been logged out, they fill in the login form to log back in, and now the bad guys have their Facebook credentials – which statistically are likely to be the same credentials they use for banking and other things.

The IP address of the scam site the IFRAME sends the user to, 92.241.169.80, tracks back to a Russian web hosting company, 2×4.ru.

We’ve already reported this scam page to Facebook using the normal routes and through the Preferred Developer Consultant avenues, but I’d be willing to bet we’re going to start to see a lot more of this kind of thing because it’s incredibly effective and very simple to execute.

Thanks to @uberbrady for seeing this for what it was when it happened to him, and bringing it to our attention.

Don’t forget to “like” our special Social Media Scam Alert page on Facebook and follow @scamdb on Twitter for more updates like this.

Also check out:

We’re finally at a point where someone who spends a reasonable amount of time at a server command line can actually get real work done, and I gotta say, it’s pretty cool. Just last night I was discussing an obscure Apache config issue with a friend at a bar, and rather than working from memory, I busted out the iPad and my Bluetooth keyboard, and 5 minutes later, the configuration issue was solved.

Having the freedom to go to the park to read for a bit but knowing I have the ability to handle an emergency should it come up is very freeing. Yes, I have become that douchebag at Starbucks – and you know what? I fucking love it.

Anyway. Point is, the iPad (or iPhone) can be used for more than just porn now (which is good, because the folks at Starbucks get surprisingly upset when you try adding your own “cream” to your latte), and I’ve spent some time and money to try out some of the most promising apps in the app store that allow you to do actual work, and edge the iPad closer to being a viable option for a netbook replacement.

I didn’t address any design/mockup/mindmapping apps in this list, but that may be a topic for another post sometime. This list isn’t meant to be all-inclusive, and doesn’t reflect the totality of what is available in the app store – it’s a short list of personal recommendations of products I actually use and like.

Disclosure: Some of the links below are hooked into the iTunes affiliate program so that I might get a penny or two if you decide to buy, however the recommendations are legit, and I wouldn’t recommend something unless I had used it. Click through on the affiliate links or don’t – but do leave me a comment if you’ve fallen in love with something I haven’t mentioned here.

Code Editors/FTP

There are quite a few nice code editors for iPad in the app store, but I won’t consider any that only offer FTP instead of SFTP and neither should you. I am just as likely to use vi in an SSH app on my iPad as I am to use a code editor, but for handling multiple open files at one time, sometimes an editor is kinda nice. Unfortunately, 90% of the code editors in the app store are complete and utterly shit-tastic garbage. Seriously. Even if you don’t pick one of my recommendations, make sure you read the comments on the code editor apps before you buy so you don’t get burned.

Textastic

I think Textastic might be my new favorite code editor for iPad. The interface is very clean, it supports FTP and SFTP, integrates with Dropbox and WebDav (if you’re into that sort of thing) and comes with syntax highlighting for around 80 different languages. It’s a little pricier than some of the other options, but I think it’s well worth the investment. I want to make sweet ASCII love to it all the time.
In iTunes: Buy Now ($9.99)
Developer: Alexander Blach

Gusto

Gusto is pretty sexy and has come pretty far in a short time. (When it first appeared in the app store, there was no SFTP support.) It supports projects, one-touch uploading, background processing so your state doesn’t get lost when you have to switch apps, pretty Coda-like site thumbnails, tabbed editing, and remove and local preview support. Three obvious features that are missing are syntax highlighting, line-wrapping and public-key authentication, but it’s a great start and a solid option for busting out quick changes on the road.
In iTunes: Buy Now ($6.99)
Developer: Horse and the Rook

An alternative to Gusto that’s an app to watch would be Markup for iPad, but I’ve heard such crap things (crashy, no SFTP) about it that I haven’t tried it. Sounds like it’s worth keeping an eye on, but not ready for prime time yet and not worth the $10 pricetag until it’s a bit more stable and can handle SFTP.

FTP on the Go (Pro)

Feature-packed FTPS app. Honestly, too many spiffy features to list – the best FTP app I’ve come across so far. Comes with a built in FTP Server and Web Server allow viewing and adding files to the iPhone or iPod touch. Browse files on your iPhone from your computer with a web browser. Madness. Madness, I say!
In iTunes: Buy Now ($9.99)
Developer: Headlight Software

MySQL

MySQL Database Client

Small, simple MySQL client for iPad and iPhone. Supports stored profiles and custom queries, but don’t go too nuts. It can handle basic queries, but more complicated stuff like JOINS will return unpredictable results. Still, it’s $0.99, and is worth at least that much, contrary to the cheesedick who “wants a refund” in the reviews. Seriously. It’s a buck. Get over it, kid.
In iTunes: Buy it Now ($0.99)
Developer: Kyle Hankinson

MySQL Editor Pro

A much more full-featured app with a price tag that reflects it, MySQL Editor Pro is the real deal. If the cost doesn’t scare you off, this is well worth the month for such a strong db admin app.
In iTunes: Buy it Now ($14.99)
Developer: Pasha Topchiyev

SSH/VNC

Prompt

That Apache configuration issue I was having? Solved in 5 minutes using Prompt. It’s made by the same folks that make the super-sexy Coda code editing app for Mac. The UI is pretty nice, and it supports special characters and keystrokes like CTRL which one ends up using frequently in a shell. Prompt supports DSA/RSA keys, automagically remembers your frequently used commands, runs in the background so screen-switching won’t disconnect you, and you can map commonly used keystrokes easily for speedy access. An added bonus – it’s a universal app, so you buy it once and it works on your iPhone and your iPad. (Given my horrible typing on the iPhone and the iPhones even more horrible auto-correction, I don’t know that I’d want to use it on my phone much, but it’s nice to know it’s an option.
In iTunes: Buy it Now ($4.99)
Developer: Panic, Inc.

iSSH

Less sexy than Prompt but still one helluvan app is iSSH. iSSH boasts a pretty impressive feature set, including a tunneled VNC client, tunneled X server, the fact that SSH, telnet and VNC all work via EDGE, WiFi and 3G, transparent keyboard, Bluetooth keyboard mapping, RSA and DSA key generation and exchange, tons of keyboard customizations and holy shit a lot more. It’s a solid client, and a universal app, so you can buy it once and use it on your iPhone, iPad, iPod touch, etc. Even works with older iPhones running iOS 3.0.
In iTunes: Buy it Now ($9.99)
Developer: Zingersoft

Network Tools & Miscellaneous Hackery

IT Tools

Puts a whole handful of diagnostics just a tap or two away, with DNS, Ping, Route, ARP, active sockets and Interface tools. 45 supported DNS record types, including A, AAAA, CNAME, LOC, MX, NS, SRV, TXT – and it come with a database of MAC addresses so you can look up manufacturers of devices on your network. All of these things can be done through SSH if you’ve already got a terminal running, but this app makes it so much easier.
In iTunes: Buy it Now ($4.99)
Developer: Kevin Koltzau

Server Admin Remote (Mac OSX Server)

Called a Swiss army-knife for the mobile Mac OS X admin, with Server Admin Remote IT administrators can monitor the alive status of Mac OS X Server services, start/stop services and observe the services’ logs (Mac OS X Snow Leopard, Mac OS X Leopard Server and Mac OS X Tiger Server). Works on EDGE, WiFi and 3G connections. No further installation on your Mac OS X Server needed, since Server Admin Remote uses the same interface as Mac OS X Server Admin.
In iTunes: Buy it Now ($11.99)
Developer: Harlekins

Rackspace Cloud

If you’ve got a Rackspace Cloud Servers account, this app is the shit. Reboot, rename, resize, and rebuild your Cloud Servers, spin up a new server or delete an existing one, change your root password, bootstrap Cloud Servers with Chef from your Chef server or the Opscode Platform, open and manage Cloud Files assets and control your CDN settings for Cloud Files containers, play Cloud Files audio and video over Airplay to your Apple TV (iOS 4.3 and up) – a ton more. It’s not a complete replacement for their control panel, but you can do a heck of a lot with it.
In iTunes: Download Now (FREE)
Developer: Rackspace

Vtrace

Simple visual traceroute (or TracerT, if you’re this kid) that uses your current location to take you down the bunny trail to whatever IP or hostname you’re looking up.
In iTunes: Download Now (FREE)
Developer: Vlad Alexa

iAccess for Nagios

Mobile Nagios client that gives you direct access to the /nagios dashboard. (Obviously, you need a Nagios server configured for this to work.)
In iTunes: Buy Now ($3.99)
Developer: ASION IT Services

Flame for Bonjour

Flame is a browser for Bonjour network services. It lists the services advertised on your wireless network and you can browse them by server or by service type. When selecting a service, its advertised details are displayed. If an application on your iPhone or iPod touch can handle any of the advertised services, a command to open it right away is provided.
In iTunes: Download Now (FREE)
Developer: Tom Insam

Ping A Majig

Handy app that lets you check the ping status of multiple hostnames at one time. It’s a bit handier as a monitoring tool than the other apps that include ping as an available tool, since the at-a-glance view lets you see if any of your hosts are in trouble on one screen.
In iTunes: Buy Now ($0.99)
Developer: Pingysoft

RBL Status

Simple but effective Real Time Blacklist looker-upper.
In iTunes: Buy Now ($1.99)
Developer: Pavel Ahafonau

iPortscan Pro

iPortScan PRO is a port scanner for your IPhone or IPodTouch. It does not feature any network discovery; however, this tool is useful for sysadmins checking what services are listening on a known system. This is very handy for the system admin who can use this tool to quickly portscan all of their systems to make sure nothing is open that shouldn’t be.
In iTunes: Buy Now ($1.99)
Developer: Whiteside Solutions LLC

Default Logins

This app contains a database of over 300 common and uncommon manufactures and the usernames and passwords they pre-configure their devices with (which there are 1,000 + in the database). Can come in handy for more nefarious reasons (if you’re that kinda person), but also super useful for fixing a relative’s biffed router when they ask you to come over and fix their internets.
In iTunes: Buy Now ($1.99)
Developer: anthony lamantia

So that’s my list – for now. Did I miss any that you love? Leave me a note in the comments.

PS – yes, that’s a photo of my actual license plate at the top of the post. And yes, that makes me more awesome than you.

Also check out:

On Facebook, “like” the Social Media Scam Alerts page to get updates as new Facebook scams and rogue applications are identified. The posts will be short, without a lot of technical jargon to make them easy to share with your less brainy friends and family.

On Twitter, follow @scamdb for tweets about the latest scams, phishing and rogue apps affecting Twitter users.

Social Media Security Tips

In addition to staying informed about bad applications, some better practices and common sense will go a long way here.

We have become completely desensitized to clicking on things in websites, our social networks, on our smartphones and in email – and this is why these types of attacks are so wildly successful, often garnering tends of thousands of “likes” before they are detected and banned by Facebook or Twitter. More often than not on social media websites, the attack is not a technical attack, it’s a social engineering attack, tricking you into clicking on something because what they are offering is something you want and you found the link through a reasonably trusted source (your friends twitter stream or Facebook news feed.)

Be skeptical. If something looks too good to be true, it probably is, even if you trust the person it came from.

Confirm before you click. If you’re not sure, take a moment to email or (gasp!) call your friend and confirm they actually intentionally posted that message. If they didn’t, you’ll be doing them (and all of *their* friends) a favor by bringing it to their attention quickly.

If your friend posted to their Facebook wall that they are stuck in London and need money for passport/plan home/etc – resist the urge to immediately send cash. Be rational, contact them using a different method (email, phone) and confirm that it’s really them. Use common sense. Did your friend even mention they were going to London?

That “stuck in London” scam has made its rounds for several years through email and social networks. I don’t know why it seems to always be London, but that’s almost always the city I’ve seen in these scams.

Use the SSL version of social networking websites when you’re surfing on public or unsecured wifi. As Ashton Kutcher learned this week at TED, non-encrypted sessions + a little Firefox addon called Firesheep = getting pwned in front of your six-and-a-half-million Twitter followers.

Facebook offers a clunky (and currently unreliable) way to switch to HTTPS for your Facebook sessions, but that method resets back to HTTP if you access a non-SSL application. My understanding is that Facebook security is aware of the bug that resets the default preference back to non-SSL, but I don’t think it’s been fixed yet.

An alternative is using something like the Electronic Frontier Foundation’s HTTPS Everywhere addon. The first release of this addon was a little buggy, but the second release seems more stable. (The first version rendered Amazon.Com effectively useless.) You can select which sites you want to use HTTPS Everywhere on, and it will always force the HTTPS (versus the plain HTTP) connection.

Ideally, you should try to avoid public or unsecured wifi connections whenever possible. Make sure your computer and smartphone preferences are to NOT automatically join wifi networks. If you have to be on public wifi, your best bet will be to tunnel your traffic over VPN, but not everyone is going to have that as an option.

In the big, scary internet, there are countless ways your personal information and login credential are at risk. Some of these are technical vulnerabilities in the websites you trust your information to, but the social engineering approach is gaining tremendous momentum. It’s cheap, it’s fast, and it works. Remember that even if you think you have nothing of value, when you are careless with your security, you are also putting your friends and family at risk.

Take a moment to check out the security presentation I posted a few weeks back that covers important information on privacy and password security, and consider joining the new Facebook and Twitter resources.

Also check out:

According to the blog entry, this feature would be opt-in, and canvas application developers would need to provide an SSL url for the “Secure Canvas URL”.

If a user who has opted into the SSL-only version of Facebook attempts to access a Facebook Application that doesn’t have a Secure Canvas URL set, the user will evidently be shown a message (which will likely be confusing and scary, not because Facebook will purposefully make it so, but because most users don’t really understand SSL) that will give them the option to switch from HTTPS to HTTP. From the post:

If you do not provide a secure Canvas URL, we will display a confirmation page to let HTTPS users switch to HTTP and continue to your app.

This currently affects CANVAS apps only – not application tabs – although that may very well change once Facebook pushes the IFRAME version of tabs out some time in Q1.

HTTPS is slower and more server intense than HTTP, and it’s one more cost/timeline issue that has to be factored in. For some clients, I set up the hosting environment (which would include DNS, SSL, etc) – for others, their IT department provisions web space and handles DNS, and they often require a mountain of paperwork and a week to process.

For the latter scenario, the cost of the certificate is negligible, but for a highly-trafficked app, the increase in server load could have serious financial impact. It could mean the difference between needing one server and several.

For smaller companies, stepping up to SSL would mean buying a certificate and potentially paying extra for the dedicated IP address it will need, and if the app takes off, a much heftier hosting bill for running everything over SSL.

If the above would actually, truly improve the safety of the users in some significant way, I’d probably still be on-board.

Security is something I take very seriously, and in 2010, Firesheep showed the world how easy it was to hijack a user’s Facebook session and essentially pwn their account because the session data was being transmitted unencrypted and was sniffable over public wifi. To be fair, it wasn’t just Facebook that was affected, but if you’re logging into websites on an unencrypted public wifi, odds are your email accounts and everything else are at risk too.

That said, this seems like it will give naive users a false sense of security and not actually provide that much value for the effort involved by the app developers.

“Oh, this application must be safe – I’m using HTTPS, and the S stands for *secure*!”

Phishing, rogue apps and malware are already horrendous problems on social media websites, Facebook especially. I would much rather see Facebook (and others) improve their session handling before going in this direction. Reputable companies who are collecting any kind of PII are already running data submission over HTTPS, and non-reputable companies aren’t going to become more honest just by forcing them to encrypt the data they’re mining from your profile.

The net result is a lot of extra work for developers and companies for not a lot of benefit to not a lot of users, with the side effect of confusing people into thinking that SSL = trustworthy, or that a non-SSL app is malicious and trying to eat their souls.

IMHO, the much bigger threat to Facebook users is their own poor judgment on what to click on. Social engineering rules social networks, and no amount of encryption is going to fix that. As the fabulous shirt from Jinx says “there is no patch for human stupidity”.

Until people start being more critical of what they’re clicking on and what apps they’re allowing access to their profile, they’ve got a lot more to worry about than SSL. It’s the same false sense of security that users running antivirus programs often suffer from.

“I don’t need to worry about what I click on – I’m running antivirus! My virus definitions are up to date, so I am safe and protected and nothing can harm me.”

In 2008, Symantec had to write new virus signatures every 20 seconds to keep up with the onslaught of malware that was released. This was increased to every 8 seconds by 2009. [Source: Gray Hat Hacking The Ethical Hackers Handbook, 3rd Edition]

To prove my point, I’ve created FB Profile Spy. It’s still a work in progress, but it’s a better-security-through-humiliation project, similar to my better-behavior-through-humiliation project socialmediadouchebag.net. It’s completely safe – and not even hooked up to the Facebook API at all (but of course please feel free to use NoScript and check it out thoroughly before interacting with the links. I have nothing to hide.) Click through and “allow” the “app”. I need to tighten up the javascript slideshow lecture at the end and I need to sync up the layout with the new profile design, but it’s coming along.

What do you think? Am I just being a whine-ass lazy developer? Am I being a slacker security pundit? Let me know in the comments.

NOTE: This article first appeared on FBMHell.Com.

Also check out:

I will warn you that a few slides are not appropriate for all corporate environments – or any corporate environments, really. But you’re welcome to use the bits that may be helpful to you.

My company is small, so I omitted the scenarios that are really more appropriate for large companies with IT departments they do not know personally. My office is open (everyone can see each other), so someone calling and claiming to be from IT would stand out as someone who is full of shit pretty quickly.

This isn’t meant to be all-encompassing, and the audience is not meant to be a technical one. It seemed to go over well though, and enough people laughed that I think it kept their attention. More importantly perhaps, more than half of them left looking a little alarmed, which was really the whole point. Also note that the slides don’t reflect the entire content of the presentations, since I would be a shitty speaker if I were just reading from slides.

PDF Download | Keynote Download | Zipped Images Download

If the topic of social engineering is of interest to you and you’d like to learn more, I strongly recommend picking up the following books – they are outstanding and worth every penny (and then some):

• The Art of Deception: Controlling the Human Element of Security [paperback] [kindle]
  by Kevin Mitnick
• Social Engineering: The Art of Human Hacking [paperback] [kindle]
  by Christopher Hadnagy

Both of these books are really exceptional, and even if you’re not in the information security field, they’re damned interesting to read. Some of the case studies in this presentation were taken directly from these books, as both have extensive detailed examples that may be more suitable for the type of company you work for.

Be sure to check out Chris’ social engineering podcast as well, and check out the episode where I was a guest.

Also check out:

I hate everything about them, from the name to what they actually are.

This post started from a discussion that popped up after I casually lamented the fact that the word “blog” actually caught on. It’s a stupid word, and I feel stupid every time I have to say it out loud. Writing it is only slightly better, and I still feel dirty.

“Blog” used to mean something, even though it was a stupid word. Now news websites have “blogs” that post… well… news. They’ve managed to completely blur the line, as if some douchenozzle in marketing said “ZOMG Blogs! We have to have blogs! Some internet marketing expert guy said blogs were the future and we don’t have any and I don’t know what they are but we need them NOW.” Opinion blogs on news sites I get. News blogs on news sites, not so much.

The only thing worse than “blog” is “vlog”.

But the word completely aside, I hate “vlogging” because it’s fucking lame. I can’t cmd+f to find the actual content I’m looking for, I can’t skim the page to find only the bits I need, I can’t copy+paste the bits I need into my notes, and I’m forced to look at your ugly fucking face rambling on and on, taking 6 minutes to tell me something I could have read in 20 seconds.

Sure, it’s easier to create a “vlog” entry than to actually write and spellcheck, and people will be more willing to forgive your fourth-grade grammar if you’re speaking instead of writing. But unless you provide a text transcription of your “vlog” to accompany the video I will never watch, I will never hear what you have to say. If you do provide a text transcription, then you’re just a narcissistic douche, instead of an inconsiderate narcissistic douche, which is arguably much better on the douche scale.

My time is precious, and I’m not going to waste it watching you babble while feeling like people care who you are because you’re on video. I care about who people are because of what they say and what they think, and if you make me sit through your “vlog”, I will never find out what you have to say because my browser is closing before your pre-roll has finished loading.

I don’t give a shit about your personal brand, or putting a face to the name, or anything you apparently think I care about. I care about what you have to say, and even then, not enough to work that hard at finding out what that is if you make it difficult for me.

The only videos I care about are ones with adorable cats and/or guys getting nailed in the junk. Preferably both. If your idea of contributing to the internet is switching on your webcam and talking at me for 5 minutes, I hate you.

There. I think I’m done.

You have no idea how tempted I was to make this a “vlog” post. But then I’d have to put makeup on. And pants. And I’m on vacation this week, so fuck you.

Also check out: