Netcfg Firewall administration

Firewall rules are divided into three categories:

• the input rules determine what happens to network packets originating from remote systems and targeted at this system.
• The output rules determine what happens to network packets originating at this system, targeted at other systems.
• The forwarding rules determine the disposition of network packets passing through this system (both originating and destined for remote systems.)

In most cases, the rules need to be symmetrical -- for instance, allowing request packets to go out to a remote web server only makes sense if the responses from that server are allowed to return.

The exception to this rule are the "SYN" packets which are used to initiate a new connection. For instance, even though packets using the http protocol are allowed in so that you can receive data from a remote web site, http packets requesting a new connection might be blocked, to prevent outsiders from connecting to internal web servers.

With ipchains and netfilter, additional user-defined rulesets may be created and referenced (or "chained") from other rulesets. Chains allow very complex firewalls to be created.

Each rule set consists of a list of rules which are compared to network packets and tested to see if they apply. The first rule to match the packet being tested determines what happens to that packet. The available dispositions are:

• ACCEPT -- packet is accepted.
• REJECT -- packet is rejected and returned to sender.
• DENY -- packet is rejected and quietly dropped.
• MASQ -- masquerade so that packet looks like it originated locally.
• REDIRECT -- redirect packet to a local socket, even if addressed to another host.
• chain -- one of the user-defined rulesets are used to test the packet.

If no disposition is specified, the packet is logged but no action is taken; more rules will be tested to see what is to become of the packet.

In general, incoming connection requests should be severely restricted unless this system is a server, and even then only those ports which are actually needed should be enabled.

The output rules are usually set to be permissive unless you don't trust some of your users.

The forwarding rules should be set to deny all fowarding unless this system is going to be used as a router and/or a firewall.

Normally, only one or two criteria are used in any given rule. For example a rule might be used to deny all access to the system's smtp port, or perhaps limit access to the ftp port to certain IP addresses.

13 -- Daytime

• incoming connection requests should be enabled on servers, and only to those IP addresses within the organization.
• forwarded connection requests should be disabled unless there is a reason for systems to be asking the time across a firewall.

20,21 -- Ftp

FTP is a little tricky because it uses two ports. In a typical transaction, the client application initiates a connection over port 21 (ftp) and the server initiates the return connection over port 20 (ftp-data).

Allowing an outside system (the server) to initiate a connection is somewhat risky. One solution is to install ftp proxy software in your firewall system. Another is to restrict ftp access to "passive mode" in which the client system initiates both connections. Fortunately, most ftp software will work this way.

For more information, see the LINUX Network Administrators's Guide by Olaf Kirch & Terry Dawson, published by O'Reilly books.

• input -- incoming connections should be enabled only for ftp servers, disabled for all other systems.
• output -- ok to leave enabled.
• forwarding -- should be set to allow systems inside the organization to contact outside systems, but not to allow outside systems to contact inside systems except for those which are designated as public ftp servers.

22 -- SSH

• input -- should be enabled if you want to allow remote logins to your system.
• output -- ok to leave enabled.
• forwarding -- should be set to allow systems inside the organization to contact outside systems, but not to allow outside systems to contact inside systems except for those which are designated as public servers.

23 -- Telnet

• input -- should be enabled if you want to allow remote logins to your system and ssh is not available.
• output -- ok to leave enabled.
• forwarding -- should be set to allow systems inside the organization to contact outside systems, but not to allow outside systems to contact inside systems except for those which are designated as public servers.

25 -- SMTP

A misconfigured smtp server can allow spammers to relay spam through your system, so enable this with care. Make sure your mail server software is configured to disallow forwarding.

• input -- should be enabled for email servers and for workstations when email is delivered directly. If you use POP or IMAP protocols to read your email, smtp should be disabled. If your system is not behind a firewall, some care should be taken when enabling smtp.
• output -- if there might be spammers on your system, outgoing connections should be restricted to only the designated mail gateway within your organization.
• forwarding -- depends on your system, but in general, only connections to your designated mail host should be permitted.

67,68 -- Bootp

69 -- TFTP

70 -- Gopher

79 -- Finger

Finger was written in more trusting times, but now it serves as a way for crackers to get information about your system's users. In addition, a bug in the finger daemon was exploited by the Morris Worm to gain access to systems.

Still, some special-purpose finger daemons exist. For instance, there are servers which will return a PGP key id if you finger something like "keyid@keyserver"

• input -- incoming connection requests should be disabled unless your system is behind a firewall that will keep non-trusted systems out or you're running some sort of specialized finger daemon.
• output -- it's generally ok to allow outgoing finger requests, but you'll probably find that not many systems will answer in this day and age.
• forwarding -- outgoing finger requests should be permitted. Incoming finger requests should usually be disallowed.

80 -- HTTP

• input -- incoming connection requests should be disabled unless your system is running a web server. Public servers should allow requests from just about anybody. Internal servers should only allow requests from internal clients, or better yet, be behind a firewall.
• output -- you should allow outgoing http requests.
• forwarding -- outgoing http requests should be permitted. Incoming http requests should be restricted to those addressed to public servers (if any).

109 -- Pop2

• input -- incoming connection requests should be disabled unless your system is a pop2 server.
• output -- it's generally ok to allow outgoing pop2 requests.
• forwarding -- outgoing pop2 requests should be permitted. Incoming pop2 requests should only be allowed if you're running a public pop2 server within your network. Only requests specifically directed to that server should be allowed.

110 -- Pop3

• input -- incoming connection requests should be disabled unless your system is a pop3 server.
• output -- it's generally ok to allow outgoing pop3 requests.
• forwarding -- outgoing pop3 requests should be permitted. Incoming pop3 requests should only be allowed if you're running a public pop2 server within your network. Only requests specifically directed to that server should be allowed.

111 -- SunRPC

• input -- incoming connection requests should be disabled unless your system is running any rpc services.
• output -- it's generally ok to allow outgoing rpc requests.
• forwarding -- outgoing rpc requests should be permitted. Incoming rpc requests should only be allowed if you're running a public rpc server within your network. Only requests specifically directed to that server should be allowed.

119 -- NNTP

• input -- incoming connection requests should be disabled unless your system is a news server.
• output -- you should enable outgoing nntp requests so that your users can read usenet news.
• forwarding -- outgoing nntp requests should be permitted. Incoming nntp requests should only be allowed if you're running a public news server within your network. Only requests specifically directed to that server should be allowed.

123 -- NTP

• input -- incoming connection requests should be disabled unless your system is an ntp server.
• output -- it's generally ok to allow outgoing ntp requests.
• forwarding -- outgoing ntp requests should be permitted. Incoming ntp requests should only be allowed if you're running a public time server within your network. Only requests specifically directed to that server should be allowed.

110 -- IMAP

• input -- incoming connection requests should be disabled unless your system is a imap server.
• output -- you should allow outgoing imap connection requests so that users can read their email.
• forwarding -- outgoing imap requests should be permitted. Incoming imap requests should only be allowed if you're running a public mail server within your network. Only requests specifically directed to that server should be allowed.

194 -- irc

• input -- incoming connection requests should be disabled unless your system is an irc server.
• output -- it's generally ok to allow outgoing irc requests.
• forwarding -- outgoing irc requests should be permitted. Incoming irc requests should only be allowed if you're running a public irc server within your network. Only requests specifically directed to that server should be allowed.

443 -- https

512 -- exec

• input -- incoming connection requests should be disabled except to trusted systems on your network.
• output -- it's generally ok to allow outgoing exec requests.
• forwarding -- it's probably safest to disable this completely.

513/tcp -- login

513/udp -- who

514/tcp -- shell

514/udp -- Syslog

• input -- incoming connection requests should be disabled unless your system is acting as a log host for a local network.
• output -- it's generally ok to allow outgoing syslog requests.
• forwarding -- there is usually no reason for syslog requests to be crossing a firewall. Just say no.

515 -- printer

• input -- incoming connection requests should be disabled unless your system is a printer server.
• output -- it's generally ok to allow outgoing printer requests.
• forwarding -- outgoing printer requests should be permitted. Incoming printer requests should only be allowed if you're running a public printer server within your network. Only requests specifically directed to that server should be allowed.

517 -- talk

• input -- incoming connection requests should be enabled.
• output -- it's generally ok to allow outgoing talk requests.
• forwarding -- probably safest just to leave this disabled except for packets sent within an organization.

520 -- route

• input -- incoming connection requests should be disabled unless your system is a route server.
• output -- it's generally ok to allow outgoing route requests.
• forwarding -- outgoing route requests should be permitted. Incoming route requests should only be allowed if you're running a public route server within your network. Only requests specifically directed to that server should be allowed.

532 -- Netnews

533 -- Netwall

• input -- incoming connection requests should be enabled for all systems on your network. If you're behind a firewall, just leave it enabled.
• output -- it's generally ok to allow outgoing netwall requests.
• forwarding -- netwall requests should not be crossing a firewall.

540 -- UUCP