In the last blog post we worked on the TCP ports on this system. From the output of the netstat program, we figured out how to convert those lines into firewall rules.
We left UDP for last, not because it falls that way alphabetically, but because, well, it’s a pain. 🙂
In TCP we had the concept of a connection – a stream of packets, initiated by a client to a server with a listening port. The “LISTEN” keyword in the netstat output makes it very easy to identify what ports are TCP servers. “ESTABLISHED” lines identify active connections between client to server.
Netstat – UDP ports
With UDP, packets still need to flow between a UDP port on one machine and a UDP port on another machine, but we lose the context clues of which end is the server. Let’s look at an example.
NTP is the Network Time Protocol daemon used on most Linux and Unix flavors; it keeps computer clocks in sync with each other. When ntpd starts up, it listens on UDP port 123. When it talks with ntp daemons on other machines, the packets flow between port 123 on one machine to port 123 on another machine.
Unlike servers using TCP, UDP sockets no longer say LISTEN when they’re servers, so we have to think about how a UDP socket will be used:
- If other machines send queries to this UDP port, we need to write a rule in the Incoming chain.
- If this computer sends queries out from this UDP port to other machines, we need to write rules in the Outgoing chain.
- And if, like NTP, the port can be used in both ways, we need to write rules in both Incoming and Outgoing.
In creating these, we had to add a new Service, calling it ntp and using udp port 123.
Should these be ACCEPT or DROP rules? Well just like TCP, you have to decide if you want these allowed or not, and if you want to allow them, are you allowing only specific ntp servers to talk with yours, or do you allow any ntp server to talk with yours (which affects the Incoming Source and the Outgoing Destination fields).
Two last notes on ntp. First, the ntpd and named (you’ll see the program name “named” in the netstat output; the package that holds it is called BIND, the Berkeley Internet Name Daemon) programs both have an odd way of listening for incoming packets. Unlike a normal service that requests a listening socket with no restrictions, they ask for multiple listening sockets, one for each IP address assigned to the system:
Second, the Halo Portal and Daemon are primarily intended for use on (though not restricted to) Cloud Servers, which are virtual machines. It’s far more difficult to keep clocks synchronized on virtual machines than it is on physical computers. VMware has provided a very well done technical paper on the challenges and solutions; see Timekeeping in VMware Virtual Machines . The coverage of the concepts and challenges is well worth reading even if you’re not using VMware as your virtual machine layer.
dhclient, pump, and other DHCP clients
Cloud servers and other virtual machines are rarely given dynamic addresses via DHCP – we need a fixed address so we can find them! In the rare case where you are using DHCP, it’s worth noting that the DCHP client program that requests an address listens on UDP port 68 (and possibly one more high port). The DHCP server that hands out addresses listens on UDP port 67.
If you’re using DHCP, you’ll need an Outbound rule. Create a new Service: “DHCP server (udp/67)” and choose ACCEPT, of course.
Other UDP ports
When you come across a UDP port you’ve not seen before, you need to decide 1) whether the port used in the role of server or client, and 2) whether to ALLOW it or DROP it.
First look at the port number itself. Is it listed in your services file (/etc/services or c:windowssystem32/drivers/etc/services)? If so, the associated program is likely a server waiting for incoming connections. Small numbered ports – especially ones below 1024 – are likely server ports as well.
Is the port number an unlisted one that’s larger than 1024 (or better yet, above 32768)? If so, then the associated program is likely using this port to make client queries to other servers.
If it’s still not clear, it may be necessary to do a little Google research to see how this program uses ports.
Now that you’ve figured out if it’s a server port (and needs an Incoming firewall rule) or a client port (and needs an Outgoing rule), set the rule to be an ALLOW rule if you want the traffic to pass and make it a DROP rule if you don’t want to allow that traffic. If you’re not sure, set it to DROP on a test machine and make sure you haven’t broken anything. In short, if you can’t convince yourself that this is a service you want to share with the world, DROP it.
If you want a restricted set of machines to be able to access a service, change the “Source” field from “any” to a Server Group, IP Zone, or GhostPort user, as appropriate. That’s how we opened up the ssh port to just a small group of machines with an IP Zone.