Hacker's ramblings

Getting Parallels Plesk Panel to do something without admin's interaction is not tricky. My favorite method of remote-controlling Plesk is via its RPC API. I am a co-author of Perl-implementation API::Plesk, which is available in CPAN.

All XML RPC -requests should be directed towards your Plesk-server at URL
https://-your-plesk-box-here-:8443/enterprise/control/agent.php

Raw XML

First we'll need to get the internal site ID of a domain. A request to get all the subscriptions looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<packet version="1.6.3.5">
    <webspace>
        <get>
            <filter/>
            <dataset>
                <gen_info/>
            </dataset>
        </get>
    </webspace>
</packet>

Note: It would have been possible to filter a specific subscription by domain name, but in this case we just wanted a list of all.

A response to it will contain domain names and their Ids:

<?xml version="1.0" encoding="UTF-8"?>
<packet version="1.6.3.5">
    <webspace>
        <get>
            <result>
                <status>ok</status>
                <filter-id>1</filter-id>
                <id>1</id>
                <data>
                    <gen_info>
                        <name>www.testdomain.org</name>
                    </gen_info>
                </data>
            </result>
        </get>
    </webspace>
</packet>

The response packet contains internal ID and name. We'll be using the internal ID of 1 to get all the DNS-records of the zone:

<?xml version="1.0" encoding="UTF-8"?>
<packet version="1.6.3.5">
    <dns>
        <get_rec>
            <filter>
                <site-id>1</site-id>
            </filter>
        </get_rec>
    </dns>
</packet>

A response packet will look like this:

<?xml version="1.0" encoding="UTF-8"?>
<packet version="1.6.3.5">
    <dns>
        <get_rec>
            <result>
                <status>ok</status>
                <id>111</id>
                <data>
                    <site-id>1</site-id>
                    <type>CNAME</type>
                    <host>www.testdomain.org.</host>
                    <value>testdomain.org.</value>
                    <opt/>
                </data>
            </result>
        </get_rec>
    </dns>
</packet>

There seems not to be any other way of picking a specific record. A filter with type/name would be welcome. Any further operations would be done with the domain record's ID. In this case it is 111.

Perl-code

With a software library, the access is much easier. The same requests would be something like this in Perl:

my $plesk_client = API::Plesk->new('api_version' => '1.6.3.5',
  'secret_key' => $plesk_api_key,
  'url'=>'https://-your-plesk-box-here-:8443/enterprise/control/agent.php',
  'debug'        => 0);

$res = $plesk_client->webspace->get();
die "Subscriptions->get() failed!\n" . $res->error . "\n" if (!$res->is_success);

my @domains = @{$res->results()};
my $cnt = $#domains + 1;
for (my $idx = 0; $idx < $cnt; ++$idx) {
    my $domainId = $domains[$idx]{"id"};
    $domainId += 0;    # toInt

    my $res = $plesk_client->dns->get('site-id' => $domainId);
    die "DNS->get() failed!\n" . $res->error . "\n" if (!$res->is_success);
    my %dns = %{@{$res->results()}[0]};
    print Dump::Dumper(%dns);
}

That is pretty much it.

Update (2nd Nov 2013)

To get all of the domains will require a two-step process (order does not matter): 1) get all the subscriptions (kind of main domains) and 2) get the other domains under subscriptions.

In my Perl-code I do it like this:

# NOTE: This is from the above code
# 1st round:
# Get all the subscriptions.
# There we have the "main" domains
$res = $plesk_client->webspace->get();
die "Subscriptions->get() failed!\n" . $res->error . "\n" if (!$res->is_success);

# NOTE: New one:
# 2nd round:
# Get all the sites.
# There we have the "non-main" domains
$res = $plesk_client->site->get();
die "Sites->get() failed!\n" . $res->error . "\n" if (!$res->is_success);
@domains = @{$res->results()};

In my case, the $res-hash is fed into a ExtractDomains()-function to get the details I need from them. If only the name is required, then no further processing is necessary.

