Search Results for: FRITZ!Box tuning

FRITZ!Box tuning part 4: Cross-building and installing additional applications

IT, Root, , , , , , , , , , , , , , , , , , ,

The articles I wrote about the FRITZ!Box are pretty popular. They are creating the most traffic on my website. I understand this, cause the FRITZ!Box is a really great piece of hardware and AVM is also a company which knows how to make their users happy by serving regular updates to the firmware. Although I didn’t tuned my FRITZ!Box any further, I updated it with the latest Labor firmware version regularly. At some point the sshd setup (with dropbear) doesn’t worked anymore and I decided it is the time to update my software as well. Beside that it didn’t work anymore it is always a good idea to update software which allow access to a host from everywhere very regularly. Anyway, it turned out this isn’t as simple as I initial thought. Therefore here is the next post in the FRITZ!Box tuning series, which shows how to cross-build software for the MIPS32 architecture used in the FRITZ!Box and in particular get the sshd software to life again. I use a FRITZ!Box Fon WLAN 7270 v2 and the firmware is 54.05.05. Please make sure you read the other FRITZ!Box articles as well, cause some of the information given there still applies.

As already mentioned in the other articles, there is no warranty that this will work on your side and I am not responsible for any damage which may happen. You have been warned!

Cross-building for the MIPS32 architecture

The FRITZ!Box itself doesn’t include any build tools. Why should it! It’s an end-consumer product which is usually never changed, beside the user is updating it with an official firmware update. So we have to do it ourself. Creating a build chain for another architecture is usually hard. There are several things you have to consider. This includes problems with the configuration, endianess differences between the host and the target, bit depths and depending shared libraries which have to be available in the target format. Fortunately this is a common problem, especially for embedded systems, which means there is a proper solution called Buildroot (look at the first line in dmsg, when the FRITZ!Box has booted and you know what I mean). Buildroot is a build system which allows, similar to the Linux kernel, configuring and generating complete embedded Linux systems. Regardless how configured, Buildroot builds a complete Linux system, always. This is of course a little bit overhead for us, but we just pick out the relevant files. First we need to know which architecture we target. You have to login into the FRITZ!Box either using telnet or a working ssh daemon. To get some information about the hardware used in your FRITZ!Box execute cat /proc/cpuinfo.

# cat /proc/cpuinfo
system type             : TI UR8 (7270)
processor               : 0
cpu model               : MIPS 4KEc V6.8
BogoMIPS                : 359.62
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : no
ASEs implemented        :
shadow register sets    : 1
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

Here we learn that the FRITZ!Box is using a MIPS processor. In this case it uses the little-endian format. Next you need some information about the system C library. On normal Linux (desktop) systems the GNU C Library is used. This library is heavyweight and therefore the uClibc was invented for embedded systems. By executing ls /lib/libuClibc* you get the version installed. In my case it is 0.9.31. Now we have all information needed to configure Buildroot. Download and extract the source of Buildroot.

If you are working on a Mac like me (where Buildroot doesn’t work), VirtualBox with a Linux system as a guest is a good alternative ;).

By executing make menuconfig in the root directory of Buildroot you are able to configure it. The most important options are Target Architecture, set this to mipsel and Target Architecture Variant, set this to mips 32r2. In Toolchain -> uClibc C library Version select a version which is close to the one on your FRITZ!Box. Next you have to select which packages should be build in Package Selection for the target. Choose whatever you want but for the beginning Networking applications -> openssh might be enough. If you prefer a more lightweight ssh implementation dropbear may also an option. In the following we use OpenSSH. You can also tweak the build options, like the gcc version to use or set the gcc optimization level to -O3 in favor of size. After saving the configuration and executing make, it is time for a coffee. When the build has been finished all relevant files are in output/target/. We only pack the directories and files which are necessary. For example the libuClibc was built by Buildroot, but we will use the one from the FRITZ!Box. The following create a zip archive of the files for OpenSSH.

zip -r ../../local.zip "lib/libutil* lib/libnsl* lib/libresolv* 
 lib/libcrypt* usr/lib usr/share usr/sbin usr/bin etc/ssh_config 
 etc/sshd_config"

