The Six Dumbest Ideas in Computer Security

Frater 219 writes "The IT industry spends a huge amount of money on security -- and yet worms, spyware, and other relatively mindless attacks are still able to create massive havoc. Why? Marcus Ranum suggests that we've all been spending far too much time and effort on provably ineffective security measures. It may come as a surprise that anti-virus software, penetration testing, and user education are three of "The Six Dumbest Ideas in Computer Security"."

Comments

Dumbest security policies?

[Anonymous Coward]

What are some of the dumbest security *policies* you've encountered?

I worked for a firm earlier where we had to change our passwords every week where the password had to 1) be exactly 14 characters and 2) be ~60% different to the previous four passwords.

The result was of course that almost every user had their passwords on post-it notes.

On my webservers...

[Space cowboy]

I patch PHP to set a constant in the namespace of the script whenever a 'dangerous' function is called (eg: system(), shell_exec, the backtick operator etc., others :-). The webserver also prepends (php.ini: auto_prepend_file) a PHP file that registers a shutdown-hook. Those constants can then be examined in the shutdown hook code to see if any of the dangerous functions have been called, and if so, check to see if *this* script is allowed to call them.

If the script is allowed to call the functions, all well and good, it's just logged. If not, the offending IP address is automatically firewalled. I purloined some scripts from the 'net that allow shell-level access to manipulate the firewall.

So, now I had a different problem - the webserver wasn't running anywhere near the privilege needed to alter the firewall, and I didn't want to just run it under sudo in case anyone broke in. I wrote a (java (for bounds-checking), compiled with gcj) setuid program that takes a command string to run, an MD5-like digest of the command, and a set of areas to ignore within the command when checking the digest. The number of areas is encoded into the digest to prevent extra areas being added. If the digest doesn't match, the program doesn't run. This is a bit more secure than 'sudo' because it places controls over exactly what can be in the arguments, as well as what command can be run. It's not possible to append ' | my_hack' as a shell-injection.

So, now if by some as-yet-unknown method, you can write your own scripts on my server (it has happened before, [sigh]), you're immediately firewalled after the first attempt - which typically is *not* 'rm -rf /' :-) Perl and Python are both unavailable to the webserver uid, so PHP is pretty much the obvious attack vector.

Well, PHP and SQL injection of course, but the same script is used there - if the variables being sent to the page are odd in some way (typically I look for spaces after urldecoding them as a first step - SQL tends to have spaces in it :-), then the firewall is called on again. It's all logged, and the site-owners get to see when and why the IP is blocked. Sometimes it's even highlighted problems in their HTML :-)

What would be nice would be a register within a PHP script that simply identified which functions were called. In the meantime, this works well for me...

Just thought I'd share, because it's similar to what the author is saying regarding only trusting what you know to work, and everything else gets the kick (squeaky wheel-like :-)

Simon

One good point this article makes

[suitepotato]

is the permit by default tendency. This is like having a fence that springs out of the ground only when certain people are sensed approaching it. It needs to be up and topped with barbed wire and the only gate needs to be locked until someone is given a key to it. NAT routers are like that. They can only forward traffic when you bother telling it to and until then sit there stupid making you wonder why your new SSH installation won't talk to the outside world.

OTOH, it is a collosal pain in the arse to deny all traffic and only allow what you want because so much code is network aware these days and designed to talk to some place across the net. Then again, it does tell you which apps are communicating in the first place.

On my Windows boxes I use Sygate Personal Firewall to create a specific list of allowed executables and block everything else with a block all entry at the bottom of the fall-through list. No match, no talk. Inbound and out. Combined with NAT it makes for very little traffic reaching my internal network. When I leave my desk for the night and Windows is running, remove a few check marks and save and it only allows the file sharing app to talk and I keep that updated and locked down at all times.
It also can be set to approve or deny execution of code that may have changed since last allow/deny challenge.

That which is not forbidden is not only not compulsory, but probably suspicious.

Re:zerg

[Kymermosst]

Unless they ban the movie Hackers and eradicate all copies of it everywhere, they're not gonna make hacking uncool...

Don't forget Sneakers, which was way cooler (IMNSHO) than Hackers.

Re:Real security has to be build into the foundati

[Alex Brasetvik]

noexec can be easily circumvented. Read here for more information.

Relevant example:


              alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
              alex@joker:/tmp# ./date
              bash: ./date: Permission denied
              alex@joker:/tmp# /lib/ld-linux.so.2 ./date
              Sun Dec 3 17:49:23 CET 2000

Re:A much bigger problem

[Johnny Mnemonic]

We give our users Mac laptops, which largely corrects this issue.