Well... the short version is: there is nothing new in it. In medium version the new Internet Explorer 11 is an improvement from IE 10, but is still letting me down.

The install-process didn't go without hiccups. Naturally I didn't read any documents and my install halted on serial number requirement. In the Windows 8.1 preview: FAQ Microsoft provides the correct serial, though.

About the IE 11: It seems bit more robust than IE 10 which failed on trivial things if using IE 7 emulation. On IE 11 the developers tools are completely re-written. That's good news to me, who am a web developer. The problem seems to be, that they completely dropped emulation for previous versions. It is pretty much the way to go but ... why did they have to introduce such functionality in the first place?

I get it, browser race is on. It was on hold for 10 years, but in 2008 when Google entered the race with its Chrome, all the other players sure started putting some effort into their product. Which is a good thing. Microsoft's latest response is IE 11 and they simply have to drop the legacy and start shifting gears to catch up with the others. The real problem is that according to my logs, pretty much every IE-version is still in use. With IE 7-10 it was possible to state in HTML, that this site uses IE 7 rendering rules, or alternatively select a rendering mode manually. Now I cannot seem to find such a switch.

About IE 11 speed: It is not that fast. It has some improvements, but still appears sluggish. The IE's Trident (also Opera) layout engine still renders things only after the page is pretty much loaded. This is exactly the opposite way of Chrome, Mozilla and Webkit -engines way of doing things. In IE the page load appears slow to user since there is always a delay when nothing happens. Also IE appears to be bit slow on CSS / DOM -parsing. Most of development effort has gone into JavaScript-speed.

In conclusion: Windows 8.1 upgrade is a major letdown. The new "start" button does not deliver, I'm still using Classic Shell as a start button, IE 11 doesn't deliver. I'm sure I'll update, but it's nothing worth waiting for.

I don't know who stole my €-char. It is supposed to be on AltGr-e, but my keyboard doesn't do it. There is a discussion about the same problem. On the thread on French keyboard layout the problem is not solved.

On my Finnish keyboard layout even Windows On-Screen Keyboard -application displays AltGr-e as the soure, but to my great amazement adds a 2nd source for the €-char, AltGr-5. WTF?! It works! See pic below:

Hope this helps somebody. Unfortunately I could not determine who stole it/where my original euro-key went.

I have couple of own daemons running on my Linux-box. Now that all the distros are going systemd, my scripts are becoming obsolete. Sure, the systemd can piggy-back into old init.d-scripts, but ... I'd rather have them converted to the new way.

Lennart Poettering's blog has a helpful article, which got me started on my project. Also the manual pages for systemd (systemd.service and systemd.exec) proved a very valuable reference.

My daemon is pretty much from the trivial end of daemons. It runs as nobody-user to prevent it from disallowing access to number of places in case something/somebody breaks it. It does the classic fork on start and parent process simply exits. Fortunately systemd programmers anticipated that and there is a perfect support for such startup sequence.

Here is my example. I simply placed a file named dhid.service into directory /usr/lib/systemd/system/. Then I could interface with it by systemctl-command. Example:

# systemctl status dhid.service
dhid.service - DHIS client for keeping track of changing dynamic IP addresses in DNS
   Loaded: loaded (/usr/lib/systemd/system/dhid.service; disabled)
   Active: active (running) since Wed 2013-07-03 15:26:03 EEST; 928ms ago
  Process: 32355 ExecStart=/usr/sbin/dhid -P /var/run/dhis/dhid.pid (code=exited, status=0/SUCCESS)
 Main PID: 32356 (dhid)
   CGroup: name=systemd:/system/dhid.service
           └─32356 /usr/sbin/dhid -P /var/run/dhis/dhid.pid

Jul 03 15:26:03 samba dhid[32356]: daemon started

My entire file is here:

[Unit]
Description=DHIS client for keeping track of changing dynamic IP addresses in DNS
After=syslog.target network.target

