Posts Tagged ‘linux’

Get IP address from Samba share/NetBIOS name

Thursday, January 5th, 2012

Suppose you’ve got a NetBIOS address of a Samba share like //SERVER/MyShare and you’d like to know the IP address of the server with the NetBIOS name SERVER. On Linux, you can use Samba’s nmblookup like so:

  1. nmblookup -I SERVER
  2. querying SERVER on 192.168.0.255
  3. 192.168.0.213 SERVER<00>

In our example above, the IP address of the machine with the NetBIOS name SERVER turns out to be 192.168.0.213.

Monitoring PowerDNS via the internal web server

Tuesday, February 16th, 2010

If you want to stay informed about the current status of your PowerDNS server, there is no need to scan the logs or use third party tools like logcheckd. Actually, you might want to do this anyway, but PowerDNS provides an internal web server, which summarizes all the status information (including log messages) in a very nice and compact way for you to view.

By default, the web server will listen on port 8081 on localhost. That means, that you can’t view the status information from the outside network. To view the page, you could use a command line browser like lynx. You could change the interface of the web server to a public IP address, but this is very insecure and not recommended. The PowerDNS web server provides some sensitive information about your DNS server and you should not expose this information to the public. Also, the PowerDNS web server is probably not as thoroughly tested and hardened as e.g. Apache or nginx. Another problem is, that you can only specify a single password and that you are limited to basic authentication, which is not very secure.

There is a secure way to retrieve the information provided by PowerDNS from outside your DNS server host. You could use Apache, nginx or any other web server you like as a proxy server. That way you can use more advanced authentication methods built into that web server to secure your status page. I will now show you how to do this using Apache 2 on Debian. We’ll need mod_proxy, mod_proxy_http and mod_headers enabled on the Apache 2 server. If you do not want to run an instance of Apache 2 on your DNS server, you could use an SSL tunnel or a secure back channel link to a remote Apache server to retrieve the status page. But this is beyond the scope of this post.

First, enable the internal PowerDNS web server by editing the configuration file.

  1. webserver=yes
  2. webserver-address=127.0.0.1
  3. webserver-port=8081
  4. webserver-password=PowerDNS

This tells PowerDNS to run the internal web server on port 8081 of the localhost interface. The user name will be admin and the password will be PowerDNS. Of course you should change the password to something more secure, it’s just an example. After a restart of PowerDNS you can connect to your server from your DNS server host. The password is optional, but it’s safer that way, especially in an environment where you’ve got other users on your DNS server box.

Now install and enable the required modules of Apache 2 by executing the following commands.

  1. apt-get install libapache2-mod-proxy-html
  2. a2enmod proxy
  3. a2enmod proxy_http
  4. a2enmod headers

The last module is only needed, if you set a password for your internal web server as recommended above. I assume that you’ve got some kind of virtual host configuration for your Apache server. You’ll want to add a new virtual host for the DNS status information. If you use a subdirectory, navigation might be a bit odd. Let’s add a new site to the available sites.

  1. vi /etc/apache2/sites-available/status.dns.example.net
  2. <VirtualHost 192.168.0.1:80>
  3. ServerName status.dns.example.net
  4. DocumentRoot /var/www/
  5. ProxyRequests Off
  6. <proxy *>
  7. Order deny,allow
  8. Allow from all
  9. ForceType 'text/html; charset=UTF-8'
  10. </proxy>
  11. ProxyPass / http://localhost:8081
  12. ProxyPassReverse / http://localhost:8081
  13. </VirtualHost>

Alright, so what are we doing here? Basically, we’re adding a new virtual host status.dns.example.net on our main interface of dns.example.net. We’re using a reverse proxy to to send all requests coming from the outside to our internal PowerDNS web server on port 8081. Also, we’re forcing a text/html content type in the proxy request filter, because otherwise we would just get text/plain and we would simply see the source code, which is probably not what you want. Let’s enable the site for a test:

  1. a2ensite status.dns.example.net
  2. /etc/init.d/apache2 reload

If you point your web browser to status.dns.example.net you should now see the internal status page of PowerDNS. If you set a password above, you will see a password dialogue. This is the password dialogue sent by the PowerDNS web server. The user name is admin and the password is your password. Try it out now, because we’ll get rid of this in a minute.