Creating overlay directories on the root filesystem

The following is based on ideas invented by the guys at http://www.spblinux.de/. Our aim is it to have as little persistent changes on the FRITZ!Box as possible. This allows us to go back to the original state with a simple reboot. Therefore all writeable directories will be on a tmpfs filesystem. tmpfs filesystems are created in RAM and the content will be removed when the filesystem is unmounted. Because the FRITZ!Box has only limited RAM, we will not copy our applications into the tmpfs filesystem, but just create symbolic links to the files on the USB stick (where usually much more space is available). Because we want the applications from the FRITZ!Box and our own one be accessible from the root filesystem, we need to merge both into the tmpfs directory. Therefore first symbolic links into the original filesystem and second symbolic links to the USB stick are created. The second step is only performed when there isn’t a file already. This makes sure the original files are always preferred over our own one. The last step is binding the directories to the root filesystem. Summarized the following will be done:

  1. remount / readonly
  2. mount / into /var/_ro_
  3. create tmpfs in /var/_overlay_
  4. symlink the files from /var/_ro_ into /var/_overlay_
  5. symlink the files from the USB stick into /var/_overlay_
  6. bind the directories in /var/_overlay_ to /

This script does the previous steps. It uses helper methods which are defined in common.sh. You will find all the necessary files in the package you can download at the end of this article.

#!/bin/sh
 
. common.sh
 
MNT=/var/_overlay_
BASE_RO=/var/_ro_
BASE_OVL="${BASE}/local"
 
DIRS="lib etc usr/bin usr/sbin usr/lib usr/share"
 
# remount root readonly
"${MOUNT}" | "${GREP}" "/dev/root" | "${GREP}" -q ro
[ $? -eq 1 ] && _lmt /dev/root / "-o remount -r"
# bind root into var
_lchkmnt "${BASE_RO}"
if [ $? -eq 1 ]; then
  _lmkdir "${BASE_RO}"
  _lmnt / "${BASE_RO}" "-o bind"
fi
 
# create our overlay dir
_lchkmnt "${MNT}"
if [ $? -eq 1 ]; then
  _lmkdir "${MNT}"
  _lmnt tmpfs "${MNT}" "-t tmpfs"
fi
 
# link/copy the base stuff
for i in ${DIRS}; do
  _lsymlnk_dir "${BASE_RO}" "${i}" "${MNT}"
done
 
# link/copy our own stuff
for i in ${DIRS}; do
  _lsymlnk_dir "${BASE_OVL}" "${i}" "${MNT}"
done
 
# now bind all overlay dirs to root
# (this is critical don't interupt)
for i in ${DIRS}; do
  _lmnt "${MNT}/${i}" "/${i}" "-o bind"
done
 
exit 0

Now copy the zip archive you have created above to the FRITZ!Box and unpack it on the USB stick in addons/local/. The scripts have to be placed into addons/. You need to configure the following in common.sh:

# the base of the usb stick goes here:
BASE="/var/media/ftp/FLASH-DISK-01/addons"
# add the encrypted root password here:
PASS=""

Point to the base directory within the USB stick in BASE. Also add your encrypted root password into PASS. This will create a root user in /etc/passwd automatically.

If you believe all is correct, you can start the installation by executing ./install.sh. If no errors are shown, you can try ssh. ssh -v should output something like this:

# ssh -v
OpenSSH_5.8p2, OpenSSL 1.0.0d 8 Feb 2011
...

Additional to the standard filesystems mounted, you should see the following when executing mount:

# mount
...
/dev/root on /var/_ro_ type squashfs (ro,relatime)
tmpfs on /var/_overlay_ type tmpfs (rw,relatime)
tmpfs on /lib type tmpfs (rw,relatime)
tmpfs on /etc type tmpfs (rw,relatime)
tmpfs on /usr/bin type tmpfs (rw,relatime)
tmpfs on /usr/sbin type tmpfs (rw,relatime)
tmpfs on /usr/lib type tmpfs (rw,relatime)
tmpfs on /usr/share type tmpfs (rw,relatime)

Configure and start the OpenSSH daemon

Now that we have our brand new OpenSSH on the FRITZ!Box working, we need some last steps to let the daemon running correctly. First create a private/public RSA host key pair for the server process by executing:

