Port Blocking in Linux

port blockingIn the previous article, I covered the network security benefit of disabling unused services. In this article, I will cover the concept of port blocking, and how it can be done under Linux.

TCP/IP networks assign a port to each service: e.g. HTTP, Simple Mail Transfer Protocol (SMTP), Telnet, FTP, and Post Office Protocol version 3 (POP3). This port is given a number, called a port number, used to link incoming data to the correct service. For example, if a client browser is requesting to view a server’s web page, the request will be directed to port 80 on the server. If the client starts an FTP session, the request will be directed to port 21. The web service receive the request and sends the web page to the client. Each service is assigned a port number, and each port number has a TCP and UDP port. For example, port 137 is used for the NetBIOS name service and has a TCP and a UDP port, with NetBIOS over TCP usually using UDP port 137 (TCP port 137 can be used, but rarely is).

There are two types of ports used for TCP/IP networks: well-known ports and registered ports. The well-known ports are the network services that have been assigned a specific port number (as defined by /etc/services). For example, SSH is assigned port 22, and HTTP is assigned port 80. Servers listen on the network for the requests of well-known ports. Registered ports are temporary ports, usually used by clients, and that will vary each time a service is used. You can also call registered ports ephemeral ports, because they only last for a brief time.

Port Blocking: Determining Which Ports to Block

When determining which ports to block on your server, you must first determine which services you need. In most cases, you can block all ports that are not exclusively required by those services. This is a bit tricky, because in implementing port blocking, you can easily block yourself from services you need, especially services that use ephemeral ports, as explained earlier.


For example, if your server is an exclusive FTP server, you can block all TCP ports except ports 20 and 21, respectively. If your server is an exclusive HTTP server, you can block all ports except TCP port 80. In the case of the FTP server, you can block all UDP ports except port 20, since FTP requires UDP port 20 to be open. If you use the system as an HTTP server, in setting up port blocking you can block all UDP ports, since HTTP uses TCP services exclusively.

However, if you want to use your server as an HTTP client, or as an e-mail client or an e-mail client to a remote mail server, you will restrict the system by doing this. Clients require registered UDP ports for DNS, as well as registered TCP ports for establishing connections with web servers.




If you, for example, try to download an operating system update, and you have only opened UDP port 20, DNS requests will be blocked because DNS queries use port 53. Even if you open port 53, a different registered port may be assigned each time for the answer. In this situation, the best policy may be to open all TCP/UDP registered ports, or set up port blocking to block all of them, and download operating system updates from another computer.

Port Blocking in Red Hat and Other Linux Distros

To utilize port blocking for TCP/UDP services in Linux, you must disable the service that uses the specific port. You may use the GUI interfaces of firewall services offered by most of the Linux distros. In Red Hat Enterprise Linux (RHEL) 5, this is achieved by navigating to System -> Administration -> Security Level and Firewall, which opens up the firewall configuration utility. To allow a service to run, just check and enable the service and to block, uncheck the service. If you want to add any non-standard port or a custom port to be allowed by the firewall, then click on Other ports and add the protocol type (TCP or UDP) and add the port number.

If you don’t use RHEL, don’t despair. Regardless of which version of Linux you use, iptables is the Linux kernel firewall, and rules can be added or deleted at the command line. For example, to set the default chain policy to block, type this:

iptables -P INPUT DROP

Once you do this, you can complete your port blocking setup by selectively enable ports. For example, to allow all incoming SSH connections on eth0, type:

iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 22 -m state –state ESTABLISHED -j ACCEPT

You may, however, opt to use a frontend to iptables to implement port blocking. Shorewall is one such frontend, and its creators call it “iptables made easy”. If you use Ubuntu, the default firewall configuration tool is ufw (Uncomplicated Firewall), and it simplifies the process of using iptables. To enable ufw, type:

sudo ufw enable

The default parameter allows us to set the default policy. Let’s assume we want set the default policy to block all incoming traffic. We would type:

sudo ufw default deny in

Here, “deny” is the policy (the choices are allow, deny, or reject), and “in” indicates the direction in which traffic is blocked (choices are in or out). Since “in” is the direction the rule applies to by default, we could have just typed:

sudo ufw default deny

If we wanted to allow incoming traffic on port 80, we would type:

sudo ufw allow in to any port 80

There’s much more to ufw than what I present here, so I advise reading the documentation (especially the man page) for more information on port blocking. However, one important parameter for ufw that should be mentioned is –dry-run. When this command is invoked, ufw won’t modify anything, but will just show the changes.


External Links:

iptables at Wikipedia

Shorewall homepage

ufw manpage