[Service]
Type=forking
PrivateTmp=yes
User=nobody
Group=nobody
ExecStart=/usr/sbin/dhid -P /var/run/dhis/dhid.pid
PIDFile=/var/run/dhis/dhid.pid

[Install]
WantedBy=multi-user.target

It is really that simple! To make the daemon to start on bootup, just use the systemctl enable dhid.service -command.

Well ... you cannot create one. They're just saying that there are "capacity issues" and due to that "West Europe was turned off for new subscriptions a short while back".

Is the old M$ is back? They very conveniently forget to tell you that when you're setting up your storage and servers, you cannot have a web site on top of them. Nice. Wouldn't it be great to know that during setup-phase?

They must be really doing well in Microsoft to treat users that badly. I'm sure that popularity of their service wasn't a surprise to them either. Yet another nice example of bad communication from a big corporation.

ISC BIND is the most popular DNS in the entire Internet. Most hostmasters never need to allow DNS-clients to change records, but then there are cases where it can be handy.

When thinking of the security, it will be very, very stupid to allow anybody to update records. Luckily there doesn't seem to be a script-kiddie-proof -tool for doing that (or at least I haven't found one yet). Most servers simply don't allow dynamic updates and those who do, don't allow it for all zones. Security-wise one of the simplest approaches is to allow updating a zone from specific subnet or hand-picked IP-addresses. That way most of the users have been excluded using a simple mechanism. Surely any motivated cracker will bend any rules, that exist.

To add security and allow updates only for those who actually are permitted, a smart move is to go TSIG. It is described in RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) and is supported by many DNS-servers, including BIND. Getting it running is described poorly. Best description I found is in Jeff Garzik's blog the article is title "nsupdate: Painless Dynamic DNS".

The basic steps are pretty much following:

1. Generate update key
• This will include executing a command like:
  dnssec-keygen -a hmac-md5 -b 128 -n HOST my.dns.update.key.
2. Inform BIND-server about the key
• This will include changing the raw key-file into BIND-format, like:
  key "my-key-name" {
    algorithm hmac-md5;
    secret "somethingcompletelybullshithere==";
  };
3. Allow a zone to be updateable by anybody knowing the key
• This can be accomplished with allow-update -configuration directive.
  
4. Go update!
   

A test run for checking out if your setup succeeded would be:

# nsupdate -k my.dns.update.key
update delete a.record.my.zone. A
update add a.record.my.zone. 3600 A 192.168.0.198
show
send

If server's messsage log says something like "client 192.168.0.1#12790: request has invalid signature: TSIG dhis: tsig verify failure (BADKEY)", then your key setup failed. Either server doesn't recognize your client's key, or client failed to provide a valid key.

If server's message log says something like "client 192.168.0.1#39782: update 'my.zone/IN' denied", then the DNS-zone to be updated does not allow dynamic updates. Add something like allow-update { key "my-key-name"; }; into your zone-configuration.

A successful update will show something like this in your logs:

named[25415]: client 192.168.0.1#64975: signer "my-key-name" approved
named[25415]: client 192.168.0.1#64975: updating zone 'my.zone/IN': deleting rrset at 'a.record.my.zone' A
named[25415]: client 192.168.0.1#64975: updating zone 'my.zone/IN': adding an RR at 'a.record.my.zone' A

(Note: the named PID and client port-numbers are just copy/pasted from my log. They will differ in your case.)

Ok. SDM is not the best piece of software ever written. It fails on everybody and everything. There is a lot of grievance in a MSDN discussion thread.

Problem 1:
The first issue I encountered was that it didn't install. It said "The System Administrator Has Set Policies to Prevent This Installation". That is not a standard Windows error message, and I gather it is something the lovely programmers made the app say when failing.

Solution 1:
Run it with Administrator -privileges. The installation package is distributed as MSI-package and Windows Explorer doesn't offer the "Run as Administrator" -option on it. I started a Power Shell as administrator and executed the installed from there. That fixed it.

