Thursday, December 4, 2008

Linux And Unix Internet User And Site Security - How Much Is Too Much?

Hey there,

Today's post is going to be about security on Linux and Unix, since we're building up to doing some work with CAPTCHA in the near future and need to keep ourselves awake and interested ;) To be more specific, today's post is going to deal with site, and user, security on the Internet (although you could apply these examples to various arenas). As we all know, maintaining a decent level of personal and professional site security on the Internet is possible to a degree. Unfortunately, as long as there's profit in breaching that security, building industries devoted to thwarting those breaches or some interdependent mish-mosh of the two, there's no way to achieve absolute security on the Internet unless you opt not to use it (The Internet, that is ;)

To get us started, I wanted to gloss over some points taken directly from RFC 4732 which, although it is (admittedly) more geared toward Denial Of Service attack prevention, still provides many useful and simple guidelines with regards to Internet security in general (identity protection, etc). The RFC is from 2006, but it seems to be the most concise and easily digestible security RFC out there. Of course, I don't read them all ;) I mainly chose this one because of it's easy blending of useful information and readability.

We'll blaze through some of the points made in RFC 4732 at a quick pace. Check out the link for more information. The following is a quick bullet list of just some of the (now standard) recommendations for DOS protection (and general Internet User and Site Security) - I'll follow each selected point (taken from the RFC almost verbatim) with a quick (hopefully, one line) summation so we get the flavour but don't have to eat the whole bird ;) Some of the suggestions for enhanced general security include:

1. Don't Hold State for Unverified Hosts: This is always good practice. If an unverified host doesn't complete a TCP handshake, let 'em go.

2. Make It Hard to Simulate a Legitimate User: Solutions like CAPTCHA, Reverse Turing Tests, Puzzles and Reachability Testing are all good ways to try and determine if you're interacting with an intelligent entity (for now, we'll assume that only means "a human being" ;)

3. Isolate Router-to-Router Traffic: Containment is always a good idea. It's much harder for someone to jump 15 hurdles than it is to jump 1.

4. Check Protocol Syntax and Semantics: Check that your (for instance) TCP traffic is legitimate and conforms to its protocol's format.

5. Properly Handle Resource Exhaustion: This is common sense. Don't allow your resources to become exhausted by design. This won't protect you from attack or inconvenience, but it will, most probably, protect you from being "downed."

6. Avoid Livelock: This has to do with how you deal with network data transactions. By utilizing polling mechanisms, rather than interrupt-driven ones, you can protect your OS kernel from spending all its time dealing with lower-level interrupts and little to no time dealing with ensuring traffic security at the application level.

7. Use Unpredictable Values for Session IDs: Being unpredictable is always a good idea. Unless you're trying to keep your job ;)

8. Establish a Monitoring Framework: If you have a relatively decent idea of what your normal system metrics look like, it will be incredibly easy to pick up on possibly bad situations that are coming 'round the bend.

The above listed points were a very limited selection from the final section of RFC 4732, and they bring us to our own little list that deals with today's topic of Internet user and site security. Oddly enough, none of my suggestions require you to have any technical knowledge to implement. In other words, they all have to do with "Social Engineering" (The world's second-oldest profession... although arguments could be made ;)

Note: These examples have been written to be personal in nature. Since social engineering is a term that covers all forms of deception, I thought it read better as a "how to not get screwed" list than a complicated network security list

1. Don't trust anyone you don't know: Yes, not even me. Don't take anything at face value (at least, initially) and don't be afraid to question authority. Odds are you don't know me and, although it may seem that my motives for writing this blog are purely altruistic, I could be [INSERT NAME OF BIG-TIME-SCAM INTERNET MARKETER HERE] using a clever pseudonym and recycling my post material from lesser known works by honest hard-working professionals who never received the recognition they deserved just so I can, eventually, steal a few pennies from each of you (an, admittedly, cost-ineffective strategy) Seriously, if you ever question anyone's credentials, authority or advice, take the time to do a little independent investigation. 5 minutes on Google can save you a major headache or two. I'm one of the good guys, I swear. Of course, no one who's looking to screw you will admit to anything less... Just be careful that you don't pass the tipping point and end up living in full-fledged paranoia.

2. Under the proper circumstances, always politely insist that people "prove" themselves to you (above and beyond whatever "proof" they may freely offer up to put that part of your mind to sleep and make you more suggestible). The "proper circumstances" will almost always mean any situation where you are initially approached. If you're reaching out for help to a specific person, you've - hopefully - already established trust and enjoy a secure relationship with them. If someone you don't know approaches you and attempts to elicit any sort of personal or confidential information, be sure that you understand why by simply asking them. Be prepared to deal with mock outrage, a misdirected reply, questioning of your question or your reason for asking it, among many other things. These are clear indicators that you just stopped someone from attempting to do something to you that they know is wrong. Not many honest people get offended if a stranger doesn't immediately trust them.

3. Check this blog out (do a search for "password," "guesser," "cracker" or any combination thereof) for a couple reasons why you should come up with a decent password, if you do anything that requires one, and never share it with anyone or leave yourself physical reminders (like a sticky-note with it written on there ;)

4. If you're approached via a non-direct medium, like the phone or via email, and you don't know who you're dealing with and/or they want information from you that you're not comfortable handing out, ask them for their return phone number or email address so that you can call them back or write them. Make up a reason (if they're full of it, you can always rationalize it as a form of sincere reciprocation), just don't email them the information if you're approached in that manner. Use the callback and the email response, etc, as a way of establishing that you can get to that person if you need to. If at all possible, insist on getting a phone number or having the requester contact a third party, whom you trust, to get their request for information approved. Do whatever you can to make a phisher's job difficult (they'll almost always blow you off if you create this sort of situation, because, in that "numbers game" you're not going to be worth the time they waste) and, if you still feel uncomfortable, refuse to communicate with them unless through your manager (if at work), an intermediary or "at all" if on your own.

5. Respond to veiled threats with indifference. If you deflect an initial attempt to gain information from you, and the requester isn't legitimate, they may attempt to intimidate you or appeal to your sense of sympathy (or some other emotion we have that separates us from the animals ;). If they intimate that your not giving them the information right away might cause you damage away from which you will never be able to walk, you're most likely safer than you've ever been when you choose to ignore them. If a guy from the "IT" department calls up and says he needs your password so he can update your computer or you won't be able to get any work done the next day (and, as a consequence, you'll be in hot water with your boss and/or he'll have some explaining to do and he made an honest mistake when he overlooked you), suck it up and let him know that you're sorry (You're not, but it never hurts to be polite ;), but you can't give out that information without proper authorization and refer back to point 4.

Well, that's enough for today. Perhaps we'll come back to social engineering again. There's a whole lot more to it than what we've laid out here today, but it merits more than what I can put on this page without breaking my RSS feed again ;)

And, even though these examples are meant as weak allegories relating to Linux/Unix/Windows/Mac computer and network security, they're also meant as a few simple tips to help safeguard "you" and your personal information.

But, wait! Before you go, be sure to fill out the form below to get your free 97 page report on how to bake a cake that will make you millions on auto-pilot. Just be sure to include your name, social security number, mother's maiden name and a valid credit card to pay the 99 cents for shipping and handling ;)

Cheers,





...There's no form. Just kidding, of course :)

, Mike




Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.