5 ms·

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 s

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). Also the author picks apart a quote, but if the assumptions in the previous paragraph is taken at face value (that an attack can have sup-10 second root with automated attacks on the logs), then even remote logging isn't a secure vector as they often aren't sent instantly so an attacker could intercept or alter them. However I suggest that such a scenario is uncommon. Most attackers have to start outside and fight their way in which will generate plenty of logs for either external logging or FSS. > It seems to me that systemd now also wants to play the role as some crude intrusion detection system. FSS isn't a "intrusion detection system." It is an attempt to make logs immutable, nothing more. The nice thing about FSS is that it can be coupled with an actual IDS and the IDS can look for attempts at altering the FSS. > If the systemd author would just have implemented sending log events to an external log server, that would have been way more useful security-wise, I think. It isn't a binary choice. They can implement FSS and remote logging. Also it is open source so you yourself can contribute external logging.

tw04 12y ago
>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.
- matthewmacleod 12y ago
  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!
  - tw04 12y ago
    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.
mikeash 12y ago
I don't know a whole lot about this stuff. Why would one set up remote logging and not send logs instantly?
- ecnahc515 12y ago
  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.
- UnoriginalGuy 12y ago
  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.
killnine 12y ago
>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.
- Tuna-Fish 12y ago
  > Point is, thus far they have not This has been possibly through forwarding to rsyslog right from first release.
- UnoriginalGuy 12y ago
  > 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 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.
- click170 12y ago
  >>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 http://www.rsyslog.com/doc/relp.html
steventhedev 12y ago
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.
- angersock 12y ago
  It would appear that systemd left behind SOLID engineering principles a long time ago.
- louwrentius 12y ago
  This is EXACTLY my complaint.
- teddyh 12y ago
  “Security” is not something you can relegate to an IDS. Security must be embedded in each program from the start.
  - steventhedev 12y ago
    > 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).
- tadfisher 12y ago
  The answer to that is that systemd is much more than an init system.

tw04 12y ago

>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.

matthewmacleod 12y ago
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!
- tw04 12y ago
  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.

mikeash 12y ago

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

ecnahc515 12y ago
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.
UnoriginalGuy 12y ago
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.

killnine 12y ago

>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.

Tuna-Fish 12y ago
> Point is, thus far they have not This has been possibly through forwarding to rsyslog right from first release.
UnoriginalGuy 12y ago
> 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 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.
click170 12y ago
>>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 http://www.rsyslog.com/doc/relp.html

steventhedev 12y ago

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.

angersock 12y ago
It would appear that systemd left behind SOLID engineering principles a long time ago.
louwrentius 12y ago
This is EXACTLY my complaint.
teddyh 12y ago
“Security” is not something you can relegate to an IDS. Security must be embedded in each program from the start.
- steventhedev 12y ago
  > 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).
tadfisher 12y ago
The answer to that is that systemd is much more than an init system.