Mike Levin SEO

Future-proof your technology-skills with Linux, Python, vim & git... and me!

An Introduction to How Internet Security Works

by Mike Levin SEO & Datamaster, 08/04/2010

But wait! Now you’re open to being hacked through SSH you say? Not quite. Remember the virtual local area network (VLAN) that QEMU establishes for just itself and the host machine? Well, those VLAN addresses don’t exist on the actual LAN that your host PC or Mac is sitting on, and is therefore unreachable from other computers on your local network or the Internet at large. Naturally, this is a double-edged sword both protecting us, and preventing our pendrive Linux from being used like a real server.

How can we prove this? If you’re on a PC, first thing you need SSH software, and by far the most popular and easiest it get is PuTTY. Just Google it. It will be the first result, at http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html The files are digitally signed, so it is generally safe to download the .exe. There is no install. This makes it easy to carry around on your USB drive with your virtual machine, and you will have it at your disposal on any PC you sit down at, without having to have admin rights to install software.

Once you’re satisfied with PuTTY’s authenticity, run it (it’s probably fine, but they’ve got a digital signature verification process). On the setup screen, put your VLAN address in the Host Name or IP field. Put 22 in the port field (the “port” that SSH works on). Make sure SSH is chosen as your Connection Type. Those are the only three settings you need to worry about right now. Click connect, and see if you can connect. PuTTY QEMU SSH Port 22

You won’t be able to. PuTTY will time out on you with the message “Network error: No route to host”, and you will have to close out of the blank window. PuTTY Timed Out Network error no route to host

We are going to fix this, but first some network security talk. You might ask why I’m bothering with the security theory talk for QEMU peculiarities when real hardware is our goal. All these principles will still apply–the only difference being in the user interface used to set up network address translations (NAT), sometimes incorrectly described as poking a hole in the firewall.

TCP/IP is the networking protocol of the Internet, and most private corporate and home networks that connect to it. The IP part of TCP/IP stands for the address system where you see that 4-part number in which each part only goes up to 255. Each four-part address (octet) stands for a particular computer on the Internet, to which network data can be routed, but not all addresses are valid. Certain ranges have been set aside so that anybody can use them without the confusion or fear that they can be reached by the Internet without a special effort being taken on the part of the person setting up the network. These non-Internet-accessible IPs are known as Private, and are frequently used in LANs. If you see any address beginning with 10. or 192.168 you know you’ve got a private IP. QEMU’s virtual machine IP is one of those, and therefore cannot be reached by the Internet by default.

So, what is the Internet anyway? It’s one big TCP/IP network using public IPs onto which lots of little networks can hang off. These little networks can either consist of public addresses, in which case each computer is directly on the Internet, or they can consist of private addresses, in which case only one machine (the router) needs a public address. Machines on one private network CANNOT send messages to machines on another private network without the message being routed out through the gateways, during which time they temporarily take on the public IP addresses of the routers. Hence, these devices are called routers, and the occasional setting you have to fill in is called the “default gateway”. Default Gateway

The private networks are called local area networks, or LANs. LANs connects to the Internet is through routers. Your WiFi box at home is a router. It has a public IP. The individual devices connecting through you home WiFi have private IPs unreachable through the Internet, but that makes it all the more secure because hackers can’t attack your home machines directly.

Simple, right?

It would sound like your home machines would have a difficult time getting out to the Internet to let you do simple tasks like surfing the net or checking email. But private IPs on your home LAN do not pose a problem for out-bound requests (like loading a webpage), because private IPs can still make requests to public IPs, so long as the LAN has a gateway. Therefore, out-bound requests are routed out by the router which then routes the return-message back to the correct private IP. The outside machine doesn’t need to know anything about your private IP. All it knows is the one public IP that belongs to your router, which was slapped on by your router and carried out on the request and stripped off on the way back. Yep, routers do a heck of a lot of book keeping.

But what about in-bound messages that were not initiated by a request? Well, if you’re not intentionally running a server on your LAN that is actually SUPPOSED to be answering such messages, then that’s called a hacking attempt. Therefore, the defensive default router setups of deny-first is a good thing. In fact, it’s not really even “deny-first” because the request makes no sense at all to your router. It’s more like “I have no idea what you mean, so I won’t route you”, making it even more secure. You’d be amazed at all the hacker probing against IP ranges that belong to Cable modems. The best defense is having absolutely no response sent back to such probing, so you’re profile comes up empty. This is called exposing very little “surface area”, and is a characteristic of a “hardened system”. In other words, when a hacker scans the public IP assigned to your home router, nothing answers.

Aside from the recent OpenSSH installation, your virtual machine is in the most secure state right now that it will ever be in. Because we built a bare-bones minimal system with debootstrap, and only added a DHCP network config, there is literally only one service running and listening on any port. Even that was our decision, since we wanted the DHCP service to get an IP. Without that, our machine is totally invisible even on its own virtual LAN–very secure indeed. But after adding DHCP networking, we can see what our port profile looks like by typing the command:

netstat -tulpn netstat -tulpn

As you can see (with a little squinting), there is only one entry, and it says that the dhcpclient service is running with the udp protocol on port 68. This is ALL that was listening on any ports, and presents very little surface area for hacking. In fact, it was really only listening at boot-up time, and is now inactive. Even then, it was listening on your virtual LAN for the DHCP server provided internally by QEMU (and not your physical LAN’s DHCP server).

At any rate, here’s why this dhcpclient service was even necessary in the first place. When your machine first connects to a network, it doesn’t have an IP yet, so it broadcasts a request to the entire local area network (to no particular machine in particular). That’s why the user datagram protocol (UDP) is being used, rather than the transmission control protocol (the TCP in TCP/IP). A DHCP server hears the UDP broadcast, and replies with another UDP broadcast carrying as its message the IP that the requesting machine should start using, so it can switch from UDP to TCP/IP and formally get onto the network. All this requires no IP addresses initially, because UDP broadcasts its communication to every machine on the local network. Sensibly, UDP generally only works over a local area network so as to not flood the entire Internet with needless broadcasts. Remember, UDP-style broadcast communication is very different from TCP/IP-style point-to-point communications.

So that dhcpclient service is the first bit of surface area we expose to the VLAN after the debootstrap process–but only during a few moments during start-up. But now that we also installed the OpenSSH SSH Server at this point, and here’s how it looks after that: OpenSSH SSH Server

As you can see, there is now surface area exposed because a service called sshd is listening on port 22 using both the tcp and tcp6 protocols. Sounds scary? Not yet, because remember, the VLAN is still totally cut off from the Internet. Our next step is going to be to fix that…

…but not before we create a new user, add it to the sudoers group, and remove/disable the root password. Security is not always about what’s listening on what ports, but also once that’s discovered by a hacker, to confound their attempts to guess your logins. Having to guess a username and password is better than having to guess only the password.