ssh-keygen -t rsa -f addons/config/ssh_host_rsa_key

addons/config/ have to be an existing directory below the USB stick base. Next create a file addons/config/sshd_config in the same directory with the following content:

Protocol               2
UsePrivilegeSeparation no
Subsystem              sftp /usr/lib/sftp-server

The following script could be use to start the sshd:

#!/bin/sh
 
. common.sh
 
SSHD="/usr/sbin/sshd"
SSH_SPKEY="${BASE}/config/ssh_host_rsa_key"
SSH_CFG="${BASE}/config/sshd_config"
SSH_TPKEY="/var/tmp/ssh_host_rsa_key"
 
# sanity check
[ ! -e "${SSHD}" ] && _lce $? "sshd not installed"
 
# start in tmp
cd /var/tmp   
 
mount -o remount devpts /dev/pts -t devpts
 
# cp key and make them user readable only
_lcp_file "${SSH_SPKEY}" "${SSH_TPKEY}"
_lchmod 400 "${SSH_TPKEY}"             
 
# start sshd
"${SSHD}" -f "${SSH_CFG}" -h "${SSH_TPKEY}"

Please note that you have to set up the root user first and maybe adjust your port forwarding rules to allow access from the Internet as described in this post. The package will contain a script startup.sh which will add the root user automatically.

Here is the obligatory screenshot which shows htop with color terminal support. You see OpenSSH and OpenVPN in the list of the running processes.

Conclusion

Thanks to Buildroot it is pretty easy to cross-build for embedded machines these days. With some tricky directory rebinding new applications could be injected into the FRITZ!Box root filesystem without overwriting the existing firmware. Now you should be able to build any software already bundled with Buildroot or even add new one to the build process. Happy cross-building!

You can download the scripts and binaries discussed in this post:
FRITZBox_OpenSSH_5.8p2.tar.gz (3.8MB, SHA1)

FRITZ!Box tuning part 3: Using the VoIP phone line from everywhere

IT, Root, , , , , ,

The contract with my Internet service provider includes a VoIP connection. Together with the FRITZ!Box 7270 all phone calls are done over the Internet, an additional conventional phone connection isn’t necessary anymore. One of the benefits of this is that you can connect to your registrar from everywhere in the world. But that’s theory, cause e.g. my provider doesn’t allow a connection if you are not in the network of the provider itself. Of course there are free services like sipgate or even Skype. There you could make free calls within the services itself, but as soon as you like to call a real phone number you have to pay. They are cheap, no question, but my contract includes a flat rate within Germany. That’s even cheaper. So what I like to do is to use my VoIP phone connection even when I’m not at home. In the following third part of the FRITZ!Box tuning series, I will explain how to achieve this. As already said in the first two post, where you at least should read the first one, I’m not responsible for anything happens to your FRITZ!Box after you have tried what is described here.

Adding a softphone to the FRITZ!Box

The FRITZ!Box fully supports softphones in its basic configuration. Adding new softphones is done in the web frontend in the extended configuration section. There is a wizard for this, where you have to answer some question about your new device. Select phone as device, LAN/WLAN (IP-Phone) for the connection type, choose a name and a password. You get a new internal phone number which usually starts at 620 for the first created device. The FRITZ!Box try’s than to connect to the new device. You can skip this for now. After that you have to select which official phone number the new device should use. This is important cause this will be displayed as the caller id when you make a call. Now you could choose if the new softphone should react on all incoming calls, regardless of the phone number called, or only on a specific one.

Configuring the client software

I will explain the client setup with the help of a free VoIP software called Telephone. It’s only available for Mac OS X, but there are many other VoIP clients out there which also works for other operation systems. After downloading and installing it you have to create a new account. Select a descriptive name for the account. For the domain use fritz.box, as username you have to use the internal number the FRITZ!Box selected above. Lets use 620 for now. The password is the one you chose previously. After the account is created, I had to select Substitute “00” for “+” in the advanced settings, cause the phone numbers in my address book are all saved with the international phone prefix of Germany which is +49. Assuming you are working in your home network right now, you should be able to connect with Telephone to your FRITZ!Box. Some simple tests like making an outgoing and incoming call with an additional mobile phone should verify a working setup. Some nice features like the Mac OS X Address Book integration, which also transfers incoming caller id’s to real names if they are found in the address book, making Telephone a really useful application. For further phone call management functionality on Mac OS X, I can advice you to take a look at the also free software Frizzix.

