Hacker News Reader

>they're less common now

Source?

>arent sent instantly so an attacker could intercept or alter them

intercept where?

>Most attackers ... generate plenty of logs

Source?

>They can implement FSS and remote logging.

Point is, thus far they have not, and their first choice was not what the author views as more secure.

> Source?

Experience. I've set up SELinux, AppArmor, etc. For example back near 2000 a lot of Apache servers I worked on were running as root, now few are, and better still many have limited permissions even as their user/group.

The same can be said for many Linux services today. And better still the few that HAVE to run as root often come shipped with some level of permission controls to limit exposure.

I can link you to a random book on Linux access controls and security if you want an actual third party source. Or be a total dick and link to a man-page.

> intercept where?

It depends which system you're using to send logs remotely (and how it is configured). Sometimes the filesystem, sometimes IPC, etc.

e.g. http://www.rsyslog.com/doc/queues.html

>> Most attackers have to start outside and fight their way in which will generate plenty of logs for either external logging or FSS.

> Source?

Source on, what? That attackers who break into systems generate logs? You REALLY need a source on that, REALLY? Come on now.

> Point is, thus far they have not, and their first choice was not what the author views as more secure.

Alright, and then criticise them for that. If the article had been about systemd's lack of remote logging that would have been one thing, but it was complaining that FSS was bad because systemd lacked remote logging. FSS existing is irrelevant.

Also, again, open source. Go implement shit.

>>arent sent instantly so an attacker could intercept or alter them

With Reliable Event Logging Protocol [0], interception is somewhat mitigated. You can configure and white-list certificates on the client and server so that even if a network attacker inserts a syslog relay with a certificate that's signed but isn't the one expected, you can't intercept the messages. Though, if you have that much control of the network, you can just drop syslog packets entirely. Having a dedicated management NIC and network helps mitigate that.

And I think there's a big difference between 10 seconds, and any delay inherent in to external syslogging. 10 seconds is enough time for an automated exploit to penetrate multiple layers of the security onion, but external logging should be able to squeak out a few messages between pwnage and syslog clobbering in the same situation (YMMV).

[0] http://www.rsyslog.com/doc/relp.html

(Not OP, but I'll reply anyway.)

>Source?

You need a reliable kernel exploit, which isn't always easy to download and compile within 15 minutes (or 10 seconds, or whatever you set the interval to). But I agree that this is not a very good mitigating factor.

>intercept where?

If you have root on the box and logs are being sent to another server via syslog, you can intercept the traffic in all sorts of ways.

>Source?

Read any incident response book or blog.

>Point is, thus far they have not, and their first choice was not what the author views as more secure.

Yeah, I side with the blog author in this case.

> Point is, thus far they have not

This has been possibly through forwarding to rsyslog right from first release.

>This article is predicated on the assumption that an attacker goes from zero access to full root within 10 seconds. While there are vectors which have allowed such rapid escalation, they're less common now than historically thanks to Linux's security looking more like an onion rather than just a binary state (root or user).

You mean like a disgruntled system administrator? There are countless scenarios in which an attacker goes from zero access to root within 10 seconds. Predicating your security on that not being a common scenario shows that you've spent next to no time in a real corporate environment. IE: Poettering.

Nonsense – defence in depth and all of that. FSS is useful because it provides a layer of audibility for users that wouldn't have external log servers in any case, and because it provides some minimal guarantees about the ability to tamper with logs. That's useful, regardless of the fact that it's not a bulletproof solution!

I didn't say FSS was a step backwards or wasn't useful. You completely ignored the content of my post. When the project founder tells people "hey, you don't need external syslog servers" it shows an absolute ignorance of WHY we have external logging servers. And that kind of ignorance is dangerous in a project leader. ESPECIALLY when his solution to being called out on his ignorance is to ignore the person who was critical.

You make a good point. FSS isn't an IDS, it's a metric to be used by an IDS.

However, that raises the question of what the hell it's doing in the init system, and not implemented by the IDS. That's a SOLID violation.

“Security” is not something you can relegate to an IDS. Security must be embedded in each program from the start.

> Security must be embedded in each program from the start.

Agreed. Wholeheartedly. However, the way most of us interpret that bit of conventional wisdom is that security should be added to existing features, for example, by cleansing user input and not passing on tainted input (shellshock is a classic example of this, in the vein of a system-based XSS vuln). It does not mean that we should develop "security" features as addons to existing systems.

In this case, they use an untested cryptographic primitive (SSKG) which was published by Poettering's brother almost a year after the feature landed. That's negligent and reeks of nepotism.

I wouldn't recommend that any sysadmin use this feature in a security context (there are existing security products that provide log-signing, with security notifications and patches).

The answer to that is that systemd is much more than an init system.

This is EXACTLY my complaint.

It would appear that systemd left behind SOLID engineering principles a long time ago.

I don't know a whole lot about this stuff. Why would one set up remote logging and not send logs instantly?

Sometimes you have a lot of throughput, and it simply isn't feasible. Could potentially saturate your network, or overload your remote aggregator. Of course, all of this is fixable, but often times when every node just pushes logs out, it's hard to throttle that.

Because sending logs has a lot of overhead. Much of that overhead can be mitigated by waiting even a few seconds, packaging several logs together, and sending a batch.

On a LAN where the sender and receiver are close this type of overhead is much lower than over the internet. It is also worth noting that on some systems several logs can be generated each second, several hundred a minute, so even modest overhead can become costly 24/7/365.

It is also worth noting that some people have remote logging configured NOT for security reasons (primarily) but for system health monitoring. In this scenario the speed isn't as vital as keeping the overhead low.