Firewall at help.ubuntu.com

25 Most Frequently Used Linux IPTables Rules Examples

Spam Blocking in BSD with spamd: Part Three (Greylisting)

greylistingIn part one and part two of this series, I discussed the advantages of using spamd and some basic configuration steps. In this article, I will cover greylisting in more detail.

The Problem

Spammers try to use other people’s equipment to send their messages. In addition, the software they install without the legal owner’s permission needs to be lightweight in order to run undetected. Moreover, spammers do not typically consider any individual message they send to be important. From this we can conjecture that the typical spam sender is probably not set up to interpret SMTP status codes correctly, if at all.

The current standard for Internet e-mail transmission is defined in RFC 2821. Section 4.5.4 covers retry strategies, and subsection 4.5.4.1 covers sending strategies. This section specifies the following:

  1. Mail that cannon be transmitted MUST be queued and periodically retried by the sender.
  2. The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP clients can determine the reason for non-delivery.
  3. Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. The parameters to the retry algorithm MUST be configurable.


The Solution

We can use these requirements to our advantage. When a compromised machine is used to send spam, the sender application tends to try delivery only once, without checking for any results or return codes. Real SMTP implementations interpret SMTP return codes and act on them, as explained above. E-mail, like most other Internet services, are described as best-effort services, with a significant amount of design and development being put into make services such as SMTP fault tolerant. Thus, real mail servers retry if the initial attempt fails with any kind of temporary error.
This is what is so elegant about greylisting. spamd reports a temporary local problem to the client. Well-behaved senders with legitimate messages will try to resend the message later, but spammers have no interest in waiting for the chance to retry, since it will increase their cost of delivering the messages. Thus, the spammers will keep hammering spamd, and will get greylisted.


Configuring spamd for Greylisting

Setting up spamd for greylisting is fairly easy, although under FreeBSD, you need to have a file descriptor filesystem mounted on /dev/fd. You can do this by adding this line to your /etc/fstab file (fstab lists all the available static disks and disk partitions and where they are to be mounted):

fdescfs /dev/fd fdescfs rw 0 0

You also want to place the relevant lines in /etc/rc.conf or /etc/rc.conf.local; e.g.:

spamd_flags = “-v -G 2:4:864”
spamd_grey = YES

This tells spamd to enable vpopmail configuration (-v); -G sets the passtime for greylisting to 2 minutes, greyexp to 4 hours and whiteexp to 864 hours (36 days). This means that the client must wait 2 minutes before resending an e-mail to avoid getting greylisted. A client will remain on the the greylist for 4 hours after violating this standard. If the client waits 2 minutes before resending, it will get whitelisted, and remain on the whitelist for 864 hours.

Why It Might Not Work

The reason why greylisting should work is because any standards compliant SMTP client is required to retry delivery after some reasonable amount of time. But there are circumstances in which it may not work. First of all, the first e-mail message sent from any site which has not contacted you for as long as the greylister keeps its data aroun will be delayed for some random amount of time which depends mainly on the sender’s retry interval. There are some circumstances where avoiding even a minimal delay is desirable. In addition, you are bound to encounter misconfigured mail servers which either do not retry at all or retry at all or retry too quickly, perhaps stopping delivery retries after a few attempts. Finally, there are some sites which are large enough to have several outgoing SMTP servers (e.g. GMail); these sites do not work well with greylisting since they are not guaranteed to retry delivery of any given message from the same IP address as the last delivery attempt for that message. The RFCs do not state that they new delivery attempts have to come from the same IP address, so these sites can legitimately claim to comply with the RFCs.

If you need to make allowances for such situations in your setup, it is fairly easy. One approach is to define a table for a local whitelist; the list should be fed from a text file in case of reboots:

table <my_localwhite> file “/etc/mail/local_whitelist.txt”

To make sure SMTP traffic from the addresses in the table is not fed to spamd, you add a no rdr rule at the top of your redirection block:

no rdr proto tcp from <my_localwhite> to $mailservers port smtp

Once you have added these changes to your rule set, enter the addresses you need to protect from redirection into the local_whitelist.txt file, then reload your rule set using pfctl -f.

External Links:

Greylisting on Wikipedia

RFC 2821 – the RFC with the specifications for Simple Mail Transfer Protocol (SMTP).

Greylisting.org – a site devoted to articles and tools related to greylisting.

Greylisting: The Next Step in the Spam Control War – Greylisting site created by Evan Harris, the guy who originally came up with the idea of greylisting. Also contains whitepapers and a fully functional example of greylisting called relaydelay.

 

 

© 2013 David Zientara. All rights reserved. Privacy Policy