Slashdot Mirror
New Mayhem Malware Targets Linux and UNIX-Like Servers
Bismillah writes: Russian security researchers have spotted a new malware named Mayhem that has spread to 1,400 or so Linux and FreeBSD servers around the world, and continues to look for new machines to infect. And, it doesn't need root to operate. "The malware can have different functionality depending on the type of plug-in downloaded to it by the botmaster in control, and stashed away in a hidden file system on the compromised server. Some of the plug-ins provide brute force cracking of password functionality, while others crawl web pages to scrape information. According to the researchers, Mayhem appears to be the continuation of the Fort Disco brute-force password cracking attack campaign that began in May 2013."
Too bad TFA doesn't mention this.
So, the infection happens through insecure PHP code.
I highlight this because I still think the assertion "Linux and opensource in general, can't be attacked by viruses" is still true. The insecure PHP code that this malware benefits from for its infection must not be opensource, otherwise the security hole would be patched, and most people would get their updates on their systems within hours.
"a very interesting and sophisticated piece of malware that has a flexible and complicated architecture." as linked.
What do the plug ins offer?
Domestic spying is now "Benign Information Gathering"
Who's that clip clopping over my bridge?
Might want to wait until there's a teensy bit more malware before safely being able to safely deploy this broadside :)
Insecure for the hours it takes for this to be patched.
Comment received signal SIGSEGV, Segmentation fault.
The code snippets have too many colors which in my opinion make them hard to read. What do you think?
For those who don't read articles, this appears to happen if you don't auto-update your software and are running php. Not to many details on what versions of software they are using, but it may be a time for a sudo apt-get upgrade.
Wow, Linux still doesn't rate-limit login attempts by default? What is this, 1985?
*goes back to my VMS box*
Same can be said for all the Windows malware, most of which targets flaws that have been fixed for years.
"Toy OS..." ...that runs most of the modern web and nearly every mobile device in your home.
Fscking idiot.
lrn to *nix.
It's difficult to rate-limit login attempts from a botnet. The attack pattern I see on my server is one IP making three login attempts, then another IP making three login attempts, and so on. I do rate limit (via temporary IP blocking) attempts from one IP, but it doesn't help much. Of course, they're all doing password-based login attempts and I disable password-based SSH logins for all Internet-connected machines...
I am TheRaven on Soylent News
Please don't feed the trolls - it gives them indigestion!
Time for bed, said Zebedee - boing
The article seems to go in depth to the operation, commands, and purpose of the various shared libraries and scripts run by this malware, but it seems to skip out on the point of how these servers get infected in the first place....... Or maybe I skipped it - I was just perusing.
If the attacker gains access to any kind of database of password hashes, he can just compute thousands of attempts per second.
Likewise, log-in rate limiting is problematic. Windows does stupid shit like lock the local console if you set up rate-limit log-in...when logging in through the Microsoft log-in manager. That's retarded. A person is sitting at that console, and can't enter passwords fast enough; it should NEVER BE LOCKED. By contrast, any network log-in (RDP, FTP, ssh, etc.) should lock for 60 seconds after 20 failed attempts in 60 seconds, not counting console log-ins.
This does pose an additional small problem: if your system is compromised by malware, a no-local-login-locking policy will allow infinite, concurrent, constant log-ins. If you rate limit it to 20 per 60 seconds, the malware can prevent local users from logging in. If the malware has a local user's access but has locked out the administrator, the admin can't log in and remove the malware; you now need to power cycle what may be a production server.
You can get around this somewhat by attaching the log-in rate limit to the terminal. That means you need rules that decide context (network, local); then, for some contexts (local), account per terminal (tty1, tty2, pts/0, etc.).
Nobody's done that yet.
Support my political activism on Patreon.
different login attempts to the same account from different IPs continuously doesn't seem at all suspicious?
So this only works if you have /usr/bin/host installed?
I want to delete my account but Slashdot doesn't allow it.
I was going to release an RFC several years back that detailed malware communications protocols, but it was out-of-scope for an RFC and I figured it would be bad when people started using it. Plus IETF might not take that as an April 1 RFC.
I had suggested that the malware be modular, and that it have a communications protocol using PKI, and an evolutionary module loading framework. It would take code for modules shipped across the network and try to compile them locally for various systems, then ship the binaries around. It would also divide when it got a new module: a kill module would just kill the weak strain. The proposal included detecting remote OS and shipping the correct primary executable code, as well as support code for cross-infection.
The whole thing was a big argument for why we need a non-executable stack and strict rules preventing in-memory transitions between non-executable and executable pages. Data written in memory should never become code. Of course, people want to use JIT compilers, so...
Modern malware still bores me.
Support my political activism on Patreon.
If you never travel outside your country, why not block all networks from outside? Back in my AT&T days I blocked all of south america, europe, and asia for our servers because nobody from those locations had any reason to even contact our advertising data collection systems. There is no reason to keep your servers wide open for the world.
Do not look at laser with remaining good eye.
Psuto-Code:
Select @LastTried = Max(LastTried) from LoginLog where LoginName = @LoginName
insert into LoginLog (now, @LoginName)
if @LastTried (now - 30 seconds) {
return error
} else {
return checkifpasswordiscorrect(@LoginName, @LoginPass)
}
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Most of what we see in the wild is caused by improperly written PHP scripts which don't validate their input and then use crud like fopen_url. That provides the crackers the METHOD to put files on the server and execute them. SuExec gives web visitors PERMISSION to ad and modify files.
Unfortunately, the folks at Plesk didn't read the first paragraph of the SuExec documentation before deploying it by default, so hundreds of thousands of DIY web servers are running with SuExec. (SuExec means allow visitors to modify files, but don't allow other clients hosted on the same shared server to do so).
What the Plesk and DirectAdmin folks should have read, from the Apache SuExec page:
-----
Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run
private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and
possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the
security issues they present, we highly recommend that you not consider using suEXEC.
-----
That last sentence bears repeatings. "If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC." Plesk, and DirectAdmin - your customers are not familiar with managing setuid programs and the security issue, so they should not even CONSIDER running suexec, much less have that foisted on them as the default.
If that account is "root", it's pretty much normal these days on the internet...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
So lock the account?
Seems clever. DoS successfull.
Notabene: All through the 90s and some years later, you could lock customers of Deutsche Telekom out of their Internet access until midnight, if you knew their telephone number.
Internet login was derived from the phone number, accounts were locked after 10 failed passwords until midnight.
There's a very simple and very easy solution for it: One password attempt every 2 seconds. 2 seconds is pretty much what an average human needs to type his password (of course, he needs to be allowed to type while he waits). Of course that limitation begins with the first login attempt. There is exactly zero reason to allow three attempts within a split second and then disallow for a minute or so if your potential attacker is a script. Quite the opposite, two login attempts within a second should automatically lead to a ban, no matter whether one of the passwords was correct, because that pretty much PROVES that it's an automated script trying to log in.
Hence my login procedure still listens after you entered your credentials. If you try again before getting an answer (something NO human being, and no sensible script either, would do), you pretty much proved you're an attacker and you don't get in. From the same or a different IP address doesn't matter, because, again, NOBODY "honest" would come from two places at once. It may lead to a DoS, of course, when someone tries to hack account A from various sources while the genuine user of account A tries to log in, but the game "confidentiality vs availability" can be played ad infinitum.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
"A lack of anti virus, and missing auto update features leave machines vulnerable"
It astounds me the lengths the article writers go too while avoiding the attack vector:
The admin must:
1. allow a method to upload files
2. allow php files to be up loaded
3. Allow execution of these uploaded scripts
4. Allow system / exec calls (disabled by default since forever ago)
5. Allow the user to write their own crontab
At that point, you might as well just install the infection through yum or apt.
Seriously, there's a reason that the article numbers are less than 1% of the size of the average windows server infection..
You were lied to: there are no monkeys working on Linux security, only apes.
Turns out you're very easy to troll.
Stupidity, bigotry, and grammar violations all in a two-line post. I suppose that's par for the course. Kids these days.
Kythe
So, all I need to do to block off legitimate access is fire off a single connection (per user I want to block) every 30 seconds...
I could have a daemon doing that without noticably slowing down my regular internet traffic on my home DSL.
a properly managed windows box is good, a poorly managed windows box is crap a properly managed linux box is pretty much bomb proof, a poorly managed linux box is good.
I know:
But other that typing an IP in and seeing which one it says (which I could automate), but I would think that info is already somewhere...I just don't know where.
I refuse to sign
Apparently you (and I) were lied to. It's not a Linux problem, it's a problem with a PHP script. Not even with PHP itself, so your Linux machine appears to be safe even if you install PHP. Not that I would recommend installing PHP.
True, unless a complete idiot is using Linux, which can't happen because Linux is Idiot proof, unless a complete idiot is using Linux, which can't happen because Linux is Idiot proof, unless a complete idiot is using Linux, infinite loop...
Did you read the attack vector? The problem isn't the technology, it's idiot admins that allow random users to install and execute code which can affect anyone else.
File under 'M' for 'Manic ranting'
I use fail2ban and RSA keys as my primary login mechanism... but I also use the RFC 6238 TOTP tokens (Google Authenticator code available from git, or just fetch it from EPEL if on RedHat or a downstream distro like CentOS. For an app, one can use RedHat's FreeOTP, Google's app, Amazon's, or a slew of others.)
This isn't 100%, but two factor authentication should be the minimum standard for Internet communication these days.
After that, what may or may not help is the push to run everything in containers (think domains in Solaris, or WPARs in AIX.) Docker seems to have a lot of enterprise support, and it is relatively new, and that would put another layer of security in place.
This isn't to say malware can misbehave in a container. In fact, malware running in the user context on Windows can do a lot of mayhem. However, containers provide better defense in depth, same with SELinux.
This virus doesn't attack Linux at all. It attacks PHP web applications. They could run on Linux or any other OS. The brute forcing is what the botnet does once it has a foothold on the machine in question, and has nothing to do with the attack vector.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
It might be that if one uses a VPN, and a limited number of IP addresses, maybe just block everything except for those ranges, and the VPN (preferably a less known, but reliable provider, maybe even a static IP on a linode box) would allow one access if one wasn't on that range.
Of course, the attacks I see coming are often compromised Windows boxes on DSL or cable modem IP ranges, so blocking Elbonia directly may not help much. The best bang for buck is maybe blocking the obvious hotspots, then rate limiting dynamic IP pools.
I've wondered, at an extreme, having a custom sshd that had a list of IPs in place, and if someone connected from a blacklisted IP, it would randomly just deny them, or perhaps give them a fake shell before closing the connection. Of course, tarpitting can't hurt either, but a botnet only connecting 2-3 times from an IP at a time, that won't help much.
Another idea would be to combine it with port knocking so that the sshd would give bogus reponses to anything that connects unless it previously knocked on another port. Of course, this would be in combination with blacklists.
Surely you must be joking. There have been Explorer bugs that went unpatched for six months. No operating system is immune and security flaws arising from bugs in code are an inevitable accompaniment to having code in the first place, especially complex code with lots of moving parts (some of them infrequently tested/visited), but Microsoft has historically been Macrosquishy when it comes to security and patches. LOTS of holes, and many of them (in the historical past) have taken a truly absurd amount of time to be patched, resulting in truly monumental penetration of trojans and viruses via superrating wounds like Outlook. I still get an average of one email message a day that makes it through my filters purporting to be from a correctly named friend or a relative and encouraging me to click on a misspelled link. You think those messages are arising from successful data-scraping via Linux malware or Apple malware or FreeBSD malware?
Perhaps, driven by the need to actually compete with Apple and Linux (including Android) instead of resting on their monopolistic laurels, they have cleaned up their act somewhat over the last few releases of Windows, but on average over the last 10 or 15 years, certainly since the widespread adoption of apt and yum to auto-maintain Linux, the mean lifetime of a security hole in a Linux based system all the way out to user desktops has been around 24 hours -- a few hours to patch it and push it to the master distro servers, mirror it, and pull it with the next update. Microsoft hasn't even been able to acknowledge that a bug exists on that kind of time frame, let alone find the problem in the code, fix it, test it, and push it.
If they are doing better now, good for them! However, look at the relative penetration of malware even today. Linux malware has a very hard time getting any sort of traction. Apple malware has a very hard time getting any sort of traction. Windows? It's all too easy to whine that it gets penetrated all the time because it is so popular and ubiquitous, except that nowadays it is neither.
rgb
Even when the experts all agree, they may well be mistaken. --- Bertrand Russell.
I think nowadays that one can assume that 1400 random infections (for the botnet in question) on the net would include most countries. Even more so for the larger botnets which exist. So my suspicion is that this tactic has limited utility, possibly so limited that it is no longer worthwhile ("Damn, I forgot to turn off the geoblocking before my unexpected trip to Peru!").
You have limited imagination, what about an attack on a public computer via replacing its keyboard with one which includes a CPU + password cracking program?
So Windows isn't quite as retarded as you think; it's just retarded in that it doesn't rate-limit the two kinds of logins separately (i.e., still very retarded).
its PHP that's the problem not linux so i guess it could also affect other systems such as Windows
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Exactly. Disabling password authentication seems to mitigate this attack entirely. If you still use a password to connect to your server, you are basically asking to be owned.
"Mayhem appears to be the continuation of the Fort Disco brute-force password cracking attack"
So, it doesn't exploit any security vulnerabilities? Awesome. The UNIX family continues its extremely good record for security. It isn't perfect but it's pretty close.
We used to also block all of AOL's ip pools as well as many of the large UNI address pools.
Do not look at laser with remaining good eye.
No need to block entire countries - just allow SSH access to those systems that need it.
Now, if you want to talk about blocking access to your web or mail server from anyone in East Elbonia, then you can implement a package like Country Block, or use a service like this one, depending on your firewall.
The lesson from this? Restrict access to important services via a whitelist, block access to public services with a deny list.
How come Slashdot never gets Slashdotted?
Or, to put it another way, you can't fix stupid.
You shouldn't even try.
Fixing stupid requires thinking like an stupid. And that is what has left the nice discipline of design in its sorrow actual state.
Start your security process by not using port 22 for ssh, and instead using some random, legal 5-digit port number. Then block IPs from anyone doing a port scan. Also, setup port-knocking prior to any authorized user even starting to login using ssh. Of course certificates should only be used, not passwords for authorization. That should go a long way to keep the bad guys out.
Also bots tend to have the same user-agent strings, which tend to be obscure in and amongst themselves. These obscure, identifying user-agents can also be blocked, once identified.
To read and actually make sense of machine logs, the free ELK Stack rocks! Here's a guide to setup your own machine, for the purpose of reading logs in a very user-friendly way.
You can't be ahead of the curve, if you're stuck in a loop.
Don't forget to add a SSH private key. Also, I was getting *lots* of failed ssh login attempts on my OpenWrt box. Changing the port to a different number helped.
You're absolutely correct. MS literally has billions in revenue and *chooses* to not secure their OS. They could allocate sufficient resources and make the very best commercially available OS, but instead, they make a crappy toy.
Apparently commies and hippies can make an OS that challenges MS's best efforts. The terrible truth is terrible but true.
IS NEVER CAN BE HAKED! SUPER SECUR1!! NEVER CAN ANY ONE DO THIS.
iwwont use many caps i swear...please dont hate me slashdot submitter button
The higher you put the ssh port, the better. I myself like 65535.
Nobody should ever be logging in as root remotely. That's what sudo is for.
a properly managed windows box is good, a poorly managed windows box is crap
a properly managed linux box is pretty much bomb proof, a poorly managed linux box is good.
Poorly punctuated posts are also crap.
Thanks for explaining that this is a difficult topic.
'Always listen to experts. They'll tell you what can't be done, and why. Then do it.'
And then every 2 seconds, the malware beats you to your password log-in attempt. You have a 2000mS period with a 5mS window, good job. I can keep all your staff sitting in their chairs not working all day with ssh and rdp.
Support my political activism on Patreon.
Who cares. Stop using passwords and start using rsa keys and they can try and guess your 'password' all they want.
That's called a movie plot security threat, and it's not a concern.
Aside from all the obvious shit like "how do you get in there unnoticed?" and "How does it know to start entering passwords?", you have the speed of the bus. Even without a 1-2 second turn-around for testing a password, keyboards can only enter 750 characters per second. That's less than 100 password attempts per second for 8 character passwords, or 10^12 seconds to try them all. 800,000 years!
In other words: console attack via keyboard is no threat. I proscribed accounting per-tty direct console attempts separately because of shell scripts (on the console), which might lock you out of sudo in x11, so you open a new xterm and get pts/17 and sudo there. Of course that creates other oddness (users can create terminals, i.e. screen, xterm), which needs addressing.
Support my political activism on Patreon.
This is essentially the one problem with the implementation, it facilitates a DoS attack.
As stated in the last paragraph, the choice is confidentiality or availability, depending on which trumps which, pick your poison.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I agree. Fully. Absolutely. Sadly, that little secret very obviously didn't get out yet to everyone. There's still plenty of machines, and I don't just mean some "hey, look at me, I am such a geek, I can install Linux" idiot's machine, that actually allow root logins.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
It's never that simple. There's all kinds of stupid dogma in every industry; things like "confidentiality or availability" and "security or ease of use" are industry dogma.
Support my political activism on Patreon.
That is why I did the insert after it got the date/time of last login. So if you get a slew of login attempts in the time frame it just kicks them off.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Well, I cut down from ~50 SSH login attempts per minute some days to basically ... looks up the logs ... four such attempts last month.
What I found: No matter how secure your lock is, when you have one, big, red, secure, lock on your stuff, which people know is active, people will try to pick it. On the other hand, when there is not one, big red, secure lock, but thousands of identical looking little, grey, secure locks, and the attacker would first have to try every one of them to see which is even active, then 99.999% of the script kiddies don't bother long enough to even find the lock.
So I moved my SSH stuff to another port. Doesn't help against any "real" attacker, and doesn't really add any security, but it DOES cut down on the noise in the logs.
> That's called a movie plot security threat, and it's not a concern.
Do you always start out your arguments by "poisoning the well"? BTW, the person who coined "movie plot security threat" doesn't exactly agree with you.
> Aside from all the obvious shit like "how do you get in there unnoticed?"
Did you miss the "on a public computer" part of my post? Never heard of social engineering?
> Even without a 1-2 second turn-around for testing a password, keyboards can only enter 750 characters per second.
Where did this "750 characters per second" come from? Is this a limit built into Windows? USB 2.0 runs at 35 MB/s, according to Wikipedia.
OTOH, comparing the "1-2 second turn-around" in your reply to the "750 characters per second" undercuts your original argument as a whole --- if the password check itself is the limiting factor, even for the "slow" keyboard, it make no sense to make a distinction between password attempts from the keyboard and those from the network, so it would be silly to call Windows "retarded" for doing so.
> That's less than 100 password attempts per second for 8 character passwords,
> or 10^12 seconds to try them all. 800,000 years!
Your naivety about the average entropy in a typical 8 character password is striking.
It's very, very tricky (impossible?) to set that up right with the newer suckurity checks in recent version of SuExec, especially now that SELinux has removed *_disable_trans. Previously you could do it with httpd_suexec_disable_trans. Now mostly people resort to running Apache as a permissive context - effectively castrating the mandatory access controls in order to run soemthing that castrates the discretionary access controls (standard permissions).
Also, before the new checks were added, SuExec could be used in a smart way, though few people did. Suppose you have a user named "joe". You could create a script user named "joes_scripts". In that way, Joe's scripts would run as their own user. The new checks won't allow the joes_scripts user to run within a the home directory of "joe", so there goes the proper use of suexec.
On a dedicated server, the you CAN create a user that safely isolates scripts, so scripts run as a separate user from everything else. That user is called "httpd" or "nobody", and that's the default you get by NOT using suexec.
BTW, the person who coined "movie plot security threat" doesn't exactly agree with you [schneier.com].
That's for keyloggers, not key entry. Typing is different than reading.
Where did this "750 characters per second" come from? Is this a limit built into Windows? USB 2.0 runs at 35 MB/s, according to Wikipedia.
There's this link that references USB-HID specifically at 750 characters per second. I can't find other references to USB HID rates, and the HID protocol is semi-flexible (i.e. it's really fucking hard to implement NKRO on HID, since HID keyboard protocol specifies 6KRO in boot mode; but you're free to implement an alternate HID protocol once your keyboard's out of boot mode).
OTOH, comparing the "1-2 second turn-around" in your reply to the "750 characters per second" undercuts your original argument as a whole
1-2 second delay is an expected human-facing turn-around: this actually happens on most modern systems. I pointed it out and then theorized eliminating that rate limit entirely, instead relying on the limits of the HID keyboard protocol at 750 characters per second, which is the faster measurement and thus can be taken as a worst case.
Your naivety about the average entropy in a typical 8 character password is striking.
We're talking about theoretical password complexity here, not dictionary attacks. If you only have 5000 or so passwords to try, a rate limit of 5 seconds to enter each will give you a maximum time of less than half a day. That's a rate of 12 per minute. Even at 3 per minute, it takes barely over a day; weak passwords are quite weak.
I also consider the full entropy of an 8 character password as a weak measurement. My typical recommendation is all lower case, with the space or underscore, and minimum 16 characters. This is to enforce a 4 dictionary word standard (passwords like "red_ant_room_lake" illustrate why so short), although you could say 20 characters and all full dictionary words, minimum 4 (which means 5 words sometimes!). The entropy is much higher even with small vocabularies.
In other words: I used conservative numbers. Real world numbers FOR A HARDWARE PASSWORD BRUTE FORCE DEVICE will involve longer time frames (log-in subsystem delays), higher-entropy passwords, and so on. I also made a final comment about console scripts and the complexity they add--because they're vastly faster than hardware HID brute force devices.
Because hardware brute force devices are not useful--not faster than a human in any reasonable case and, even then, not fast enough to actually crack anything--your proposed attack is a movie plot.
Support my political activism on Patreon.
For Europe at least, you can get RIPE IP blocks from their web site or through their RIPEstat Text Service. I use it for one of my servers to get daily lists for one country, and feed it to ipset. Maybe others like ARIN etc. also publish lists? Or you can get GeoIP databases. Or you could try a (Perl) module like IP::Country?
What about just not allowing passwords to connect from a network? Is it too simple, or what?
It's simply stupid to prohibit robots from connecting. It means you'll never be able to automate your work. It's also not viable to lock the system, as it'll turn any bot anywhere into a severe DoS attak. And trying to discern intent from behaviour is way too hard a task for a computer.
Rethinking email
There's this link that references USB-HID specifically at 750 characters per second. I can't find other references to USB HID rates, and the HID protocol is semi-flexible (i.e. it's really fucking hard to implement NKRO on HID, since HID keyboard protocol specifies 6KRO in boot mode; but you're free to implement an alternate HID protocol once your keyboard's out of boot mode).
Thanks for the hint to look at the USB-HIB standard (1.1) in which even high-speed devices are limited to 64KB/s. That's interesting info. Does the USB hardware + operating system on most computers actually enforce that?
OTOH, comparing the "1-2 second turn-around" in your reply to the "750 characters per second" undercuts your original argument as a whole
1-2 second delay is an expected human-facing turn-around: this actually happens on most modern systems. I pointed it out and then theorized eliminating that rate limit entirely, instead relying on the limits of the HID keyboard protocol at 750 characters per second, which is the faster measurement and thus can be taken as a worst case.
You don't actually seem to be addressing my argument here, perhaps you misunderstood? It's clear to me what you did, my argument was that doing what you did made no sense given the "1-2 second delay" you state, and given that datum, your characterizing Windows as "retarded" for not distinguishing between 750 char/s and the much faster network, was illogical.
Your naivety about the average entropy in a typical 8 character password is striking.
We're talking about theoretical password complexity here, not dictionary attacks.
Yes, I am capable of reverse engineering your math. You err, though. "We're talking about..."? No, you're talking about...
I'm not quite getting this. You dismiss the possibility that weak passwords are used, so that hardware password attacks are dismissable, but at the same time address the problem that these same non-weak passwords aren't strong enough to withstand network password attacks without lock-outs? Yes, I suppose there is some real-life situations in which that's true, but why would you rag on Microsoft for trying (in what I agree is not a reasonable way) to cover other possible situations (and, given their user base, much more probable ones)?
Everybody picks on PHP. Like every language it's not perfect, by far. But by several orders of magnitude (my estimate), the vast majority of all vulnerabilities regardless of operating system have directly resulted from design flaws in C (and C++) - buffer overflows, pointer issues, assignment instead of evaluation in conditionals due to missing equals, etc. Even many/most of the vulnerabilities in PHP have been the result of these same C design flaws. While _some_ of those flaws can be argued to be necessary for writing at the bare metal level - device drivers and such, they are completely unnecessary for application programming.
The standard counter argument is that "C programmers (must) learn better programming habits, and deal with those things." To which I merely append, "Some ..." and note that many of these bugs have demonstrably been put there by highly skilled, experienced developers who know better, but just forgot "this one particular time."
It's enough to make one yearn for Haskell, or Erlang, or something. :D
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
I have long since given up the use of passwd's for DSA keys in ssh.
I had always considered Bob Beck's post the definitive guide concerning ssh'ing as root, but it seems a number of users feel otherwise.
http://archives.neohapsis.com/...
Oooh... 1400 linux servers infected? Um, out of how many on the internet?!?
Thanks. I'll give it a try.
Limit access to SSH to systems on the whitelist.
How would one go about whitelisting a restaurant if an admin gets an urgent call and needs to log in ASAP?
You appear to be making the assumption that your pet language is being unfairly picked on. Seriously, grow up.
We had lots of trouble with WordPress bot-logins from Russia and Ukraine, so I decided to block those ip-ranges.
Turns out one such block was also partly being used by customers in my own country. I received some vague mails about some things not working correctly. So I removed that ip-block, and sent back some vague replies that it was a firewall that was too strict.
There might be other blocks listed as from Russia and Ukraine, that are actually being used elsewhere.
Anyway, with the advent of ipv6, the whole idea of ip-blocks might change.
Well, don't worry about that. We can get you back before you leave. (Dr. Who)
Isn't this normally a bad idea as a non-root account can listen on those non-reserved ports should yourprimary daemon die or get restarted?
Yes, you are right and I stand corrected. In fact late yesterday, I happened upon a blog post teaching me the same explanation you gave me just now:
Thank you for your important clarification regarding my security practices.
You can't be ahead of the curve, if you're stuck in a loop.
Here's the link to the blog post, that didn't make it into my previous reply: https://www.adayinthelifeof.nl.... It clarifies several reasons for using the standard port 22 for ssh.
You can't be ahead of the curve, if you're stuck in a loop.
People still use php after all the security problems?
I'm shocked!
It is like saying that people still use Java and anything from adobe. Crazy people out there.
your characterizing Windows as "retarded" for not distinguishing between 750 char/s and the much faster network, was illogical.
There are two parts to that.
The first part is that the network log-in source can be grouped as an infinite number of terminals--lots of connections--so a per-connection rate limit is useless; thus all network service log-in (caveat: Active Directory handles console log-ins... over network) must be grouped as one thing to be effective. Console log-ins are separate so that a network attack can't function as a DOS; as well, the risk is mitigated because you can't enter passwords fast enough for any use.
The second part is that a console brute-force is slow. Your concern about what amounts to typing really, really fast (i.e. programmed HID plugged into USB) isn't a real concern because of password complexity. It's not that passwords are necessarily that complex; it's that a password which isn't complex enough can be readily brute forced under strong password policies like "3 passwords per minute", it just takes a week or two.
You dismiss the possibility that weak passwords are used, so that hardware password attacks are dismissable, but at the same time address the problem that these same non-weak passwords aren't strong enough to withstand network password attacks without lock-outs?
No, I dismiss the possibility that short lock-out intervals help with weak passwords.
You can attack 129,600 passwords per 30 days if you have a 3 failure per minute policy. Basic English 1250 extends out to about 5000 words with conjugations and domain language (medical, legal, whatever) for most people. Weak passwords in the traditional complexity scheme are like "rainman" becomes "Rainman1", so 100,000 attempts has a fair chance of getting it eventually. That's within the realm of a hardware keyboard typist. Common policy is 60 or 90 day retention, which increases the risk into strong viability; while public kiosks are too visible for a multi-hour console log-in attack, which makes these attacks less viable even at high rates.
Complex passwords reach 10^14 theoretically, and four-word passwords reach 10^16. Reasonable rate limits of 20 attempts per minute carry this out to hundreds of thousands of years. A human can type barely that fast. Remember the original argument:
Windows does stupid shit like lock the local console if you set up rate-limit log-in...when logging in through the Microsoft log-in manager.
If the attacker tries to log in over RDP or telnet or such, and locks the account, the actual console log-in box no longer works. That's dumb, because no attacker can possibly brute force the password through that, unless the password is laughably weak--in which case, as stated above, the rate limiting doesn't actually help.
tl;dr: I can lock you out of your server by constantly trying to log into your server, so you can't apply patches anymore. Then I hack it on Tuesday.
Support my political activism on Patreon.
Nobody should ever be logging in as root remotely. That's what sudo is for.
Servers are infected through the execution of a hypertext preprocessor (PHP) script that establishes Mayhem on the victim computer and sets up a communications channel with a command and control server.
...it doesn't need root to operate.
RTFA, AC dumbass troll.
Data written in memory should never become code: So you want to kill all interpreted langauges?
Pseudo.
Not to be confused with sudo
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
OK, I agree that your argument here is OK, if the 1-2 second delay is an artificial one generated by the OS (and the OS doesn't sufficiently limit the number of active connections). If the 1-2 second delay comes from actual computational overhead of the authentication process (e.g., PBKDF2), then your argument still fails.
Well, if I understand correctly, the lock-out is on a per-account basis, so you'd have to know the usernames of all my admin accounts, so this seems to me to not be very likely to succeed if I have heard about the attack ahead of time (thanks to your post)...
We're getting spam here because someone, somehow, got our Active Directory mailing list out of Outlook Web Access. I know all of your admin accounts.
Support my political activism on Patreon.
Well, well, sounds like both of us are in big trouble because of Microsoft, and not even because of the problem you originally complained about. :-)
Anyway, thanks for the interesting discussion. As someone whose job doesn't include having to worry about Microsoft's idiocies... I wish you the best of luck!
You see my point, though. Knowing your administrator log-ins isn't a never-happens situation. People get user lists all the time.
Support my political activism on Patreon.