[Novalug] Powerful, highly stealthy Linux trojan may have infected victims for years | Ars Technica

shawn wilson ag4ve.us@gmail.com
Tue Dec 9 09:55:51 EST 2014


It's not hard to write firewall rules to stop the cnc initialize
packet from getting to the host. Though, I'll bet that's changed with
10000 % epoch or something like that. Either way, kinda cool to see
linux malware actually written about - I know it's been out there as
I've spoken to people who analyze it, but I rarely see mention of it.
So, good on them for that.

On Tue, Dec 9, 2014 at 8:09 AM, Rich Kulawiec via Novalug
<novalug@firemountain.net> wrote:
> On Mon, Dec 08, 2014 at 10:58:40PM -0500, Kevin Cole via Novalug wrote:
>> http://arstechnica.com/security/2014/12/powerful-highly-stealthy-linux-trojan-may-have-infected-victims-for-years/
>
> That article notes:
>
>         Administrators who want to check for Turla-infected
>         Linux systems can check outgoing traffic for connections to
>         news-bbc.podzone[.]org or 80.248.65.183, which are the addresses
>         of known command and control channels hardcoded into the Linux
>         trojan.
>
> And this is why I said (in http://www.firemountain.net/pipermail/novalug/2014-November/042290.html)
>
>         "Default permit" is dead.
>
> That IP address is routed by AS30982, and allegedly belongs to
> "CAFE Informatique et telecommunications" in Togo.  (But I doubt that's
> who's really behind it.)  If one's operation doesn't have a functional
> requirement to make outbound connections to places like that, then
> one's operation shouldn't be able to.
>
> In other words, the first rule in every firewall should be the
> functional equivalent of:
>
>         block all from any to any (i.e., bidirectionally block all traffic)
>
> Followed by the careful enumeration of which {networks, systems} are
> able to reach which {networks, systems, ports} via which protocols and
> vice-versa.  Yes, it's tedious.  Yes, it means that frequent updates
> may be necessary: that's why we have make(1), rsync(1) and rcs(1), which
> constitute a perfectly adequate revision control and maintenance system
> for this use case.  Yes, it means that you need to know exactly what
> every system you run is doing all the time, but quoting Ranum again:
>
>         To which I respond, "How can you call yourself a 'Chief Technology
>         Officer' if you have no idea what your technology is doing?"
>
> Of course, this tactic won't stop your hosts from being infected by
> malware like this.  But it will stop it from phoning home.  And while
> that's not a cure, it at least (a) mitigates the effects to a certain
> extant and (b) hopefully makes enough noise in the logs that you notice
> and realize that something in your operation is doing something
> that it shouldn't.
>
> ---rsk
> **********************************************************************
> The Novalug mailing list is hosted by firemountain.net.
>
> To unsubscribe or change delivery options:
> http://www.firemountain.net/mailman/listinfo/novalug



More information about the Novalug mailing list