Duqu Attackers Managed to Wipe C&C Servers 227
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."
NO! (Score:5, Funny)
Umm, how about a little context? (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.
Re:Umm, how about a little context? (Score:4, Informative)
Re: (Score:3)
No, and this proves that you didn't read it.
Re: (Score:2)
Re: (Score:2)
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 utte
Re: (Score:2)
Re: (Score:2, 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
Re: (Score:2)
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, b
Re: (Score:2)
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.
Anyo
Re: (Score:2)
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.
Re: (Score:2)
Unsurprisingly, so are unattended Windows installations. That is, after all, kind of the point of an unattended install.
Re: (Score:3)
Well, you see, Count Duqu was trying to trap Anakin Skywalker and Senator Padmé Amidala....
duqu definition in short (Score:4, 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.
Re: (Score:2)
Re: (Score:2)
I always thought Adam and Eve were fish from the stars. That's why they lived so long and had so many kids.
Dear Kids... (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.
Re: (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?
Re: (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?"
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)
Re:Dear Kids... (Score:5, 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.
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 ma
Re: (Score:2)
Re: (Score:2)
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!
Re: (Score:3)
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.
Re: (Score:2)
Just open a different port in the firewall?
Security through obscurity, eh?
obscurity security has value in some scenarios (Score:2)
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).
Re: (Score:2)
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.
Re: (Score:2)
How do I get remote shell access if the SSH port isn't open? .
Dial into the modem...?
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
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).
Re: (Score:2)
Re:Dear Kids... (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.
Re: (Score:2)
You never need SSH open to the internet. VPN in then access the ports.
Re: (Score:2)
They should have known better. (Score:2)
The first thing you do in C&C is build walls around your MCV so engineers won't get it. Seriously, guys.
CentOS (Score:4, 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.
Re: (Score:2)
"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.
Sa
Re: (Score:2)
...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.
Re: (Score:2)
Well ones I know off
http://www.platinumservermanagement.com/ [platinumse...gement.com]
http://24x7servermanagement.com/ [24x7servermanagement.com]
http://seeksadmin.com/ [seeksadmin.com]
One I used before and they were ok was http://www.acunett.com/ [acunett.com] but then again you can't reply for these companies for real management.
kinda scary (Score:3)
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...
Re: (Score:2)
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 [trygnulinux.com]
Re: (Score:2)
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. Co
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:3)
"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.
Points 4. and 5... (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).
Re: (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?
Re: (Score:2)
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 roo
Re:Points 4. and 5... (Score:5, 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.
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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 n
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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).
Re: (Score:3)
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.
Re: (Score:3)
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
Re: (Score:3)
"Brute force" in only three tries? How logical is that?
All CentOS, but no RHEL (Score:3)
That makes me think twice about skipping on that Redhat license.
Perhaps the folks at Cent should be checking their logs.
Re: (Score:2)
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..
Re: (Score:2)
This event spanned YEARS. Why no RHEL victims?
I smell a rat in CentOS.
Sleep well at night. (Score:2)
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
Re: (Score:3)
Re: (Score:2)
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
Re: (Score:2)
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 you
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:3)
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 e
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
They got it backwards (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
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 "se
Re: (Score:2)
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 w
Re:AC troll that "kicked my ass" (lol, NOT) (Score:5, 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?
Re:This says it all for Linux "security" (Score:5, Insightful)
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
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3, Interesting)
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
Re: (Score:2)
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 En
Re: (Score:2)
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 t
Re: (Score:2)
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 Anonymous Cowards
write with the tagline of APK
It's very jarring. I usually read the first few lines, let him rant like Gene Ray [timecube.com], then read the closing argument.
Re: (Score:3, Interesting)
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
Re: (Score:2)
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 [imagicity.com].
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 relati
Re: (Score:3)
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.
Re: (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.
Re: (Score:2)
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?