Quote:
Originally Posted by Hangdog42
(Post 4385214)
I think because that answer is dependent on many factors specific to your installation. The knee-jerk answer is everything, but that is likely to generate a huge signal to noise ratio. What is your tolerance for investigations everytime something changes? So if you eliminate folders (maybe like /tmp) that change a lot, you'll reduce the noise, but give the crackers a place to hide stuff. We can't answer these sorts of questions for you because the answer is completely dependent upon your own needs and tolerance for risk.
|
Okay, but I think the only acceptable result is zero noise. Files that change a lot such as log files wouldn't be scanned. Indeed, the hacker could replace a log with a bin and I wouldn't see it, but a main goal is to prevent the web server from being hacked, that includes PHP & Python files, and Apache bin files. The script will scan such files.
Quote:
Originally Posted by Hangdog42
(Post 4385214)
There is a difference between underestimating the crackers and granting them superhuman abilities. So lets go review you're original post:
|
When Google email gets hacked, it seems superhuman to a lot of people, lol.
Quote:
Originally Posted by Hangdog42
(Post 4385214)
Here you are talking about splitting the files and doing checksums on the separate bits because you are afraid a cracker might alter a file and pad out the bytes to make it the same size. and therefore evade the checksum scans. What I am saying is that if you use a decent algorithm to start, splitting the files is completely and totally unnecessary. ANY change to the file will be detected by a whole file checksum.
|
Sorry. The hacker would pad the file with code, and strip unnecessary bytes to obtain the same net checksum. Very easy!
Quote:
Originally Posted by Hangdog42
(Post 4385214)
Furthermore, for every split you propose (50-50, 70-30, 51-49), you will have to have a pre-existing set of data for comparison. That means that you can't just randomly make up a new percentage on the fly because you never would know if the checksums were valid or not. So essentially, you're creating a ton of additional work for zero security gain. So no, I'm not agreeing with you at all. I'm saying your multiple checksum idea is a waste of time and effort compared to a single checksum.
|
Not a waste of time. Hackers can edit a file without changing the entire files checksum. So the script does two things. First, it verifies the previous scan, and obviously it would remember what the previous scan %'s are, e.g., (50-50, 70-30, 51-49). That's easy enough. Second, it records a new scan.
Quote:
Originally Posted by Hangdog42
(Post 4385214)
Then maybe you ought to try thinking harder. Your assertion throughout this thread is that undisclosed code is secure code. I'm saying that is a dangerous and completely incorrect assertion. The HBGary example proves that undisclosed code can have very, very large security holes that even script kiddies can exploit.
|
I never said it's "secure code." I have essentially said that customized undisclosed code has the potential of being *more* secure. Also, I fail to see your point except that you're saying nothing in life is guaranteed. Agreed, lol!
As for being dangerous, come on, adding security is safer, not more dangerous. Does it seem like it would make me feel secure & at ease? Come on man, I'm paranoid! Haha
Quote:
Originally Posted by Hangdog42
(Post 4385214)
Any code that is exposed to users in any manner is potentially vulernable. People will try all sorts of crap on it. And they don't need to see the code to make that job easier.
|
Hmmm, so now you're saying that if a hacker can see the source code, that it does not help them find vulnerabilities. What school of logic is that from? You might want to rethink that one, my friend.
Quote:
Originally Posted by Hangdog42
(Post 4385214)
Normal attack vectors like SQL injection or buffer overflows require absolutely no knowledge of the underlying code. They just require some sort of input form. Other vectors, like man-in-the-middle only require that communications occur over a network. Again, no knowledge of underlying code needed.
|
I agree, that's a common and well known attack that's preventable by using SQL prepared statements. :) It's the uncommon attacks that I'm concerned about. Attacks that hackers don't want the public to know about.