Need to prevent ssh remote server redirect to a local file

iksrazal · 03-16-2015, 05:14 PM

Our sysadmin considers this SSH command, from a Linux client to a Linux server, a security risk as it creates a local copy of the read-only file confidential.txt too easily.

Code:

ssh myuser 192.168.2.100 'cat confidential.txt' > local_copy.txt

Is there any way to prevent that command from creating a local file copy - via some type of SSH config option, firewall rules etc?

Unfortunately that issue is leading to moving the server access to Windows RDP, as it being claimed the clipboard can be disabled for a more secure environment.

TobiSGD · 03-16-2015, 06:06 PM

Quote:

Originally Posted by iksrazal

Our sysadmin considers this SSH command, from a Linux client to a Linux server, a security risk as it creates a local copy of the read-only file confidential.txt too easily.

Code:

ssh myuser 192.168.2.100 'cat confidential.txt' > local_copy.txt

Is there any way to prevent that command from creating a local file copy - via some type of SSH config option, firewall rules etc?

Unfortunately that issue is leading to moving the server access to Windows RDP, as it being claimed the clipboard can be disabled for a more secure environment.

The proper solution would be to not make the file readable in the first place for those people that shouldn't see it. Windows RDP will not prevent anyone from making a screenshot when the file is displayed, so you can still get a copy if you want to.

unSpawn · 03-16-2015, 06:13 PM

In addition you may entertain your "sysadmin" by pointing it to the slightly over-the-top exercise "Ways of getting data off the premises?".

iksrazal · 03-16-2015, 06:16 PM

Thanks for the replies.

The files in question need to be viewed locally on the remote machine for debugging purposes, via VI etc.

The sysadmin feels screenshots are acceptable because its too hard to parse a large amount of sensitive data - these files can be upwards to 100MB in size.

Quote:

Originally Posted by unSpawn

In addition you may entertain your "sysadmin" by pointing it to the slightly over-the-top exercise "Ways of getting data off the premises?".

Thanks!

Miati · 03-16-2015, 06:29 PM

This is just a possibility, but you could require a su to access the files. This would require a login to shell and couldn't easily permit local copying.

e.g.:

sshd_config

Code:

AllowGroups ssh_access

Then only permit user file_access to access the file (who is not part of group ssh_access)

Since ssh access can only be obtained through a second step, a command like

Code:

ssh host 'cat file' > file

wouldn't work.

Users would need to login to the server, switch user (su) to file_access, then access the file.

I wouldn't be surprised if there was a way to work around it, but it's an idea.

TobiSGD · 03-16-2015, 07:01 PM

Quote:

Originally Posted by iksrazal

The files in question need to be viewed locally on the remote machine for debugging purposes, via VI etc.

That is even worse. Even if Windows RDP can disable copy/paste via clipboard, absolutely nothing will prevent you from running a shell command in Vi to copy the file wherever you want, send it per mail, FTP, SSH, ... .

unSpawn · 03-16-2015, 07:01 PM

Isn't that easy to bypass loading up screen and issuing a ^a^h before SSH'ing into the system or using a terminal like konsole that offers to save output directly?..

Miati · 03-16-2015, 08:11 PM

Quote:

Originally Posted by unSpawn

Isn't that easy to bypass..

Probably. If you are remotely accessing a file and have read access, you can copy it. Trying to introduce "restrictions" just encourages users to be more creative when it comes to doing their job. This means more complexity, lost time and a lot of "feel good" safe-guards (like my idea which took a good 32 minutes to find a way around).

Quote:

The sysadmin feels screenshots are acceptable because its too hard to parse a large amount of sensitive data

It is a lot harder to parse a lot of data. It's also going to be a lot harder to deal with it in the first place.

Frankly, a more effective method would be for the sysadmin to announce that copying files is prohibited.
rather then micromanaging how people do their work.
(IMO)

unSpawn · 03-17-2015, 02:47 PM

Quote:

Originally Posted by Miati

(like my idea which took a good 32 minutes to find a way around).

With all due respect but isn't that an assumption? ;-p

Quote:

Originally Posted by Miati

It is a lot harder to parse a lot of data. It's also going to be a lot harder to deal with it in the first place.

Not really as you can rent whole rooms of eyeballs and keyboards for cheap: look for example at how some captcha problems are "solved".

Quote:

Originally Posted by Miati

Frankly, a more effective method would be for the sysadmin to announce that copying files is prohibited.
rather then micromanaging how people do their work.
(IMO)

...except that this isn't something for a sysadmin but the company itself as (regulatory) compliance should be governed at that level. At the sysadmin level one then only has to bother with adjusting controls, auditing and reporting.

Miati · 03-17-2015, 05:09 PM

Quote:

Originally Posted by unSpawn

With all due respect but isn't that an assumption? ;-p

Lol, ok. Here's my quick idea on getting around any restrictions placed "once logged in"

Code:

(ssh host) &> log

then on another terminal

Code:

tail -f log

