SSH allows secure connections from one host to another. All traffic is encrypted. Authentication is usually by means of a key pair, where the private key resides on your local machine, and the public key is imported to the remote system. SSH keys have become particularly important for cloud computing, where users need to access cloud servers over a potentially hostile Internet.
Sometimes, the requirement is to access one system via another. You “hop” through the first system to reach the second. The following article shows how to do that, in a secure way, without having to place a private SSH key onto the middle system. Continue reading →
Iptables is the name of the firewall built into the Linux kernel. It is also the tool used for firewall configuration. This post explains how to use iptables with a range of IP addresses and/or ports. It could be used, for example, to allow SSH traffic from a number of systems. Or to open up a range of ports with a single firewall rule.
The Linux firewall (part of the Netfilter project) is important on Internet facing systems, “edge” servers and “jump” boxes. Particularly when they do not sit behind another protective network element such as a load balancer or discrete firewall. For example, standaline cloud instances that are not part of a protected VPC infrastructure. Continue reading →
The Linux packet filter provides an easy way to protect against unwanted network intrusions. Often referred to simply as “iptables“, it is a basic firewall built into the Linux kernel. Iptables is most useful, perhaps, on those servers most susceptible to attack, such as LAMP systems, content management servers and blogging platforms, especially where they are Internet facing.
Ipset is a fairly recent addition to Linux, having been introduced into kernel version 2.6.32. This means it is supported in Debian 7 and 8, as well as Red Hat 6 onwards. In short, ipset allows a large number of IP addresses to be blocked in an efficient way, as demonstrated below. Continue reading →
Here is a quick fix that might help users experiencing the “no devices available” problem when using xsane, the Linux scanning tool.
In this case, the device was an HP 3070 B611, a combined printer and scanner. The OS (Fedora 20) was able to see the device as a printer and print okay, but the scanner part did not work. Xsane just popped a small window saying unable to find device.
The fix was a change in the CUPS configuration, and it may therefore work with other versions of Linux.
Note: (19th June 2016) This article receives an unexpectedly large number of hits. If you have come here expecting something else, for example information about network scanners like nmap or Wireshark, please leave a comment to that affect and I will adjust the keyword settings. This article is about document scanners, not software to snoop your LAN.
This article was rewritten and updated on 9th April 2017.
BT is a popular Internet service provider in the UK. BT subscribers receive a free router called the “BT Home Hub“. A new model of Home Hub is launched every few years, and as BT never takes the old ones back, many people have an old Hub tucked away somewhere, gathering dust.
This post explains how to convert an old BT Home Hub 5.0 or Home Hub 4.0 into a second wireless access point (“AP”) on your network, strengthening and extending the wireless signal around your home or office. Although the details are for those routers, the basic procedure works for other BT and perhaps non-BT routers. In particular, notes have been included for the BT Home Hub 3.0 and the now ancient Home Hub 1.0 – these are indented and written in italics. Many users have also had success in reusing Home Hub models 2.0 and 6.0 (BT’s latest router, also known as the Smart Hub). Continue reading →
This article explains why the BT Home Hub routers appears unable to access SSL/TLS (https) websites on your internal home network. It may interest users in the UK, where the Home Hub is a popular router/ADSL modem.
Hosting your own website(s) at home is pretty easy these days. You have a small server running Apache, and configure your router to forward port 80 to it. For SSL sites, you forward port 443. That’s about it. Continue reading →
In need of some network storage in the home ? Well, you could go off and buy a proper NAS unit, offering RAID, several Tb of storage, fast access speeds and so on. On the other hand, you might have something lying round the house that will do. It won’t be as good as a proper NAS, but it might just be good enough. Continue reading →
This post may be of interest to UK users who own both a BT Home Hub 3 router and a WD TV Live media streamer. Both are Linux based systems, but getting one to work with the other can be a bit of a challenge.
The USB port on the back of the Home Hub 3 can be used to share storage over the network. Plug in a disk or memory stick, and it is automatically shared out as a windows share. Using a large capacity memory stick offers the possibility of NAS like, always-on access to your media files from any connected device. Low power consumption too. This post explains how access the USB connected drive from the WD TV Live. Continue reading →
This post explains how to use tcpdump on Linux to detect and investigate DNS requests. One of our Red Hat client systems was making requests to an old DNS server, even though it had been adjusted, through a change to/etc/resolv.conf, to point to a new one.
Requests to the old server were identified as follows.
[root@pluto root]# tcpdump -i eth0 -l -vvv dst host 192.168.1.103 and dst port 53
(...waited 15 mins or so...)
tcpdump: listening on eth0
16:38:18.019703 pluto.mycompany.com.41783 > olddnsbox.mycompany.com: [bad udp cksum 48f5!] 21331+ A? somebox.mycompany.com. (42) (DF) (ttl 64, id 48623, len 70)
16:38:18.033461 pluto.mycompany.com.41783 > olddnsbox.mycompany.com: [bad udp cksum 5919!] 12099+ A? somebox.mycompany.com. (42) (DF) (ttl 64, id 48625, len 70)
192.168.1.103 is the ip address of the old DNS server. Tcpdump shows network packets sent to the standard DNS port (53) at that IP address. Requests were few so I had to wait 15 or 20 minutes to capture the above.
The client was last rebooted a year ago, many months before /etc/resolv.conf was last edited. Tcpdump shows that some application is still querying the old server. The fix was to reboot the client, restarting the erroneous application and stopping the outdated requests.