Archive for July, 2010

Mass Virtual Hosting Part Eight: MySQL-Proxy for Easy Network Topology Changes and Localhost vs. Sockets

Once your hosting clients are all settled in you may find one day that you need to change their MySQL server address or other configuration parameters. Naturally it’s not going to look good on you or be a very good use of your time to contact every webmaster and have them update their settings. Worse, juggling two active database servers would be a nightmare. Fortunately Oracle came up with mysql-proxy, a lightweight app that sits between your clients and MySQL server(s) which acts as a drop-in replacement for mysqld. Users connect to the proxy like they would the actual server and it transports data to and fro. You can do all sorts of neat things to the data while it’s in motion with lua scripts but that goes beyond the focus of this article.

By default mysql-proxy listens on port tcp/4040 and mysqld listens on tcp/3306. In my experience most users who come from other ISPs are already wired to use localhost as their default SQL host and I don’t want to make them have to remember the port number, which is typically defaulted in most webapps. If you’re running mysqld on the same host you’re serving web from you’ll need to change the port it listens on in /etc/mysql/my.cnf.

MySQL has a contentious age-old convention of changing “localhost” to “use the local socket” rather than resolving localhost to 127.0.0.1 and connecting via TCP. That’s because at the time the decision was made local sockets were far more efficient than using TCP, now it’s not so much an issue. We need to configure mysql-proxy to listen to a socket too or our users will have to use the numeric address, lest they encounter this error:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

This can be specified – not all too intuitively – by replacing the proxy-address value in /etc/mysql/mysql-proxy.cnf with the default path to the local socket, thus:

proxy-address = /var/run/mysqld/mysqld.sock

Configure the proxy-backend-address variable to reflect the actual server’s location and port number. Restart mysql-proxy and you now have a working, default-looking configuration that can be redirected anywhere. Thanks to the lua capability of the proxy you can even implement fast and easy load balancing and failover, but that will be the topic of another article!

Thwarting the isc.org DNS DDoS

Yesterday I posted an article regarding the importance of ACLs in BIND because a client’s DNS server was under extreme load and, at the time, I believed it was because a network of web form spammers was outsourcing their lookups to the target. Upon further investigation it turned out that this was not the case – the hosts were indeed a part of some sort of spamming ring/botnet but they were actually performing endless repeated ANY lookups on isc.org – the producers of BIND, among other things.

The whole attack doesn’t make any sense; if they wanted to involve this server in the attack against isc they would be wasting reams of bandwidth that could otherwise have been applied directly, unless they knew both recursive lookups were allowed and caching was disabled. Even with no recursive ACL at the time the only server suffering was my client’s thanks to caching and there is no conceivable reason, in my mind, that a spam network would be targeting this specific dns server among many in its address space – from one source address at a time. Fortunately adding a recursive ACL reduced the bandwidth impact but it did not stop the scans, and bandwidth is a pricey commodity after all.

I whipped out wireshark and took a sample capture, these are the contents of a typical request packet:

0000  00 16 3e bb 00 02 00 16  3e cc 00 02 08 00 45 00   ..>..... >.....E.
0010  00 40 8b 0d 00 00 e9 11  d7 93 d1 0b f2 7b 00 00   .@...... .....{..
0020  00 00 63 01 00 35 00 2c  00 00 2a 39 01 00 00 01   ..c..5., ..*9....
0030  00 00 00 00 00 01 03 69  73 63 03 6f 72 67 00 00   .......i sc.org..
0040  ff 00 01 00 00 29 10 00  00 00 80 00 00 00         .....).. ......

Next it was just a matter of crafting a suitable snort rule for the upstream gateway:

alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS isc.org DDoS"; content:"|03 69 73 63 03 6f 72 67 00|"; reference:foxpa.ws,369; classtype:attempted-dos; sid:4000002; rev:1; fwsam: src, 1 day;)

Now I’m kicking back, watching the spammer network expose itself as its constituent hosts smack against the firewall like bugs against a windshield.

If only I had some beer.

See how this story progressed:

Portage Errors: app-arch/lzma-utils is blocking app-arch/xz-utils

Gentoo recently made the switch from lzma-utils to xz-utils, to quote the project page at http://tukaani.org/lzma/:

LZMA Utils are legacy data compression software with high compression ratio. LZMA Utils are no longer developed, although critical bugs may be fixed as long as fixing them doesn’t require huge changes to the code.

Users of LZMA Utils should move to XZ Utils. XZ Utils support the legacy .lzma format used by LZMA Utils, and can also emulate the command line tools of LZMA Utils. This should make transition from LZMA Utils to XZ Utils relatively easy.

As you are probably aware, Portage has largely used lzma for the past year – before which bzip2 was the compression standard of choice. If alarm bells went off in your head when you saw this message:

[blocks B     ] app-arch/lzma-utils ("app-arch/lzma-utils" is blocking app-arch/xz-utils-4.999.9_beta)

You can rest easy uninstalling lzma, the xz-utils package comes in a good ol’ fashioned tarball and it works as a drop-in replacement for it so it’s safe to unmerge lzma-utils completely then – before emerging anything else – emerge xz-utils:

# emerge --unmerge lzma-utils; emerge xz-utils

 app-arch/lzma-utils
 selected: 4.32.7
 protected: none   
 omitted: none   

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

>>> Waiting 5 seconds before starting...
>>> (Control-C to abort)...
>>> Unmerging in: 5 4 3 2 1
>>> Unmerging app-arch/lzma-utils-4.32.7...

 * GNU info directory index is up-to-date.
Calculating dependencies... done!

# emerge xz-utils
Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) app-arch/xz-utils-4.999.9_beta
>>> Downloading 'http://gentoo.osuosl.org/distfiles/xz-4.999.9beta.tar.gz'

I’ll take this opportunity to point out that in this day and age the word beta has become such a gimmick that Gentoo is including so-called beta software as part of its core system. Back in my day beta meant beta and you had to walk 17 miles uphill both ways to get to the nearest phone jack. Mind you we didn’t call them modems in those days, we called em clinkerdinkers….

Way to go, Internet.

Return top
foxpa.ws
Online Marketing Toplist
Internet
Technology Blogs - Blog Rankings

Internet Blogs - BlogCatalog Blog Directory

Bad Karma Networks

Please Donate!


Made in Canada  •  There's a fox in the Gibson!  •  2010-12