-2

I'm trying to block users with command line access to a RHEL7 server from easily exporting large chunks of data wholesale. I'd like to block outgoing email, ftp, sftp, etc.

I understand that there are limitations to what can be achieved. If a user has unrestricted access to data, then they could dump it to the screen and cut and paste, for example. But I'd like to make it at least slightly difficult.

I've seen the suggestion to add accounts to /etc/mail/access and REJECT each account that shouldn't be allowed to send. This is feasible, given the number of users. But the sendmail daemon does not seem to be running by default and there's no /etc/mail directory. Should I just create it and make an /etc/mail/access config file and make the database? Or is there a different default location of this file on RHEL7?

And would this prevent something like the following from working?

mail some@address.com < bigpileofdata.txt

Can outgoing sftp be disabled while allowing standard ssh command line connections? I suppose incoming should be blocked as well, given that they'd be able to create a local file in their account and then download it via sftp. Outgoing ssh could be blocked entirely, but incoming ssh needs to be allowed or the user won't be able to use the server at all.

I'm open to other suggestions for clamping down.

Thanks for your thoughts.

bumfoozled
  • 1
  • 1
  • 4
  • 1
    If your data is that crucial and security is a concern, you should be hiring security experts. As a matter of fact, even giants like yahoo, are still getting hacked. What you are thinking is just not worth doing. – alvits Jan 07 '17 at 01:09
  • The data is not crucial, otherwise I wouldn't be framing the question this way. But there's a difference between leaving a dish of after-dinner mints at the exit and keeping a shipping container full of 10,000 count mint packages wide open next to a playground. – bumfoozled Jan 07 '17 at 01:27
  • You need to block all outgoing connections. Without blocking outgoing connections, one could simply use external smtp server to send out the data via email. You need to disable ssh, both incoming and outgoing. Nothing can stop a user from running `ssh user@server dd if=data | dd of=/my/local/file`. – alvits Jan 07 '17 at 02:10
  • Disabling incoming ssh is impossible, since the reason for the existence of the server is to allow users command line access to specific software. Maybe what you're saying is that we should block outgoing access at the firewall. Thanks, maybe that's a better way of thinking about the issue. I'd still like to deal with the low-hanging fruit, however. – bumfoozled Jan 07 '17 at 02:34
  • Didn't I mention that commands like `ssh user@server dd if=data | dd of=/my/local/copy` is a workaround even if you disable `sftp`? – alvits Jan 07 '17 at 02:35
  • The point is not to lock things down, the point is to do more than nothing. "We did absolutely nothing to limit access to the data." is not nearly as reasonable a response as "We did a few things, with the understanding that we can't actually prevent anyone with a small amount of Unix proficiency from participating in shenanigans." It's like using norobots on your web page. It doesn't do much, but it's better than not doing it. Bosses don't care about philosophical objections, regardless of their integrity. – bumfoozled Jan 07 '17 at 02:56
  • My comments are based solely on the title and description. But I'm glad you are now agreeing with my very first comment. – alvits Jan 07 '17 at 03:00
  • I'm more concerned with the actual technical issues of shutting down the things that are possible to shut down, but your philosophical input is appreciated. – bumfoozled Jan 07 '17 at 03:08

1 Answers1

0

What about using something like iptables to block outgoing traffic on a per user basis? Any potential pitfalls?

bumfoozled
  • 1
  • 1
  • 4