Allowing calls from everywhere

All the previously isn’t any magic, cause it uses build in support of the FRITZ!Box. But this article is about allowing connections to the VoIP part of the FRITZ!Box from everywhere. To make this happen we have to edit an internal configuration file of the FRITZ!Box. This time we aren’t change the ar7.cfg file, but a file called /var/flash/voip.cfg. As the name suggest there is most of the VoIP configuration included. Use nvi to edit it and search for a section called extensions. There should be a newly created one which have a value extension_number with 620. Change the value reg_from_outside from no to yes. This section should then look like the following:

extensions {
    enabled = yes;
    username = "$$$$SSFSDFSOPKSFDOPK;LWE§REWSDFMKFSLDF3232SDFSDFSDF";
    authname = "";
    passwd = "$$$$DFS342ASDFSDFDSFDS§344WLKKHMSJHAJHASDAHQASLKADJSA";
    extension_number = 620;
    reg_from_outside = yes;
    tx_packetsize_in_ms = 0;
}

Save the file and reboot your FRITZ!Box by typing reboot. Next we have to tell Telephone to use a proxy when connecting to the FRITZ!Box. Go to the advanced settings and add your DynDNS name, in this example it would be xtestx.dyndns.org, to the proxy field. That’s all. Now you should be able to make calls from every network you are currently logged in.

Conclusion

This simple change to the internal configuration of the FRITZ!Box allows you to use your VoIP account from everywhere over the world. As nice this feature is, I like to add some words of caution at the end. First you need a good download and especially a good upload connection speed in your home setup, cause all phone calls are routed over the FRITZ!Box. Secondly I didn’t know if VoIP transfers are encrypted in any way, so be aware that there is the possibility someone monitor your calls. And as last note you should understand that you opened a port on your FRITZ!Box for everyone, which in the case your password is stolen, could be abused. In the worst case someone use your account to SPAM other people or call expensive service numbers.

FRITZ!Box tuning part 2: Access your home network with OpenVPN

IT, Root, , , , , , , ,

AVM has built a VPN server into the FRITZ!Box, why should I use some other software for this job, you may ask. The reason is quite simple: the build in one is a piece of closed source software written by AVM and there is only one official client which could be used to connect to it, the FRITZ!VPN software. This client software is only available for the Windows operation system family and so by no means anything useful to me. I’m pretty sure they are using some official protocol like IPSec, so it might be possible to connect to the FRITZ!Box with other clients as well, but that’s something I didn’t want to try. OpenVPN on the other side is a rock solid open source software which could be used from many popular OS’s these days. Even graphical clients, like TunnelBlick for Mac OS X, are available. So here comes the second article of the FRITZ!Box tuning series, which will explain how to convert your FRITZ!Box into a OpenVPN server, where any number of clients can concurrently be connected. I highly recommend to read the first part of this series, because this post is build on top of the stuff done there. This count especially for the filesystem layout on the usbstick and the way additional software is started. Also in the following it will be helpful to have ssh access to the FRITZ!Box all the time. As already written in the first part, there is no guarantee that the information presented here will work on your side or that I’m responsible for anything happen to your FRITZ!Box. In preparation of the following you need access to a second OpenVPN installation which will be used to create all necessary certificates and keys and which could be used to test the installation afterward. I’m using a Gentoo Linux host where you could install OpenVPN simply by executing emerge openvpn. Make sure you have the examples USE flag set to get all the helper scripts which make the life much more easier.

The agony of choice

