Is it possible to prevent SCP while still allowing SSH access?
Solution 1
While you could edit your /etc/ssh/sshd_config
to look something like this:
ForceCommand /bin/sh
PermitOpen 0.0.0.0
AllowTcpForwarding no
PermitTunnel no
# Subsystem sftp /usr/lib/openssh/sftp-server
PermitUserEnvironment no
I would instead determine what the user is likely to use it for. Because if there are only a few commands that you want them to have access to, I would instead remove the ability for them to even invoke a normal ssh
shell.
AllowUsers root
PermitRootLogin forced-commands-only
PermitUserEnvironment no
AllowTcpForwarding no
PermitTunnel no
# Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem smb-reload /usr/bin/smbcontrol smbd reload-config
Subsystem status /opt/local/bin/status.sh
ssh root@example -s smb-reload
If you find that you really do need to be able to run a normal shell, the most you really can hope for, is to slow them down, and make it more difficult.
Solution 2
As others have noted, you can't block scp (well, you could: rm /usr/bin/scp
, but that doesn't really get you anywhere).
The best you can do is to change the users' shell to a restricted shell (rbash) and only then to run certain commands.
Remember, if they can read files, they can copy/paste them off the screen. Binary files? xxd/uuencode/mmencode all get around this.
I'd also suggest using process accounting to help you track activity.
Solution 3
Depending on what SSH is needed for, you may be able to achieve this goal (for non-trivial) files by using IPTables to terminate sessions if the packet size is bigger then, say 1400 bytes. This means that interactive ssh will mostly work, but as soon as something tries to send a 1500 byte packet - like scp should for a file larger then 1499 bytes assuming a standard MTU of 1500, it will terminate the connection.
This will also prevent the "catting" attack you mention.
Unfortunately this means that you may have problems editing some files with a text editor, if the screen needs to draw more then 1400 characters, or if you need to cat a long file or do a long directory listing.
In the simplest case a command to do this might look something like
iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff -j DROP
We can make this work better by combining the packet length checks with ipt_recent, so that you allow a limited number of packets larger then 1400 bytes within a set timeframe (say 8 packets per 5 seconds)- this would allow packets up to 12k to slip through, but may give you the interactivity you will need for editing files etc. You can, of course, tweak the number of packets.
This might look something like
iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
-m recent --name noscp --rdest --set
iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
-m recent --name noscp --rdest --update --seconds 5 --hitcount 8 \
-j REJECT --reject-with tcp-reset
The rule examples above only protect against scp uploads such as scp myfile.data remote.host:~
. To additionally protect against scp downloads such as scp remote.host:~/myfile.data /local/path
, repeat the above rules but replace --dport
with --sport
.
A clueful hacker can work around these limitations by setting an MTU of less then 1400 on his machine (or force mtu or similar). Also, while you can't limit this to certain users, you can limit it by IP by modifying the iptables lines as appropriate !!
Cheers, David Go
Solution 4
You gain nothing by stopping "scp" when you're still allowing literally infinite additional mechanisms of transferring files. Disallowing scp but allowing other mechanisms of copying files is a method of lying to auditors. Often auditors ask to be lied to. Usually I see auditors working with managers to make fake fixes, so that they can state something like "the scp file transfer command has been disabled, so that files can not be copied from the server using scp".
Now a reasonable logging mechanism would be nice. Maybe auditd finally works on Linux. Maybe Solaris finally added some mechanism or dtrace could be used safely. It's reasonable to want the OS to log every time a file is accessed. Of course there's no difference between "reading" and "copying". But this can satisfy an auditor and give significant security to the system. Your logs could be so noisy that the data is useless, or even that you're forced to keep a ridiculously short audit trail. (e.g. you can't log every read() - and one application that does something surprising can make logging every open() a disaster).
Solution 5
Your best bet isn't to lock down scp, but to use a file system with ACLs to prevent read access. You could probably do something with SELinux to prevent certain applications from reading from certain files.
Related videos on Youtube
Mike Holdsworth
(Last updated 2018-08-28.) http://stackoverflow.com/questions/1825585/how-to-determine-what-version-of-powershell-is-installed/1825807#1825807 Experienced application developer. Software Engineer. M.Sc.E.E. C++ (10 years), software engineering, .NET/C#/VB.NET (7 years), usability testing, Perl, scientific computing, Python, Windows/Macintosh/Linux, Z80 assembly. My other accounts: iRosetta. [/]. Stack Overflow (SO). [/]. Server Fault (SF). [/]. Super User (SU). [/]. Meta Stack Overflow (MSO). [/]. Careers. [/]. Other My 15 minutes of fame on Super User Blog. Sample: Jump the shark. LinkedIn profile @PeterMortensen (Twitter) Google profile Quora profile GitHub profile Full jump page with other SOFU related, Stack Exchange sites, etc. Contact I can be contacted through this reCAPTCHA (requires JavaScript to be allowed from google.com).
Updated on September 17, 2022Comments
-
Mike Holdsworth over 1 year
Using Solaris and Linux servers and OpenSSH, is it possible to prevent users from copying files using "scp" while still allowing shell access with "ssh"?
I realize that 'ssh $server "cat file" ' type file accesses are much harder to prevent, but I need to see about stopping "scp" for starters.
Failing that, is there a way to reliably log all SCP access on the server side through
syslog
?-
Admin almost 15 yearsIf you wanted to close ssh but not scp you could have used this: sublimation.org/scponly/wiki/index.php/Main_Page Too bad you want it the other way around :-\
-
-
user28859 almost 15 yearsYes, the obvious answer would be to lock up the system and not give out access. In reality however, my company has auditors who say that we need to prevent files from being copied off of the servers and / or log attempts despite the fact that we seriously limit ssh access and have a robust RBAC system in place.
-
derobert almost 15 years@Jason: Then you need to log file access. Even if you disabled scp, how would you stop someone from running: ssh server 'cat /path/to/file' > copy ?
-
msanford almost 15 yearsOr you could do both.
-
Tyler Dumont almost 15 yearsProcess accounting helps a bit, but the historical process accounting was really useless (e.g. logging only the basename of the command run). I'd like to hear about any modern successes with process accounting that is actually useful.
-
Steve Townsend almost 15 yearsHow about using a patched restricted shell that also logs all commands run to a pipe somewhere? A centralized .bash_history kind of idea.
-
Brad Gilbert almost 15 yearsActually on the server side you would have to delete /usr/lib/openssh/sftp-server, but I think sshd has a built in sftp server.
-
Steve Townsend almost 15 years@Brad: Any commands specified by the client are still run via the shell; so if sftp-server isn't in the default PATH (which it's not) changing the shell to a restricted one is enough to disable it, you don't have to delete the binary.
-
nutax over 7 yearsThis link is dead.
-
IceArdor over 7 years
-
symcbean almost 4 yearsI'm not familiar with the details of Solaris but would be urprised if it is significantly different from Linux, where its possible to make /home and /tmp seperate mounts with noexec and thereby prevent running executables apart from places where you control the permissions. But yes , there are still lots of ways to get non-executable files onto the device. This is still not a complete solution though as a sophisticated attacker could still tinker with LD_LIRARY_PATH to incoproate a binary lib into an existing executable. Still, at least its not MS-Windows :)