Before we enable logging you should verify that your Pi has its clock configured correctly. ser2net will add a timestamp to its log files and logging is pretty much useless if you don’t have the correct date or time.
By default it will synchronize its time by using NTP but the timezone might be incorrect. Changing the timezone is easy to do:
The ‘TRACEFILE’ line is new and at the end of the 4001:telnet… line we will add “tr=tr1 timestamp”. This will enable logging for this port and add timestamps to the log files.
You will have to restart ser2net before logging is active. The next time you connect you will see the log files in the /var/log/ser2net folder:
$ ls /var/log/ser2net
tr-4001-2013-Jul-19-09:18:26.893894
You now have a console server that saves logging information. In the next part I’ll show you how to enable wireless support and how to secure your Pi:
Wireless Access Point
Most wireless adapters also support access point mode. This is very useful since we can make our Pi broadcast a SSID and let wireless clients connect to it. This turns our Pi into a wireless console server…nice!
Plug in your wireless USB adapter and see if it’s recognized:
$ lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 0bda:8179 Realtek Semiconductor Corp.
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Keep in mind that the USB port of the Raspberry Pi has limited power and not all wireless adapters are supported. Take a look at the elinux Rpi page to see which adapters are supported.
If your USB device is recognized we still have to check if our wireless drivers are operational:
If iwconfig doesn’t give you any information you probably have an issue with drivers.
Once your wireless card is up and running we will install hostapd. This configures the wireless adapter as an access point:
$ sudo apt-get install hostapd
We’ll configure the wireless adapter to use a static IP address instead of DHCP:
$ sudo vi /etc/network/interfaces
Remove the following two lines from this file:
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
And replace them with the following lines:
iface wlan0 inet static
address 172.16.82.254
netmask 255.255.255.0
Our wlan0 interface will use static IP address 172.16.82.254 /24. Now we’ll configure hostapd to set some parameters for the access point:
$ sudo vi /etc/hostapd/hostapd.conf
ssid=Console
wpa_passphrase=mysecurepassphrase
wpa=3
You can leave most of the settings in this file alone but I will change the SSID and the WPA passphrase. The passphrase will be “mysecurepassphrase” and wpa=3 means we will support WPA and WPA2. Let’s start hostapd:
$ sudo service hostapd start
To make sure hostapd runs after rebooting the Pi we’ll add it to the startup list:
$ sudo update-rc.d hostapd enable
Your Raspberry Pi should now be broadcasting SSID “Console” but wireless clients will have to configure a static IP address. We’ll fix this by installing a DHCP server:
$ sudo apt-get install dnsmasq
At the bottom of this file you should add the following two lines:
interface=wlan0
dhcp-range=172.16.82.10,172.16.82.100,12h
This ensures that the DHCP server only runs for wireless clients and that we’ll use 172.16.82.10 – 172.16.82.100 for DHCP clients.
Restart the DHCP server:
$ sudo service dnsmasq restart
[ ok ] Restarting DNS forwarder and DHCP server: dnsmasq.
And make sure it boots at startup:
$ sudo update-rc.d dnsmasq enable
Your Raspberry Pi is now configured as an access point. Wireless clients are now able to connect to it and access the console port by telnetting to 172.16.82.254:4001.
In the final part of this tutorial we’ll take a look at some security measures. Your Pi is using a default username / password and the firewall is allowing all traffic.
Security
Even though the Pi is a little box, it’s still a fully functional Linux server. It’s best to take some security measures to protect it. I’m going to change the default username, tighten SSH security a bit and add some rules to the IPTables firewall.
Change username
First i’ll replace the default user ‘pi’ with my own username:
$ sudo adduser renemolenaar
Adding user `renemolenaar' ...
Adding new group `renemolenaar' (1002) ...
Adding new user `renemolenaar' (1001) with group `renemolenaar' ...
Creating home directory `/home/renemolenaar' ...
Copying files from `/etc/skel' ...
Don’t forget to add a password:
$ sudo passwd renemolenaar
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
And we need to add the new user to the sudoers list or you can’t run any important commands:
$ sudo vi /etc/sudoers
Change the following line:
pi ALL=(ALL) NOPASSWD: ALL
to:
renemolenaar ALL=(ALL) NOPASSWD: ALL
Now try if you are able to log into the Pi using your new username and if you can use sudo. When it’s working we’ll delete the old ‘pi’ account:
$ sudo deluser pi
Removing user `pi' ...
Warning: group `pi' has no more members.
Done.
I always like to change the default SSH port and ensure that the root user can’t login through SSH directly:
$ sudo vi /etc/ssh/sshd_config
Now change the following line:
PermitRootLogin yes
To:
PermitRootLogin no
And change the port number to something else:
Port 22
To:
Port 10050
Don’t forget to restart SSH to apply the changes you made:
$ sudo service ssh restart
This makes SSH a little bit more secure.
IPTables Firewall
Your Raspberry Pi has the IPtables firewall installed on it by default but we’ll have to add some rules ourselves. I want to make sure outside LAN users can only connect to TCP 4001 for the console port and TCP port 10050 to access SSH. The same rules will apply to wireless users with the exception that they also will request an IP address through DHCP.
Create a new file for IPTables:
$ sudo vi /etc/iptables-rules
And add the following lines to it:
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
This is useful information (although not really what the question relates to), but better to just link to the original article by Rene Molenaar, or at least cite the source:
