On Wed, 25 Dec 2013 18:54:57 -0500 "Michael H. Warfield" <[email protected]> wrote:
> [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 agree that using known, weak default passwords is asking for trouble and I think your suggestions are a big improvement. Some of the usability problems could be overcome if we would standardize that all templates support ssh authorized_keys injection (ala what the ubuntu template already can do) but maybe we should look at what cloud-init does as well for comparison. > 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 _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