OpenVPN could be configured in many different ways. So first of all we have to decide which features of OpenVPN we will use. In its simplest variant OpenVPN could be used with one preshared static key. The advantage of this setup type is the easy configuration. The disadvantage is that only one client could be connected at the time. That is not what we want, so we will configure our setup to be using a Public Key Infrastructure (PKI). This allows more than one client to be connected at the time and it is possible to mark single keys invalid without affecting other client keys. The second question which has to be answered is, if we want use routing or bridging in our setup. Again, routing is simpler to set up and also a little bit faster than bridging. Bridging on the other side allows the tunneling of non IP protocols such as IPX, tunnel all the IP broadcast and make it possible to use the same subnet on the client side as on the server-side. Especially the last point is a nice feature as with routing all hosts on the server-side needs a routing table entry to find the connected clients. But my main reason for preferring bridging over routing is the broadcast feature of the first one. In my home network works a NAS station as a file server. This includes of course simple filesystem sharing with AFP and NFS, but also serves this box audio data with the Digital Audio Access Protocol (DAAP). DAAP is used by Apple in iTunes to share music with other clients in the network and that is what my NAS station does. This protocol, as well AFP, using broadcast messages (ZeroConf) to find some potential clients. So now it should be clear why I want bridging, it allows me to hear music or to simply connect to my file station without any interaction.

Building up a PKI

To create all necessary certificates and keys we are using the easy-rsa scripts from OpenVPN. They are located under /usr/share/openvpn/easy-rsa. First we change the vars file. On the bottom of the file are personal information defined which should be changed to fit to your environment. The entries looking as follow on my side (with a pseudo email address).

export KEY_COUNTRY="DE"
export KEY_PROVINCE="Sachsen"
export KEY_CITY="Dresden"
export KEY_ORG="64k"
export KEY_EMAIL="you@yourdomain.org"

You could also increase the KEY_SIZE from 1024 to 2048 within that file. This should make your keys unbreakable for the next few decades years. Now we are ready to create the master-key and the master certificate of the Certificate Authority (CA) by executing:

source vars
./clean-all
./build-ca

Please be aware that this will delete all previously created keys. Answering all questions with the default values should be sufficient. Next the key for the server has to be created.

./build-key-server server

You can again accept all default values. A challenge password is not necessary, but you have to sign the certificate. Now its time for our first client key and certificate. You could the following repeat again and again, for every new client you want allow to access the OpenVPN server.

./build-key client

Again, don’t forget to sign the key. If you ever have to mark a client certificate invalid you could do it with the following command:

./revoke-full client

This will create or update a Certificate Revocation List (CRL) file which will be later used by the server to verify the certificate integrity of a connecting client. For now we create an empty one with

KEY_CN="" KEY_OU="" KEY_NAME="" $OPENSSL ca -gencrl -out keys/crl.pem -config $KEY_CONFIG

The last step in this key building marathon is to create a Diffie-Hellman key. This key will be used to initiate the secure channel between the two parties. Its created by:

./build-dh

Creating the server and client configuration

We start with the configuration of the server:

# set the path to the tap device
dev tap
dev-node /var/tmp/tap0
mssfix
tun-mtu 1500

# TCP or UDP server?
proto udp
port 1194

# CA and key files
ca /var/media/ftp/FLASH-DISK-01/addons/openvpn/keys/ca.crt
cert /var/media/ftp/FLASH-DISK-01/addons/openvpn/keys/server.crt
key /var/media/ftp/FLASH-DISK-01/addons/openvpn/keys/server.key
crl-verify /keys/crl.pem # this is opened after the chroot

# Diffie hellman parameters
dh /var/media/ftp/FLASH-DISK-01/addons/openvpn/keys/dh1024.pem

# bridge setup
server-bridge 192.168.220.1 255.255.255.0 192.168.220.50 192.168.220.99
mode server
tls-server
push "dhcp-option DNS 192.168.220.1"

ifconfig-pool-persist ipp.txt
client-to-client

# compression?
comp-lzo

# The maximum number of concurrently connected clients we want to
# allow.
max-clients 20

# It's a good idea to reduce the OpenVPN daemon's privileges after
# initialization.
user nobody
group nobody

# Put openvpn in a jail.
chroot /var/media/ftp/FLASH-DISK-01/addons/openvpn

# The persist options will try to avoid accessing certain resources on
# restart that may no longer be accessible because of the privilege
# downgrade.
persist-key
persist-tun

# where to log
log-append /var/media/ftp/FLASH-DISK-01/addons/openvpn/log/openvpn.log

