[Holiday is mostly over... Most of the family has departed to their homes or other homes. Grandpa lays back to a late nap - errr - E-Mail...]
Ok all, Serge and Stéphane know my background as a security researcher and expert. This has been something that has been bothering me for some time and I think it's time for some serious discussion. The current container templates create templates with horrible bad passwords. Fedora, CentOS, and others create the "root" account with the password "root". Ubuntu creates the user "ubuntu" with the password "ubuntu" with su / sudo authority to superuser. There are other static conventions. All are bad bad BAD! I recently had opportunity to spin up a couple of CentOS PoC (Proof of Concept) containers for another project I'm working on. Now, remember, I'm a security person and, as such, I have a number of honeypots and security detection mechanisms in place. My "interesting days" usually being with "what just happened" or "what the hell was that" or "it never did that before". So it came to pass... One of those containers tripped some alarms and I examined it to find that I had neglected to change that password (I was working on the other container) and it had gotten whacked within one day (my containers are bridged onto my IPv4 /16 network space). Ok... Day just got more interesting now. Flipped off my "LXC hat" and flipped on my "security hat". Let's see what we've got. We've got some processes running and burning time like "/etc/atdd", "/etc/lsapd", "/etc/kysapd" and "/etc/cupsdd". Hmmm... Not good... Cool... Shut that container down and find some interesting goodies. Things that relate directly to this: https://isc.sans.edu/diary/Unfriendly+crontab+additions/17282 Very cool. Now, I've got the attacker toys and binaries to play with. I even caught them before ISC did. :-) Not so cool for non security people, though. What happened... Shortly after spinning those containers up, one of the frequent ssh scans came by and busted the root account. This was confirmed through /var/log/secure. Amateurs! They didn't even clean the logs behind them. RANK amateurs! Geeeze... Hacker quality control really has gone to shit these days. The attacks came from a site in China and the C&C (Command and Control) was also located in China. For me, this is nothing. This is actually a lot of what I use LXC for. Set up systems and let them get whacked and collect new toys for analysis. I just wasn't expecting it so soon in this particular one and was due to an oversight on my part in my haste. The malware seems to be of a DNS amplification attack family for DDoS I have yet to see any ssh brute force attack that does any further than lame password attacks. The attackers are LAZY. They don't need to do sophisticated attacks because the stupid attacks still work sooo well. attacks, which seems kinda crude, as they set themselves up on port 53/udp and started chattering with their C&C servers. Really kinda boring stuff. I have ssh honeypots running continuously and the scans and dain bramaged simple minded scans with lexicons of only a few hundred passwords for a few accounts like root, toor, user, plus a few strange ones I won't mention. Yes, ubuntu and liveuser are on the use hit list and, yes, ubuntu/ubuntu is toast. I have yet to see any ssh brute force attack that does any further than lame password attacks. The attackers are LAZY. They don't need to do sophisticated attacks because the stupid attacks still work sooo well. Bottom line is that we have to do SOMETHING better than the bone headed dain bramaged passwords the templates are currently setting. We're not even giving users instructions to immediately change those passwords (even though it should be obvious). What I propose to do is to change the Fedora and CentOS templates to conform to the following convention... Default root password as follows: Root-${Container_Name}-${RANDOM} Note: Contains one capital, multiple numbers, plus punctuation. Add a warning that the user should change it to a user selected password. Include instructions on how to change it from the host using chroot. If they fail to note it down, it can always be changed with a "chroot {rootfs} ; chpasswd" so there's little loss of control. Is it secure? Not really, but security is a process, not a state. Is it more secure than the current state? Most definitely. Is it more of a problem for administrators of the host system? Yes, but only trivially so. It's a PITA to enter but is readily changed from the container or the host and vastly more secure than the lame passwords we're using now. It's not "bad" and highly unlikely to be busted by simple brute force. Without the attackers having internal knowledge of the container name, their attack surface is pretty large. With that knowledge, the profile is still over a /16 surface (65536 guesses) from the ${RANDOM} variable. I intend to implement this in the templates I'm working on. I would love to hear comments and suggestions from everyone else. I would definitely want to see something better in 1.0. Doesn't have to be this, but someone needs to come up with something better. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | [email protected] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
_______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
