Web-Based Administrative Tools 11

Posted by JD 10/12/2011 at 23:00

It happened again to another website. Their password database was stolen. The entire DB. At least they were encrypting user passwords in some way. That will slow down the crackers, a little, but in the end, almost all those passwords will be known. My readers know that only the longest passwords will be safe, for now.

If you run a website, it can happen to you too. Can you Prevent this from happening? Probably.

Not Geniuses Here

I saw similar attacks against my websites, daily, constantly. Since I don’t use any web-administrative tools, they weren’t going to get in or be able to find a bug in the web interfaces to get administrative privileges. Still, they were filling up the log files and seemed to think that nobody noticed.
Try this link. What did you see? Simple. Effective.

The crackers aren’t usually too smart. They are using freely available tools that look for known, published attacks against specific versions of these web tools. You can use these same tools to protect yourself. Just google for backtrack to find the main tool. Download a copy and go crazy on your websites. If you don’t own the website, be certain to get written approval from the owners since without this you are breaking laws in most countries and probably the acceptable use clause from your ISP.

Stop Allowing Access to Administrative Tools

If you must have web-based administrative tools, lock access down to a few known-good IP addresses.
Personally, I don’t use the webadmin or phpmysql admin tools. I’ve found them to be more hassle than they are worth. Looking through my web server log files showed hundreds of attempts to access these administrative pages daily, that is until I blocked all requests of that type.

Nginx Filtering

Chances are if you are using these tools then you don’t know how to block restrict access. If you use a reverse proxy, and you should, controlling access is pretty easy.

Block “Bad” Requests

Inside the server stanza, 

server xyz {
....
   if ($request_uri ~* (phpMyAdmin) ) { return 403; }
   if ($request_uri ~* (setup.php) ) { return 403; }
   if ($request_uri ~* (login.php) ) { return 403; }
....
}

These are case-insensitive pattern matches. Think of the things you can do with this simple capability.

There may be times when you need to relax this. Since my sites don’t use php, it is easier for me to simply block these php-related requests. I could be more selective and only allow access from the internal LAN IP addresses.

Block IPs

If there are specific IPs that should be allowed to access certain pages and no others, then nginx covers that too. In the location stanza:

location /admin {
....
allow 192.168.0.0/24; # Internal LAN
deny all;
....
}

Parts of our websites are limited to 4 people. They know that access is only possible from their static IPs at home, not their mobile phone, not the local coffee shop, just home.

Don’t forget to restart nginx after making any changes. It is a good idea to validate your configuration files first.

$ sudo /etc/init.d/nginx configtest

nginx configurations can get really complex. Just be certain to have a backup way to get in and correct any mistakes. Key-based ssh connections with Fail2ban are probably the best way.

Firewall / IPTables Blocking

Of course, you can block and allow using iptables too. This is probably better than doing it in the nginx configuration files, more efficient. I have a few rules in /etc/rc.local like these:

/sbin/iptables -I INPUT -s  112.224.0.0/11     -j DROP

Today, I’m blocking over 60 subnets in this way. Mainly it was due to bandwidth abuse, but a few places were actively harvesting content and republishing it without permission.
IPtables can do all sorts of really cool things. More examples here.

Long Non-Trivial Passwords

Using a long, non-trivial password for any web-based administration is an easy way to protect yourself too. This may be the only solution for some people running servers at hosting providers. Use the longest possible password – 30+ characters. Use a password database tool to handle this.

Lock Down DBMS Access

This isn’t a perfect answer, but locking down access to the DBMS so that only those specific systems or just local access is allowed should be setup. MySQL Security Considerations.

Backups

Having a breach sucks. There is nothing that most companies can do to protect against breaches beyond the standard things; however, the thing we all should be doing daily, automatically, is backing up our servers and having the ability to restore from a backup 2-4 weeks prior. This provides insurance against the crackers having all your data and deleting it for good. It also means that if it takes a few days to realize you’ve been cracked, you’ll be able to get to a state before that penetration occurred. Backups are the first line of defense.

What Do You Do?

You guys are smart.

  • How do you protect your content from nasty access attempts?
  • Do you bother?
  • What happens when a bug is found in your software? Do you patch it immediately or wait?