# verbose level for debugging
;verb 4

# make sure the connection is kept alive
keepalive 10 120

For bridged mode it is essential that OpenVPN uses a TAP device and not the TUN device mode (see here for the reason). We use UDP as the transport protocol and enable compression. Also we want that OpenVPN drops its privileges after the initialization and chroot into a jail to make it a little bit more secure. As the subnet for clients 192.168.220.0/24 is used. That is the same as my internal network uses. OpenVPN is allowed to use addresses ranging from 192.168.220.50 to 192.168.220.99. You have to make sure that the FRITZ!Box (or any other DHCP server in your network) doesn’t serve addresses from that range. Of course you could change some of the settings to your needs, but then you have to make sure they match the configuration of the client.

Next we create the client configuration, which looks as follow:

# Specify that we are a client and that we will be pulling certain
# config file directives from the server.
client

# The hostname/IP and port of the server.
remote xtestx.dyndns.org 1194

proto udp
dev tap

pull

mssfix
tun-mtu 1500

# SSL/TLS parms.
tls-client
ca keys/ca.crt
cert keys/client.crt
key keys/client.key

ns-cert-type server

# Keep trying indefinitely to resolve the host name of the OpenVPN
# server. Very useful on machines which are not permanently connected
# to the Internet such as laptops.
resolv-retry infinite

# Don't enable this; It must be disabled for iTunes to find the iTunes
# server and for AFP broadcast in general.
#nobind

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# Enable compression on the VPN link.
comp-lzo

# debug level
;verb 4

mute-replay-warnings
mute 20

You have to change the remote hostname to your needs. You may also add the full path to the certificates and keys depending on your client OpenVPN installation.

Next we pack all files up for the server and the client respectively. The server needs the following one:

server.conf
keys/ca.crt
keys/crl.pem
keys/dh1024.pem
keys/server.crt
keys/server.key

The client needs this one:

client.conf
keys/ca.crt
keys/client.crt
keys/client.key
keys/server.crt

Customizing the FRITZ!Box

Connect to your FRITZ!Box and copy all the server files to the usbstick. I created a directory openvpn under the /var/media/ftp/FLASH-DISK-01/addons path. Next we need the OpenVPN binary for the FRITZ!Box. You can get it here. Unpack the file and copy the openvpn binary to /var/media/ftp/FLASH-DISK-01/addons/bin on the FRITZ!Box. Make sure the file mode has the executable bit set for the user. All files are now on the right places, so we can adjust our start script. Add the following code to the startup.sh file.

# Add a nobody user
echo 'nobody:x:65534:65534:nobody:/:/bin/false' >> /var/tmp/passwd

# Add some groups
echo 'root:x:0:' > /var/tmp/group
echo 'nobody:x:65534:' >> /var/tmp/group

# Create a tap device for openvpn
mknod /var/tmp/tap0 c 10 200

# Start openvpn
${BASE}/openvpn/bin/openvpn --config ${BASE}/openvpn/server.conf --daemon

As you see, we add a new nobody user to the Linux system. Then the device node for the TAP device is created and at the end the OpenVPN server is started. As we using the bridged setup, we have to add the new device to a bridge. Fortunately we haven’t to create one, cause the FRITZ!Box itself is working in bridged mode. You can confirm this by executing:

brctl show lan

To let the system automatically add our TAP device to the lan bridge, we change the internal FRITZ!Box configuration. Edit the /var/flush/ar7.cfg file with nvi and search for the string brinterfaces. There should be one section with the name lan. Simply add the new tap0 interface to the interfaces value. The section should then look like this:

brinterfaces {
     name = "lan";
     dhcp = no;
     ipaddr = 192.168.220.1;
     netmask = 255.255.255.0;
     dstipaddr = 0.0.0.0;
     interfaces = "eth0", "ath0", "tap0", "wdsup1", "wdsdw1",
                  "wdsdw2", "wdsdw3", "wdsdw4";
     dhcpenabled = yes;
     dhcpstart = 192.168.220.100;
     dhcpend = 192.168.220.200;
}

