Zero noise? Probably not a good idea either, particularly for a web server. I suspect if you go for zero noise, you'll be ignoring directories that you really should be watching. The served files are likely going to change, if for no other reason than for version upgrades. Furthermore, the OS and server will have security upgrades, and you'll need to handle those. You're going to need a process to handle the inevitable changes.

You keep saying that crackers can change the file and not the checksum. Specifically, what algorithm is this vulnerable? md5? sha1? Which one(s)?

And I'm saying that considering code more secure because it is custom and undisclosed is a serious mistake. Some of the most vulnerable systems out there are closed source. Is IIS any more secure than Apache because it is closed source?

If a cracker can see the vulnerabilities, so can the good guys. What you seem to completely discount is that a lot of people have a very vested interest in keeping software secure, so security audits of open code do happen and bugs do get fixed. The fact that something is open doesn't give the crackers any additional advantage over the good guys, just like the fact that closed code doesn't give the good guys any advantages over the crackers. Security through obscurity has been repeatedly proven to be a failed security model. Unfortunately, we haven't seen the last proof.

Attackers will take whatever vulnerability they can find, whether common or uncommon. Sure, an poorly known vulnerability may give one cracker group a temporary advantage, but to be honest, programmers make the same mistakes over and over so consistently that classics like SQL injection or buffer overflow remain very viable and popular tools in the cracker arsenal.

1 members found this post helpful.

softwarelabus, by your logic Windows would be the least vulnerable OS in the known universe, while GNU/Linux and *BSD would be every administrator's worst security nightmare. Your argument about "hackers" having access to free software source code may sound appealing in theory, but in practice it's about as far from reality as you can get. As has already been stated here numerous times, security through obscurity has been historically proven to be a failed model.

You also seem completely convinced that adding your shell script will undoubtedly increase your level of security. This is not true at all. There could be numerous reasons why such an action could actually have detrimental effects. For example, I would argue that the false sense of security you've developed alongside your script idea is your greatest vulnerability of all.

Furthermore, you seem hellbent on re-inventing the wheel, which is not only a waste of time/energy, but can also lead to disaster. The high probabilities of this being the case here are made evident when you make statements like:...which would indicate a lack of basic understanding on your part of the extreme technical difficulty involved in such a feat (broken algorithms aside). Yet here you are, putting together some dubious shell script based on a technique that has absolutely no factual basis and is festooned with security through obscurity – all while there's tons of excellent, full-featured, free software out there which has received years of peer review.

Watch it--- one of the moderators here is a coauthor of another widely used linux security utility. So you might step on toes if you pursue that idea.

... reading on ... oh, I was too late...

HBGary? Did someone say HBGary? That's like waving a red flag! If anyone would like to discuss the many many lessons of the HBGary scandal, we can start a thread in the General forum. Not here, because the subject is politically charged.

It's been a long day, but there's a connection to Hangdog's point about the dangers of insecure custom code, since I am calling for sysadmins everywhere to exercise their ingenuity by writing custom passive monitoring code they disclose to no-one, with the goal of getting some information about who is really messing with their networks (traditional for-profit-cybercriminals? rogue spycos like HBGary Federal? cyberwarriors foreign or domestic? "hacktivists"?)

0 members found this post helpful.

Sorry, I disagree, but that's not the point of this thread. Fact still remains that having access to source code gives a hacker an advantage. Arguing against such logic only makes you appear a bit suspicious in your intent here.


You still don't acknowledge the concept. It's a tendency. Read what it means. You can't point out a company and use that to stereotype a concept. Doesn't work that way. There are not that many commercial OS's, so it's results a bad average. Try using open-source CMS vs commercial to obtain a proper average. Lets at least be scientific here.



Silliness. I already said *adding* my script to existing security would not give me any more sense of security. BTW, you & your friend still have not pointed out a single vulnerability in my script.



It's unique in that it's custom & undisclosed code.

0 members found this post helpful.

To clarify this thread, I'm advising SA's to *add* custom code, not replace their exiting security.

Essentially, what the opponents want is for SA's to just install existing open-sourced security code, and leave it at that, code that every hacker in the world can analyze. If an SA has some strong programming skills, and some ideas how to write security code that's geared only for his or her server, then go for it. Adding extra security would not make me less cautious.

The cksum bin on unix-like OS is easily defeated. As for scanning an entire server with MD5 pretty much means you have a dead server for ages. That does not seem like an option. The checksum bin would have to be comparable to cksum in performance.

softwarelabus: look for some of my recent posts, discussing pretty much the same things which I think concern you. I even suggested that everyone should write their own code, on the theory that the more variety, the more impossible it will be for our adversaries (conventional for-profit cybercriminals, state-sponsored cyberwarriors, and some would add, spycos working for the Surveillance State, maybe "hacktivists") to keep up.

Okay, if security through obscurity is your thing, then so be it. While most of us disagree with your views, it's not our job to try and change them, and this endless back and forth is getting ridiculous, and now even threatens to enter into TFH territory. So, moving on...Is it a hardware limitation you're dealing with? I've had Tripwire set to check using multiple algorithms (SHA256, SHA1, MD5, CRC32, etc.) and have not experienced any deaths. Have you actually tried it or are you just assuming? BTW, keep in mind that using only MD5 would be risky, as it's broken. Using it alongside the other algorithms is fine, though, as it exponentially increases the difficulty of generating a collision (as it would need to trick all checks).

Again, I'm advising the *addition* of custom undisclosed code.



Yes, MD5, SHA1, etc are terribly cpu intensive compared to cksum. cksum is not cryptographically secure. It has nothing to do with my server, rather everything to do with not bogging down a shared web server. It would have terrible consecutive on websites as the script performed MD5 sums on the entire OS, lol. If you know of a relatively easy way of forcing the server to limit the scripts cpu usage for md5sum scans, then please by all means let me know. Obviously md5 is better than cksum. BTW, limited the number of md5sums per minute is not an option, as each single md5sum per file can take far too long. The only option for me is to somehow limit the scripts cpu usage.

TFH means..."troll for hire"? Did I guess right?

0 members found this post helpful.

That's good to hear. I think this trend will slowly take off in the SA's community. That is, if they care about the data of 1000's of customers.

I also think the *probability* of hackers trying to hit the forums to deter people from doing this is relatively high. My advice is that people start to think for themselves rather than being so influenced by group consensus because that opens a huge vulnerability, as hackers can hit a thread, thus making it appear as if mass majority are against something. People might want to consider the fact that I'm being hammered against even advising people to *ADD* custom undisclosed security scripts. I'm not pointing out names or accusing anyone because you can't be certain, but it is a bit odd. IMO, their premise is just outright illogical.

0 members found this post helpful.

Seriously, if you think cksum is an appropriate method to use here, there is nothing any of us can do to help you. Good luck on your project, you are really going to need it.

2 members found this post helpful.

Again, by all means point out the vulnerability in my script idea.

I already have. And win32sux has as well. You just don't seem to be receptive even in the slightest to different ways of thinking, so what is the point in further discussion?

1 members found this post helpful.

Lets please leave the personal ad hominem out of the discussion. If you've already posted it, then why not copy & paste it?

0 members found this post helpful.