You'd have to get rid of everything capable of displaying file contents to stdout, and everything capable of writing its stdin to stdout, and by the time you've removed all of those there's so little left that there's no point to allowing shell access at all. Also, while you can't limit this to certain users, you can limit it by IP by modifying the iptables lines as appropriate !!īlocking file transfer without removing so many system utilities as to leave the machine completely useless is impossible. To additionally protect against scp downloads such as scp remote.host:~/myfile.data /local/path, repeat the above rules but replace -dport with -sport.Ī clueful hacker can work around these limitations by setting an MTU of less then 1400 on his machine (or force mtu or similar). The rule examples above only protect against scp uploads such as scp myfile.data remote.host:~. m recent -name noscp -rdest -update -seconds 5 -hitcount 8 \ Iptables -I OUTPUT -p tcp -dport 22 -m length -length 1400:0xffff \ This might look something like iptables -I OUTPUT -p tcp -dport 22 -m length -length 1400:0xffff \ You can, of course, tweak the number of packets. 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. 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 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. This will also prevent the "catting" attack you mention. 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. you can't log every read() - and one application that does something surprising can make logging every open() a disaster).ĭepending 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. Your logs could be so noisy that the data is useless, or even that you're forced to keep a ridiculously short audit trail. But this can satisfy an auditor and give significant security to the system. Of course there's no difference between "reading" and "copying". It's reasonable to want the OS to log every time a file is accessed. Maybe Solaris finally added some mechanism or dtrace could be used safely.
Now a reasonable logging mechanism would be nice.
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". Disallowing scp but allowing other mechanisms of copying files is a method of lying to auditors. You gain nothing by stopping "scp" when you're still allowing literally infinite additional mechanisms of transferring files.
0 kommentar(er)