Now, as soon the tap0 interface is created it will be added to the bridge. The last important point in the server setup is to change the internal firewall to allow connections to port 1194 from the outside. Search for forwardrules in the ar7.cfg file and add this new rule:

forwardrules =
               "tcp 0.0.0.0:7777 0.0.0.0:22 0 # SSH-Server",
               "udp 0.0.0.0:1194 0.0.0.0:1194 0 # VPN-Server";

Thats all for the server. A reboot of the FRITZ!Box should start the new OpenVPN server. If you have trouble you should manually start the OpenVPN server and increase the debugging level, as shown in the above configuration with the keyword verb.

Setting up the client

On the client side we need the files we packed above. On Gentoo the OpenVPN configuration is located at /etc/openvpn. Copy the configuration, the certificates and the key file to that place. The OpenVPN start script of Gentoo looks for the configuration file, based on the start script name. So we have to create a link like this:

cd /etc/openvpn
ln -s client.conf openvpn.conf

By the way, this lets you configure more than one OpenVPN connection at the time. Just create a link in /etc/init.d with the new configuration name and link it to the openvpn start script.

To make a first attempt to start the OpenVPN connection type

/etc/init.d/openvpn start

If all goes well you should have a new device tap0 when you execute ifconfig. Also there should be a route set, which point to the tap0 device when the 192.168.220.0/24 subnet is the target. Of course now you should be able to connect to any host in your home network by the IP. I didn’t experiment enough with the pushing of the name server from the OpenVPN server, instead I just added the FRITZ!Box as an additionally name server to my /etc/resolv.conf. So here is room for further experiments.

To let the OpenVPN client start at boot time add it to the default runlevel by executing:

rc-update add openvpn default

Also note that with the above configuration the client always try to reconnect to the server, even if the FRITZ!Box is rebooted, which is a nice feature.

Conclusion

This setup allows you to connect to your home network in a very secure way without loosing any functionality. You are able to browse network shares on the local network or using services like DAAP without any further interaction.  The public key infrastructure make this setup a candidate for small business installations. If an employee leave the company his certificate is simply revoked without affecting the access of other employees.

http://wwww.cswpro.de

FRITZ!Box tuning part 1: Enable remote access over ssh

IT, Root, , , , , ,

Recently I changed my Internet service provider to Kabel Deutschland which offers some really good bandwidth for a reasonable price. You get 32 MBit in the download direction and 2 Mbit in the upload direction. Additionally to this you can order a FRITZ!Box 7270 which allows you to use VoIP for the phone part. As I always try to maximize the usage of new hardware I started to explore what is possible with this combination. In this post I will explain how you get access to your FRITZ!Box using ssh. Following this post, some articles about how you can turn the FRITZ!Box into a OpenVPN server and how you can use the VoIP access point remotely from any computer having a VoIP software installed, will be done. As I said the hardware used is a FRITZ!Box Fon WLAN 7270 with the firmware 54/74.04.80 from 2009/12/15 which is an official one from AVM. Other firmware versions may work also, but I haven’t tested that. The following topics are all for advanced user. So if you aren’t in touch with Linux or start asking what the hell is vi and how get I out of it, stop reading now. All the information in this and the following posts are based on several websites I found in the Internet. Mainly this are some forum entries at http://www.ip-phone-forum.de, the series about the FRITZ!Box at http://www.tecchannel.de, the posts on http://www.teamarbyte.de, the blog at http://www.realriot.de and this article at http://www.cswpro.de. So thanks to all the people for sharing this kind of information. Before we start some words of caution: It’s easily possible to render the FRITZ!Box unusable. So there is no warranty of any kind if you do some of the things mentioned in this blog. Also I’m not responsible for anything happen to your FRITZ!Box or the Internet connection. After all making a backup of your current configuration might be a good idea.

Preparing the FRITZ!Box

First of all you should register an account at http://www.dyndns.com or any other service for dynamic IP resolution. You can then add this information to the “DynamicDNS” tab of the Internet settings in the FRITZ!Box web frontend. This will allow you to connect to your FRITZ!Box without knowing the IP after a reconnect. Lets use us xtestx.dyndns.org in the following examples. Next you need telnet access to the FRITZ!Box to make the initial configuration for the ssh server. Enabling telnet is as simple as calling #96*7* with a local connected phone. To disable the telnet daemon later you call #96*8*. Now you need a usbstick where all the software will be installed on and which have to be connected to the FRITZ!Box all the time. In principle the size doesn’t matter, around 5 MBytes free space should be enough. Time to connect to the FRITZ!Box for the first time. A simple telnet fritz.box should do it.

