Some of the members that frequent this forum spend most of their time performing incident response. Those who did, and some have done that the past decade here at Linuxquestions.org, have found themselves confronted with a wide variety of breaches of security and a changing threat-scape. Based on their personal knowledge and practical experience with auditing and solving security whodunits those members may post advice or solutions that go well beyond what a member may ask for in his or her OP. And I trust win32sux and Hangdog42 to give quality security advice.

Now, because you keep focusing on one minor aspect could it be that (since you have been away for that long) you no longer possess a good view on Linux security (as in threats, hardening and auditing)? Sure checking hashes is a standard part of auditing server security but it is just one aspect (and some of the things you're talking about like servers-stored hash databases and binary, configuration file and database encryption are already done: see Samhain). Could it be you do not actually know what kind of threats you will be dealing with and their common solutions?

1 members found this post helpful.

Of course. Again, I'm talking about *adding* security, not replacing it. That being said, win32sux and Hangdog42 have not pointed out any vulnerabilities in my method.

0 members found this post helpful.

No, it's entirely different concept. I keep pointing out that's open-source code, while the entire point of my script is that it would be custom and undisclosed code.



I probably know a lot more than you might think I know. It's been a long time since doing SA work, but as a software engineer, website developer and owner of numerous websites for over a decade I've dealt with Internet security. When two guys start telling people that adding a simple checksum script that merely checks for file changes is going to decrease my security is when I know something odd is happening.

I'm still waiting to see the vulnerabilities in my script idea.

0 members found this post helpful.

I don't know anything about cybersecurity except what I read in the IT news and a few books, so I'm perfectly suited to ask stupid questions.

Tripwire (for example) does that and much more (agreed?), so your custom script will check up on what Tripwire finds? Is that the idea?

You can configure tripwire to ignore log files. Everyone should tail their log files, and look over the suitably filtered entries, independently of running an IDS.

You could take a look at what Tripwire does; that should give you plenty of ideas.

Wouldn't a better idea be to use multiple "integrity hashes" such as SHA-256 and some others, for each file? It seems to me that this would be more likely to detect an attempt to change the file but not the checksum.

Yes, you don't want your database to be accessible in your server to the hypothetical cracker who gets into your server.

Another possibility would be to encrypt it, using a passphrase not stored on the server in any form, which you manually type in each time you run the script. (If your intent is the check the integrity checker, say Tripwire, you might as well let Tripwire run daily and only run your custom script when you feel squirrelly.)

You are not trying to detect loadable kernel module trojans, correct?

Strictly speaking, wouldn't it be more correct to say that you are trying to detect possible replacements of executable files with maliciously modified variants? And that the kind of intrusion you envision probably attacks vulnerable unpatched applications, rather than the Linux kernel?

I think the point is that goofs in open source code are far more likely to be noticed and brought to the attention of the author. In the nicest possible way. Goofs in closed source code are likely to be noticed only long after the cracker has come in and exfiltrated the good stuff.

Pet peeve: since when do we computer enthusiasts let the mass media get away with the incorrect substitution of "hacker" for "cracker"?

A hacker is someone who can quickly put together an elegant program which works as designed. (The term is ironic, because it refers to good work, not hack work.) A cracker is someone who cracks open servers. Analogous to a safecracker.

Yes, the already mentioned HBGary scandal confirmed what many had long suspected, that low level operatives of the Surveillance State (and probably, Microsoft and some other companies which can't decide whether they want to kill Linux or buy it) employ "astroturfing" software to skew discussion in places like LQ in the directions they prefer. Or to spread FUD in an attempt to disrupt innovations which threaten their interests. So wise LQ readers expect to see some "probable astroturfing", and try not to take offense if they are sometimes suspected of same.

Excuse me? Are you accusing LQ members of deliberately misinforming people about security practices?

1 members found this post helpful.

Do realize that I don't deal with hearsay, assumptions or fiction: I only deal with facts. I can only determine what you know by what you show evidence of.

These days the majority of compromises no longer happens due to rootkits but through the web stack, as evidenced by the myriad of flaws in (commonly PHP-based) applications caused by RFI, LFI, database injections and such. These vectors of attack may lead to situations where you will not be able to generate hashes or where hashing makes no sense, where generating hashes lead to too many false positives or where there may be no actual hash mismatches. Before-the-fact ops like hardening and detection provide a smaller attack surface and early warning / mitigation capabilities and as such the main problem with checking hashes is it is an after-the-fact op which, if you do not question trustworthiness of the kernel or userland utilities you use for checking hashes, could lead to "interesting" results. Any (pseudo) code or anything showing you already paid attention to all of that and how you countered it could turn this discussion into something more meaningful slash interesting IMHO.

1 members found this post helpful.

Unless you are able to back up anything with well-vetted references as moderator I strongly suggest you refrain from posting anything about "the Surveillance State" or any claims about "astroturfing software to skew discussion" in this forum. Feel free to discuss this with me via the use of email, TIA.

1 members found this post helpful.

I've never seen a study on that. So it's unknown.

Regarding commercial software, it all depends on the hiring team, how picky they are in selecting their team, the software engineers, managers. Two identical software engineers, both who equally love the project they're on, where one gets paid handsomely, and other does it for free at his or her own schedule, logic dictates that the paid coder will produce higher quality code. That's just pure logic. Sure, some open source projects have a truckload of coders, but when given a good choice from both sides, I would take quality over quantity any day. More coders equates to more mistakes and crappier code.

I believe the future of open-source will be in improving the process of obtaining higher quality. They need to be far more selective in who pick to be on the team. If I owned a popular open-source project, I would be ridiculously selective. Maybe that's why FreeBSD does good work, e.g., quality over quantity. My open source project would be my way, or the highway. Then again, that's probably why my open-source project would be a ghost town, lol. So long as we live in a capitalistic society, I'm sorry to say that my preference / 1st-pick is commercial. Most of the products I use are commercial products. Don't get me wrong, I absolutely love the concept of open-source. Hey, if I ever become financially free, I'll try my best to support open-source. One requirement is that every coder must also be financially free. Doesn't hurt to dream.

0 members found this post helpful.

What makes you think that open source programmers aren't paid? Do a little googling and you'll find that there are legions of paid open source programmers. From companies like IBM, HP, Red Hat and many others. You keep asserting that paid = quality. Personally, I'd like to see some data on that because in my professional experience, that certainly has been far from a hard and fast rule. I've seen talented, paid programmers produce crap. Sometimes it is because they don't understand the target market, sometimes it is because they've become enamored of a truly bad idea. For example, Adobe has had a lengthy series of security headaches because some bozo decided that it was a good idea to allow a pdf reader to execute embedded code. And I'm sure ActiveX was well coded. Didn't stop it from being a security nightmare though.

Also, you seem to assume that money is the only driver. If you actually look at open source projects like Apache, you'll see that the participants realized very early on that the mechanism they used to serve web pages was simply not a competitive advantage. However, by joining an open source community, they got to greatly leverage their investment and ended up with a superior, and less expensive, product than they would have had access to otherwise. In other words, in many instances, open source make sound business sense in that it allows you to cut costs and focus on your true competitive advantages. Sounds like basic capitalism to me. And as the owner of a small business, I can say from personal experience that use of open source software has allowed us to explore areas that would have been prohibitively expensive with commercial software. This means we are a better, more productive business because we didn't buy into the idea that commercial is always better.

Or perhaps a more likely explanation is that the management of said coders is incompetent.

But this is digressing to a huge degree from the point of this thread. You asked for advice on your security approach and you got it. However, your recent posts indicate that you don't seem to feel that way, so let me summarize my opinion on your approach:

In and of itself, it probably doesn't increase your security risk. However, it appears to me to be a flawed approach that will lead to a false sense of security, and therefore a higher likelihood that you will be compromised and not know it. In particular:

- Your approach relies on a single algorithm known to be flawed. Interestingly, this algorithm and its Linux implementation are open source, and by your own criteria are therefore completely unsecure.

- Your approach is completely redundant with known high-quality software that has been in active use for years. Which is more secure, newly written untested software or battle tested software?

- Your approach (namely the random file-splitting aspect) is overly complex and will be completely dependent on maintaining a large data set of known good values. In my opinion, the larger the reference data set needs to be, the more open it is to errors that could result in security breaches. Furthermore, there is no indication that you have a process to verify the integrity of any reference data set. In other words, you've got a referential problem here. In order for this approach (or any like it) to work, there has to be a known good state. And in your case, if the crackers fool the known good state, you have no other way of detecting it.

So there you have it, I think your approach is flawed. It might not open any new avenues of attack, but it certainly isn't increasing security.

1 members found this post helpful.

You're twisting the truth. If you believe most open-source coders get paid money, then you're sadly mistaken.



There you go again with your biased cherry picking. If you're going to bring in specific examples, then be a bit unbiased, and scientific.



Incorrect. Don't pretend to know me. I've already stated you are wrong about me.


Wrong. First, I never said I would or would not use cksum. It take me about 30 minutes >at most< to write my own cksum in c++. Even if I used cksum, I see no sufficient reasons to not trust it. Second, I said from the start of this thread that I'll randomly split the files in multiple checksums to overcome the possibility of a hacker trying to outsmart checksums.



Again you refuse to acknowledge what I've said repeatedly, that the difference is my code is undisclosed.


Put your $ where your mouth is. I'll conduct a legal bet with anyone that I could write such effective code in one day. The code is extremely easy. I'll be writing it within a few weeks.



The known is to keep the OS in it's original state.



Ah, I see. You say it "certainly" isn't secure, lol. Says you.

0 members found this post helpful.

Really, you should have IDP/IDS in place to know that someone has accessed your system. Use auditing, traffic monitoring, firewalls, logging, alerting etc...

The "scan it every so often" idea might work... but at what cost? If you scan it every hour, then someone could have already been in your system for 59 minutes. If you scan every 5 minutes you will kill your performance.

To me, its better to watch the gates and doors than spend time to count the money every 5 minutes.

1 members found this post helpful.

Seems like a contradiction since the very definition of open-source means it must be free:

http://www.opensource.org/docs/osd

BTW, this forum uses vbulletin, correct? Vbulletin is not open-sourced, and is a commercial product. If true, then why are you here? ;-) ... Just playing with you.

Interesting discussion on the topic:
https://www.vbulletin.com/forum/arch...p/t-65504.html


http://en.wikipedia.org/wiki/VBulletin
Quote, first line of the wiki page, "vBulletin (vB) is a commercial Internet forum software produced by Jelsoft Enterprises and vBulletin Solutions, both subsidiaries of Internet Brands."

0 members found this post helpful.

I generally stay out of arguments that are of little help to anyone. But I must point out that this quote is a false statement.

If you don't understand what you are talking about, then you shouldn't be talking about it. It can be misleading for someone else looking for correct answers.

And who says that companies that pay people to work on open source software can't release that software as open source? MySQL is developed by a company, but open source, AMD has paid programmers for the radeon-drivers, also open source. And there are many more. No contradiction here.

An individual can define a word, e.g., open source, as they wish, but that doesn't change the standard definition. It appears that the standard definition of open-source is that it must be free. Sounds silly to me, but I'm just saying.

I just checked another source, dictionary.com. The first & top most definition is,

"o·pen-source"
"Computers . pertaining to or denoting software whose source code is available free of charge to the public to use, copy, modify, sublicense, or distribute"
http://dictionary.reference.com/browse/open-source

0 members found this post helpful.