Problem 2:
Download fails to start on "Active Scripting must be enabled". Well, I have that enabled.

Solution 2:
Make sure following domains are in Trusted sites -list. (See: Internet Options -> Security)

• http://e5.onthehub.com
• http://static.onthehub.com
  
• http://ajax.googleapis.com

Then the goddamn thing starts to download.

I'd like to second OtaconHC's opinion from the MSDN-thread: The SDM is a failure by design.

This was pretty funny one. I was about to start a Windows Azure 30-day trial on Windows 8 with Internet Explorer 10, but it failed on payment options.

I waited for 10 minutes, but no avail. It was pretty obvious that a failure was imminent after 30 seconds of nothingness. The payment just hangs forever without doing anything. They simply never tested it on IE10. On any other browser I tried it works just ok.

Most Linux distros have udev. It has been around a while and is pretty much the way of handling physical devices in your box.

In The Old Age™ making a device to be something was very simple. /dev was in regular filesystem and could have permissions/symlinks/whatever set by admins. During modern era creating a symlink or setting permissions is bit more complex. The steps are:

1. Identify the device
2. Figure out the identifying attributes from udev
3. Choose an operation / operations to be executed when the device is found
• This can be during boot or plug'n'play / USB
  
4. Bring it all together in a configuration file readable by udev
   

An example:

External USB-drive/-stick can have pretty much any drive letter assigned into it by SCSI-subsystem during plugin. It can be /dev/sde today and /dev/sdf tomorrow. Trying to figure out the drive letter each time it is plugged in is both tedious and unnecessary. With (simple?) udev-wrangling you can have a /dev/myownusb to access it every time the drive is plugged in. Steps:

1. Identify
1. lsusb is your friend, from the output it is possible to determine that:
   Bus 001 Device 007: ID 1941:8021 My C00l USB-drive
   
2. Today USB-bus 001 device 007 is the drive. What if you plug it into a different USB-port next time? We need to find identifying attribute/attributes to make configuring possible.
1. If we assume that the drive is /dev/sdf this time, all the udev-attributes can be displayed with a:
   udevadm info --query=all --name=/dev/sdf --attribute-walk
   
2. It will reveal a drive serial number in a format similar to:
   ATTRS{serial}=="0000002CE09310500C1B"
3. The operation we'd like to be done when such a USB-device with a matching serial number is plugged into the computer is a symlink.
4. The final step to get this configured would be to create a file into /etc/udev/rules.d/ with a suitable name.
1. I chose my configuration to be /etc/udev/rules.d/99-mylocalrules.
2. The file will contain a single line with identifying information and the operation. Example:
   SUBSYSTEMS=="usb", ATTRS{serial}=="0000002CE09310500C1B", KERNEL=="sd?1", SYMLINK+="myownusb"
   
3. That literally reads: Whenever a new device is introduced into USB-subsystem with suitable serial number and having a partition, the 1st partition will be symlinked into udev with name "myownusb"
   

To get the rule into effect you need to run:

udevadm trigger 

It is not necessary to unplug an already working drive. Just confirm that it worked:

ls -l /dev/myownusb

... or similar. Then just mount:

mount /dev/myownusb /mnt/myownusb

Another example:

I have a weather station connected into my Linux via USB-cable. There is no point of accessing it as a root, but out-of-the-box that's the only way to go. I need to chgrp the device after every boot for regular users to gain access into it.

With above process my identifying factor is the USB ID of the device and operation is to chgrp the device with a suitable group to allow access for those users belonging into the group. The rule is:

SUBSYSTEMS=="usb", ATTR{idVendor}=="1941", ATTR{idProduct}=="8021", GROUP="110"

Yet again the udev-rule reads: Whenever a new device is introduced into USB-subsystem with vendor ID of 0x1941 and product ID of 0x8021 the newly created udev-device will have a group with id 110. I prepared a group with groupadd and confirmed that it exists:

# getent group 110
WH-1080usb:*:110:itsme