Installation and configuration of the ssh server

For the ssh server software dropbear is used. You can get a prepared version for the FRITZ!Box from the spblinux server.

cd /var/tmp
wget http://www.spblinux.de/fbox.new/cfg_dropbear
chmod u+x cfg_dropbear

After downloading, the server has to be installed on the usbstick by executing

./cfg_dropbear usb_install

In my case the software is installed into /var/media/ftp/FLASH-DISK-01/addons. Now we will create a host key which will be reused even after a reboot of the FRITZ!Box.

cd /var/media/ftp/FLASH-DISK-01/addons
dropbear/bin/dropbearkey -t rsa -f dropbear/etc/sshd_rsa_host_key

The FRITZ!Box has initial no root password entry. We have to create one and save the password hash for later usage.

passwd
cat /etc/passwd

You have to note the part between root: and the next colon.

Putting all together

The initial starting point for all modifications on the FRITZ!Box is a file called /var/flash/debug.cfg. Its executed on every boot after all the other services are started. We will use it only to start a script which is located on the usbstick. This makes sure that even after a firmware upgrade our changes are not lost. The content looks like the following:

# execute the start script which is on the usb stick
/var/media/ftp/FLASH-DISK-01/addons/startup.sh

Please note that you have to use the nvi to edit files on the flash device from the FRITZ!Box, cause all files there are marked as non regular. The startup.sh will do all the work necessary for preparing and starting the ssh server. The content is:

#!/bin/sh
# whats the base usb directory
BASE=/var/media/ftp/FLASH-DISK-01/addons

# change to a temporary directory
cd /var/tmp

# install and start dropbear with our host key
${BASE}/cfg_dropbear usb_install
/bin/dropbear -E -r ${BASE}/dropbear/etc/sshd_rsa_host_key

# set passwords
echo 'root:XXXXXX:0:0:root:/var/tmp/:/bin/sh' > /var/tmp/passwd
echo 'ftpuser:any:1000:0:ftp user:/var/media/ftp:/bin/sh' >> /var/tmp/passwd

# add fritz box itself in resolv.conf to resolv dhcp attached machines in your network
echo "nameserver 192.168.220.1" >> /var/tmp/resolv.conf

You have to replace XXXXXX by the password hash you created above. In my case the network is in the 192.168.220.0/24 subnet and the FRITZ!Box has the IP 192.168.220.1. You have to adjust the name server entry to your environment. After a reboot which could be initiated with reboot you should be able to access your FRITZ!Box over ssh.

To allow connections from the outside of your home you need to change the forward rules of the internal FRITZ!Box firewall. Unfortunately you can’t add this rule using the web frontend cause it isn’t allowed to add rules which targeting the FRITZ!Box itself. Most of the settings for the FRITZ!Box configuration are located in a file called /var/flash/ar7.cfg. Use nvi to edit it and search for the string forwardrules. If this string is missing you could temporary create a rule in the web frontend, which will you later remove again. You have to change the line so that it looks like this:

forwardrules =
               "tcp 0.0.0.0:7777 0.0.0.0:22 0 # SSH-Server";

Here the connection port is 7777, but of course could you use any valid port number. You could also add more rules by separating them with a comma. To make the configuration change happen the execution of ar7cfgchanged is sufficient.

Conclusion

With this setup its possible to connect to the FRITZ!Box with the very secure ssh protocol from inside of your home environment and from the outside. This makes it easily possible to change parameters without manually starting the telnet daemon which is in addition very insecure. Don’t forget to remove any temporary rules from the ar7.cfg file and to disable the telnet daemon with the procedure explained above. Stay tuned for the next post about going one step further and making the FRITZ!Box an OpenVPN connection point for your internal network.

Update

There is a new article about installing ssh on the FRITZ!Box. If you are interested have a look at this post.