Re: IRC in corporate enviroment

[Dennis Dayman <dennis-lists () thenose net>]

Thanks! This is the best thinking on the matter and the route we might take

-Dennis

On Jun 21, 2011, at 12:50 PM, MaddHatter wrote:

> I find IRC to be an invaluable resource for getting answers and getting
> stuff done in a relatively short time. In the right communities, one
> can have real-time access to the authors/developers of the tools one is
> using, or at least access to very knowledgeable people. A question that
> would take three days to answer on a mailing list, with a third of the
> replies being useless, can be answered (sometimes) in 15 minutes on IRC
> with a much better signal-to-noise ratio. I find IRC to be such a useful
> collaboration tool that I encourage workgroups to use it internally,
> although that only works well in certain kinds of environments.
>
> IRC can also be a excellent way to get distracted, nerd-sniped*, or
> otherwise wasting time. Some users on IRC may be rude, unpleasant, or even
> make it their mission to harass others. Unlike in the workplace, where
> such behavior can be addressed, there is no recourse for it on external
> IRC networks but to ignore. Employees shouldn't have an expectation that
> IRC happenings can be sanitized the way many workplaces sanitize HTTP
> traffic via myriad proxy rules.
>
> IRC itself is a text-only protocol (albeit one with extensions like DCC
> that can allow file transfers, encrypted chat sessions, or almost anything
> else you can imagine). That means vulnerabilities in IRC clients are less
> frequent than other software. By sticking to pure IRC clients (not multi-
> protocol clients that include IM) with a reasonable track record, I think
> the security prospects are at least as good as any other software that's
> new to your enterprise.
>
> IRC has gotten almost no attention in the "enterprise" market, except
> for McAfee deciding that all port-6667-bound traffic _must_ be malicious
> botnets and should therefore be blocked. That means there aren't any
> IRC implementations designed to respond to the interests of a workplace
> systems administrator. You'll probably be inventing your own solutions
> as-you-go.
>
> I would allow IRC access to employees by granting them ssh access to a
> linux/unix-like server (or VM) where they could run a terminal multiplexing
> program (e.g. screen, tmux, dtach) and IRC client (e.g. irssi). This
> IRC-client server would have external access to IRC, and have ssh
> port-forwarding disabled. Employees' individual workstations would not have
> external IRC access (so as to force the employees to use the server). This
> gives employees the useful ability to keep long-running IRC sessions
> open, and limits any potential damage (from an IRC client compromise)
> to their non-elevated user accounts on that server. By keeping most
> of your company intellectual property (IP) off of that server, there's
> little opportunity for IP to leak out of your control. Having a dedicated
> server (or VM) that offers no other services makes it relatively easy to
> secure against any potential attack that might come from the hostname
> being seen on IRC networks. And as already mentioned, without IP to lose,
> the damage is small, even if the server were compromised.
>
> Talk to your users and find out if that's a workable solution for
> them. If they have internet access, they're probably already using
> web-based IRC clients like Mibbit and similar. They might insist on having
> a GUI IRC client, which makes isolation and security more challenging. Your
> users need to be aware of the usual basic-safety-on-the-internet kinds
> of things, like not downloading/running unknown stuff, not accepting
> unexpected DCC requests, and so on. If they're asking you to support IRC,
> I'd venture to guess they're already well-aware of those basics.
>
>
> Hmm... that got unexpectedly long. TLDR: it's useful, and can probably
> be made relatively safe.
>
>
>
> * http://xkcd.com/356/
>
>
>
> > Date: Sat, 18 Jun 2011 14:47:31 -0400
> > Resent-Date: Mon, 20 Jun 2011 18:52:08 -0700
> > Subject: IRC in corporate enviroment
> >
> > Looking for some pros cons to having IRC connectivity in a corporate
> environment. Our R&D guys would like to join some coding channels to get
> ideas and help, but we are hesitating to allow them for fear of a possible
> hole being opened via an IRC channel and client.
> > thoughts on pro's or cons?
> >
> > what is the beat way to implement if it is deemed ok?
> >
> > -Dennis



------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------