Hi,
if I may comment on that one: These days, we see a lot of reports on malware targeting Linux machines, both botnets and backdoors/rootkits. There are two common aspects that struck me:
-
Initial infection vector is trivial, if not primitive.
It has been a while since I saw the last report on Linux malware that spread through something fancy, such as 0-day (or near-0-day) exploitation. While the initial access vector is not always known, it often boils down to successful brute-forcing of publicly exposed SSH servers, or exploitation of vulnerabilities that have been published (and patched) a long time ago.
Certainly, it is sad to see that despite all prayers from security organizations, CERTs and other industry actors, basic security principles such as swift and thorough patching still are often neglected. (And in this regard, it must be noted that less than 50% of all IPFire installations run on the latest Core Update, or the one before, so we clearly have potential for improvement on that front.
)
However, it is good to see that patching works, and that - unlike other operating systems - security issues such as 0-days still remain a niche threat to Linux users. (It is not clear, however, how this would change if Linux would gain some decent popularity on end-user devices…) -
Despite its sophisticated userland activity, Symbiote does not appear to feature kernel-space one
This seems a bit odd to me, as a malware author that capable could have added kernel-space persistence measures as well. However, given that apparently even userland-based rootkits still go widely unnoticed during forensic investigations, that might have not been necessary to achieve the target of this threat actor.
To cut it short: Please, please, please, install Core Updates on IPFire as soon as possible, and ensure your entire IT landscape is provided with updates of any kind in a timely and thorough manner. Or, to put it more bluntly: The time you save doing so is then wasted on incident response, and trying to scrub infected systems - which is, given the sophistication of post-exploitation activity, more difficult by orders of magnitude.
Thanks, and best regards,
Peter Müller
Hi Peter,
I agree. One of the areas I suppose could be improved would be autoupdate and alerts. I know ipfire has an email configuration for sending emails. However I don’t think I’ve ever received an email bar the test one I’ve set up with. It might make sense to send an email alerting of an update for each box to inform admins there is an update pending. Or another option is auto updates outside of hours, with a tickbox to select auto restart or not.
BR
Joe.
Hi,
thanks for your suggestions.
To be frank, I don’t think that is a good idea: Organizations only running a few IPFire machines could just register at www.ipfire.org so they receive e-mail notifications regarding new blog posts, which includes release announcements.
(Actually, this might have the benefit that they realize the availability of testing updates, and hopefully consider participating in testing.)
E-mail notifications for larger organizations would mean a flood of notifications as soon as a new Core Update is published. For such entities, it is probably more feasible to do something like
ssh [IPFire machine] -C "grep 'PRETTY_NAME' /etc/os-release"
over all of their IPFires once a day, and compare the outputs against the current Core Update. This also reveals incidents where fetching update/package lists fails, whereas in case of active notifications, such systems would simply remain silent, most likely overlooked by the appropriate IT divisions.
We did feature that once, but it has been removed way before I joined the IPFire project. There has probably been a rationale behind this change, but I alas cannot recall it.
Thanks, and best regards,
Peter Müller