A full log of any activity you do, logged in real time to log. One cat command and you're good.
(Yes, I tested it

- I would of posted it to your data lifting thread but it's closed.)
I'm not sure of anyway to block that server-side since it's essentially identical to a normal ssh login except all stdout/error is being redirected to a file.
Since you can just follow it in another terminal (tail -f) it would only minimally slow you down for a moment as you set it up and following probably require a clean of "extra" data.

Quote:

Not really as you can rent whole rooms of eyeballs and keyboards for cheap: look for example at how some captcha problems are "solved".

When the original difficulty was a mere typing of the command ssh host 'cat file' > file, that is more difficult. Renting a entire room and staff to copy a 100mb text file seems like a lot of mundane work and satisfies my requirement for "lot harder"

iksrazal · 03-17-2015, 09:35 PM

Quote:

Originally Posted by Miati

This is just a possibility, but you could require a su to access the files. This would require a login to shell and couldn't easily permit local copying.

We do require a su but I couldn't get those config ideas to stop this command below, was that the idea? Maybe I didn't do something right?

Code:

-rw------- 1 myfileuser file_access 8 Mar 17 09:27 /home/myfileuser/confidential.txt

ssh -t -l myuser 192.168.0.100 'sudo -u myfileuser cat /home/myfileuser/confidential.txt' 
Password: 
myfileuser's password:
my confidential info

This redirect did hang however, was that the intent of requiring sudo and AllowGroups?

Code:

ssh -t -l myuser 192.168.0.100 'sudo -u myfileuser cat /home/myfileuser/confidential.txt' > local_copy.txt

In any event, the sysadmin remains against SSH even after discussing AllowGroups. Possibly because...

Code:

(ssh host) &> log

I was hoping to find a way to prevent that type of thing. Guess I'm not in luck.

Quote:

Originally Posted by Miati

When the original difficulty was a mere typing of the command ssh host 'cat file' > file, that is more difficult. Renting a entire room and staff to copy a 100mb text file seems like a lot of mundane work and satisfies my requirement for "lot harder"

I found lots of code that makes captcha solving via an image trivial - and our known screen font or console makes that simpler than a captcha.

http://scraping.pro/example-captcha-solver-java/

I asked the sysadmin that if I could easily code a screenreader of a screenshot of our data being read, would it influence his thinking? It would not, he said.

He did say though that its possible to have something like the Linux Terminal Server Project where I'd have a locked down Linux desktop in our datacenter, and "SSH is a non-starter" .

Miati · 03-17-2015, 11:36 PM

A lot of what the sysadmin is wanting sounds a lot like digital rights management (DRM) so that you can see but not copy.
I wouldn't have to throw a rock too far to identify various DRM technologies (and just as easily, methods of circumventing them)

But it's existence in linux is very minimal (thank goodness!). Tools like ssh are designed to give you more access, not less access. They do their job and they do it well. Because of that, you are given greater freedom in how you use it. In the same way, preventing those exact same freedoms becomes just that much harder.

There is one possibility that comes to mind though (requiring that the client be controlled though)
Should the client be running a bash shell set to restricted, they would be unable to redirect content.
This means (in theory) that the restricted bash could access the server and yet not be able to "get around" by redirecting the shell.
It conveniently makes everything significantly more difficult (who needs to change directory anyways?)

Code:

RESTRICTED SHELL
       If bash is started with the name rbash, or the -r option is supplied at invocation, the shell becomes restricted.  A restricted shell  is  used  to
       set up an environment more controlled than the standard shell.  It behaves identically to bash with the exception that the following are disallowed
       or not performed:

             changing directories with cd

             setting or unsetting the values of SHELL, PATH, ENV, or BASH_ENV

             specifying command names containing /

             specifying a filename containing a / as an argument to the .  builtin command

             specifying a filename containing a slash as an argument to the -p option to the hash builtin command

             importing function definitions from the shell environment at startup

             parsing the value of SHELLOPTS from the shell environment at startup

             redirecting output using the >, >|, <>, >&, &>, and >> redirection operators

             using the exec builtin command to replace the shell with another command

             adding or deleting builtin commands with the -f and -d options to the enable builtin command

             using the enable builtin command to enable disabled shell builtins

             specifying the -p option to the command builtin command

             turning off restricted mode with set +r or set +o restricted.

TobiSGD · 03-18-2015, 06:35 AM

Quote:

Originally Posted by iksrazal

He did say though that its possible to have something like the Linux Terminal Server Project where I'd have a locked down Linux desktop in our datacenter, and "SSH is a non-starter" .

Your admin should get used to the idea that everytime I have read access to a file I can copy it by simple means, regardless if that access is granted via SSH, RDP, VNC or using LTSP. Your company should get used to the idea that this admin needs a bit of training.

iksrazal · 03-18-2015, 01:40 PM

Quote:

Originally Posted by Miati

Frankly, a more effective method would be for the sysadmin to announce that copying files is prohibited.
rather then micromanaging how people do their work.
(IMO)

Fortunately that's how it turned out in the end, at least for now.

Shell access for using VI etc will continue, but UI viewing for those that want it now requires RDP.

Thanks everyone for the help, as a lot of the comments here helped the technical discussion proceed to a happy outcome.

tibiv12 · 04-02-2018, 01:06 AM

I have not such a knowledge about the security of linux.I like your post.Thanks for sharing the informative post.