Meeting: The RISC OS Firewall

Reports by Peter Richmond, Ian Macfarlane and Kevin Corney

Firewalling RISC OS

By Peter Richmond

Steve Potts was presenting the October meeting, and in order to more easily understand the way network traffic travels between client and server, had arranged for me to bring my video/data projector to enable him to show the two computer screens side by side. One screen was showing the client and the other was showing the server. Steve had cunningly made backdrops for these two computer screens with the words ‘client’ and ‘server’ on them just to help the audience out.

Steve was using two A9home computers to show the networking firewall in operation, and mentioned that the firewall configuration tool he was using was from the latest RISC OS Six build, which he had copied over to run on the A9homes as they cannot currently run a full version of RISC OS Six.

Firstly, Steve enquired how many people had some sort of home network – about half of the attendees did, so Steve carried on, assuming some sort of baseline for understanding the terminology of network messages. Steve then mentioned that although there was a newer IP address standard (IPv6) slowly being adopted in the wider computing world, that he would be staying with the more widely used version IPv4, because RISC OS and many consumer networking devices don’t yet support IPv6 and many people are unfamiliar with its very different notation.

Different protocols

In TCP/IP networking there are three main types of protocol, TCP, UDP and ICMP. Steve pointed this out because firewalls treat them all differently when processing rules.

With the use of a simple diagram, Steve illustrated that TCP/IP servers use ‘well-known’ port numbers for common services so that clients know how to connect. Steve’s example showed that email (POP3) servers use TCP port 110, web servers use TCP port 80. The same diagram showed that clients usually use dynamic outbound ports, and so POP3 and HTTP clients will be connected via the next free port in the range allowed for such use, for example TCP 1024, 1025 respectively in Steve’s example. The diagram also illustrated that, although both TCP and UDP make use of port numbers, they are separate ranges, so TCP 80 is not the same as UDP 80 for example.

Typical network connections between client and server

After the introductory slides, Steve moved to practical demonstrations. First he tested the link between the two machines using a task window and the Ping tool. Additionally, WebJames was used as the Web Server. Igor was used as a remote command console on the server and Steve’s own VNCServer front end was also running the RISC OS VNCServer module. NetSurf, Nettle (Telnet), and Avalanche were used respectively on the client to connect to those services.

Configuration of the firewall on RISC OS Six is much more easily understandable than on previous versions of RISC OS (it was first introduced with RISC OS 4.29). This is mainly because there is now a Configuration Plugin with standard settings and menu options, rather than the previous ‘editing a text file’ approach.

Rules of entry

The way the Firewall works is that all traffic is denied when the firewall is active, if no rules are applied. The plugin provides a comprehensive list of standard rules, which can be used as-is or adapted as required. Steve suggested that one approach to building rules was to use the ‘Allow all outbound’ rule, and then look at setting up some ‘inbound’ rules.

Firewall rules are set in Configure, using the firewall dialogue to set inbound and outbound restrictions

The rule editing window gives hints about some inappropriate combinations of settings, and reminds you of standard subnet masks which are in common use. Interactive help is available on all of these menus and values, to further assist in constructing rules.

Having demonstrated creation of simple rules, Steve then went on to remind us that it is easy to have firewalls block traffic, but that you can make some complicated, and if you’re not careful, contradictory rules.

Next came actual examples of the firewall blocking and allowing particular traffic into and out of the computers. To demonstrate web browsing working, Steve set the ‘allow all outbound’ rule on the client computer; he then only needed to allow the web server’s response to arrive by opening the firewall to traffic originating from port 80 (the web server).

To help people get started using the firewall, the configuration program supplied in RISC OS Six provides a Default button, that allows things to happen with regard to DNS, web browsing and local traffic. Additions to this standard list may be POP3 for email.

Although a router gives a firewall, adding the RISC OS firewall will often help further protect your computer. Having at least one of the two is important: as an example, Steve suggested that if you are using Samba (the Windows disc sharing protocol), you’d need to have a firewall of some sort because otherwise people could look at your shared drive from the internet.

Steve then pointed out (and demonstrated) that the order in which the rules are applied to the firewall is important, and that these rules can be moved up and down the list with regard to their order of being carried out. Steve also pointed out that there may be some overlap on some of these rules with regard to filtering criteria. Normally you would apply very specific rules first, followed by the more general rules. Whenever the firewall is able to match a rule against packets of data, it stops looking for other rules to match, so the most important rules must be nearer the top of the list.

Wireless security

There were then some questions about wireless interfaces, where Steve was clear that you would be more likely need to have a software firewall enabled on wireless networks, because if hackers manage to get into your wireless network, then a router firewall is useless because they would already be on the inside of that one. Some wireless encryption can apparently be hacked within around ten minutes using the right software tools.

If you have more than one network interface in your machine, the RISC OS firewall allows you to make different rules for each interface. This is probably more complex than most users need, but the facility is there if required.

The surprising point about Steve’s talk was that, apart from RISC OS Six itself, all the other programs were public domain!

At the end of the evening, everyone had a much clearer idea of the usefulness of firewalls – this being greatly aided by the dual screen method of presentation that Steve used.

Using the Firewall

By Ian Macfarlane

