``You do not want to overbuild your security or you will interfere with the detection side, and detection is one of the single most important aspects of any security mechanism. For example, it makes little sense to set the schg flag (see chflags(1)) on every system binary because while this may temporarily protect the binaries, it prevents an attacker who has broken in from making an easily detectable change that may result in your security mechanisms not detecting the attacker at all.'' Wouldn't it be better to detect /and/ prevent an attempt to change the system binaries? It seems to me that advising people to focus on detection rather than prevention is wrong-headed. What are you going to do after you detect the attacker? If it's not "prevent him from doing anything", then I question the intelligence of this approach. Root-level compromises don't always get detected immediately, don't always get caught, and once they're in, the playing field is level, and they are very time-consuming to investigate and clean. For example, I know someone with a rootkit that he can install to flash on an add-in card for a device that has DMA access to main memory. For this reason, I usually recommend on prevention as a first priority, and detection as a second priority. For example, Markus Ranum said he once recompiled ls to reboot if it is run by root. Another trick involves recompiling /bin/sh to check to see if it has a tty (shells spawned by network daemons will generally not). Perhaps there is some way to locate any part of the kernel that performs access control and optionally klog the details, so that any actions which are denied also automatically detect possible intrusions? Hmm, I should mention this to elad efrat, who is doing kauth work on NetBSD... -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
On 9/6/06, Travis H. <solinym@gmail.com> wrote:> It seems to me that advising people to focus on detection rather > than prevention is wrong-headed. What are you going to do after you detect > the attacker?And, if your answer is "prevent further intrusions by doing foo", allow me to point out that if you had taken that preventative foo step up front, you wouldn't ever have had to think about it. Now, if you're administering a LAN full of Windows hosts, I think that detection may be your only workable option, or maybe the cheaper option. There is a similar debate on monitoring outside vs. inside the firewall. I'd prefer to do both, but if you have to choose one, I'd do inside, because I don't care how long people beat in futility on the outside. Since knowing wouldn't change how I behave, there's no point in spending effort or time to monitor it. Coincidentally I also thought of the NFS-exported file system checked by a remote system. I always thought you could set a trap by placing a file whose purpose was to pique the intruder's interest enough for him to try reading it. You could monitor the inode times via NFS and trigger an alert if it changes. Another thing one could do is build a Live! CD that you boot periodically to check the system for signs of an intrusion. All the tools would basically be unknown to an intruder. Persistent state could be stored on a flash drive or other removable storage. That may well be the only way to be sure that the detection tools are not compromised, or that the intruder is clever enough to trick any remote monitoring. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
"Travis H." <solinym@gmail.com> writes:> ``You do not want to overbuild your security or you will interfere > with the detection side, and detection is one of the single most > important aspects of any security mechanism. For example, it makes > little sense to set the schg flag (see chflags(1)) on every system > binary because while this may temporarily protect the binaries, it > prevents an attacker who has broken in from making an easily > detectable change that may result in your security mechanisms not > detecting the attacker at all.''Uh? Since when do we have crap like that in the handbook? It should be removed with extreme prejudice. DES -- Dag-Erling Sm?rgrav - des@des.no
On Wed, 6 Sep 2006, Travis H. wrote:> ``You do not want to overbuild your security or you will interfere > with the detection side, and detection is one of the single most > important aspects of any security mechanism. For example, it makes > little sense to set the schg flag (see chflags(1)) on every system > binary because while this may temporarily protect the binaries, it > prevents an attacker who has broken in from making an easily > detectable change that may result in your security mechanisms not > detecting the attacker at all.'' > > Wouldn't it be better to detect /and/ prevent an attempt to change the system > binaries?That's how I interpret that passage from the handbook - that you should detect *and* prevent. I'm not clear on how anyone is interpreting that passage to suggest that unequal weight should be given to one side or the other (detection vs. prevention). The above passage all but says, "don't do X because that will interfere with Y." I just don't see that advice as advocating imbalance.> It seems to me that advising people to focus on detection rather than > prevention is wrong-headed. What are you going to do after you detect > the attacker? If it's not "prevent him from doing anything", then I > question the intelligence of this approach.I find that extreme examples are good at illustrating points. I think that everyone can agree that we cannot prevent 100% of attacks; if we could, we wouldn't be having this discussion. In the extreme case where we take absolutely every possible preventative security measure, logically, the only attacks that can succeed are those that we didn't know about, that we did not foresee, and thus that we could not prevent against. In those cases, where you're hit by attacks that you didn't know existed, the importance of detection probably rises. In fact, in the case of attacks (and possibly vectors) that you weren't aware of, I would argue that detection can be a prerequisite of prevention. Oh, there are examples where it's not: I can prevent all of the network attacks that I don't know about by unplugging the host from the network. But in the cases where you cannot remove or mitigate the attack vector (eg. because to do so would interfere with availability vs security), it seems to me that prevention needs detection. -- "I don't think they could put him in a mental hospital. On the other hand, if he were already in, I don't think they'd let him out." finger://bigby@home.ephemeron.org http://www.ephemeron.org/~bigby/ irc://irc.ephemeron.org/#the_pub news://news.ephemeron.org/alt.lemurs