For security reasons, you probably want to use Apache 2 for authentication. E.g. you might want use a SSL connection and authenticate your co-workers using the internal LDAP server of your company intranet. You might even stay with the insecure basic authentication method, but use other user names. This is entirely up to you and beyond the scope of this post. Consult the Apache 2 documentation on how to do this. What you probably don’t want to do, however, is to authenticate twice (first your secure authentication method and then PowerDNS basic authentication. Luckily, we can configure the Apache 2 proxy to do the authentication for us. This is a bit tricky, though.
To authenticate at the PowerDNS server, Apache 2 needs to send an additional Authorization header line to the PowerDNS server with every request it handles. We use the RequestHeader directive to override any existing Authorization header with our own authentication data. Add the following lines just before the end of the virtual host container.

  1. <Location />
  2. RequestHeader Set Authorization "Basic YWRtaW46UG93ZXJETlM="
  3. </Location>

The above example works only for our example password, which is PowerDNS. Try it for a test. This is, because part of the header value is encrypted using the base64 algorithm. You need to change the encrypted part YWRtaW46UG93ZXJETlM=. In plain text the encrypted string would read admin:PowerDNS, where admin is the user name and PowerDNS is the password. To use your own password, you need to encrypt the string admin:yourownpassword using the base64 algorithm and replace our example string. Be sure to keep the Basic and the space. It is crucial for success, that you’ve got the right encrypted string. There are a number of online tools, to encode and decode these strings. To ensure, that you’ve got the correct encryption method, encode the example string and compare it to the string above for a reference. If you’ve got the wrong string, it will not work.

Restart the Apache 2 server. To clear your password cache, restart your browser. Now surf to the site again. You will see, that the password dialogue is gone. Now, don’t forget to secure the page again using Apache 2. Under any circumstances, do not use Directory containers in the configuration. These will not apply to the proxy, because the proxy is not a physical directory on your server. Use Location containers like we did above for setting the RequestHeader directive. Also, you could still use insecure basic authentication to secure the page, if you wanted. It would work regardless of the RequestHeader magic.

A light-weight alternative

For those of you, who think that Apache is too heavy, here is an example for the nginx web server:

  1. vi /etc/nginx/sites-available/status.dns.example.net
  2. server {
  3. listen 192.168.0.1:80;
  4. server_name status.dns.example.net;
  5. root /var/www/nginx-default;
  6. location / {
  7. index index.html
  8. proxy_pass http://localhost:8081;
  9. proxy_redirect off;
  10. proxy_set_header Authorization "Basic YWRtaW46UG93ZXJETlM=";
  11. }
  12. }

Getting rid of Apache pass-phrase dialogs

Thursday, August 20th, 2009

Throughout the internet, HTTPS is used to encrypt traffic between a web server and its clients and thus provide a secure way of communicating with a server. Unfortunately, the best encryption is (somewhat) worthless, if you can’t be 100 percent sure that you are communicating with the right server. If Alice wants to send her credit card number to Bob, all encryption is worthless, if Mallory can trick her into thinking that he is Bob. SSL certificates to the rescue. If Alice trusts Carol and Carol has issued a SSL certificate to Bob, Alice can be sure that Bob is actually Bob and not someone else. SSL certificates are usually protected by private keys. You need the private key to use the SSL certificate. These private keys are usually encrypted with a pass-phrase. If Mallory manages to compromise Bobs server and steal the private key file, he can not (mis-)use it, because it is encrypted. That’s the theory.

However, Bobs web server needs to read the private key file to utilize the SSL certificate. If it is encrypted, Bob has to either store the pass-phrase somewhere or enter it by hand every time he starts the web server. If Bob uses Apache, he will get a so-called pass-phrase dialog. By default it looks like this (on the command line):

  1. https-www:/etc/apache2-itk/# /etc/init.d/apache2-itk start
  2. Some of your private key files are encrypted for security reasons.
  3. In order to read them you have to provide the pass phrases.
  4. Server secure.example.org:443 (RSA)
  5. Enter pass phrase:
  6. OK: Pass Phrase Dialog successful.
  7. .

While entering the pass-phrase of an SSL certificate by hand is a very secure approach, it has its share of problems:

  • Upon reboot of Bobs server, the web server will not start automatically. It will hang, because it waits for the pass-phrase to be entered. Likewise, if the web server is restarted automatically for some reason (e.g. by monitoring software) the web server will hang on start-up, because it waits for the pass-phrase to be entered.
  • For security reasons, it is unwise to use the same pass-phrase for all private keys. Also, Bob shouldn’t use overly simple pass-phrases, that are easy to remember. If Bob needs tenths (or even hundreds) of private keys he can’t possibly remember every single pass-phrase.
  • It takes some time until Bob has looked up the corresponding pass-phrase in his mind or in his secure pass-phrase store. Even if he manages to immediately know every pass-phrase in use at his web server, it takes some time until he has entered the pass-phrase.

For the sacrifice of some security, you can mitigate these issues. If you really don’t care much for security, you can either not use a pass-phrase in the first place or – if you somehow entered a pass-phrase by accident – remove the pass-phrase from the key file. To remove the pass-phrase from an RSA private key use:

  1. openssl rsa -in secure.example.org-2009.key -out secure.example.org-2009.key.unprotected

If you want a somewhat more secure approach (depending on the implementation), you can check out the SSLPassPhraseDialog directive of the Apache mod_ssl module. Using this directive, you can tell Apache to ask an external script for the pass-phrase of your certificates:

  1. SSLPassPhraseDialog exec:/path/to/script

Apache will supply two arguments to the script. The first argument is of the form servername:portnumber, e.g. secure.example.org:443 and the second argument is either RSA or DSA. The script would print the corresponding pass-phrase to stdout. Of course, you still need to store the pass-phrases somewhere. How much security you sacrifice using this construct depends on the implementation of your external script. But it might be a slight bit more secure than just using no pass-phrase for the private key files at all.

Choppy Flash video in full-screen mode on Ubuntu

Wednesday, August 19th, 2009

When I originally upgraded to Ubuntu 9.04 (Jaunty), I noticed that Flash video in full-screen mode was kind of choppy. I never took the time to debug this and instead worked around this by either not watching Flash videos in full screen mode, not watching Flash videos at all or using the excellent Youtube integration of Totem. However, today I did some research into the problem and found a bug in Launchpad, which solved the problem for me. It turns out that there is a bug affecting the Intel stack (in this case Intel stack means not necessarily an Intel graphics card, but Intel processor). The bug is a miscommunication between X.org and the Kernel, which results in a misconfiguration of the Memory Type Range Registers (MTRR) in the Kernel. The result is poor performance in video playback and everything that involves graphics in general. This bug has been fixed upstream and in Karmic. A fix for Jaunty has been developed, but is yet to be released.

You can test, if you are affected, by running cat /proc/mtrr on the command line. If you can’t see a line, which ends in write-combining you are most certainly affected by this. You can further check with lspci -vv and check the Region 0 memory range of your VGA adaptor. If you cant find that memory range in your mtrr file, you are probably affected.

Until the fix is released, one solution is to run this shell script as root after every restart of your X.org server. Warning: Audit any external file before you run it as root on your computer! The script should update the MTRR configuration of the Kernel with the correct settings. If you are affected by the bug, you will notice a slight improvement in overall graphics performance and the full-screen Flash videos should now play as originally intended.

Commenting out multiple lines in Vim

Saturday, August 8th, 2009

Somtimes you want to comment out multiple lines in Vim. There’s an easy way to do this out of the box without any rc magic or plugin.

  1. Navigate with the cursor to either the first or last line you want to comment out.
  2. Pess Control and v to select a new visual block.
  3. Move your cursor down (or up respectively) to the last (or first) line you want to comment out. You just formed a visual block of your comment.
  4. Press I to insert text before all selected lines.
  5. Type your comment code (for example // or # or ;).
  6. Press Escape. Your comment code will be inserted before every line of the visual block.

To uncomment, do exactly the same, but instead of executing step 5 apply a regular expression. The regular expression should look something like this: :s/^#/. This will replace every # at the beginning of the line with nothing. If your comment code has only one character, you can also press d to delete the first character of every line.

Easy. Now tell me how to do this in Emacs. Christine graciously commented on how to do this in Emacs. Looks similar, except that Emacs seems to be a bit smarter about what comment code to use.