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.
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.
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).
>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.
This has been possibly through forwarding to rsyslog right from first release.