Steve Potts began his talk by asking how many of those present had a home network with more than one machine. There were a few members, including your writer. He explained about the network protocol standard, TCP/IP, which had two versions, IPv4 and IPv6. Steve said he would only cover aspects of IPv4 in his talk, since IPv6 was not available on RISC OS. TCP/IP allowed communication between machines and was the basis of the internet. Data was transferred in packets, which could be of three basic types: TCP, UDP and ICMP. Applications on the internet used port numbers of the correct packet type to signify that they owned the data. A computer’s firewall would only allow transfers between known port numbers. If an application is running on two computers it will use its own allocated port number to transfer the data between the machines. Each machine will have its own unique address, but use the port number associated with the type of transfer.

Network topology

Steve described a typical network. There was a server, which may have several ports, one for each application. There may be an e-mail server with a specific port number and a web server with a different port number. The software on the client, which was requesting the service from the server, would allocate the next free TCP or UDP port to make an out-going connection of the same type; this was called dynamic selection. For example if the client wanted to make a web connection it would make sure that it was talking to port 80 on the server as this is the allocated number for web service, but would use its next available port for the out-going request.

The terms ‘client’ and ‘server’ apply not to a machine, but to the process. Whichever machine is asking for data, it is acting in the role of a client for that data transmission and the machine supplying the information is acting as the server. Since there are generally many of these processes going on at the same time, a computer could be acting as a client for one data transmission and a server for another.

Steve then showed a simple firewall working on his computer, which was connected to another computer, not the internet, in order to keep it simple. He used the Ping facility to demonstrate that they were communicating with each other using the ICMP protocol, which doesn’t use ports; ICMP is used for sending error messages round the network. The TCP protocol is used for conversational data transfers and the UDP protocol for sending data one way. He went on to demonstrate how the web-server (WebJames) worked on one of the computers and then the Telnet-server (Igor); with this he was able to open a filter window on the other machine.

Breaking the connection

He had thus established applications working across a link and then demonstrated how the firewall in RISC OS could be used to prevent these data transfers. In RISC OS 4.29 the firewall could be manipulated by command lines, but there is now a front end application in RISC OS 6.20 which makes it easy to configure the rules of the firewall: Steve altered a rule to show what effect it had on the transmission, using the Ping facility. He explained why the rules for both inbound and outbound transfers in the firewall existed and was able to demonstrate these rules working. There exist predefined rules for RISC OS, with interactive help; its firewall type is known as a packet filter; it is not a full firewall. Steve said that in order to set up and test these rules, it was easiest to permit all outbound transfers and work on the rules for inbound transfers: you could more easily see what was happening; the rules sometimes can contradict each other.

The firewall can be accessed from Network configuration in RISC OS Six

Steve then examined the default rules for the RISC OS firewall. He made the point about the order that the rules occurred in the list, explaining that the first rule took precedence and so on down the list. In general, specific rules should be placed at the top of the list to be effective. In answer to a question from the floor, Steve said he was not aware that RISC OS 5 had a firewall. Another questioner asked where the firewall lived, and Steve was able to show the slot in the RISC OS boot sequence where the firewall was started up, if invoked. He also showed us the port numbers and what they were allocated for – in a file that should never be amended!

When to use it?

I asked Steve on what occasion would a RISC OS user want to alter these rules. Steve said that it would be necessary to stop certain traffic, if that traffic was becoming a problem. He didn’t think that there was much, if any, malpractice on RISC OS. He thought that the firewall was disabled by default. When Steve visits clubs and uses his computer on their networks, he does switch his firewall on. He said that in most situations the router’s firewall protected the local area network from external attacks and the computer’s firewall was not required. However Steve did make the point that it was possible for someone to be parked outside your home and hack into your network via the wireless link that many routers possess and so get behind your router’s firewall. The type of wireless key was very important. The WEP type key was not secure enough and he recommended using the latest WPA2 (Wireless Protection Access) encryption.

Peter Richmond asked about WebJames and the VNC server and Steve said that they were freely available. The Flying Pig’s website was also worth a look at. To help with the formation of the firewall rules, Steve said that there was a command available, called netstat on Windows and inetstat on RISC OS. This details what the TCP/IP stack is doing at the present time and he talked around these interesting commands. Steve felt that he was becoming too technical and so stopped his talk there.

The Firewall in Action

By Kevin Corney

The meeting opened with a presentation by Steve, who outlined some of the terminology he would be using – for example the protocols UDP, ICMP and TCP – and gave a representation of what was actually happening when clients and servers were connecting.

Before the start of the meeting Steve had set up two machines, one to act as client, and the other to act as server. He then gave an explanation and demonstration of the Firewall as it is pertinent to RISC OS Six.

The Firewall icon can be found via the Network icon in Configure, with which we are no doubt all familiar. Clicking on the Firewall icon opens up the Firewall Rules window as seen on page 2.

This window gives us options as to whether or not we wish to enable or disable the firewall, by ticking or unticking the box. The default seems to be ‘off’. You can also choose whether you wish to deal with inbound or outbound traffic. Clicking on the New button opens up another window, which enables you to further configure the Firewall, by adding new rules, including the direction (inbound or outbound), the policy (allow or deny) or the protocol.

Now I have to admit that it is at this stage that the technical side of things was getting beyond me, but I was pleased to find out that there is a drop down menu which enables you to choose a number of pre-defined rules, so all-in-all configuration was a lot easier than I had expected.

The session ended with a Q&A session. One question (my own!) was whether or not there was a similar program for the Iyonix. There is apparently not, so this leads me to ask two further questions: does anyone know if it’s possible (or even legal!) to port the firewall from the RPC, and am I better off accessing my internet banking through a firewalled RiscPC rather than an un-firewalled Iyonix?

This article doesn’t even start to do justice to Steve’s excellent presentation, so thanks to Steve for all his hard work both before and during the meeting.