After a udevadm trigger the result can be confirmed:

# ls -l /dev/bus/usb/001/007
crw-rw-r--. 1 root WH-1080usb 189, 6 Jun 19 10:07 /dev/bus/usb/001/007

The long(ish) path into the device comes from the lsusb output, it reads:

Bus 001 Device 007: ID 1941:8021 Dream Link WH1080 Weather Station

... and can be also translated as /dev/bus/usb/001/007. Simple, huh?

Fedora Linux guys replaced the ancient Initd with Systemd in Fedora 16. Bold move. I understand it had to be done. It speeds up booting and does a bunch of other things Initd can't or won't.

The classic story when introducing something new is that it has bugs. This particular time I struggled to get my Magic Sysrq key working on boot. Looks like Fedora people failed (at least) two times with it: Bug 760254 in Fedora 16 and Bug 924433 in Fedora 18 describe these shortcomings.

In short, the trouble with this new thing is that your changes won't take effect on boot. Most Linux admins never touch any of the sysctl(8)-settings and continue living successfully. Then there are rest of us, who tinker&tune their boxes to match their requirements. In Fedora Linux there is a directory of /etc/sysctl.d/ into a sysadmin may create a file with own settings to either override existing settings from /usr/lib/sysctl.d/ or set completely new values, which have only their kernel default set.

An example:
To set the Sysrq-key into "dangerous"-mode allowing all possible operations, the value of file /proc/sys/kernel/sysrq needs to be "1". It can be achieved with a file in /etc/sysctl.d/ containing following:

kernel.sysrq = 1

In Fedora the default value according to /usr/lib/sysctl.d/50-default.conf and manual inspection after boot is "16". So, the big trouble is to get the value of "1" stick. After a couple of reboots I realized that it is possible to test the functionality without booting the computer. As a root, simply run:

systemctl restart systemd-sysctl.service

... and watch what happens. The rather complex name of the service is something I couldn't figure out without Fedora discussion forums.

Anyway, after many many failures I concluded that my own settings need to be executed before the file 50-default.conf. To make things easier, systemd-sysctl.service first gathers a full list of files to be processed, then alphabetizes them and finally executes the settings in order. So I made my file to be /etc/sysctl.d/01-myownsettings.conf, which seemed to do the trick! There is a logic behind that, but it is just tricky to figure out.

My Fedora 19 got an update for KVM. It was a no biggie, nothing really happened at the time.

Then one of the virtual guests got a new kernel (RHSA-2013:0911-1). I rebooted the guest and BANG! My KVM hung the entires machine. I have the Magic SysRq enabled, but nothing. The box was completely hung.

The "funny" part happened after I forced a reboot from the button. The box wouldn't boot! My LDAP was corrupted. All I got was a "BDB0060 PANIC: fatal region error detected; run recovery" -message.

There is the /usr/bin/db_recover -tool, but it just said FUBAR. I didn't get the actual phrase, but surely you'll get the meaning. Then, what next? I was lucky enough to have a 3 week old slapcat of my entire LDAP. That was plenty of luck for me. But the morale of the story is, that I'll need to start dumping the LDAP or change the back-end format into something more recoverable.

Linux-distros are having a race for the most popular one. Part of the setup is to have the latest Linux kernel, and any other part of the software library a distro has. This effect yields into a "nice" effect where running the bleeding edge distros (Fedora, ArchLinux, Debian sid, etc.) every now and then something breaks.

The latest race is with PHP programming language which is nearing the 5.5.0 release. It has an RC3 version already out. Now the problem is that distro-guys start using the latest stuff, but PHP has incompatible changes in it. Plenty of things made with PHP 5.4 or 5.3 or ... won't run.

One of them is phpLDAPadmin. For some incomprehensible reason they are using stuff, which has been flagged as obsoleted years ago. So, it won't work. Luckily somebody at Debian made a fix. That makes my system's LDAP-admin working again. Hopefully somebody does the same with with all of the PEAR packages.

