Comment Re:smoothwall--readable files (Score 1) 296
Yes, this _is_ a big deal.
This firewall can be administered remotely. As far as I understand, this can happen via a web server. You do not have to "log in" to the firewall to break it. It is enough to convince an application running on it to do it for you. And btw, "logging in" just means that you convince some trusted application (sshd, login, and so on) to spawn a shell process for you. You do that _somehow_, not necessarily following the protocol it tries to implement. If you're an intruder, you'll maybe exploit a bug in the implementation.
As the httpd seems to be running as user nobody, you can try to make it read/change all these files owned by nobody. Plus any world readable/writable files, of course.
The point is that you do not deactivate security mechanisms just because you think they are redundant (because you hink another security measure already takes care of it). Redundancy is a primary strength of any secure system (not only with computers).
Build "defense in depth". Don't create single points of failure.
It is always possible that there is a bug in an implementation.
It is always possible that someone can think of a way to break your security that you have not thought of.
It is always possible that a person administering, or equally likely a person in the interior network, inadvertently, intentionally, or by beeing fooled (think trojan horses delivered by mail, social engineering, ...) opens up a hole.
If you have only one security measure you trust, you are fucked in all these cases.
If you have several measures that have to be broken one after the other, AND IF YOU KEEP GOOD LOGS AND LOOK AND THEM REGULARLY, then you may notice the intrusion attempt.
To deactivate standard measures such as shadow passwords is particularly moronic.
And to prove the point, c't have now broken this firewall design.
I want to comment on another thing that came up in the original thread, which was by far the most depressing thread I ever read on Slashdot, starting with the posted article itself.
This is the claim that "it just has to get the job done".
This is not wrong in itself, but you have to think what job this is. Quick installation is not your goal, but securing your network is, and this must define what you are going to do. An out-of-the box installation whose workings and weaknesses you don't understand likely will just hurt your users (by denying them some internet services, for example) and the attackers will only laugh about it. A standard installation may protect you against known standard tools as used by script kiddies, but not much more than that. This may be convenient, but it has little to do with security.
This firewall can be administered remotely. As far as I understand, this can happen via a web server. You do not have to "log in" to the firewall to break it. It is enough to convince an application running on it to do it for you. And btw, "logging in" just means that you convince some trusted application (sshd, login, and so on) to spawn a shell process for you. You do that _somehow_, not necessarily following the protocol it tries to implement. If you're an intruder, you'll maybe exploit a bug in the implementation.
As the httpd seems to be running as user nobody, you can try to make it read/change all these files owned by nobody. Plus any world readable/writable files, of course.
The point is that you do not deactivate security mechanisms just because you think they are redundant (because you hink another security measure already takes care of it). Redundancy is a primary strength of any secure system (not only with computers).
Build "defense in depth". Don't create single points of failure.
It is always possible that there is a bug in an implementation.
It is always possible that someone can think of a way to break your security that you have not thought of.
It is always possible that a person administering, or equally likely a person in the interior network, inadvertently, intentionally, or by beeing fooled (think trojan horses delivered by mail, social engineering,
If you have only one security measure you trust, you are fucked in all these cases.
If you have several measures that have to be broken one after the other, AND IF YOU KEEP GOOD LOGS AND LOOK AND THEM REGULARLY, then you may notice the intrusion attempt.
To deactivate standard measures such as shadow passwords is particularly moronic.
And to prove the point, c't have now broken this firewall design.
I want to comment on another thing that came up in the original thread, which was by far the most depressing thread I ever read on Slashdot, starting with the posted article itself.
This is the claim that "it just has to get the job done".
This is not wrong in itself, but you have to think what job this is. Quick installation is not your goal, but securing your network is, and this must define what you are going to do. An out-of-the box installation whose workings and weaknesses you don't understand likely will just hurt your users (by denying them some internet services, for example) and the attackers will only laugh about it. A standard installation may protect you against known standard tools as used by script kiddies, but not much more than that. This may be convenient, but it has little to do with security.
