SlashDot had an article today on a Linux server malware attack, http://it.slashdot.org/story/14/03/18/2218237/malware-attack-infected-25000-linuxunix-servers.
I wonder if there is a simple test to see if a CentOS machine has been infected in this way?
The article mentions Yara and Snort rules to test for this, but I wonder if there is something simpler? Alternatively, are there Yara or Snort packages for CentOS? ("Yum search" didn't seem to find anything.)
On 03/19/2014 08:50 AM, Timothy Murphy wrote:
SlashDot had an article today on a Linux server malware attack, http://it.slashdot.org/story/14/03/18/2218237/malware-attack-infected-25000-linuxunix-servers.
I wonder if there is a simple test to see if a CentOS machine has been infected in this way?
The article mentions Yara and Snort rules to test for this, but I wonder if there is something simpler? Alternatively, are there Yara or Snort packages for CentOS? ("Yum search" didn't seem to find anything.)
Look at this PDF:
On 03/19/2014 09:01 AM, Johnny Hughes wrote:
On 03/19/2014 08:50 AM, Timothy Murphy wrote:
SlashDot had an article today on a Linux server malware attack, http://it.slashdot.org/story/14/03/18/2218237/malware-attack-infected-25000-linuxunix-servers.
I wonder if there is a simple test to see if a CentOS machine has been infected in this way?
The article mentions Yara and Snort rules to test for this, but I wonder if there is something simpler? Alternatively, are there Yara or Snort packages for CentOS? ("Yum search" didn't seem to find anything.)
Look at this PDF:
Specifically:
1. ssh -G
and
a couple of curl commands to check for a website issues .. in the section on IOC starting on page 57.
Also, here is a git repo if/when the writers start changing the items:
On Wed, Mar 19, 2014 at 10:01 AM, Johnny Hughes johnny@centos.org wrote:
On 03/19/2014 08:50 AM, Timothy Murphy wrote:
SlashDot had an article today on a Linux server malware attack, <
http://it.slashdot.org/story/14/03/18/2218237/malware-attack-infected-25000-...
.
I wonder if there is a simple test to see if a CentOS machine has been infected in this way?
The article mentions Yara and Snort rules to test for this, but I wonder if there is something simpler? Alternatively, are there Yara or Snort packages for CentOS? ("Yum search" didn't seem to find anything.)
Look at this PDF:
The article I read, linked to a detection toolkit on GitHub. https://github.com/eset/malware-ioc
Read this: https://github.com/eset/malware-ioc/blob/master/windigo/README.adoc
On 03/19/2014 12:11 PM, SilverTip257 wrote:
On Wed, Mar 19, 2014 at 10:01 AM, Johnny Hughes johnny@centos.org wrote:
On 03/19/2014 08:50 AM, Timothy Murphy wrote:
SlashDot had an article today on a Linux server malware attack, <
http://it.slashdot.org/story/14/03/18/2218237/malware-attack-infected-25000-...
.
I wonder if there is a simple test to see if a CentOS machine has been infected in this way?
The article mentions Yara and Snort rules to test for this, but I wonder if there is something simpler? Alternatively, are there Yara or Snort packages for CentOS? ("Yum search" didn't seem to find anything.)
Look at this PDF:
The article I read, linked to a detection toolkit on GitHub. https://github.com/eset/malware-ioc
Read this: https://github.com/eset/malware-ioc/blob/master/windigo/README.adoc
I didn't see anything about how the machines got infected. Did I miss something?
Thanks,
From: Steve Clark sclark@netwolves.com
I didn't see anything about how the machines got infected. Did I miss something?
From what I understood, it is no brand new vulnerability...
It is just bad guys who simply got some servers logins/passwds and installed their malware...
JD
Linux server attacks are nothing new. 14 years ago I was installing a server, Red Hat 7 I think, and in the hour or so after I installed it to the time I applied the patches it was infected with an Apache ssl trojan.
Years ago I moved sshd off port 22, disabled password logins and use certificates after noticing my logs filling up with numerous daily attempts at hacking into sshd.
Mike
On 03/19/2014 12:11 PM, SilverTip257 wrote:
On Wed, Mar 19, 2014 at 10:01 AM, Johnny Hughes johnny@centos.org wrote:
On 03/19/2014 08:50 AM, Timothy Murphy wrote:
SlashDot had an article today on a Linux server malware attack, <
http://it.slashdot.org/story/14/03/18/2218237/malware-attack-infected-25000-...
.
I wonder if there is a simple test to see if a CentOS machine has been infected in this way?
The article mentions Yara and Snort rules to test for this, but I wonder if there is something simpler? Alternatively, are there Yara or Snort packages for CentOS? ("Yum search" didn't seem to find anything.)
Look at this PDF:
The article I read, linked to a detection toolkit on GitHub. https://github.com/eset/malware-ioc
Read this: https://github.com/eset/malware-ioc/blob/master/windigo/README.adoc
On 03/19/2014 01:35 PM, Mike McCarthy wrote:
Linux server attacks are nothing new. 14 years ago I was installing a server, Red Hat 7 I think, and in the hour or so after I installed it to the time I applied the patches it was infected with an Apache ssl trojan.
Years ago I moved sshd off port 22, disabled password logins and use certificates after noticing my logs filling up with numerous daily attempts at hacking into sshd.
Mike
On 03/19/2014 12:11 PM, SilverTip257 wrote:
On Wed, Mar 19, 2014 at 10:01 AM, Johnny Hughes johnny@centos.org wrote:
On 03/19/2014 08:50 AM, Timothy Murphy wrote:
SlashDot had an article today on a Linux server malware attack, <
http://it.slashdot.org/story/14/03/18/2218237/malware-attack-infected-25000-...
.
I wonder if there is a simple test to see if a CentOS machine has been infected in this way?
The article mentions Yara and Snort rules to test for this, but I wonder if there is something simpler? Alternatively, are there Yara or Snort packages for CentOS? ("Yum search" didn't seem to find anything.)
Look at this PDF:
The article I read, linked to a detection toolkit on GitHub. https://github.com/eset/malware-ioc
Read this: https://github.com/eset/malware-ioc/blob/master/windigo/README.adoc
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
An even more compelling question: does this only affect servers? or will it also infect desktops as well (running CEntOS as a desktop but have never ssh'd anything from or to it...have a standard type of setup with a wireless router connected to my DSL/cable line...)
EGO II
On 03/19/2014 12:39 PM, EGO.II-1 wrote:
On 03/19/2014 01:35 PM, Mike McCarthy wrote:
Linux server attacks are nothing new. 14 years ago I was installing a server, Red Hat 7 I think, and in the hour or so after I installed it to the time I applied the patches it was infected with an Apache ssl trojan.
Years ago I moved sshd off port 22, disabled password logins and use certificates after noticing my logs filling up with numerous daily attempts at hacking into sshd.
Mike
On 03/19/2014 12:11 PM, SilverTip257 wrote:
On Wed, Mar 19, 2014 at 10:01 AM, Johnny Hughes johnny@centos.org wrote:
On 03/19/2014 08:50 AM, Timothy Murphy wrote:
SlashDot had an article today on a Linux server malware attack, <
http://it.slashdot.org/story/14/03/18/2218237/malware-attack-infected-25000-...
.
I wonder if there is a simple test to see if a CentOS machine has been infected in this way?
The article mentions Yara and Snort rules to test for this, but I wonder if there is something simpler? Alternatively, are there Yara or Snort packages for CentOS? ("Yum search" didn't seem to find anything.)
Look at this PDF:
The article I read, linked to a detection toolkit on GitHub. https://github.com/eset/malware-ioc
Read this: https://github.com/eset/malware-ioc/blob/master/windigo/README.adoc
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
An even more compelling question: does this only affect servers? or will it also infect desktops as well (running CEntOS as a desktop but have never ssh'd anything from or to it...have a standard type of setup with a wireless router connected to my DSL/cable line...)
There really is no difference between server and desktop except the packages installed. In this case, the if you have openssh-clients and openssh-server installed and external passwords logins activated, then yes, someone could have gained access. If they did, they could have replaced parts of your RPMs with their own items.
Everyone using any Linux should test for this.
On 03/19/2014 02:21 PM, Johnny Hughes wrote:
On 03/19/2014 12:39 PM, EGO.II-1 wrote:
On 03/19/2014 01:35 PM, Mike McCarthy wrote:
Linux server attacks are nothing new. 14 years ago I was installing a server, Red Hat 7 I think, and in the hour or so after I installed it to the time I applied the patches it was infected with an Apache ssl trojan.
Years ago I moved sshd off port 22, disabled password logins and use certificates after noticing my logs filling up with numerous daily attempts at hacking into sshd.
Mike
On 03/19/2014 12:11 PM, SilverTip257 wrote:
On Wed, Mar 19, 2014 at 10:01 AM, Johnny Hughes johnny@centos.org wrote:
On 03/19/2014 08:50 AM, Timothy Murphy wrote:
SlashDot had an article today on a Linux server malware attack, <
http://it.slashdot.org/story/14/03/18/2218237/malware-attack-infected-25000-...
.
I wonder if there is a simple test to see if a CentOS machine has been infected in this way?
The article mentions Yara and Snort rules to test for this, but I wonder if there is something simpler? Alternatively, are there Yara or Snort packages for CentOS? ("Yum search" didn't seem to find anything.)
Look at this PDF:
The article I read, linked to a detection toolkit on GitHub. https://github.com/eset/malware-ioc
Read this: https://github.com/eset/malware-ioc/blob/master/windigo/README.adoc
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
An even more compelling question: does this only affect servers? or will it also infect desktops as well (running CEntOS as a desktop but have never ssh'd anything from or to it...have a standard type of setup with a wireless router connected to my DSL/cable line...)
There really is no difference between server and desktop except the packages installed. In this case, the if you have openssh-clients and openssh-server installed and external passwords logins activated, then yes, someone could have gained access. If they did, they could have replaced parts of your RPMs with their own items.
Everyone using any Linux should test for this.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thanks for this! I just checked and apparently (and thankfully!) I'm clean. Will be trying this out on my Ubuntu laptop as well.....awesome teamwork!! thanks again!!!
EGO II
On 19/03/14 18:31, EGO.II-1 wrote:
On 03/19/2014 02:21 PM, Johnny Hughes wrote:
On 03/19/2014 12:39 PM, EGO.II-1 wrote:
On 03/19/2014 01:35 PM, Mike McCarthy wrote:
Linux server attacks are nothing new. 14 years ago I was installing a server, Red Hat 7 I think, and in the hour or so after I installed it to the time I applied the patches it was infected with an Apache ssl trojan.
Years ago I moved sshd off port 22, disabled password logins and use certificates after noticing my logs filling up with numerous daily attempts at hacking into sshd.
Mike
On 03/19/2014 12:11 PM, SilverTip257 wrote:
On Wed, Mar 19, 2014 at 10:01 AM, Johnny Hughes johnny@centos.org wrote:
On 03/19/2014 08:50 AM, Timothy Murphy wrote: > SlashDot had an article today on a Linux server malware attack, > < http://it.slashdot.org/story/14/03/18/2218237/malware-attack-infected-25000-... > . > > I wonder if there is a simple test to see if a CentOS machine > has been infected in this way? > > The article mentions Yara and Snort rules to test for this, > but I wonder if there is something simpler? > Alternatively, are there Yara or Snort packages for CentOS? > ("Yum search" didn't seem to find anything.) > > > Look at this PDF:
The article I read, linked to a detection toolkit on GitHub. https://github.com/eset/malware-ioc
Read this: https://github.com/eset/malware-ioc/blob/master/windigo/README.adoc
An even more compelling question: does this only affect servers? or will it also infect desktops as well (running CEntOS as a desktop but have never ssh'd anything from or to it...have a standard type of setup with a wireless router connected to my DSL/cable line...)
There really is no difference between server and desktop except the packages installed. In this case, the if you have openssh-clients and openssh-server installed and external passwords logins activated, then yes, someone could have gained access. If they did, they could have replaced parts of your RPMs with their own items.
Everyone using any Linux should test for this.
Thanks for this! I just checked and apparently (and thankfully!) I'm clean. Will be trying this out on my Ubuntu laptop as well.....awesome teamwork!! thanks again!!!
Just to add, I'm sure everyone has already read and implemented many of the suggestions here:
http://wiki.centos.org/HowTos/Network/SecuringSSH
Numbers 2 and 7 have already been highlighted in this thread.
On 3/19/2014 2:50 PM, Ned Slider wrote:
Just to add, I'm sure everyone has already read and implemented many of the suggestions here:
http://wiki.centos.org/HowTos/Network/SecuringSSH
Numbers 2 and 7 have already been highlighted in this thread.
#1 These days I would say that 8 chars minimum length is too few, even if they are completely random (and most won't be). If you're not willing to type gibberish, then a more reasonable minimum length is 12-14. Especially for your root password (or other administration accounts).
If you have your users creating 15+ character passwords, don't make them change it every 30/60/90 days. Password aging hurts more then it helps as passwords grow longer. Users are more likely to adopt poor behavior like simply adding or incrementing numbers from month to month. Longer durations, like 3-5 years, give the users time to memorize the password rather then just keeping it on a sticky on the desk.
#2 (disable root login) is a must for any public facing box, and a strong recommendation for all other boxes. It's the top target of attack, so why allow it to be attacked at all?
#5 (non-standard port) is very useful. Not for protecting yourself against attack, but from not having your log files fill up with all of the automated attack scripts. Which makes it easier to spot the more serious attackers who have taken the time and effort to find your SSH port.
#7 (public-key pairs) is also a must for any public-facing box. It defeats all attempts to brute-force account passwords remotely.
Now you just have to worry that someone will steal your private key files. But if someone has gotten far enough inside to steal your private key file then you have bigger security problems to worry about.
Thomas Harold wrote:
On 3/19/2014 2:50 PM, Ned Slider wrote:
Just to add, I'm sure everyone has already read and implemented many of the suggestions here:
http://wiki.centos.org/HowTos/Network/SecuringSSH
Numbers 2 and 7 have already been highlighted in this thread.
#1 These days I would say that 8 chars minimum length is too few, even if they are completely random (and most won't be). If you're not willing to type gibberish, then a more reasonable minimum length is 12-14. Especially for your root password (or other administration accounts).
And most people can remember that? And then there's the annoyance factor.
If you have your users creating 15+ character passwords, don't make them change it every 30/60/90 days. Password aging hurts more then it helps as passwords grow longer. Users are more likely to adopt poor behavior like simply adding or incrementing numbers from month to month. Longer durations, like 3-5 years, give the users time to memorize the password rather then just keeping it on a sticky on the desk.
Unfortunately, the real issue on this is that I think most of us here do *not* have control of that, that's upper management. And even though NIST says, I think, 2 years, I'm at a US gov't agency and it's the inane 2 months.... Though I will say the *really* bad places are the folks who compare it to previous passwords, and do their best to keep you from having any pattern at all, and so making it a *lot* harder to remember your current one. When I worked at AT&T, a few years back, for the very first time, I had a *list* of passwords for different systems (not the ones that we controlled)....
As Bruce Schneir says, security theater.
#2 (disable root login) is a must for any public facing box, and a strong recommendation for all other boxes. It's the top target of attack, so why allow it to be attacked at all?
Other than at the console, yep. And as you note later, if someone can log in as root to the console who shouldn't, you've got much larger security issues.
#5 (non-standard port) is very useful. Not for protecting yourself against attack, but from not having your log files fill up with all of the automated attack scripts. Which makes it easier to spot the more serious attackers who have taken the time and effort to find your SSH port.
Huh! That's the *only* rationale I've ever heard for security through obscurity that actually makes sense. (One of my ongoing "goals" for the annual review is cutting down the noise in our logs.) <snip> mark
On Fri, Mar 21, 2014 at 4:18 PM, m.roth@5-cent.us wrote:
#5 (non-standard port) is very useful. Not for protecting yourself against attack, but from not having your log files fill up with all of the automated attack scripts. Which makes it easier to spot the more serious attackers who have taken the time and effort to find your SSH port.
Huh! That's the *only* rationale I've ever heard for security through obscurity that actually makes sense. (One of my ongoing "goals" for the annual review is cutting down the noise in our logs.)
<snip>
It's all obscurity even if you think you can call it something else. OpenVPN over UDP configured to not respond at all unless the certificates match is even better at being hard to find with random probes, though.
On 3/25/2014 10:38, Les Mikesell wrote:
On Fri, Mar 21, 2014 at 4:18 PM, m.roth@5-cent.us wrote:
#5 (non-standard port) is very useful.
Huh! That's the *only* rationale I've ever heard for security through obscurity that actually makes sense.
It's all obscurity even if you think you can call it something else.
The original term of art has gotten stretched out of its original shape.
"Security through obscurity" originally referred only to practices intended to confer security purely through obscurity. As soon as you learn the secret, the security is gone.
Security practitioners started beating "security through obscurity is bad" into people's heads, until now people have this knee-jerk reaction to *any* obscurity, as though obscurity is bad in and of itself.
Moving Telnet to port 2323 is security through obscurity. Moving SSH to port 2222 is defense in depth, because you still have security after an attacker penetrates the obscuration layer.
For another example, think about network switches. They prevent trivial snooping on your neighbor's traffic. ARP poisoning can defeat this security-through-obscurity, but that's no reason for us to all go back to dumb hubs. To the extent that it confers security at all, switched Ethernet is one layer in a good layered defense incorporating switches *and* subnets *and* VLANs *and* encrypted tunnels.
Still another example: ALSR. ASLR doesn't prevent buffer overflow attacks, it just makes them a lot harder to craft.
On 03/19/2014 10:35 AM, Mike McCarthy wrote:
Years ago I moved sshd off port 22, disabled password logins and use certificates after noticing my logs filling up with numerous daily attempts at hacking into sshd.
Not only do I not use port 22, no passwords, and keys with passphrases, the port I use for SSH is also protected by port knocking. Hey, just because I'm paranoid doesn't mean they aren't out to get me! Though few, there have been remote exploits against SSHd.
-
EGO.II-1 -
John Doe -
Johnny Hughes -
Les Mikesell -
Lists -
m.roth＠5-cent.us -
Mike McCarthy -
Ned Slider -
SilverTip257 -
Steve Clark -
Thomas Harold -
Timothy Murphy -
Warren Young