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.

11 of 123 comments (clear)

  1. Slashdot Admin, you forgot it's a BOOK REVIEW! by Anonymous Coward · · Score: 4, Insightful

    Please add "Book Review: " to the beginning of the title. This is the second time I've noticed this.

  2. The same way parents keep a handle on their kids by voice_of_all_reason · · Score: 4, Insightful

    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.

  3. Maybe the author should take his own advice? by Anonymous Coward · · Score: 1, Insightful

    Blocking ftp isn't enough, but blocking DCC, AIM, and Kazaa is?

    1. Re:Maybe the author should take his own advice? by fishybell · · Score: 2, Insightful
      I agree. Too often admins see the problem of "insecure or unwanted traffic on port XX" and solve it by blocking port XX. My question is why wasn't that port already blocked? As a system administrator I block All ports except the ones we need. Even then those ports are monitored for the correct kind of data.

      No this won't stop all the baddies, but why would you leave ports open at all?

      --
      ><));>
  4. PEBKAC by SatanicPuppy · · Score: 2, Insightful

    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.
  5. Real risks or pretend ones? by Ed+Avis · · Score: 3, Insightful
    File transfer can still be carried out by most instant messaging clients, and that can pose serious security risks.
    I'm not convinced of this. It's not as if the instant messaging client magically runs with higher privilege and gives someone access to files they couldn't otherwise view. If they transfer a file to a friend, it must be a file they already had permission to read. If they receive a file by instant messenger, the risk is no greater than if they'd simply downloaded it in their web browser or loaded it from a CD.

    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
  6. Well, It Might Help Some, But... by Bullfish · · Score: 3, Insightful

    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.

    1. Re:Well, It Might Help Some, But... by No2Gates · · Score: 2, Insightful

      I could not have stated it better than you. You are at work, you are being paid to work, not P2P or IM. Do it and you are fired. Where I was, we have this policy as well as not allowing users to install their own software. No P2P software or IM software is originally on the machine, if it shows up, the machine gets formatted as so does your employment.

      --
      Every time you call tech support, a little kitten dies.
  7. Re:The same way parents keep a handle on their kid by tpgp · · Score: 3, Insightful

    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.
  8. Securing IM and P2P by Anonymous Coward · · Score: 1, Insightful

    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!

  9. Thanks (from an author) by Rurik · · Score: 2, Insightful

    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.

    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 ;) //Feeling obliged to use Karma Bonus