We realize this is a losing battle. Under IPv6, IP-based will become impossible. Nginx filtering will be our front-line defense.
  1. fireshadow 10/13/2011 at 14:06

    Just a hint (off-topic for the article, but I don’t know any other way to reach you): In the rss-Feed of the blog the “direct link to this article”-Link links for all articles to blog.jdpfu.com/2008/05/29/hello-world.

  2. JD 10/13/2011 at 17:05

    Actually, the direct link to this article link in every article of the RSS feed does that. Interesting.

    There are a few issues too. I’ve been in contact with the primary developer today and was forced to hack the code this morning to get around a broken front-page and broken RSS feeds – seems they support (badly) password protected content.

    I’m already running the latest version of the blog software.

    I’ll look at the RSS layout to see if there’s an easy fix when I get time. Fortunately the main links at the top of each article in the RSS seem correct.

    Seems there’s a :TODO: tag in that area of the code.
  3. duijf 10/29/2011 at 18:01

    Just so you know, your Typo admin page is accessible for me.

    Hell I could even create an account and login. I could not do anything, though. Trying to go to the write a post page resulted in a redirect loop.

    You did send me my password via email, which is a method I’ve heard you criticize ;-)

    The funniest thing is that I just tried to visit the /admin page you wrote about.

    I will, of course, take no offense if you delete this comment and the account I created on your server, I just do not know any other way to reach you.

  4. JD 10/30/2011 at 02:22

    Laurens!!!!!!#!#!#!!

    Holy Frack! Thanks!

    The nginx blocks were still in there – it isn’t like I didn’t test this before publishing the article either. BTW, your IP was the only one in any of the logs besides mine to access the /admin areas.

    You didn’t have admin rights, just end user permissions. I’d thought about giving accounts to trusted friends, just never have. It isn’t like there’s any super secrets in here. ;)

    Yes, I dislike emailed passwords. There is much to dislike about this blog software. I’ve had to hack it just so articles can be viewed. Seems the maintainers added all sorts of password protection for each article and it doesn’t really work. All blog software has issues like this, so you can understand why I’m not really looking for readers to have accounts. There really isn’t anything you can’t do with comments that your account allowed – besides that I could track you easier. If you want to be a power commenter, just use textile to format your comments.

    So, here’s the point – I’m pretty crazy about security and I (somehow) made a mistake on a simple blog. Imagine what someone working inside a company with 100 other things to do today would have done.

    BTW, I did change something in the nginx config and retested it again to prove it is blocking as expected. If you see something again that isn’t permission denied, I failed somehow.

    For a different way to reach me – I bet you can guess an address that would work, but this is fine too.

    Thanks.

  5. duijf 10/30/2011 at 14:42

    You’re welcome, however Nginx still isn’t blocking as expected.

    You seem to have set up the /admin URI to redirect to /accounts/login.

    I get an 403 forbidden error when I try to access the /admin URI, but I can reach /accounts/login without any trouble.

    I suppose I could have tried to guess an address, but I figured that a comment like this is way too important to risk losing it because of an invalid email address.

    BTW, what would trusted friends be able to do with an account?

  6. JD 10/30/2011 at 15:56

    The /accounts/login page needs to be available – that’s how I login when I’m remote too. OTOH, the signup page link there shouldn’t work anymore, at least not externally. That was how you got in with a limited account.

    If you are interested in what a trusted friend could do, grab a copy of the blog software, typo. It seems there are 3 account types built-in.

    1. Contributor (basically a commenter with a few nicer interfaces for feedback management and emails for new content)
    2. Author (can write blog articles + comment)
    3. Administrator (controls all the software settings + Authoring)

    I don’t really expect anyone to bother with any of this stuff. There are about 5 people who I’d trust as authors, but the software has been too flaky to inflict those bugs onto anyone else. It is the blog software, not the infrastructure being flaky. I can’t imagine that anyone would really be interested either. Well, maybe this guy would. My trusted friends are too busy to bother blogging.

    I suppose anyone who comments regularly might earn a “commenter account” limited to a single static IP address. Nginx makes that easy. Oh, commenter accounts don’t have to wait to be posted either.

    There isn’t any money being made on this site and we aren’t traffic whores. 100K hits per month is more than enough.

    Contacting Me

    You can drop a note to me over at Identi.ca , but guessing an email address is probably the easiest way. Guessing any of the popular UNIX management email addresses for the domain will probably reach me. Those UNIX management email addresses seem to be immune from spammers, which is nice. There are a few spam-hole addresses in hidden links here. Those train the antispam software running. It is really amazing how many messages they get. Oddly, the “spam” email address itself doesn’t get spammed at all. Handy for website signups if I can’t be bothered to create a new domain-specific email alias.

    I use to have a Recaptcha link to reveal an email address. It was too much hassle, even for me.

    Or talk to me after any presentations that I give around the region. I’m active in the local LUGs and a few other programming meetup groups, maybe too active.

    Blog Spammers

    I do see about 5 spam comments here daily. Ironically, the most spammed article is the one about Blog Spammers.

  7. duijf 10/30/2011 at 16:40

    If you’re having so much issues that you are considering to use different blogging software, then you might be interested in using a static site generator, Jekyll, which is also the engine behind Github Pages.

    It is a Rubygem, which generates a static HTML file from source code. It uses the Liquid Templating System to create a layout, in which content is placed.

    Posts can be written in Textile, Markdown, HTML and also some other stuff.

    Deploying is easy, and can be done using Git, Subversion or something else, like scp. Jekyll will automatically regenerate your website after you push to a server. A VCS, Jekyll and a web-server is all that is needed to serve your website.

    Comments is where it gets more difficult. You could use Disqus or a similar service if you’re into that kind of thing.

    If you’re interested, you can check out the source of my personal website, which is still very much under construction, if you need an example. The Jekyll Wiki is of course also very helpful.

  8. JD 10/30/2011 at 17:38

    Thanks.

    I’ve been using Template::Toolkit for about 5 years for the static parts of my website and I tried a ruby static generator – webgen.

    The only reasons I haven’t switched are:

    • I like comments
    • I dislike centralization to someone else’s servers

    Basically, my comments are only stored here and aren’t automatically broadcast to the world as content for other for-profit websites. BTW, the comment RSS feed here is broken. I don’t have the heart to tell the typo maintainers about yet another bug.

    I’ve also thought about migrating to TikiWiki. That system has blogs, articles, wikis and is multiuser. They used automatic testing to ensure their code doesn’t break before releases.

    This blog started in 1998 as a place to store things that I’d learned. Actually, I started around 1995 just manually creating HTML pages in a directory on my home system. The fact that anyone else reads my blubbering was secondary for many, many years.

    I’ve thought about writing a Perl-Dancer blog that is compatible with the DB schema used for this engine. There are issues in doing that, since the perl textile module doesn’t work exactly the same as this ruby-based one. OTOH, I’d probably create most of the content in static files, not stored inside a DB and only have the comments in a DB at all. Things that aren’t transactional don’t need a DB, IMHO. File permissions are good enough already. The more I think about this, the dumber it sounds. Heck, this blog engine broke editing articles in textile. The first save goes in fine, but after that, it insists on using either an HTML or “visual” editor and completely trashes the markup language.

    Am I the only one who prefers Textile? I like it enough to have written a little tool that creates presentations for S5 using textile. It has some major issues still – due to bugs in the Perl textile module. Some day I need to fork that and provide some patches.

  9. JD 02/24/2012 at 13:20

    I don’t remember writing about this before, at least not directly, but I don’t use any web front-ends for databases or system administration or web administration unless I’m forced to do so. I consider these administrative tools to be major security risks.

    • Webmin
    • PhpMySQLAdmin
    • phpMyAdmin
    • Plex
    • cPanel
    • many, many others …

    All of these “tools” to make life easier are huge security risks.
    Plex was hacked. I gotta ask, why was the Plex webpage even available from the outside on all those sites?

    Any of them could have been hacked. This time, it was Plex. Nothing can replace a knowledgeable system administrator. Nothing. Being easier doesn’t mean being secure.

    Just because we block outside access, that doesn’t mean we shouldn’t have a good password and otherwise be careful.

  10. JD 08/07/2012 at 12:56

    Falco over at howtoforge has written a short article with examples nginx: How To Block Exploits, SQL Injections, File Injections, Spam, User Agents, Etc.

    I need to incorporate some of these into my rulesets.

    Definitely worth a look.

  11. JD 09/26/2012 at 17:07

    So all those lazy people who don’t learn how to manage their Linux LAMP system are burned. phpMyAdmin has a backdoor

    There isn’t any shortcut.