Your company puts private information on a server that has a 6667/tcp sitting out on the Internet?

I'm guessing it does not, and setting this server up was considerably more irritating than just spawning off another t1.micro and apt installing IRC onto it.

We have all our instances in a VPC so nothing is available without a VPN. (Openvpn, on phone, laptop, built into the wifi router for everyone else). Once any service for our firm onlt is set up it is effectively private it we manage our keys. Private IRC is a one line apt get on a server. Close to zero cost from there.

Explain why that's any worse than putting private information on a server on with port 80 open. Go!

In AWS t1.micros don't really exist anymore (they do, but you have to use oooolldd images), and except for legacy accounts, a default install puts you into a VPC where the instances are never going to have 6667 open to the internet unless you specifically open it (well, that's more of a Security Group thing) and possibly don't even have a public IP address. :)

So put in an iptables rule that restricts it to their network and make people remote in to use their client. Done and done.

iptables rules are not magic security talismans.

Oh yes they are you just need to add the --rabbit-foot switch.

True, but for this case it's more than adequate. An attacker would need to be able to tunnel through your companies network, and then what? Assuming they're that far, who cares if they can read what you talk about on IRC?

And even then, they'd further need to exploit some vulnerability in your IRC server to do it unnoticed.

How very lucky of you.

I hope you have a repeatable provision, AMI, static IP linked to a tcp loadbalancer and autoscaling group in the event AWS rotates out your instance.

And of course, the same goes for your logging and search and file sharing infrastructure. And of course, similar caveats exist for the database said features use.

If your file sharing infrastructure is limited to what Slack provides, then your file sharing infrastructure sucks. Slack is good for quick "check this outs", but it's not a file sharing system.

Well, you add the google docs integration, or the dropbox integration, or the box integration, or use the Zapier integration to tie things together.

Slack isn't a file sharing platform, it's a communication platform. As such, they try to make communicating about, discovery and grouping of files in dedicated file sharing platforms easier.

That's a terrible solution for anyone handling data that has to remain on-prem, which is the case for a lot of large corporations that deal with financial data, personal id data, etc.

Of course it's a bad solution in that case. You've picked a case where a specific business requirement precludes using an external service. In which case, why would you use slack anyway, since it would then necessitate a chunk of your communication be external as well?

how very sarcastic of you.

This is the realm of systems administrators, if you can't read a 20 line config file then sure, run slack..

but for a biggish company that values security and publishes NDA's like mine, an IRC server is a better solution.

however, Project Managers fucking -love- emoji and sending word documents across the planet.

How very decisive of you.

And you'd take on the burden of constellation of comparable services as opposed to a white label hipchat because....?