Slashdot Mirror
Securing IM and P2P Applications
Ben Rothke writes "Noted security veteran Bruce Schneier has observed that for those organizations that have incorrectly deployed cryptography, it is akin to putting a big flagpole in front of your facility and hoping that it will stop any attackers from breaking in. Of course, any attacker with intelligence will simply go around the flagpole rather than running into it." Read the rest of Ben's review.
Securing IM and P2P Applications for the Enterprise
author
Paul Piccard
pages
454
publisher
Syngress
rating
9
reviewer
Ben Rothke
ISBN
1597490172
summary
How to get a handle on the increasing number of IM, P2P, and IRC applications that are found on the corporate networks
Similarly, many organizations have deployed myriad security hardware and software products in their infrastructure. But when it comes to instant messaging and peer to peer applications, these applications often execute below the radar of many security products. This is due to the fact that the security infrastructure in many organizations was not architected to deal with such applications. These applications often have so much functionality that it obviates much of the security afforded by the security hardware and software products.
Using file transfer as an example, many organizations have policies and controls in place to stop the use of protocols such as ftp and tftp. This is fine, but that will only work for the ftp protocol. File transfer can still be carried out by most instant messaging clients, and that can pose serious security risks.
With that, Securing IM and P2P Applications for the Enterprise provides an excellent overview on how to handle, manage and secure IM, P2P, and IRC applications. This book is written for security and system administrators that need specific details on how to control and secure IM, P2P and IRC applications in their organization.
The need to get a handle on IM and P2P is crucial given that IM has turned into a global communications medium with most organizations today reported that they allow it for business usage. Many marketing and technical support calls are now handled via IM and this translates in to well over 250 million IM users worldwide. P2P is great for downloading music and movies, but that that poses serious security and legal liability risks when done on most corporate networks.
But with all the benefits that IM provides, it introduces many security and privacy risks. IM viruses, identity theft issues, phishing, spyware and SPIM (SPAM over IM) are just a few of the many risks. These risks can turn into intellectual property losses and legal liability issues especially when they are combined with targeted attacks on corporate IM users. Companies that don't have an effective way in which to deal with IM and P2P are in serious danger as most IM and P2P threats fly under the radar of many traditional security solutions.
The book has a fairly straightforward approach. Chapter 1 provides an introduction to IM and the most common security issues that IM brings into an organization. The bulk of the remainder of the book details various different IM applications in Part 1 (AIM, Yahoo, MSN, ICQ, Google, Skype), P2P applications in Part 2 (Gnutella, eDonkey/eMule, BitTorrent, FastTrack) and IRC networks and applications in Part 3.
Each chapter details the specific architecture of each application, its protocols, security issues, and solutions in which to secure the application. System administrators can use many of the checklists to quickly perform the initial steps necessary to secure their organization from unauthorized IM, P2P, and IRC applications.
Each chapter also provides significant details about the internals on how each application operates. In addition, various 3rd-party tools that can be used to secure and limit the various applications are listed.
Many companies are finding that a significant amount of their bandwidth is being used by P2P applications and Part 2 describes how to secure networks from the use of P2P applications. This is not always an easy thing to carry out given that many P2P applications, such as Gnutella are designed to easily bypass many of the security control mechanisms placed against it. Administrators will find that in this case, simply blocking Gnutella ports will not block all Gnutella traffic and the application still will be able to run. What is required in this case is the use of a firewall that supports deep packet inspection. Chapter 9 helpfully lists the commands to use when using iptables to block Gnutella traffic.
Chapter 12 provides an interesting look at FastTrack, which is the P2P protocol and network used by clients such as Grokster, Morpheus and other file sharing programs. The chapter also uses Ethereal to detail the internals of FastTrack.
Part 3 deals with IRC and is the sparsest part of the book. This is due to the fact the P2P and IM are much more heavily used on enterprise networks, which this book is geared to.
The only negatives about the book are its price, and some of its formatting. At $49.95, it is on the higher-end of computer security books, with the majority of such titles being in the $25.909 - $39.99 range. The formatting uses a font size that is somewhat larger than other book. This seemingly serves to achieve a high page count.
In addition, the book often references tables of secondary information that spans a few pages (for examples see pages 72-80, 115-120 and more). Such information would be better served in a multiple-column table in a smaller font. Printing the information in such a manner can cut down on the page total, and save a few trees at the same time.
Besides those two minor issues, Securing IM and P2P Applications for the Enterprise is a most helpful guide. Security and system administrators can use the book to get a handle on the increasing number of IM, P2P, and IRC applications that are found on the corporate networks they support.
Ben Rothke, CISSP is a New York City based senior security consultant with ThruPoint, Inc. and the author of Computer Security 20 Things Every Employee Should Know (McGraw-Hill 2006) and can be reached at ben@rothke.com"
You can purchase Securing IM and P2P Applications for the Enterprise from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Similarly, many organizations have deployed myriad security hardware and software products in their infrastructure. But when it comes to instant messaging and peer to peer applications, these applications often execute below the radar of many security products. This is due to the fact that the security infrastructure in many organizations was not architected to deal with such applications. These applications often have so much functionality that it obviates much of the security afforded by the security hardware and software products.
Using file transfer as an example, many organizations have policies and controls in place to stop the use of protocols such as ftp and tftp. This is fine, but that will only work for the ftp protocol. File transfer can still be carried out by most instant messaging clients, and that can pose serious security risks.
With that, Securing IM and P2P Applications for the Enterprise provides an excellent overview on how to handle, manage and secure IM, P2P, and IRC applications. This book is written for security and system administrators that need specific details on how to control and secure IM, P2P and IRC applications in their organization.
The need to get a handle on IM and P2P is crucial given that IM has turned into a global communications medium with most organizations today reported that they allow it for business usage. Many marketing and technical support calls are now handled via IM and this translates in to well over 250 million IM users worldwide. P2P is great for downloading music and movies, but that that poses serious security and legal liability risks when done on most corporate networks.
But with all the benefits that IM provides, it introduces many security and privacy risks. IM viruses, identity theft issues, phishing, spyware and SPIM (SPAM over IM) are just a few of the many risks. These risks can turn into intellectual property losses and legal liability issues especially when they are combined with targeted attacks on corporate IM users. Companies that don't have an effective way in which to deal with IM and P2P are in serious danger as most IM and P2P threats fly under the radar of many traditional security solutions.
The book has a fairly straightforward approach. Chapter 1 provides an introduction to IM and the most common security issues that IM brings into an organization. The bulk of the remainder of the book details various different IM applications in Part 1 (AIM, Yahoo, MSN, ICQ, Google, Skype), P2P applications in Part 2 (Gnutella, eDonkey/eMule, BitTorrent, FastTrack) and IRC networks and applications in Part 3.
Each chapter details the specific architecture of each application, its protocols, security issues, and solutions in which to secure the application. System administrators can use many of the checklists to quickly perform the initial steps necessary to secure their organization from unauthorized IM, P2P, and IRC applications.
Each chapter also provides significant details about the internals on how each application operates. In addition, various 3rd-party tools that can be used to secure and limit the various applications are listed.
Many companies are finding that a significant amount of their bandwidth is being used by P2P applications and Part 2 describes how to secure networks from the use of P2P applications. This is not always an easy thing to carry out given that many P2P applications, such as Gnutella are designed to easily bypass many of the security control mechanisms placed against it. Administrators will find that in this case, simply blocking Gnutella ports will not block all Gnutella traffic and the application still will be able to run. What is required in this case is the use of a firewall that supports deep packet inspection. Chapter 9 helpfully lists the commands to use when using iptables to block Gnutella traffic.
Chapter 12 provides an interesting look at FastTrack, which is the P2P protocol and network used by clients such as Grokster, Morpheus and other file sharing programs. The chapter also uses Ethereal to detail the internals of FastTrack.
Part 3 deals with IRC and is the sparsest part of the book. This is due to the fact the P2P and IM are much more heavily used on enterprise networks, which this book is geared to.
The only negatives about the book are its price, and some of its formatting. At $49.95, it is on the higher-end of computer security books, with the majority of such titles being in the $25.909 - $39.99 range. The formatting uses a font size that is somewhat larger than other book. This seemingly serves to achieve a high page count.
In addition, the book often references tables of secondary information that spans a few pages (for examples see pages 72-80, 115-120 and more). Such information would be better served in a multiple-column table in a smaller font. Printing the information in such a manner can cut down on the page total, and save a few trees at the same time.
Besides those two minor issues, Securing IM and P2P Applications for the Enterprise is a most helpful guide. Security and system administrators can use the book to get a handle on the increasing number of IM, P2P, and IRC applications that are found on the corporate networks they support.
Ben Rothke, CISSP is a New York City based senior security consultant with ThruPoint, Inc. and the author of Computer Security 20 Things Every Employee Should Know (McGraw-Hill 2006) and can be reached at ben@rothke.com"
You can purchase Securing IM and P2P Applications for the Enterprise from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Of course, any attacker with intelligence will simply go around the flagpole rather than running into it.
Hey! Are you calling me stupid?
This is very important to keep productivity up and to keep illegal music from being shared on the network. A lot of illegal filesharing occurs on the faster corprate networks instead of the slower home networks. This will also be a barrier against viruses, porn, etc. BTW first post
sudo mod me up
Microsoft's doing their bit by including UPnP in new version of Messenger and encouraging people to use it.
Please add "Book Review: " to the beginning of the title. This is the second time I've noticed this.
Get ready for it...
Pay attention!
Even if you're a Fortune 500 company with a 70-story building, you'd be surprised what a walkaround by the CTO can accomplish. Stick your head in a few cubes, say "what the shit is going on here?" and let the rumour mill work for you.
It will take less time/money then hiring a "solutions" firm to police your internets. And it's the same way midlevel managers make sure their employees haven't been screwing around since like, forever.
Blocking ftp isn't enough, but blocking DCC, AIM, and Kazaa is?
I don't see how it is possible to secure an open protocol that allows file transfers. There is always going to be some idiot who'll click on the bad link, and download the trojan that can compromise the security of the entire network.
Even if you put in multiple cutouts when dealing with untrusted users, inevitably you'll have a trusted user who will unthinkingly violate protocol and open the whole setup to exploitation.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Although somewhat on point with what it sounds like the point of the book is, something that is still important to point out is that user education is one of the best ways to "secure" "IM, P2P, and IRC applications". Just because you can secure the most use applications doesn't stop your employee from installing abnormal, so to speak, and then misusing it as a means of getting around restrictions. Educate your employees and users and ensure they know why there are restrictions and the need for security with applications they use.
I work as a security consultant for Hospitals and Banks. In some of the audits I have done, I have found that are controls, or even considerations for IM. Even P2P, I was at one bank that the VP of the place ordered the third party vendor to open ports on his firewall for P2P stuff. I am no legal expert, but I told the 3rd part to get it in writing from the VP (if he still wants it open after our scathing report) that the VP orders the 3rd party to open those ports. That way, the Bank and the VP are the liable ones. I couldn't believe that though. PLus if you consider IM, most places don't have checks on the application layers especially regarding IM. I have seen quite a few banks with Egress filters, but those only block some IM protocols from connecting, many just default to port 80. It's a scary world out there, and the IM and P2P isn't helping anything.
The formatting uses a font size that is somewhat larger than other book. This seemingly serves to achieve a high page count.
Is this a security book or a term paper?
He who knows best knows how little he knows. - Thomas Jefferson
Simply create a patent that will protect IM and P2P. Although, I keep forgeting if /. is for patents or against patents this week.
I'm deliberately taking a one-sided position here, but it seems there is a lot more heat than light generated over file-sharing 'dangers'. I am reminded of Catbert's banning of camera phones as a security risk - notwithstanding the fact that the only documents people could take photographs of would be those they're allowed to read and photocopy anyway - and without even banning ordinary cameras.
-- Ed Avis ed@membled.com
This may help some companies get an idea of what all activities going on in their network, but I doubt anyone will ever stop the activity going on as described. For companies, the biggest deterrent will remain getting fired if someone is using work computers to do P2P or IM. If the company policy is clear, and people are aware of it, the company really only has that (and a series of graduated warnings) to use as a club. Blocking ports, trying to shape protocols, trying lockouts etc are, IMHO, a waste of time. A workaround will always come. Better to have a clear policy and enforce it than buying fancy-ass software or spending 50 bucks for a book on what any good IT manager knows already.
Out in the world of ISP's (which is different than in companies), the same situation exists. Try to block P2P, or bittorrent, and someone will find a way around the security. They could kick people off their service driving them to another ISP, but that's about it. This book doesn't really sound like it applies to that situation really.
....is Eric Rescorla's SSL and TLS: Building Secure Systems. It's got excellent descriptions of how SSL works, including a chapter on various attacks (million message, small-subgroup, etc). He's got some nice stuff in chapter six about SSL server performance, too - talks about hardware acceleration and whatnot.
Oh, and, plug!
The Army reading list
Bah, screw that. Just block the ports on the firewall. If certain users need those services, then do a NAT directly to their workstation, and put that workstation on a subnet that can be isolated from the rest of your systems. Firewall based security isn't a total solution, but if you have a tight firewall then your security problems are so much more managable.
I had a client who objected to this one the grounds that their employees used it "only" to talk to each other, so it was more "efficient" to keep the service. So I set them up a jabber server in the building, and blocked all outgoing traffic. The boss was fine with it, and while the employees were pissed as hell, they couldn't say anything about it because they'd all sworn that they weren't using it to chat with people outside the building.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Even if you're a Fortune 500 company with a 70-story building, you'd be surprised what a walkaround by the CTO can accomplish. Stick your head in a few cubes, say "what the shit is going on here?" and let the rumour mill work for you.
I'd say sack someone or put them on notice at the least and make sure the word gets around.
We're supposed to be on a secure network, but you should see the crap people keep emailing each other, with outside links to gawds knows what sites.
I know Dow Chemical had a Zero Tolerance policy, years ago, and gave a few people the sack.
IT people, though, can be much more clever about masking their activity. Who but an outsider could catch them at it?
A feeling of having made the same mistake before: Deja Foobar
you'd be surprised what a walkaround by the CTO can accomplish.
You're right that this will stop a lot of problems - maybe even up to a third (and I generally agree that this is something a CTO should consider doing)
However, it does nothing for:
1) Malicious users (OK they're pretty hard to stop no matter what)
and
2) Stupid users who are using IM for legitimate company purposes, and get a message from their workamte / business partner saying "lol no this is not a virus."
I certainly think companies should think about these applications in their security planning.
My pics.
If a company's checking incoming email attachments for viruses and trojans, then it only makes sense to do as much for IM.
Each chapter also provides significant details about the internals on how each application operates. In addition, various 3rd-party tools that can be used to secure and limit the various applications are listed.
Awesome. Sounds like there is plenty of detail on applications and 3rd party tools. Can I also assume a considerable chapter on user education? We all know that there is always a way "around the flagpole"... its usually end users.
with the majority of such titles being in the $25.909 - $39.99 range
When $25.90 just isn't enough, but $25.91 is just too much...
-everphilski-
Not with the RIAA on their case...
I guess the flagpole metaphor would make sense if a flagpole was a security device.
:)
I think what he is trying to say is that there is no use putting a gate on your driveway unless you put walls around it as well. Otherwise people will simply drive around the gate.
Certainly works better than the flagpole story anyway, unless there's a secret security use for flagpoles than I am missing.
- "When you want something with all your heart, the entire universe conspires to give it to you" -Paulo Coelho
That's a little harsh, eh? I mean, yeah, you have to know what the policy is before you push off into the deep waters of the internet, but zero tolerance always equals zero sense.
I use firefox at home with adblocker. Lots of sites surprise me at work when I see what the ads are actually hawking. If I find one of them has teh boobies, then I can't go there anymore. No harm done.
Someone else posted the obvious solution of blocking all the ports at the firewall. That's simple enough, but stupid people can still download software via the web and mess things up.
The simplest solution is to lock down the user's rights. Just prevent them from installing any software and don't put P2P or IM clients on their systems. Problem solved. If you really need them to be able to use IM, run it via MSN IM through your Exchange server (I'm sure there's OSS alternatives to do the same thing). That way you can give all your employees IM access to each other but not the outside world.
Not to mention the fact that restricting installation rights on workstations is smart for a number of other reasons.
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
I already know how to secure IM and P2P apps, so this book, imho, sounds like a complete WASTE of time.
nudge nudge wink wink...say no more...
Blocking all but trusted attachments in email (.doc, .txt. and .exl okay, but not .doc.exe.vbs) should be alot easier than 1) making and 2) keeping current a blacklist for ports and numbers/users who are exempt. People who really need to transfer some wierd file type will find a way (put it in a zip, sneakernet), but it will cut down on viruses are malware, which -- because they can really muck things up -- require a more technological solution than harsh language.
But most of these policies are to block porn and bittorrent because the guy approving them either a) has a moral stance on their use or b) irrationally fears lawsuits. No one's going to get hurt if they see a nipple or two by accident on the company PC. If the guy keeps getting ignoring the policy, then its insubordination, which is alot easier ground for firing anyway.
So now I got all these great ideas, but no megacorporation to use them in. Anyone care to lend me theirs?
From the outset the use of language reveals a sad attitude and misunderstanding. This smells of the familiar lack of harmonious thinking by naive security writers and pundits that is becoming a theme in todays FUD infested world. Remedial thinking, plaster over the cracks, waste money.
Painting a picture of security applications locked in mortal combat with user applications is just wrongheaded.
A coherent policy based on what the company is actually doing would be more useful, but that would entail actually spending money on systems analysis and employing some thinking. Most of these 'Fortune 500' companies would be better off simply admitting that their networks have grown so large that nobody knows what's going on in them anymore. Start again from the bottom up based on what is needed. But they can't shut down the mighty machine for long enough to understand and fix it. Statements like "Using file transfer as an example, many organisations have policies and controls in place to stop the use of protocols such as ftp and tftp. This is fine, but that will only work for the ftp protocol." leads me to think the article was written for 10 year olds. So it's a summary of protocols, how to recognise their packets and block them. As a security policy it's a chocolate teapot. A cookbook of protocol hitlists. When will they learn? Two two things... Whitelists. Mandatory Access Control. Sorry to come over as so cynical, but I am frightened by the kind of people working in so called security positions, really worrying.
However, it does nothing for:
1) Malicious users (OK they're pretty hard to stop no matter what)
Um... maybe companies shouldn't hire malicious employees.
Yeah, businesses really need this so their employees can securly trade dvd torrents and chat with their spouses.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Why would you assume these IM/P2P applications are even installed in the first place?
In most corporate environments, software policies are already in place to restrict users from installaing any software on their own. In addition, generally any requests for installation of IM/P2P apps are quickly denied citing company policy (the reasons for which should be painfully obvious).
There's really no need for IM at work, but if you really really want it, use a corporate IM solution (such as Exchange IM or Apple iChat) to keep things local. Problem solved.
Is this really an issue for most IT departments?
smattawichu
Certainly, social engineering attacks come down to user education.
BUT, there is NO excuse for not having the technical side locked down. It's all too common for people to claim that you can't protect against someone clicking on a link. The fact is, you CAN. Quite simply, install a secure browser (dump IE, in other words), put it through a filtering proxy like dansguardian, and then close http ports on the firewall, except for the proxy server itself. Disable webmail at the web proxy, and disable downloads anyway at the same proxy. If you need windows update or something like that to work, you can explicitly allow certain sites. But DON'T allow any more than strictly necessary. Don't allow SSL, except to trusted sites where no uploads or downloads or conversations take place.
Likewise, install a secure email client, and have mail filtered through a company mail server, disable HTML mail and encrypted mail.
These are basic security precautions. But already, you've secured your organisation far beyond most of the windows shops out there that get virus and spyware issues every day.
It doesn't take a genius, it just takes you to choose what technology you allow on your systems, and to use it wisely.
Right, because malicious employees all have goatees, dress in black denim and leather, and have skull and crossbones tatoos on the side of their neck. You can spot them from eighty yards.
You need to read some books on management. Doing this will never, ever work. You'll just get people to periodically give a look to see if the CTO is walking around, which is even more of a distraction from work.
Putting "protected by [insert alarm company name here]" stickers on the windows of my house will discourage most of the amateurs from breaking in, even if I don't really have an alarm. Even the pros may skip to the next house without looking, unless they know I have something they want. Not that I condone improper use of cryptography or anything, but you can use analogies to support any position.
God, that worm swept through my company not too long ago, and it pops back up from time to time. I've mentioned that using straight AIM is a bad idea, but unfortunately I'm a little too far down the food chain to make much difference quickly. I was one of the few using gaim on Linux and literally had to kill it because of the flurry of IMs from that worm.
Although I admit to using AIM to talk to my gf and other people outside the building, I'd not complain at all if it blocked and switched to Jabber or some other internal thing. Not gonna happen though, the IS/IT/developers are already bogged down with what they currently have, much less adding more. There's already a company policy in place about sending private information over AIM, but everyone uses it to send passwords, usernames, other login info, customer info, internal stuff... it's really pretty bad.
Not to substitute axioms for well-thought out ideas, but you can't catch all the fish in a pond anyway. Just because a solution isn't perfect doesn't mean it's not more valid than the current model.
And if you have people slacking off in order to not get caught slacking off, then that's a whole other type of problem. Might be better to flush out the deadweights by doing it, actually.
You are correct on that. I have a tight firewall here w/ proxy service and I can't get a single IM client, BT client, pretty much anything besides a web browser to connect outside the intranet, even when I got the proxy settings from my admin. We have an in-house IM client but AIM, Yahoo, etc, are all blocked. Pretty effective IMHO. No need for "what the shit" policing. Who has time to do that, anyways? If you got time to lean, you got time to clean!
Or his opinions? Just curious...
Arash Partow's Philosophy: Be a person who knows what they don't know, and not a person who doesn't know.
Therefore you buy yourself a piece of software that can virusscan these files instead of blocking them ! Oh protocol xyz can be used to transfer files (name 1 protocol that cannot be used for this purpose ? even ping can be used to transfer files).
"There will always be one idiot who" -> perhaps, but why punish 1000 non-idiots instead of firing the idiot ?
If IT security becomes synonim with bullying (which it is in many companies), I can assure you nobody, absolutely nobody will care about security, and then your job becomes impossible.
Just a thought.
Save yourself almost $17 by buying the book here: Securing IM and P2P Applications. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
...why things like this are so difficult. If you know the basics, problems like this can be avoided. Don't give users administrative/root or power user accounts on any computers, Linux or Windows.
Sure you can break a local windows password with a floppy, but that's there policies come in. You find someone doing that, you fire them.
Problem solved.
You guys amaze me. Take a really easy thing to solve, and make it sound like brain surgery.
Start with an IM proxy i.e. IMLogic, fake up all of the DNS zones and names for the IM sites, and require specific group membership in AD to allow access to the proxy. If you're not in the group, you can't IM, and the proxy rules keep out the bad stuff while archiving all of the conversations for compliance purposes.
For P2P, it should simply be disallowed. If a company runs a decent IDS/IPS system, it's very easy to block all forms of P2P. And it doesn't matter that these apps can hop between ports; a good IDS/IPS is looking at the payload to determine the traffic, not just the layer 4 protocol.
Besides, employees should not have time or the inclination to waste company resources, and can save that activity for home.
If your company is allowing P2P and IM unfettered, you may want to ask your data security group to get their heads out of their rear ends!
I mean, Securing IM is a legitimate and important thing for corporate IT departments and people with real responsibilities to concern themselves with.
On the other hand, "Securing P2P" is basically just another step forward in the arms race between those who would choose to flaunt copyright laws and those trying, however vainly, to stop them. Even if you would try to make the rather weak case that P2P has legitimate uses in some legitimate businesses somewhere, you'd be hard pressed to extend that into why, exactly, that your mythic "Linux Distribution ISOs" need to be encrypted.
(PS - try this at home, kids! Boot up eMule and do a search for "Linux." Amazingly, even under this keyword, at least 9 out of 10 search results when I tried this were actually PIRATED STUFF RELATED TO LINUX!) (in other words, manuals, videos, etc that are in no way under the GPL).)
I work for a large enterprise and we can't even use the personal version of IM. We do however use the corporate IM client (MSN Messenger v 4.6)
Remote to a machine at home, do everything I want from there.
Web 2.0 == Giant Blogspam Circle Jerk
Um... maybe companies shouldn't hire malicious employees.
Have you ever read any of the memoirs of Richard Feynman? I'm not going to make the ridiculous claim that every malicious employee is the equivalent of Nobel prize physicist Feynman, but any objective review of what he claims to have done makes it clear he would be classified as malicious. He found the security at Los Alamos labs during WWII to be onerous and pointless in the manner it was handled. That inspired him to various exploits that caused headaches for them. On the other hand he was one of the best physicists our country has ever produced. His contributions during the Manhattan Project might have been crucial. The idea here is that making the security department happy might not be the most important criterion when choosing employees.
one problem some IM's redirect to port 80 if their default port is unavailable. I know gaim does. and I tricked my gf parent's into thinking she wasn't talking to me once, because I was logged on to msn with 2 different account's so it couldn't be me... lol. stepping around the flagpole. of course a layer 7 firewall could block all IM client's trying to go through any port.
In my experience, malicious users aren't hired. They are created by the company that employs them.
"The Adobe Updater must update itself before it can check for updates. Would you like to update the Adobe Updater now?"
Blocking port 80 generally works. :)
I am aware of the fact that different companies have different policies. This seems to be occasioned by the the fact the CEOs have different personalities and that many policies are based on whatever someone did in the the past that caused a problem.
I am aware of the fact that different jobs require different types of concentration. For example, an assembly line worker can only relax after completing the task and before the line moves on. It tends to be a short fixed length of time. A software developer has to concentrate for longer periods of time to do good work.
Ignoring all that, I suspect that most folks with computers on their desk also have phones. The phones are mostly used to call people for business reasons or to receive business calls. But if the kid's school calls or the wife or golf buddy calls it is acceptable to talk for a little bit. Most companies don't mind a call to the house but they do frown on a call to Thailand (unless you are in Thailand). And even if you don't have a phone on your desk you may have a cell phone that you use during the work day. Most employers expect you to do a bunch of work and a little personal stuff. They just don't want the personal stuff taking all day or costing them money.
Now, why is IM different? Some jobs don't have a need to do an IMing so all use would be personal. Some jobs can be done better when you IM. Either way, it doesn't cost much. As long as the personal IM doesn't take all day, why bother cutting it off.
(The comment about the cost of the bandwidth used for IM seems spurious. Companies spend money all the time for their employees personal affairs. What is air conditioning or smoking areas or coffee pots?)
I can see the problem with file transfers. It might be a good idea to figure out how to turn them off. Most of those people that need to transfer files can email them when they need to.
I can also see industries where you can get into problems if you let the employees communicate with the outside. I once did a project at a securities firm that recorded every phone call so it could prove, in a possible court case, that no employees gave any inside information to anyone outside. Of course, the IM worked just fine at that time. It really should have been recorded or turned off for the same reason the phones were. (Cell phone calls were not allowed.)
a rooster only crows so many times before the mama knows a henhouse fulla graham crackers.
Until the IM clients start speaking perfectly legitimate HTTP over port 80 (a la XMLRPC or SOAP or HTun or the like). All the firewall can do is look at traffic and make sure it conforms to a specific protocol, but that doesn't mean the traffic is desireable.
No firewall will ever be able to look at traffic and say with certainty "this is legitimate business-related stuff" or "this is somebody BSing with their friends" or "this is someone trying to get a trojan horse in here" or "this is someone trying to post trade secrets"...
Thanks for the brief, though good, review of the book. I'm B.B., author of three chapters of the book: 9, 11, 12 (Gnutella, BitTorrent, FastTrack). If you look at the book's profile on other sites, you'll see there were a variety of co-authors on the book. As a long time member of Slashdot, and a long time advocate of both Open Source applications and Linux, this was a small way for me to at least give a little back. My chapters were written from a Linux admin POV, with details and steps on iptables (with installing strings), self-made Snort rules, and Ethereal screen shots (which were done in Windows, my Linux boxes are headless) I can only speak for my sections, but I hoped that if a regular Windows admin picked it up, and saw how easy it was to create firewall rules in Linux, it may help to win some hearts and heads.
;) //Feeling obliged to use Karma Bonus
Overall, it was an honor and priviledge (cliched, I know) to help out with the book, with a great bunch of other guys. And thanks Slashdot
My wife's company required that all developers (i.e., anyone who has access to source control), uninstall all IM programs from their computer (a requirement for some security certification). The devs just use the web-based IM clients MSN and AIM provide to do their IMing (both internally and externally). Yeah, the IM client sucks eggs compared to the desktop client, but it's better than nothing, and it's something I'm surprised the employees you talk about didn't start using...
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
When talking about limiting, monitoring, and controlling a given user's Internet access within a company, why not just hire better people.
You can't control how badly the average user will mess things up but perhaps you can control the skill level of the average user within a company. If employees are good then they'll know to not click on suspicious links, waste company time chatting, or open suspicious attachments. Also, I believe that if a company would rather censor mediocre employees than hire good ones then part of the problem actually rests with that company's management.
Of course, "good employees" screw up just like bad ones but simply employing people who know not to make dumbass mistakes seems like a better solution, with this issue as well as in general, than attempting to block those mistakes.
I realize this is an idealistic perspective; still, I think it makes sense.
For those who don't know:
The storys the poster is refering to can be found in the book Surely You're Joking, Mr. Feynman!
(A Few Excerpts from the text)
Math Magic http://www.craigr.com/books/surely.htm
Education in Brazil (my favorite) http://www.wallaceinfo.com/feynman.asp
There is also a sequel What Do You Care What Other People Think?
Required reading for internet skeptics
most companies that try to lock down their Internet programs often use Internet Explorer and Microsoft Outlook as the default web browser and email client. Yet these two programs have the most exploits of any Internet based programs out there. So even if you do lock down the ports of the firewall and stop users from installing programs, chances are the exploits will install the malware for you when they get the wrong email or click on the wrong link.
:)
99% of the malware infections that happened in the past four places that I worked in, were caused by management clicking on the wrong email or wrong link in Outlook or IE. They did lock down their Internet, turned off port forwarding, took away admin access, prevented the install of new programs (which screwed up Visual BASIC and MS-Access development, because they needed Admin access or else things don't work via certain controls), and other things.
I think one of the funniest momments was getting the "Love Bug" email from the Network Administrator 12 times in a row that said "I LUV YOU!" over and over again. Guess who was using MS-Outlook and McAfee Anti-Virus and got infected due to some exploit? Needless to say I was smart enough not to open up those emails, unlike my co-workers who did, and sent me their own "I LUV YOU!" emails.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
No firewall will ever be able to look at traffic and say with certainty "this is legitimate business-related stuff" or "this is somebody BSing with their friends" or "this is someone trying to get a trojan horse in here" or "this is someone trying to post trade secrets"...
No, but router ACLs and a packet inspection service can certainly filter out the largest chunks of data, using application "fingerprints" to determine what particular traffic streams are likely generated by. It will never be 100% perfect, but deployed on core and border routers it can take out the majority of unauthorized application traffic within a network.
Exactly, just put a question on the job application: "Are you malicious?".
Observe:
You could just disable all HTTP access, but then the Internet wouldn't be very useful.
The correct way to block IMs is to tell people that it's against company policy and that they'll be fired if they are caught using it.
My other car is first.
Yes, if you are doing dumb things, it's only right to be consistently stupid. You would not want to ban cellphones with cameras while allowing ordinary cameras would you? Pass it by the Homeland Security Office if you have to think about it long. If IM is what you consider your new IP threat, you proably need to reconsider what's important to your company and why.
Such shenanigans only make sense when you believe in intellectual property and treat the creators of such property like criminals. If your entire business relies of a few secrets that could sneak out the door, you have a sorry business. If you do have secrets you need to keep but employees you can't trust to keep them, there is something wrong with the way you hire and treat your employees. The idea of network "security" through port blocking is so laughable the company in question must be using a M$ desktop. If your company has such sorry software, you probably flunk the other tests of dumb company and your life is miserable.
Stupidity is self punishing.
Friends don't help friends install M$ junk.
Hey Willy, how's life these days? How's the old "Red Stick" doing? Lotta problems from Katrina, eh? Still live close by LSU?
Say hi to J for me, will ya?
(btw, that 'M$' bit is hilarious! clever as ever)
Here is a new head-ache for you: http://www.http-tunnel.com/html/ http://www.nocrew.org/software/httptunnel.html
Oh well, what the hell...
Shhhhh, damnit... :-)
Actually, whenever I work at a client's, I SSH into one of my own boxes and do everything and anything over an encrypted link. I even listen to my own music over SSH from my own streaming server. I don't leave any traces of my doings, comings and goings on client systems.
Oh well, what the hell...
Just put a transparent squid proxy between them and the net.
Keep detailed logs, and throw the book at someone when a rule is broken.
Basically, protocol inspection won't work because the user can make the protocol look exactly like (say) viewing slashdot.
Actually, no you can't. Packet inspection technology does not live in a vacuum. An automated system looking for (and allowing) web traffic to Slashdot will notice if you are sending the same traffic to different IPs. An automated system can also pick up on keywords. But this is not about preventing generic communication. This is about stopping particular applications, especially ones that risk exposure. The vast majority of them are easily detected, and those masquerading as HTTP traffic are usually detectable by recording some traffic, making it into a generic signature, and then looking for packets that match it. As I said, this will not always work, but it will catch the vast majority of people trying to hide an application. This works today.
I dont think u can make software that is secure even if they cant crack it today they can probably crack it soon