This is what you get when running alpha version of Fedora 19.

Windows 7 and 8 IPv6-stack has a nice feature. Every now and then when waking up from sleep/hibernate there is no autoconfigured IPv6-address. It looks like this when checking for IPv6-address with netsh interface ipv6 show address:

Interface 12: WiFi

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Other      Preferred     infinite   infinite fe80::227:10ff:1234:5678%12

Note how there is only link-local address and no "proper" IPv6-address. On Windows 7 there is a fix. Just disable the Teredo-interface:

netsh interface teredo set state disabled

After that IPv6-autoconfiguration works much better. That doesn't do the trick for Windows 8, tough. I have no idea what would help. My only fix is to discard autoconfiguration and manually set an IPv6-address. This setting won't survive a reboot, so it will keep using autoconfig under normal conditions. But anyway, this is what I do to fix my laptop:

netsh interface ipv6 add address "WiFi" 2001:1234:5678:0:227:10ff:1234:5678

After this, netsh interface ipv6 show address will function properly:

Interface 12: WiFi

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Manual     Preferred     infinite   infinite 2001:1234:5678:0:227:10ff:1234:5678
Other      Preferred     infinite   infinite fe80::227:10ff:1234:5678%12

If anybody knows how to fix this, please drop me a comment.

I got a new Supermicro server. Pretty much the next day there was a writing about computer security. The article is in Finnish, and it contains interviews from

• Stonesoft, the Finnish firewall / intrusion detection company bought by McAfee / Intel
  
• F-Secure, the Finnish virus detection company
  
• CERT-FI, the Finnish national computer security incident response team
  
• SSH, the Finnish security company
  

It contains allegations from USA about Chinese Huawei using their hardware for spying American companies. There is also allegation that Supermicro had intentionally left specific IP-addresses open in their Base Management Controller. I didn't find a single trace about that, however, there is a security warning by SEC Consult about Barracuda-products having something similar what they describe in the article.

Taiwanese Supermicro is not totally innocent. I found that they had/have a flaw in their documentation. They failed to mention that their IPMI implementation has two admin-accounts. That is pretty rare when it comes to networked appliance. Typically one admin-account will do fine for most of us. Intentional or a honest mistake? Nobody knows. And those who do, won't tell.

Otherwise, I found two separate issues about remote management security issues. First one is about using a non-standard chiper to encrypt the IPMI-traffic. It simply lets you pass without encryption or authentication. Nice!

The second one is from almighty Bruce Schneier. It describes findings about general lack of security in those very critical systems used to manage the servers. Consumer products are safe, they don't have BMC / IPMI -chips in them.

I have one Asus ASMB4 and one Hewlett Packard iLO 2 on-line at the time of writing. The Asus BMC doesn't survive two weeks in the wild Internet. There is an unknown flaw to shoot it out of the Net somehow. That's why I put a firewall appliance in front of it. The HP iLO 2 seems to survive in the wild, however it has a very sluggish response time and absolutely requires a firewall also. It seems to be a target for lots of incoming traffic. Those BMC-boards are tiny both in physical size and computing capabilities, it doesn't take much to overload them.

This is a cool move! At least Arch Linux and Fedora Linux have done this. A typical root directory listing will look like this:

lrwxrwxrwx.   1 root root     7 May 30 23:17 bin -> usr/bin
lrwxrwxrwx.   1 root root     7 May 30 23:17 lib -> usr/lib
lrwxrwxrwx.   1 root root     9 May 30 23:17 lib64 -> usr/lib64
lrwxrwxrwx.   1 root root     8 May 30 23:17 sbin -> usr/sbin

The /bin, /lib and /sbin have been in the root directory since first Unix was released in 1969. Any modern Linux distro won't have and won't need that many partitions than the legacy *nixes used to have. The reasoning is in this discussion thread.

Arch Linux guys have a pretty complex update process. The classic pacman -Syu won't do it for you this time.