On 27/09/14 12:31, green wrote: > green wrote at 2014-09-26 21:04 -0500: >> Ric Moore wrote at 2014-09-26 18:08 -0500: >>> On 09/26/2014 05:08 PM, green wrote: >>>> So, all other things being equal, binary logs are more secure than >>>> plain text logs. Is that actually what you are saying? >>> >>> Yes. The benefit of using a binary log is the lesser vulnerability to an >>> external attack from an intruder. <gently> No - it is not. </gently> Good security is based on the "assumption" that you are defending against a skilled and knowledgeable attacker. Bad security "presumes" the unknown, and can thus be certain the attacker is stupid and unskilled. Script kiddie attacks 'might' be the most common, which is probably why stupid security "policies" are designed to deal with the best case scenario rather than the worst case. Secure against intelligent attacks and you'll find you don't need to worry about attacks by idiots.
>>> That huge security flaw was mentioned on a >>> recent PBS video regarding the new day Hackers and how simply they >>> removed/edited text-log files to hide their tracks of what they did. >> >> So now the attacker just destroys all the logs instead, because it is >> easier than editing the binary. And then you *know* your system has been compromised. Which is a very poor substitute for proper security where your system is designed to:- ;detect intrusions (e.g. SNORT and other NIDS*1) ;limit the extent of successful intrusions (e.g. SELinux) ;detect file alterations (e.g. tripwire and other HIDS*2) ;detect application intrusions (e.g. don't presume all writes to MySQL are from WordPress - or are legitimate, profile and monitor for abnormalities. System analysis is good) ...and your OS is kept up to date*4, and the system is constantly monitored for intrusions while continually being tested to ensure the security works. *1 Network Intrusion Detection Systems *2 Host (-based) Intrusion Detection Systems *3 Application Protocol (-based) Intrusion Detection Systems *4 debsecscan An excellent starting point is to check off the points in:- https://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html (also see the chapter on Debian security tools). > > Hm, if you are concerned about the validity of your server logs, ... you're doing it wrong (FTFY) :) Instead you should rely on system logs only to provide, um, system logs. System logs != Intrusion Detection Systems (e.g. tripwire) In the event of intrusion system logs are of limited value as you must presume they have been tampered with. Useful for forensics but shouldn't be rely on as a primary means of confirming a successful attack. > it > might be prudent to read #10 at > http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html > Expecting enlightenment there 'might' be the triumph of optimism over experience. It's a *selective* collection of claims from disparate sources couched in weasel language. e.g.:- "Unit files GOOD! Shell scripts BAD!" How about:- Debian's biggest fallacies "Free Software GOOD! Paying for Software BAD!" What's wrong with the old tests - see if it floats, if it does drown it - or burn it at the stake (sigh). As others have pointed out - the prudent practise is to only deploy that which has been well tested before deployment. If you're not employing change control you cannot reasonably expect security. Change control stops you from deploying Jessie without a compelling argument for not deploying Wheezy instead (ditto Wheezy vs. Squeeze). Likewise every single package you install. Do you really need perl *after* installation? And laptop tools? Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54263db5.5020...@gmail.com
