Slashdot Mirror


Duqu Attackers Managed to Wipe C&C Servers

Trailrunner7 writes with an update in the saga of Duqu and Stuxnet. From the article: "Shortly after the first public reports about Duqu emerged in early autumn, the crew behind Duqu wiped out all of the command-and-control servers that had been in use up to that point, including some that had been used since 2009. An in-depth analysis of the known C&C servers used in the Duqu attacks has found that some of the servers were compromised as far back as 2009, and that the attackers clearly targeted Linux machines. All of the known Duqu C&C servers discovered up to this point have been running CentOS ... There also is some evidence that the attackers may have used a zero-day in OpenSSH 4.3 to compromise the C&C servers initially."

134 of 227 comments (clear)

  1. NO! by masternerdguy · · Score: 4, Funny

    Damn, not the command and conquer servers. My weekend is fried.

    --
    To offset political mods, replace Flamebait with Insightful.
  2. They didn't infect Kippo by Anonymous Coward · · Score: 1

    I ran kippo on SSH. Hell of a honeypot, with the ability to replay sessions to watch how hackers think.

    1. Re:They didn't infect Kippo by mzs · · Score: 2

      Kippo will not work for anyone but the kiddies. Did you change the default root passwords even? Those two are a real tip-off to a honeypot. Also there are hardly any commands, ifconfig never changes, and in this case /etc/issue says Debian and these people were after CentOS. If you had been hacked, you would have had the vulnerable sshd and no Kippo logs would have been the least of your worries.

    2. Re:They didn't infect Kippo by Anonymous Coward · · Score: 3, Interesting

      Same AC here.

      I actually rewrote many of the commands to appear more realistic. You can also change the output of various commands with a simple configuration change.

      I also implemented better wget/curl support along with the virtual FS so it appears to be more accurate.

      I agree about it being obvious to educated attackers. That's why I modified it. I enjoy watching the sessions on many of the servers I run for a large hosting company.

  3. Umm, how about a little context? by Evro · · Score: 5, Informative

    Editors, your job is not simply to click "post." Read the submission and see if it makes sense. I have no idea what Duqu is or what this is about. I had to dig down 2 links deep to see that this was related to an attack in India. Context: provide it.

    --
    rooooar
    1. Re:Umm, how about a little context? by martas · · Score: 3, Informative

      Didn't the very first link in the summary do that?

    2. Re:Umm, how about a little context? by Anonymous Coward · · Score: 1

      Who are Adam and Eve and where they came from?

    3. Re:Umm, how about a little context? by ackthpt · · Score: 1

      Editors, your job is not simply to click "post." Read the submission and see if it makes sense. I have no idea what Duqu is or what this is about. I had to dig down 2 links deep to see that this was related to an attack in India. Context: provide it.

      It's about distributing a worm using servers which were largely set up, using default passwords or never updating anything. This is why it's so critical to have good, dedicated system administration, intelligent installation and follow-up support . Honestly. Most of these servers were likely built once and left to run on their own, without a single thought to maintaning or even checking for security updates. Lazy, cheap people never seem to learn. It's like leaving your keys in your car and being utterly stunned when someone actually steals it.

      --

      A feeling of having made the same mistake before: Deja Foobar
    4. Re:Umm, how about a little context? by forkfail · · Score: 2

      Well, you see, Count Duqu was trying to trap Anakin Skywalker and Senator Padmé Amidala....

      --
      Check your premises.
    5. Re:Umm, how about a little context? by mapsjanhere · · Score: 1

      So, what you're saying is Linux, so easy even a Windows user could do it?

      --
      I'm aging rapidly, I bought a new game and had no idea if my machine was good for it.
    6. Re:Umm, how about a little context? by sourcerror · · Score: 2

      No, and this proves that you didn't read it.

    7. Re:Umm, how about a little context? by mcgrew · · Score: 1, Insightful

      Actually, I find that Linux is far easier to use than Windows. When a distro upgrade comes along, there are new perks that you learn. In Windows, an upgrade means you have to relearn the whole damned OS.

      Someone who ran Mandrake eight years ago would have no trouble at all migrating to kubuntu 11. Someone running Windows 98 or XP at that time has to relearn everything when upgrading to Win 7.

      The "Windows is easier and more user friendly" is a myth. It only seems that way because you kids grew up with Windows computers. My experience is far different. I bought a notebook with a "feature" I absolutely hated -- "tap to click". It took a MONTH to find out where to shutr it off. It was nowhere in the control panel, but in a little widget at the bar at the bottom of the screen, and about twenty mouse clicks from there. When I installed Linux on it, it took less than five minutes to find and change it.

      How user friendly is having to reboot? Yes, Windows has gotten better about this, but it still sucks.

      How user friendly is the need for AV software?

      How user friendly is changing the entire menu system of an application around with every upgrade? How user friendly is that forty character antipiracy key? How user friendly is two dozen reboots for an OS upgrade (which includes all the apps you have to reinstall manually)? in Linux, an OS upgrade requires a single reboot.

      How user friendly is having to type your password to log on to a machine behind locked doors that only you use?

      How user friendly is a machine that when the power goes out, you restart it and all the apps and documents that were open are now closed? Restart a Linux box and it comes up exactly like you shut it down, unless you change that behavior. Windows doesn't even give you a choice.

      How user friendly is doing things the Microsoft way instead of your own way? Actually, I want my computer to be obedient, not friendly. I don't care if it curses me as long as it does what I want it to do, how I want it to do it.

      How user friendly is an OS that makes you reinstall every single app when you upgrade?

      Can you name ONE thing about Windows that's more "user friendly?"* I use both OSes, do you? I'd be surprised if you've touched a Linux box in at least ten years.

      *"Pretty" != "User friendly"

    8. Re:Umm, how about a little context? by MikeBabcock · · Score: 1

      Setting up a CentOS server is even faster than configuring a Windows 7 PC, yes.

      I run unattended CentOS installations regularly, its very very simple.

      --
      - Michael T. Babcock (Yes, I blog)
    9. Re:Umm, how about a little context? by martas · · Score: 1

      That's extremely interesting, considering that I did in fact read it. You have just proven that common logic is inconsistent, congratulations!

    10. Re:Umm, how about a little context? by fast+turtle · · Score: 1

      I always thought Adam and Eve were fish from the stars. That's why they lived so long and had so many kids.

      --
      Mod me up/Mod me down: I wont frown as I've no crown
    11. Re:Umm, how about a little context? by ljhiller · · Score: 1

      Do you know what Bitcoin is? Duqu has been in the news and on the slashdot pages for four weeks at least. Sorry you're behind.

    12. Re:Umm, how about a little context? by Zamphatta · · Score: 1

      I love how easy it is to find software for my Ubuntu laptop & install it. Rarely ever even have to reboot too. So much easier than Windows.

    13. Re:Umm, how about a little context? by zero0ne · · Score: 1

      I'm sorry what?

      It's "easy" for someone with 8 years of Mandrake experience to switch to kubuntu 11?
      Now, someone with 8 years experience of 98/XP would have it "hard" when migrating to Windows 7?

      I love the fair and biased comparison here. /sarcasm

      An "End-User" is _ALWAYS_ going to have a difficult time migrating, regardless of the OS, however any technically savvy "computer person" will be able to make either migration easy.

      I don't know about you, but in both Linux and Windows, I learned by messing around, be it clicking on random tabs / buttons / icons or typing commands with random arguments.

      Someone who used Mandrake for 8 years is NOT a "end user" and never will be. However, that person who used 98 / XP for 8 years is _MOST LIKELY_ a "end user"

      Your whole "User Friendly" rant is pointless because you are writing about points that matter to YOU. That married couple down the street may want to be prompted for a password, and may "need" the AV software.

    14. Re:Umm, how about a little context? by drsmithy · · Score: 1

      Someone who ran Mandrake eight years ago would have no trouble at all migrating to kubuntu 11. Someone running Windows 98 or XP at that time has to relearn everything when upgrading to Win 7.

      Complete and utter bullshit. The basic structure of the current Windows UI (Start Menu, Desktop, Taskbar, application and document windows, etc) hasn't changed significantly since Windows 95, and in many ways (window manipulation, drop-down menus, the concept of document-application associations) since Windows 3.0.

      Anyone who has significant problems going from Windows XP, 98, or even 95 to 7, is going to have _at least_ as much trouble moving between just about any two Linux distributions.

      The rest of your rant is equally biased and inaccurate.

    15. Re:Umm, how about a little context? by drsmithy · · Score: 1

      I run unattended CentOS installations regularly, its very very simple.

      Unsurprisingly, so are unattended Windows installations. That is, after all, kind of the point of an unattended install.

    16. Re:Umm, how about a little context? by im_thatoneguy · · Score: 1

      Can you name ONE thing about Windows that's more "user friendly?"

      Last time I tried to get a dual monitor setup working it took about 3 days.

      No, it wasn't ten years ago.

    17. Re:Umm, how about a little context? by Chris+Mattern · · Score: 1

      I read the first link. The only piece of concrete information it provided about Duqu was that it was "malware". It actually had more information about Stuxnet than about Duqu.

    18. Re:Umm, how about a little context? by mcgrew · · Score: 1

      The biggest problem I have with Windows (and MS products in general) is changes between releases. For example, what was wrong with XP's control panel? Why did they change the damned thing around making it so hard to find anything? Why couldn't I disable the "tap to click" feature from there? Why was the "settings" in IE in a completely different place in every release from 1 to 6?

      The married couple may want to be prompted for a password, when you install Linux it asks you. Simple. They would be prompted for a password. Not there at all in Windows; you get the password whether you want it or not.

      I equate "less choice" as "less user friendly". I equate "having to hunt for shit" as being user-hostile. I equate "do it my way or you can't do it" as user hostile.

    19. Re:Umm, how about a little context? by MikeBabcock · · Score: 1

      Unattended Windows installations are not easy to configure or set up or get started with. Your average person who knows how to install Windows would not figure out how to create an unattended installation.

      Your average computer person who can read a blog can create their own custom CentOS distribution for installation over PXE in a couple hours (or a lot less).

      The actual installation part was not what I was commenting on, sorry.

      --
      - Michael T. Babcock (Yes, I blog)
    20. Re:Umm, how about a little context? by drsmithy · · Score: 1

      Your average computer person who can read a blog can create their own custom CentOS distribution for installation over PXE in a couple hours (or a lot less).

      Firstly, you're already comparing apples to oranges ("average person who knows how to install Windows" vs "average computer person") to suit your bias.

      Secondly, having spent a sizeable chunk of my career as a Linux sysadmin, and been responsible for setting up and maintaining several unattended install environments, the idea that some random person only capable of installing Linux from a CD can sit down and create one in a matter of hours is utterly laughable.

    21. Re:Umm, how about a little context? by Evro · · Score: 1

      No, the first link, http://it.slashdot.org/story/11/11/16/1810231/experts-convinced-duqu-work-of-stuxnet-authors , talks about Duqu being related to Stuxnet, but offers no indication about what Duqu is or who it's affecting. Yes, I can google it and look it up on Wikipedia. The point is that an editor should do that. A simple sentence like "Duqu, the recently-discovered malware that's related to Stuxnet, which researchers believe is being used to log Iranian President Mahmoud Ahmadinejad's porn collection...", or some other 10-word summary of what it is, is what editors are supposed to provide.

      --
      rooooar
    22. Re:Umm, how about a little context? by MikeBabcock · · Score: 1

      Actually, I suited the opposite bias. I compared people who already know how to install Windows to people who may not know how to install Linux at all. If you'd bothered considering that, you'd realized I'd actually stacked the deck against my argument, not for it.

      As a result, the rest of your comment is meaningless to me.

      Psst, random Google result: try this.

      --
      - Michael T. Babcock (Yes, I blog)
    23. Re:Umm, how about a little context? by drsmithy · · Score: 1

      Psst, random Google result: try this [greghaygood.com].

      If that's your idea of "create their own custom CentOS distribution for installation over PXE", then yes, I suppose anyone could do it in a matter of hours.

      As could someone with Windows.

    24. Re:Umm, how about a little context? by MikeBabcock · · Score: 1

      Feel free to post the instructions for Windows for someone to follow; including rights required and hardware compatibility issues.

      --
      - Michael T. Babcock (Yes, I blog)
    25. Re:Umm, how about a little context? by drsmithy · · Score: 1

      Feel free to post the instructions for Windows for someone to follow;

      There's a zillion guides out there on making a bootable USB key (preferable) or DVD to install Windows from. It's about 5 steps. Here is one example. After that's done, you just copy whatever custom software you want onto the USB key and you've achieved the same result as that link you gave.

      including rights required and hardware compatibility issues.

      Now you're moving the goalposts.

    26. Re:Umm, how about a little context? by MikeBabcock · · Score: 1

      I didn't move any goalposts. Its the total cost of ownership concept but in total cost of deployment terms. If any random person can do the one thing, but the other is only available to specific people, its different, isn't it? And worth noting.

      PS the above guide is only to make a USB bootable installation image, not a fully automated self-installing image that could be used on a headless system, or for PXE deployment. Those were the original goalposts.

      --
      - Michael T. Babcock (Yes, I blog)
    27. Re:Umm, how about a little context? by drsmithy · · Score: 1

      I didn't move any goalposts.

      Yes, you did. You went from automating installs to talk of permissions and compatibility, completely separate topics.

      Its the total cost of ownership concept but in total cost of deployment terms. If any random person can do the one thing, but the other is only available to specific people, its different, isn't it? And worth noting.

      Why would "any random person" be creating automated installs ? Why would someone with a need to create automated installs not have "rights" to do their job ?

      PS the above guide is only to make a USB bootable installation image, not a fully automated self-installing image that could be used on a headless system, or for PXE deployment. Those were the original goalposts.

      Indeed they were. But then you posted a link to a process for nothing more than rolling some custom RPMs into an ISO image, so I assumed that's all you were talking about. Hence my comment of "If that's your idea of "create their own custom CentOS distribution for installation over PXE""...

  4. Dear Kids... by Lumpy · · Score: 2, Insightful

    You never need your server directly on the internet.
    put it behind a firewall with holes poked through. they can't attach a zero day SSH exploit if the only hole is port 80 to Apache.

    And if you are one of the incredibly rare cases where you really do need to have the machine on the net directly.. I suggest daily security audits.

    --
    Do not look at laser with remaining good eye.
    1. Re:Dear Kids... by amicusNYCL · · Score: 1

      they can't attach a zero day SSH exploit if the only hole is port 80 to Apache.

      What about the edge cases where you're running something other than a vanilla web server?

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    2. Re:Dear Kids... by RobertLTux · · Score: 1

      "they can't attach a zero day SSH exploit if the only hole is port 80 to Apache.

      What about the edge cases where you're running something other than a vanilla web server?"

      then its "they can't attach a zero day SSH exploit if the only hole is port(s) N-Z to %service%."

      the point is if the only ports open are bound to an active service (and you have stripped the list down to what is absolutely needed)
      then its a lot harder to attack that system (bonus points if those services are not on default ports)

      --
      Any person using FTFY or editing my postings agrees to a US$50.00 charge
    3. Re:Dear Kids... by amicusNYCL · · Score: 4, Insightful

      My point was that several servers do use SSH. If I rent a dedicated server, SSH is how I get things done. If an exploit is discovered in httpd, the correct solution is not to block port 80.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    4. Re:Dear Kids... by elsurexiste · · Score: 2

      they can't attach a zero day SSH exploit if the only hole is port 80 to Apache.

      What about the edge cases where you're running something other than a vanilla web server?

      As in "any server that can be sysadmin'ed remotely"? :)

      About half of the system administrators I know don't work on-site. A few use VPNs + ssh; the rest uses plain ssh. Either way, it's more than a single port 80.

      --
      I rarely respond to comments. Also, don't ask for clarifications: a brain and Google are faster, believe me!
    5. Re:Dear Kids... by Hatta · · Score: 1

      How do I get remote shell access if the SSH port isn't open? It might be wise to run SSH on a non-standard port, or to use port knocking, but simply blocking SSH entirely is way too far down the security/convenience tradeoff. You might as well unplug the thing entirely.

      --
      Give me Classic Slashdot or give me death!
    6. Re:Dear Kids... by Anonymous Coward · · Score: 1


      My point was that several servers do use SSH. If I rent a dedicated server, SSH is how I get things done.

      So get a static IP address if you don't already have one, and setup iptables to only allow that IP address access to port 22.

    7. Re:Dear Kids... by 93+Escort+Wagon · · Score: 1

      Just open a different port in the firewall?

      Security through obscurity, eh?

      --
      #DeleteChrome
    8. Re:Dear Kids... by Anonymous Coward · · Score: 1

      It actually works pretty damn well to get rid of 99% of bot attacks.

      Of course, if you have an actual person who is interested in what's behind your firewall, it's probably not very effective.

    9. Re:Dear Kids... by morgauxo · · Score: 1

      Ha, Typical BOFH statement. What if you don't spend all your time on the LAN? What if you actually USE ssh on a regular basis from outside locations. I guess you run an ethernet cord from home to work to the coffee shop and any other place you go?

    10. Re:Dear Kids... by Em+Adespoton · · Score: 5, Informative

      The only things you should need open to the internet are SSH ("the attackers may have used a zero-day in OpenSSH 4.3 to compromise the C&C servers initially") and/or IPSec/L2TP. Anything else should redirect to a DMZ that does NOT route to the same subnet as SSH/IPSec/L2TP. The DMZ should not have port access to the regular network (everything should be pushed). The firewall should be set to not allow active connections out from the DMZ to anywhere, and any activity should not just be logged, but flagged and sent to the administrator. All devices in the DMZ should log to a remote (to them) syslog that is polled from outside the DMZ.

      There... that's the ideal world. In reality, this doesn't account for people who don't have that much hardware/expertise with VMs, for people who don't keep up with their patches, for those who want to do an end-run around this policy to set up torrents, etc. directly from their working computer, etc.

      It also doesn't help that most gateway routers these days have some full-fledged OS inside and as a result often have exploits that can be leveraged directly against them due to inappropriate default configurations.

    11. Re:Dear Kids... by Lumpy · · Score: 1

      You never need SSH open to the internet. VPN in then access the ports.

      --
      Do not look at laser with remaining good eye.
    12. Re:Dear Kids... by SharkLaser · · Score: 1

      You don't need SSH open to the internet, especially if the server is running on internet network. Even then, it's good to assign it to random number and not 22.

    13. Re:Dear Kids... by SharkLaser · · Score: 1

      That damned preview and/or edit... internal network.

    14. Re:Dear Kids... by Anonymous Coward · · Score: 1

      SSH /is/ VPN. Pick your poison.

    15. Re:Dear Kids... by morgauxo · · Score: 1

      And is there any security threat to a port being open that does NOT have an active service on it? If so what is the attacker cracking? The TCP/IP stack itself?

      Why have an active service on any port if you aren't using it?

      As far as I can tell firewalls are useful if you aren't sure what services are running on your network and cannot or do not feel like cleaning them up. Or... as a lazy way to make services accessible only on the LAN. For the former use I can understand on a LAN with many users. It may just be impossible to police. For the latter... that is just lazy. What server worth it's salt can't be configured to only accept connections from the LAN and ignore all others?

      On the other hand, all firewalls I have seen are prone to err. Perhaps an update fails leaving it in an unusable state. Or the user tries to configure some fancy rules resulting in this or that internet service not working. As an example I know a guy who works in IT security now. When he was still in school he liked to run his own email server. That was back before all the home ISP IPs were blacklisted by most smtp hosts. Most of the time his email didn't work. Not because of his smtp server but because he was tweaking his firewall rules. Eventually I learned that the only way to reach him was to call him on the phone. I guess he liked learning about that security stuff though and now he loves his job.

      I just don't see the point of a firewall unless you are in a situation where you cannot control your own LAN. I do think that services should be limited to what one actually uses and then should be actively updated though.

    16. Re:Dear Kids... by Lumpy · · Score: 2

      Most people use the secret service called...... VPN. or if you like more secure, you use an out of band initiation that opens a port for a short window.
      Example: I simply SMS my server, it get's the SMS message and opens the VPN firewall rule for 3 minutes. I connect and do my work. if my connect did not happen in the 3 minute window it closes down again.

      SMS is easy with a cellular rs232 modem, but there are plenty of other ways to do it as well. Email to a specific gmail account can do the same exact thing.

      This is Computer security 101 stuff, nothing advanced.

      --
      Do not look at laser with remaining good eye.
    17. Re:Dear Kids... by DigiShaman · · Score: 1

      But but but, it's Linux! What do those Windowz lamers know anyways? Like, OMG! You're doing it wrong and stuff.

      --
      Life is not for the lazy.
    18. Re:Dear Kids... by Anonymous Coward · · Score: 1

      1) VPN implementations can have 0-days as well
      2) SSH can be used as VPN

      Having a single open port with SSH is just as legit as with VPN.
      One may argue about VPNs being less of a swiss army knife provide smaller attack surface, but that's theoretical. I'm convinced there are some VPN implementations being much more prone to exploitable flaws than OpenSSH.

    19. Re:Dear Kids... by imemyself · · Score: 1

      I for one would much rather control which network can access a service in one place (a centralized firewall), rather than manage it through ten different config files that use different syntaxes on a bunch of servers for every service.

      --
      Every time you post an article on Slashdot, I kill a server. Think of the servers!
    20. Re:Dear Kids... by KingMotley · · Score: 1

      I've found that firewalls work best when you are trying to protect only one machine. You can put a firewall up front, then run a script to open all 65535 ports and forward the packets to the single machine on the internal network. Whoa-la! You have all the protection of a state of the art firewall AND you have all the transparent configurability of being directly on the internet!

    21. Re:Dear Kids... by Bert64 · · Score: 1

      Well you should only be running the services you need...
      If you need a service and have a firewall, then you will allow it through...

      It's ridiculous to run unnecessary services and then use a firewall to hide them.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    22. Re:Dear Kids... by camperdave · · Score: 1

      How do I get remote shell access if the SSH port isn't open? .

      Dial into the modem...?

      --
      When our name is on the back of your car, we're behind you all the way!
    23. Re:Dear Kids... by MikeBabcock · · Score: 1

      We still have modems at most customer sites; although IPSEC is configured to allow remote VPN access; but that's firewalled to only permit attempted connections from known IP addresses (including ours).

      --
      - Michael T. Babcock (Yes, I blog)
    24. Re:Dear Kids... by amicusNYCL · · Score: 2

      In an ideal world, that's right, you would whitelist IPs. But in the practical world, that's not how it happens. Web hosts aren't going to whitelist IPs, they just open SSH.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    25. Re:Dear Kids... by Culture20 · · Score: 1

      LOL! You're sitting at 0, and he's at +3.

      Actually, the AC is at 0 and GP is at 1 (was only modded down 1 by a mod who decided that modding me redundant was more important than modding the AC up, but I had the karma bonus added in).

      Nobody notices MOST ACs because most ACs don't contribute much if anything to the discussion.

      Nobody notices most ACs because AC comments don't send notifications upon posting (you have to actively recheck your posts to see them), and they start 2 points under where most people read. I wanted to make sure the originator saw the response because it's good practice.

    26. Re:Dear Kids... by symbolset · · Score: 1

      Dear kids: your faith in firewalls is part of the problem. It's a scuba suit in a deep fat fryer.

      --
      Help stamp out iliturcy.
    27. Re:Dear Kids... by hughesjr · · Score: 1

      You control the iptables on your machine, not the ISP. These guys are not hacking commodity shared servers they are hacking individual/coloacted servers. You would use IPTABLES and limit the access to at least known networks. Why have your ssh port open to China and Russia if it is located in the UK and never accessed from those locations (for example). Even if you don't have a single IP, you are on a specific network and you can allow only access from the "4" class B networks (as an example), etc. Also, you should always disable password logins and use keys to access your servers via ssh. Certainly you should disable direct "root" logins.

    28. Re:Dear Kids... by Em+Adespoton · · Score: 1

      Of course, if you're using SSH without a cert and a secure pass-phrase, it's not much better than having telnet open to the world. That said, I've had a number of sshds open to the world with password auth only for over a decade, and despite getting hit with numerous attacks a day, they have yet to be compromised. Turning off ssh access to all but a single account with a hard to guess user name and a much harder to guess pass-phrase probably has something to do with this. Most remote connections appear to be from China running a dictionary attack.

      I did have one interesting connection from Indonesia once that appeared to be trying to leverage some sort of certificate exploit, but as I had certs disabled, it failed.

      Right now, it appears that the most insecure part of my internet gateway is the part managed by my ISP and locked away from me... they're running a number of insecure services, some with known potential vulnerabilities. I haven't worried too much, as for the most part you'd have to be on their local line talking ATM to leverage most of the issues. And then you'd have to either re-flash the device with exploit code (dropping my connection) or get past my firewall to do anything at all nefarious.

  5. They should have known better. by xeeno · · Score: 2

    The first thing you do in C&C is build walls around your MCV so engineers won't get it. Seriously, guys.

  6. CentOS by future+assassin · · Score: 3, Insightful

    >All of the known Duqu C&C servers discovered up to this point have been running CentOS

    Probably since this is a popular OS for web hosts that resell/sell servers. Who are the people who buy these server? Well anyone and everyone who wants to be another web host yet have no idea on how to secure a server so they hire some $40 per month security company to secure their servers. There must be 1000's of those servers out there ripe for raping.

    --
    by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
    1. Re:CentOS by JSBiff · · Score: 1

      "so they hire some $40 per month security company to secure their servers. There must be 1000's of those servers out there ripe for raping."

      If each customer is paying $40 per month, and their are thousands of customers, wouldn't that be a $40,000+ per month security company? For that kind of cash, they should be competent. When I buy into a company like that, I figure I'm supposed to be getting more than $40/mo worth of security expertise, because I'm *sharing* the costs with thousands of other customers.

      Sadly, however, you're probably right that many hosting companies don't really have sufficient expertise to know how to secure their customers' servers for them. But, it's not because they aren't being paid enough, it's because they aren't spending the money on the right things.

    2. Re:CentOS by dotancohen · · Score: 1

      ...so they hire some $40 per month security company...

      What should I be googling to find these companies? I have one customer that I can no longer support and I'd like to at least refer him to _somebody_ professional.

      --
      It is dangerous to be right when the government is wrong.
    3. Re:CentOS by future+assassin · · Score: 1

      Well ones I know off

      http://www.platinumservermanagement.com/
      http://24x7servermanagement.com/
      http://seeksadmin.com/

      One I used before and they were ok was http://www.acunett.com/ but then again you can't reply for these companies for real management.

      --
      by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
    4. Re:CentOS by dotancohen · · Score: 1

      Thanks. At the least that should give me an idea of what to look for. Have a great day!

      --
      It is dangerous to be right when the government is wrong.
  7. kinda scary by martas · · Score: 2

    Am I the only one who is kind of worried about the whole stuxnet/duqu thing? We've been hearing/hypothesizing about the dangers of "cyber-warfare" (as much as I hate the term) for a while, pretty much since the beginning of Internet malware, but it seems as though recently shit has finally started to hit the fan, first with increasingly worrying allegations about Chinese hackers and such, and now with this (which seems to be the doing of the US/Israel, at least a lot of people think it is).

    If things continue along this trend, one could expect a really bleak future for the Internet where major world governments and other well-financed organizations have virtually unlimited power to do what they like with any computerized system, and continually carry out covert attacks against each other. It seems the only thing that could prevent that from realizing would be some major game-changing advances in computer security, but I'm not seeing any indication that that's likely to happen...

    1. Re:kinda scary by Statecraftsman · · Score: 1

      Even though this story posits a 0-day in OpenSSH as the culprit, I'm of the mind that free software with a strong patch and update system is as good as it gets. If you don't update your systems say because you don't want to break stuff, sorry but even non-0-days will bring you down. So on the sysadmin side, we're moving toward more specialization.

      On malware and free software: http://trygnulinux.com/action/?q=node/68

    2. Re:kinda scary by Baloroth · · Score: 1

      That "future" already more or less exists. In fact, it always has. What prevents it from getting bleak is the checks and balances. Governments can screw other governments of course, but being caught really sucks for them diplomatically, so they have to be cautious. Corporations can be caught either by the government (which often seems to do little or nothing) or by the public eye, which can wreck the company. Or by other companies, of course.

      This has always been true, and in far more than "cyber"-space. Covert attacks are limited by pressure from various sources. Some of those weaken or grow stronger as public opinion or diplomatic situations change, but it always exists. Except in full-on war (and even some there), and then the attacks stop being covert.

      China, for example, could attack the US infrastructure (probably). They don't, because they need our money as much (more, IIRC) as we need their manufacturing. And intelligence agencies have, supposedly, built in backdoors to many systems for decades now. The danger of those being abused is present, but not much greater than the abuse any intelligence agency ever could do. Which is a lot, in theory, but in practice is usually relatively limited (again, by public pressure.)

      --
      "None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
    3. Re:kinda scary by morgauxo · · Score: 1

      Or.. after a couple high profile attacks they finally disconnect these critical control systems from the internet and we don't hear about it again.

    4. Re:kinda scary by Hentes · · Score: 1

      If things continue along this trend, one could expect a really bleak future for the Internet where major world governments and other well-financed organizations have virtually unlimited power to do what they like with any unsecured computerized system,

      FTFY
      Also, I don't want to frighten you, but with an unsecured system it's not just incredibly powerful governments, but every 16 year old scriptkiddie can do what they like.

    5. Re:kinda scary by martas · · Score: 1

      Well, there are certainly degrees to it. A script kiddie probably couldn't have pulled off stuxnet, because he wouldn't have intel about how Iran't enrichment program is run and such.

    6. Re:kinda scary by couchslug · · Score: 2

      "It seems the only thing that could prevent that from realizing would be some major game-changing advances in computer security, but I'm not seeing any indication that that's likely to happen..."

      Pre-computer security was an "air gap" (often reinforced with guards and alarms etc) between valuable systems and potential attackers.

      The horny craving to have everything connect to the internet and run Windows is to some extent a self-punishing mistake born of extreme hubris.

      --
      "This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
    7. Re:kinda scary by Anonymous Coward · · Score: 1

      Or you don't update your system because you use a system (centOS) that leeches off of a company that actually does all the work (Redhat), and said leech doesn't provide security updates as fast as the company doing the work, you will always be under the gun and vulnerable to quick acting hackers.

  8. Points 4. and 5... by djsmiley · · Score: 5, Insightful

    4.The servers appear to have been hacked by bruteforcing the root password. (We do not believe in the OpenSSH 4.3 0-day theory - that would be too scary!)
    5.The attackers have a burning desire to update OpenSSH 4.3 to version 5 as soon as they get control of a hacked server.

    Ah yes, lets pretend there is no problem because the idea that there is, is too scary. Someone kill me, please. The only other reason I can think of, which also ties in with the fact they were appently checking the man page for sshd_config is that something changes in the default settings between 4.8 and 5 and this they wanted desperately, but even then this would point to some sort of exploit. *(Maybe an exploit in the way the default settings are in centos, rather than in openssh).

    --
    - http://www.milkme.co.uk
    1. Re:Points 4. and 5... by Anonymous Coward · · Score: 3, Informative

      4.The servers appear to have been hacked by bruteforcing the root password. (We do not believe in the OpenSSH 4.3 0-day theory - that would be too scary!)

      Why the f**k PermitRootLogin defaults to yes on CentOS's sshd config?
      Isn't it supposed to be a enterprise oriented distro?

    2. Re:Points 4. and 5... by CyprusBlue113 · · Score: 2

      Judging by the rest of the article, I strongly suspect it has more to do with enabling their secure hierarchy of kerebos based logins than turning off the exploit they used. You can see some of the other things they do relate to features that require a 5+ openSSH once they're in.

      --
      a handful of selfish greedy people are no match for millions of selfish, greedy people -u4ya
    3. Re:Points 4. and 5... by knarfling · · Score: 1

      That was my question!! The second one being, "Why wasn't PermitRootLogin turned off?" One of the first things I do when setting up a new server is verify that the root cannot get in remotely. As soon as there is any kind of user authentication set up and a user either set up or can log in, PermitRootLogin is set to no. From then on, admins wanting remote access with root privileges must log in as a user and either use sudo (preferably) or su. I even have the server email a group if someone does an su to root or logs in as root from a console.

      I don't expect everyone to be able to set up that kind of monitoring, but allowing remote root logins is just asking for trouble.

      --
      Great civilizations have lived and died on false theories. Don't mess up mine with a few facts.
    4. Re:Points 4. and 5... by Pharmboy · · Score: 4, Informative

      Why the f**k PermitRootLogin defaults to yes on CentOS's sshd config?
      Isn't it supposed to be a enterprise oriented distro?

      Most enterprises have IT staff to change that as soon as the OS is installed. The problem with not allowing root to ssh in with a fresh install is that a fresh install only creates the user "root", so you physically have to be at the machine to log in and setup the system if you don't allow root to ssh in. Yes, it is technically safer to disallow root to log in with a vanilla install, but it is inconvenient. On the DESKTOP, it makes sense to disallow root via ssh from a vanilla install, however.

      On servers, I usually setup vanilla, then ssh in, add a user, change to disallow root logins, and change the default port, then restart ssh, open a new session to test as that new user on the new port and "su -" to root, then log out of the first root shell, and finally start a new session on the new port and try to root in, to make sure I can't. I can't be that unique in doing it this way.

      Serious question to all: Do people still use the default port for SSH anymore? I never have, as once we went from telnet to ssh (over a decade ago...) we just always used a non-standard port. Makes my logs a lot easier to read.

      --
      Tequila: It's not just for breakfast anymore!
    5. Re:Points 4. and 5... by asdfghjklqwertyuiop · · Score: 1

      Serious question to all: Do people still use the default port for SSH anymore? I never have, as once we went from telnet to ssh (over a decade ago...) we just always used a non-standard port. Makes my logs a lot easier to read.

      Yes, I run it on the default port, as does everyone else I personally know. How does running it on a non-standard port make your logs easier to read?

    6. Re:Points 4. and 5... by gatkinso · · Score: 1

      It decreases the number of script based dictionary attacks aimed at port 22, so your logs are not as cluttered. Other than this running on a nonstandard port does nothing to enhance security.

      However some fools somehow think it does.

      --
      I am very small, utmostly microscopic.
    7. Re:Points 4. and 5... by gatkinso · · Score: 1

      The whole nonstandard port thing is silly. It does nothing (yes, nothing) to enhance security but to be fair it doesn't impact security either. Note that some places block outbound connections on nonstandard ports.

      Have fun logging into your box from such places.

      --
      I am very small, utmostly microscopic.
    8. Re:Points 4. and 5... by asdfghjklqwertyuiop · · Score: 1

      It does nothing (yes, nothing) to enhance security

      It may enhance your luck. Sometimes exploits are found and there's some time between the discovery of the vulnerability and you fixing your system. In that time it could be that the only attack that will be attempted on your system will be an untargeted one by someone who's just quickly sweeping the whole internet on the standard port for as many machines to root as quickly as possible.

    9. Re:Points 4. and 5... by ChumpusRex2003 · · Score: 2

      I don't understand the "brute force" claim. In the article, they later explain:

      "Note how the 'root' user tries to login at 15:21:11, fails a couple of times and then 8 minutes and 42 seconds later the login succeeds. This is more of an indication of a password bruteforcing rather a 0-day. "

      This makes no sense to me. 2 attempts at a login, and then the 3rd succeeds? How is that brute force? Or is it just extraordinary luck (or an inept password policy).

      While I don't regularly perform penetration testing, my current understanding of brute-forcing SSH passwords, is that it requires thousand or millions of attempts, with the hope that an IDS doesn't spot the attempted ingress and lock-down firewalls, etc.

      To me, this looks more like a 0-day. A few probes with potentially exploitative malformed logins, until they find one that works on the specific kernel/SSH version.

    10. Re:Points 4. and 5... by Pharmboy · · Score: 2

      Nothing foolish about knocking out 100% of the scripted attacks on the server, which are over 99% of the attacks that will ever be attempted on most servers. Running on a non-standard port isn't the solution to running a secure server, it is just part of the solution, and works great for 0 day exploits in particular. Any decent admin knows that.

      --
      Tequila: It's not just for breakfast anymore!
    11. Re:Points 4. and 5... by Pharmboy · · Score: 1

      THAT is the entire point of using non standard ports. Anyone who says otherwise is too busy trying to sound important to realize how attacks really happen. I've run on non-standard for years, and I get no (repeat, NO) entries in my logs from scripts trying to log in. Obviously I still have to patch everything and keep it all up to date, but this removes one vector: 0-day ssh exploits. I keep my stuff up to date, my concern isn't the easy stuff, it is the 0-day stuff that I can't just patch.

      Some will say "big deal, how often does that happen?" and of course, the obvious answer is "it only has to happen once to fuck up your whole week".

      --
      Tequila: It's not just for breakfast anymore!
    12. Re:Points 4. and 5... by gatkinso · · Score: 1

      It isn't part of the solution, it is just lazy (which ironically ends up being more work), and imparts a false sense of security.

      Even if I were foolish enough to buy into the whole security through obscurity angle, I would implement this via a firewall/router that forwards traffic on a nonstandard port to port 22 on the server in question, not by simply plugging in the red cable into my box and having it listen on a nonstandard port (or even more retardedly forwarding the nonstandard port ssh traffic to a nonstandard port on the ssh server).

      --
      I am very small, utmostly microscopic.
    13. Re:Points 4. and 5... by MikeBabcock · · Score: 1

      Its actually handy for those of us who do multiple VNC installs of CentOS on the LAN at once. I start a bunch of LAN installations, monitor them by VNC, and on reboot, I ssh in as root, upload keys for the default user, disable root access and password logins, and voila, its done.

      What I really wish they'd do is put up an /etc/issue.net prompt complaining that the server hasn't been configured yet (like snmpd.conf's).

      --
      - Michael T. Babcock (Yes, I blog)
    14. Re:Points 4. and 5... by grcumb · · Score: 1

      The problem with not allowing root to ssh in with a fresh install is that a fresh install only creates the user "root", so you physically have to be at the machine to log in and setup the system if you don't allow root to ssh in.

      Is this true? I haven't installed plain CentOS in years and years, but I don't recall seeing this behaviour back when I was using RedHat (1990s - early 2000s), and it absolutely never happens with Debian.

      But even if it is true, it's not difficult at all to customise one's installer so that it runs a script to create a second user account, add it to sudoers, and then disallow remote root login. It's as easy as adding a single RPM to the install image. Given the security risk that root login creates, something like this would surely be worth the effort for any company running more than a trivial number of servers.

      --
      Crumb's Corollary: Never bring a knife to a bun fight.
    15. Re:Points 4. and 5... by Raenex · · Score: 1

      Even if I were foolish enough to buy into the whole security through obscurity angle

      What's foolish about this? If I have all the security plans and an exploit is found (as they have been time and time gain), then you are vulnerable. If an additional layer of obscurity was applied on top of that, you are a harder target.

    16. Re:Points 4. and 5... by Jerry · · Score: 2

      "Brute force" in only three tries? How logical is that?

      --

      Running with Linux for over 20 years!

    17. Re:Points 4. and 5... by dweller_below · · Score: 1

      Given two equal SSH daemons, both fully updated but one on a random high port, the one listening on 22 will log hundreds or thousands of attempts per day, the one on a random port will log *zero*. Which do you think makes log auditing easier to look for truly dangerous threats?

      I can second this. For years I have monitored the SSH activity at my university. Today we had 30K+ active devices and hundreds of SSH servers. I use Snort rules to detect SSH negotiation on non-standard ports. We have NEVER had an attack against a SSH server using a properly obscured SSH port. Of course, we don't depend on obscurity. Here is a snippet from our guide to setting up a SSH server: https://it.wiki.usu.edu/ssh_description

      We try to use multiple overlapping security layers to protect SSH:

      • Set your firewall to limit the vulnerable scope of SSH to a few trusted hosts.
      • Set your firewall to prevent credential guessing by rate-limiting connections to the SSH port.
      • The SSH Port is treated as a shared secret. Only interesting, targeted attacks find the SSH server.
      • The SSH server should not allow known usernames including root. The attacker must find a username.
      • The admin is trained to create good passwords for his usernames.
      • SSH users are taught to verify the identity of their systems when they first connect.
      • System admins must regularly review the activity of their SSH servers.
      • USU IT Security monitors all SSH connections, including ones on non-standard ports. We follow up on interesting connections.
      • USU has SSH Honeypots that help us respond to SSH attack.

      When we reviewed the SSH activity today, we found 2 compromised systems. One had sprouted an SSH server on port 8080 and had a large community of hackers connecting to it. The other had bot C&C running over an SSH connection to the Netherlands. This review is easy when we don't look at all the crap on TCP/22.

      Miles

    18. Re:Points 4. and 5... by hughesjr · · Score: 1

      It is set up that way because that is how RHEL is setup.

  9. This says it all for Linux "security" by Anonymous Coward · · Score: 1, Interesting

    "An in-depth analysis of the known C&C servers used in the Duqu attacks has found that some of the servers were compromised as far back as 2009, and that the attackers clearly targeted Linux machines" - Posted by Unknown Lamer on Wednesday November 30, @11:46AM
    from the nsa-reads-slashdot dept. FROM THE MAIN ARTICLE ITSELF

    Current proof that Linux's NOT "invulnerable secure" yet again, & yes, that Linux does get targetted by malwares...

    (Despite all the "FUD" you see & have seen for YEARS now on this website from the "Pro-*NIX/Penguinista" around here!)

    Linux gets "hit" by the worst kind too, in these "blended-threat tech" types, that use rootkits that employ drivers + bogus bootsectors shown in this article today...

    Plus - the entire LAMP stack doesn't do well http://www.theregister.co.uk/2011/06/10/domains_lamped/
      (especially Apache lately -> http://apache.slashdot.org/story/11/11/28/0335213/apache-flaw-allows-internal-network-access & earlier still here http://www.theregister.co.uk/2009/09/03/apache_website_breach_postmortem/ ).

    * Yes - Any OS' is securable, & far better than they come by default (yes, even SeLinux, but you have to go beyond its mere defaults to make it better, + MacOS X too (Apple produces guides for that in fact)), however/again:

    The years of hearing how "secure" OpenSores/LAMP is around here was totally unrealistic & a blatant lie based on the information above, & yes, below next too!

    APK

    P.S.=> Top that off with this current information from this year 2011 also:

    ---

    KERNEL.ORG COMPROMISED:

    http://linux.slashdot.org/story/11/08/31/2321232/Kernelorg-Compromised

    ---

    Linux.com pwned in fresh round of cyber break-ins:

    http://www.theregister.co.uk/2011/09/12/more_linux_sites_down/

    ---

    Mysql.com Hacked, Made To Serve Malware:

    http://it.slashdot.org/story/11/09/26/2218238/mysqlcom-hacked-made-to-serve-malware

    ---

    ---

    Linux's showing in CA's breached recently too? Ok:

    http://uptime.netcraft.com/up/graph?site=StartCom.com

    http://uptime.netcraft.com/up/graph?site=GlobalSign.com

    http://uptime.netcraft.com/up/graph?site=Comodo.com

    http://uptime.netcraft.com/up/graph?site=DigiCert.com

    The majority (4/5) of what was breached RAN LINUX (StartCom, GlobalSign, DigiCert, & Comodo)... per these articles verifying that:

    http://itproafrica.com/technology/security/cas-hacked/

    ---

    Toss ANDROID (yes, a Linux since it uses a Linux kernel) also, since it's being "shredded" on the mobile phone security-front rampantly for years now? You get the picture...

    ... apkb

    1. Re:This says it all for Linux "security" by MMAfrk19BB · · Score: 3

      If I had mod points I would give them to you for actually linking articles that prove your point, but try to be a bit more coherent and maybe don't post as AC next time. Have the balls (or ovaries) to stand up for what you said. That being said, anyone who thinks that FOSS is $DEITY's gift to security by default is mistaken. Nothing is safe until someone competent configures, patches, and hardens it correctly. However, I don't believe that the proprietary corps are any better, and are usually worse, because they rely on security through obscurity (i.e. no one knows our code so we don't have to worry that much about it.)

    2. Re:This says it all for Linux "security" by americamatrix · · Score: 5, Insightful

      It's just like any other OS. You need to know what your doing.

      A poorly setup Linux box will be worse than a locked down Windows install. Everyone knows this.

      To say Linux itself is inherently vulnerable is an ignorant statement.


      -americamatrix

    3. Re:This says it all for Linux "security" by c0d3g33k · · Score: 1

      1. Please try again with a coherent critique of Linux security rather than a spittle spraying rant. I might read it and take it seriously.
      2. You seem to have an agenda here, and have convinced yourself that it is validated. Good for you (pat on head).
      3. Schadenfreude is bad for your health.
      4. So ... what's your point exactly, and what do you expect people to do exactly if they happen to agree with whatever your point is?

    4. Re:This says it all for Linux "security" by sandytaru · · Score: 1

      I'd argue that they're targeting Linux precisely because everyone assumes their Linux servers are invulnerable.

      --
      Occasionally living proof of the Ballmer peak.
    5. Re:This says it all for Linux "security" by jellomizer · · Score: 2, Interesting

      Oh come on!
      If someone did a rant like this for Windows it would be moderated +5 Insightful.

      The Agenda here is to point out that Linux isn't the God of OS. It has its problems just like Windows and the others. As we giggle and glee when there is a Major Windows Issue, we like to discredit any Linux problem.

      It isn't that Windows is More Secure then Linux but there are too many people running Linux feeling invincible from all the world has to attack them.
      The biggest problem in IT Security isn't the OS it is the Dumb Ass who runs the systems.

      You can have a Windows Network running for years without a security issue. You can Have a Linux network that is attacked daily. It determine the skill of the System Administrator.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    6. Re:This says it all for Linux "security" by dclozier · · Score: 1

      Yes I think it does say it all for Linux "security".

      I'd argue that this was because after taking control the attackers could easily secure/defend the machine and prevent others from taking it over. A C&C machine is a valuable asset for any organization.

    7. Re:This says it all for Linux "security" by Anonymous Coward · · Score: 3, Interesting

      Current proof that Linux's NOT "invulnerable secure" yet again, & yes, that Linux does get targetted by malwares...

      Yeah, go for it! You keep at it, pal! You're beating your opponent so hard that the straw is leaking out!

      Seriously, nobody with any credibility has ever claimed that Linux is "invulnerable secure". The strongest argument usually made is that Linux is more secure than Windows, which was absolutely true when it was commonly being made 10 years ago. The debate has moved on. The claims you should be arguing against today are that Linux is better value-for-money on servers, and more secure than Windows specifically on the desktop.

      As for malware - well, a targeted attack probably by a nation-state is hardly the scenario people are thinking of when they say "Linux doesn't get viruses". The claim you should be fighting here is that Linux is less likely to be hit by drive-by malware or compromised at random by malicious websites. These claims are absolutely true; even if Linux is no more secure than Windows, it is still a much smaller and less attractive target, and therefore safer.

      But, hey, I'm getting in the way of you beating on your strawman, so I'll shut up now and let you keep on with your regularly scheduled trolling!

    8. Re:This says it all for Linux "security" by Anonymous Coward · · Score: 1

      The guy is a common troll around here and will link pages and pages of articles in incoherent rants whenever OS security is mentioned (you can see his joke of a thread about locking down Windows, it's just as badly written as every single one of his posts here, with a lot of bolds, caps, and dotted lines)

    9. Re:This says it all for Linux "security" by magamiako1 · · Score: 1

      As far as desktop is concerned I don't consider linux to be any different than Windows. While it is true that by default Windows XP and previous permitted Administrative privileges, UAC in Vista and 7 go a step above to prevent "drive by" system-level malware infections.

      Local root escalation exploits exist, but they exist in Linux, too. This goes for a very wide range of applications.

      Both Windows and Linux have gone through great lengths for local security though, and I'd suggest looking at the Microsoft Enhanced Mitigation Experience Toolkit utility that is available.

      You can harden individual processes from common exploit techniques (heap spray, null page, structured exception handling, etc)

    10. Re:This says it all for Linux "security" by Culture20 · · Score: 1
      Sorry in advance for feeding the Troll, but he's at +4 Interesting...

      Current proof that Linux's NOT "invulnerable secure" yet again, & yes, that Linux does get targetted by malwares... (Despite all the "FUD" you see & have seen for YEARS now on this website from the "Pro-*NIX/Penguinista" around here!)

      Great Scott! It's the Strawman! Hurry Robin, knock it down before Commissioner Gorden gets here!

      The line of reasoning here has always been: Linux Nut: Ha Ha! Windows has another [TCP stack / Kernel Font Rendering] vulnerability!
      Microsoft nut: Well, that's only because Linux is never targeted. It's just as non-secure, but no one wants it. Linux Nut: Linux is targeted, and it's more secure because patches are delivered in a shorter time frame (unless you're using CentOS, then patches go through two layers of slow bureaucracy after the upstreams maintainers fix the issue)

      Here we have a case where someone wants Linux (usually the prime target, but always out of reach), and they had a small window of opportunity to hack badly administered boxes. These were the microsoft equivalent of Windows 2k3 boxes set up without auto-updates and username/password administrator/administrator.

    11. Re:This says it all for Linux "security" by grcumb · · Score: 1

      The Agenda here is to point out that Linux isn't the God of OS. It has its problems just like Windows and the others.

      Fine, but that's an inaccurate statement. To say that it 'has its problems just like Windows' implies that it has the same problems as Windows. That's a perfect example of false equivalence.

      For decades now, Windows has had systemic problems with security. Its ecosystem is fundamentally weakened by malware due to a legacy of flagrant disregard to security. (Unix once suffered from the same naiveté, but happily managed to move past it, by and large.) The problem runs so deep, in fact, that even relatively secure versions of the software (those produced in the last two years or so) are still burdened by the deficiency of the environment in which they operate, and the culture of complacency and ignorance that pervades MS systems administration.

      In fact, things have got so bad that black hats sometimes overlook the low-hanging Linux fruit, instead spending inordinate amounts of time and effort to break into an increasingly secure Windows environment.

      My organisation is in the middle of a Exchange upgrade as I write this, and if this experience is any guide, there are fundamental differences between how people administering Microsoft systems approach change management and how grey-haired old *nix farts like me approach it. These differences are cultural in part, but the respective cultures derive from the design philosophy, which in turn dictates the toolkits and approaches taken.

      And yes, the Linux philosophy (and approach and toolkit) does have flaws. Here's just one example. But they have very little in common with Windows. The single most important difference is that Linux's flaws have not yet led to systemic dysfunction. I'm not saying they won't; I'm saying they haven't. Yet.

      --
      Crumb's Corollary: Never bring a knife to a bun fight.
    12. Re:This says it all for Linux "security" by Culture20 · · Score: 1

      Apk showed current information which u don't disprove in each point of his on Linux being hacked on servers, hosting malware ... which u and others who are Linux fans seem to avoid disproving in each documented current point from reputable sources he used to show that much. Why's that? Because you can't do it?

      Actually,

      I can't read the stuff that

      is formatted in the way that
      Random Anony
      mous Cowards

      write with the tagline of APK

      It's very jarring. I usually read the first few lines, let him rant like Gene Ray, then read the closing argument.

  10. All CentOS, but no RHEL by gatkinso · · Score: 2

    That makes me think twice about skipping on that Redhat license.

    Perhaps the folks at Cent should be checking their logs.

    --
    I am very small, utmostly microscopic.
    1. Re:All CentOS, but no RHEL by Culture20 · · Score: 1

      That makes me think twice about skipping on that Redhat license. Perhaps the folks at Cent should be checking their logs.

      It's just representative of the extra week that CentOS sometimes takes before patches are available. They've been slightly better lately, only one day behind RHEL. Of course compare that to windows machines with a sometimes multi-month lag on patches..

    2. Re:All CentOS, but no RHEL by gatkinso · · Score: 1

      This event spanned YEARS. Why no RHEL victims?

      I smell a rat in CentOS.

      --
      I am very small, utmostly microscopic.
    3. Re:All CentOS, but no RHEL by hughesjr · · Score: 1

      Because CentOS is used more than any other linux server on the Internet maybe:

      w3techs web usage

    4. Re:All CentOS, but no RHEL by gatkinso · · Score: 1

      But CentOS X.Y is supposed to be basically identical to RHEL X.Y-1.

      So, again, why no exploited RHEL servers? Note that RHEL is pretty damn common as well.

      --
      I am very small, utmostly microscopic.
    5. Re:All CentOS, but no RHEL by hughesjr · · Score: 1

      You would have to ask the people who did it. I suppose that they might think that people who pay for RHEL are more security savy that those who take the free route. I am a centos developer, so I do not appreciate the suggestion that the CentOS team did something. There is no issue that makes centos more or less secure than RHEL in this instance. They likely chose CentOS because it is more prevalent than any other distro in the world and they had a scanner to find it. The initial entry is almost certainly a brute force ssh root password break in. They also likely developed their "malicious code" using the CentOS distro (it is free and the most widely used distro ... what would you pick to develop your code on?), so they likely know it works for sure on CentOS. Why take a chance it does not work on RHEL if they developed it on CentOS?

      One of the issues in bding the most widely used distro and free is that bad guys use your stuff to build bad things.

  11. Sleep well at night. by bmo · · Score: 1

    1. Don't run services you don't need. This goes for all systems, including Windows.
    2. If you do need sshd running, install denyhosts.
    3. If at all possible, run sshd on a nonstandard port.

    #3 keeps the logs quiet from bots trying to jiggle a door handle that isn't there on 22.

    --
    BMO

    1. Re:Sleep well at night. by knarfling · · Score: 2

      4. Change PermitRootLogin to no. If you must have remote root access, make them log in as a normal user and su to root. (Better yet, set up sudo and control who can do what.)

      --
      Great civilizations have lived and died on false theories. Don't mess up mine with a few facts.
    2. Re:Sleep well at night. by bmo · · Score: 1

      Yeah, that too.

      It's just that I've been running Ubuntu so long and got so used to sudo and no root logins and all that I entirely forgot about it.

      Because any other way is madness.

      Speaking of no-root-login, there is a certain kind of user or admin who will fight to the death against removing the login for root and say how sudo is a security hole. I just don't get it.

      Someone else also mentioned fail2ban. I endorse that too.

      --
      BMO

    3. Re:Sleep well at night. by magamiako1 · · Score: 1

      From the article it appears it had nothing to do with whether or not root login is turned on.

      Remember, OpenSSH runs as the root user even if root logins are not accepted. Exploiting a vulnerability in OpenSSH isn't entirely out of the picture.

      A more proper way to do things is to force a VPN scenario to manage your servers. Try to run known proven VPN hardware from major vendors (such as Juniper and Cisco) where the hardware they use is special purpose (and not running a lot of extra fluff), which limits your attack surface. Then you enable management of your machines via the VPN.

      FYI: I have seen video proof of a current version of OpenSSH with a remote escalation exploit that has yet to be acknowledged or patched. The exploit code was supposedly purchased by Apple. The demonstration was run on Ubuntu 11.10.

    4. Re:Sleep well at night. by knarfling · · Score: 1

      From the article it appears it had nothing to do with whether or not root login is turned on.

      Sorry, but the logs from both servers in the article (second link) do show that they both accepted a password for user=root from a remote IP address. That doesn't happen when sshd_config is set to prevent remote root logins. The sshd logs should show a normal user logging in. The secure logs should then show the su or sudo with privilege escalation.

      Even though OpenSSH runs as root, that does not mean that anyone who connects in has root privileges. If the exploit allowed someone to connect in as root when PermitRootLogin is set to no, that would be very, very scary.

      BTW, I am not claiming that there is no exploit or that they did not use one. It seems very possible that they could have used the exploit to gain access the first time, changed or found a way to guess the root password and then logged in as root from then on. On server from 2009, it appears that they did not do that since there were several bad password attempts for user=root before they got in. But they could have done it on the other server.

      A more proper way to do things is to force a VPN scenario to manage your servers. Try to run known proven VPN hardware from major vendors (such as Juniper and Cisco) where the hardware they use is special purpose (and not running a lot of extra fluff), which limits your attack surface. Then you enable management of your machines via the VPN.

      A good VPN is definitely a good idea for the first line of defence. But that should not be all. Some people cannot afford the VPN hardware, and have to make do without it. Even with it, you should still limit remote root access. That makes a breach that much harder to accomplish. At my company, we happen to use both. In addition, we have monitoring set up so that even if someone does access the root user, we get alerts.

      --
      Great civilizations have lived and died on false theories. Don't mess up mine with a few facts.
    5. Re:Sleep well at night. by magamiako1 · · Score: 1

      You employ good security measures IMO :)

      Even if attackers can remove relevant logs they have no guaranteed knowledge of what your logging is doing and triggering upon first entry (hopefully). A root login or escalation that triggers an e-mail is something they're very unlikely to catch before you are notified about the intrusion.

    6. Re:Sleep well at night. by Anonymous Coward · · Score: 1

      FYI: I have seen video proof of a current version of OpenSSH with a remote escalation exploit that has yet to be acknowledged or patched. The exploit code was supposedly purchased by Apple. The demonstration was run on Ubuntu 11.10.

      And I'm the Queen of Sheba.

    7. Re:Sleep well at night. by DrBoumBoum · · Score: 1

      1. Don't run services you don't need.

      You'd have to know what services you truly need. I remove all obvioulsy uneeded services on any new CentOS installation but always stop at these ones: acpid, auditd, cpuspeed, haldaemon, irqbalance, messagebus, microcode_ctl and possibly kudzu and sysstat. Do I need them? I just have no idea and no willingness to try.

      2. If you do need sshd running, install denyhosts. 3. If at all possible, run sshd on a nonstandard port.

      #3 keeps the logs quiet from bots trying to jiggle a door handle that isn't there on 22.

      No. You just shouldn't have SSH accessible from the outside, period. Use OpenVPN if you need remote access, it's free.

    8. Re:Sleep well at night. by bmo · · Score: 1

      You know, I had a reply half thought up, but then all I have to say is this now:

      Thanks for jumping down my throat.

      Piss off.

      --
      BMO

    9. Re:Sleep well at night. by pclminion · · Score: 1

      If you must have remote root access, make them log in as a normal user and su to root.

      Can somebody please explain how this is safer than just logging in as root?

    10. Re:Sleep well at night. by knarfling · · Score: 2

      There are several ways that this is safer.
      1. It removes the known user problem. Since root is a user on all Linux boxes, if I want access, all I have to do is to find a password. I only have to discover one piece of information. If root cannot log in, I must now find three pieces of information, a username, a password for that user, and the root password.
      2. It discourages scripting attacks. Since root cannot get in, I would need to modify my script to try common usernames, or try specific usernames for each company or server I am attacking. While this does not block attacks that are targeted directly against me, script writers going after the easy targets are unlikely to spend the time needed to figure out what usernames are valid for my servers.
      3. If I do breach a computer with a specific username, I now have two avenues of approach. I can try to exploit another hole that allows privilege escalation, or try to determine a root password. Guessing, using dictionary attacks/ribbon tables, or brute force methods take time. This increases the odds of being detected by Host Integrity Monitors (If they are being used). There is no guarantee that the server has the software with an exploit is deployed on that server, or that the users I have compromised has access to that software.
      4. Logging. Instead of one part of a log that might be missed showing that I logged in as root, I now have multiple log entries. At least one showing that I logged in as a normal user, and another showing that the user had escalated privileges. Again, increasing the odds that I will get caught. Hopefully before I can do any damage.
      5. Although this does not appear to be common, at least one company I know has monitoring set up to detect root access. A second local account is set up with root privileges. Admins sudo to the second account and only admins have rights to sudo su to it. The root is given a very, very complex password that is hidden. Traps are placed so that all admins are alerted if anyone at all logs in as root. If I get an alert in the day that someone is logging in as root, I can check with other admins to see who is doing what. If I get an alert at night, I can guess that my server has probably been breached and I can take appropriate steps. I don't get alerts for normal occasional root functions, but if someone does breach my servers, I know before they can do much.

      These are just a few ways that using a normal user and then forcing su or sudo to root is safer. There might be more that I don't remember at the moment. BTW, this does not prevent all attacks, but it does help.

      --
      Great civilizations have lived and died on false theories. Don't mess up mine with a few facts.
    11. Re:Sleep well at night. by pclminion · · Score: 1

      Some of those are good points, but several of them seem to be logically equivalent to "use a longer root password." You can argue that logging in as a user, then su'ing to root requires more information, but I can just cat those three bits of info together and use that as the root password. You might as well just pick a longer password.

  12. They got it backwards by David+Frankenstein · · Score: 1

    I would think this points to an exploit in SSHD 5.x, not 4.3. Once I brute-forced into a system, I would think the first order of business is to ensure I can get back in if the password is changed, not to patch the little-known exploit I used to get in in the first place.

    1. Re:They got it backwards by gatkinso · · Score: 2

      Patch the hole because you don't want someone else (say a pron spammer) to come in behind you and end up getting caught (or screwing up your server). But yes there could be an exploit they are using in 5.x as well.

      I suspect it was not a brute force attack, they simply disguised the exploit as one so that it falls into the noise of the hundreds of brute force attacks each day.

      --
      I am very small, utmostly microscopic.
    2. Re:They got it backwards by magamiako1 · · Score: 1

      This guy ^

  13. duqu definition in short by boldi · · Score: 3, Informative

    http://en.wikipedia.org/wiki/Duqu

    Duqu is a computer worm discovered on 1 September 2011, thought to be related to the Stuxnet worm. The Laboratory of Cryptography and System Security (CrySyS) of the Budapest University of Technology and Economics in Hungary, which discovered the threat, analyzed the malware and wrote a 60-page report, naming the threat Duqu. Duqu got its name from the prefix "~DQ" it gives to the names of files it creates.
    Symantec, based on the CrySyS report, continued the analysis of the threat, which it called "nearly identical to Stuxnet, but with a completely different purpose", and published a detailed technical paper on it with a cut-down version of the original lab report as an appendix. Symantec believes that Duqu was created by the same authors as Stuxnet, or that the authors had access to the source code of Stuxnet.

    More likely Duqu==Stuxnet==Stars. Same guys, different vulns, different tools. Duqu is an instance made from a lego-kit.

  14. Re:Thank you & more inside... apk by chill · · Score: 2

    People don't like your posts for several reasons.

    1. You compare Apples to Oranges. Specifically a fully-hardened Windows system to an out-of-the-box Linux distro.

    2. You're overly sensitive to little criticisms. This is easily seen by the thread you linked to on the PC Pitstop forum. (Side question -- why are you banned from there?)

    3. Your childish references to things like "open sores" ranks you right down there with the people who call it "M$". Grow up.

    4. You seem to confuse the OpenBSD crowd and their "secure by default / no remote hole in XX years / we are unhackable" attitude with Linux supporters. Though, admittedly, there are fanboys and fanatics in every camp.

    5. Some of your indirect links are questionable. For example, from the PC Pitstop forum article you lauded this link on IPSec. http://www.analogx.com/contents/articles/ipsec.htm

    I'm unsure how to respond to that other than to say WTF? That has as much to do with IPSec as your post does with ice skating. It is talking about configuring a host firewall and never mentions anything about, well, IPSec!

    Finally, one of the main security benefits a Linux system has over Windows is the ability to REMOVE any component that isn't needed. Not just disable, but actually remove it totally.

    Custom Linux kernels can be built to support only the hardware on a specific machine. Entire classes of devices, from the printing subsystem to networking can be removed totally. You can't do that with Windows.

    --
    Learning HOW to think is more important than learning WHAT to think.
  15. obscurity security has value in some scenarios by Onymous+Coward · · Score: 1

    For the case of most worms and other such automated attacks, moving your service from its default port is actual defense.

    I can imagine worms that port scan looking for service signatures, but I haven't heard that that's common. Anyway, scanning lots of ports per machine would greatly slow a worm down or make an automated attack more obvious (showing up in more service logs).

  16. Re:A CentOS user responds by Culture20 · · Score: 1

    why would they yum update openssh, since you report they installed 5.8 from an ubuntu/debian source package.

    Because the rpm database would list openssh as the latest RHEL version if it were audited, but they could modify the ubuntu source before compiling it to allow for a back door?

  17. Re:AC troll that "kicked my ass" (lol, NOT) by Jerry · · Score: 4, Insightful

    Wow, windy fellow, aren't you?

    Your rant has one HUGE hole. Your citations are about one-off manual attacks against Linux. Not a single case involves a large group of Linux boxes being compromised by with a single email sent out from a spam box.

    Most attacks against Windows boxes are carried out by a simple email payload. That's how the 4,500,000+ Windows zombie bot farm was created last year within a couple of weeks. A Linux zombie bot farm was found last year as well. It contained only 700 boxes and it took the group of hacker who created it nearly six months to do so because they had to manually attack each machine. They ran dearjohn against who knows how many machines trying to find those with insecure root passwords. 700 in six months. They immediately secured those machines against all known exploits and used them for C&C machines to control much, much larger Windows bot farms because Linux IS secure. How many C&C Windows boxes have you heard about?

    --

    Running with Linux for over 20 years!

  18. Re:Others disagree w/ U, 75:1++... apk by chill · · Score: 1

    I understand you have provided useful and informative posts. I was responding to YOUR assertion that the "Penguinistas" get up in arms about your posts. If they are a small minority, then why complain?

    Why didn't you respond to my point that you were comparing well secured Windows systems to out-of-the-box Linux systems?

    Posting links of compromised Linux systems doesn't "prove" anything. I can match every one with ten on compromised Windows systems. However, in neither case can it be demonstrated that they were properly secured.

    You also didn't address my question of why you've been banned in the PC PitStop Forum, nor why I considered Linux superior for security -- because of the modularity that Windows simply does not have.

    As for Android, a phone is a different environment. That would be like me pointing out that lack of reports of hacked supercomputers running Linux. Total security! Right? No -- an environment you can't compare to standard desktops and servers.

    --
    Learning HOW to think is more important than learning WHAT to think.