Live data from Hacker News

Posting successful SSH logins to Slack

sandrinodimattia.net

31–40 of 71 posts

Re: Posting successful SSH logins to Slack

#31
post #30

Earlier quoted context omitted.

People are _way_ too trusting of Slack and similar services. You could run your own IRC or Mattermost server accessible only in your LAN or over VPN and this would be fairly safe. Heck, even SSL-only with cranked up SSL options would be fairly safe. Instead, people ship all their data off to a 3rd party company, often letting that 3rd party have control over their servers and such. Their customer data, their payment…

People will always feel comfortable trading privacy for convenience!

Very unfortunate but I feel it may be true.

Re: Posting successful SSH logins to Slack

#33
I did a similar thing a couple of days ago. I just added this (with the correct values) in the `sshrc` file inside `/etc/ssh` and enabled a webhook. that's it.

ip=`echo $SSH_CONNECTION | cut -d " " -f 1`

curl -X POST --data-urlencode 'payload={"channel": "#", "username": "SSH Login watcher", "text": "User '${USER}' just logged in from '${ip}'", "icon_emoji": ":robot_face:"}' https://hooks.slack.com/services/ of the webhook>

Re: Posting successful SSH logins to Slack

#34
post #15
post #4

Excellent. I've been thinking about having a SSHD keylogger post to slack (or some other log). It's crazy that sshd doesn't have this functionality built-in. It's so important to know what your admins are executing on your machines. Aside from the fact that they might have been compromised, it's just good to know what sort of general administration is being done.

Some shells do have this built in, for example bash's history file, typically set to ~/.bash_history

Which is easily defeated, of course ...

Re: Posting successful SSH logins to Slack

#35
post #25
post #10

Earlier quoted context omitted.

> It's so important to know what your admins are executing on your machines... Micromanagement at its finest! > it's just good to know what sort of general administration is being done. Your change management process will give you an overview of what your admins are doing.

Incident response. When one of your admin accounts is compromised, you'd want to know what the attacker executed.

Yes you would - but why just SSH? Wouldn't auditd execve syscall logs sent to a logstash server be better? It'd handle compromises other than SSH too.

Re: Posting successful SSH logins to Slack

#37
post #4

Excellent. I've been thinking about having a SSHD keylogger post to slack (or some other log). It's crazy that sshd doesn't have this functionality built-in. It's so important to know what your admins are executing on your machines. Aside from the fact that they might have been compromised, it's just good to know what sort of general administration is being done.

Look into auditd for logging execve() syscall instead. OSSEC can (directly) report or act on any thing reported through logs.

Re: Posting successful SSH logins to Slack

#38
post #23

Earlier quoted context omitted.

That's some very sensitive information to put in Slack. If Slack has a security breach or if any of your slack accounts are hacked then an outside party could see this channel. Ever accidentally typed your sudo password at the wrong prompt?

How quickly we forget that Slack was hacked not more than a year ago.

How can we forget that? Literally any time Slack is mentioned on HN, people come out of the woodwork to let everyone know they don't use it cause it's hosted by someone else.

Re: Posting successful SSH logins to Slack

#39
post #5
post #3

Elegant. Thank you! Is there a way to extend it to override DND?

That's a great idea. But I didn't find any docs that explain how to override DND. I opened a feature request instead, so we'll see how it goes :)

That kind of gets you into this sort of problem: https://blogs.msdn.microsoft.com/oldnewthing/20110310-00/?p=...

If you start overriding DND, now the user is going to want super-DND. Which somebody will then want to override, and so on. The correct solution is that your users need to not set DND when they in fact need to be disturbed, and your systems shouldn't be disturbing unnecessarily, and to the extent that's a really hard problem, well, yes, it very much is, but an unboundedly-large hierarchy of "bother that person, no don't bother me, SUPER bother that person, no SUPER don't bother me, SUPER MEGA bother that person" isn't part of the solution set.

Re: Posting successful SSH logins to Slack

#40
post #25

Earlier quoted context omitted.

Incident response. When one of your admin accounts is compromised, you'd want to know what the attacker executed.

Yes you would - but why just SSH? Wouldn't auditd execve syscall logs sent to a logstash server be better? It'd handle compromises other than SSH too.

Yes - though there's more to a SSH session than executing commands (interacting with interactive editors, port forwarding, etc.)
Post reply on HN