Tracking

All firewall rule tracking should be set to long The rule tracking facility provides a logging mechanism for tracking the triggering of rules. There are three options available: None, short and long. Long pro-vides detailed logging of triggered rules, whilst short gives a basic record.

DNS queries from internal hosts (clients)

As described in xxx, DNS queries are disabled through the control properties. This is done mainly to prevent internal hosts to communicate with the outside world by running standard applica-tions (Telnet etc..) through the Firewall-1 using the DNS port, TCP port 53. If this isn’t disabled, internal users may get access to systems on the Internet, without the firewall being able to log or detect this activity.
Internal clients (workstations and servers) should only depend upon an internal DNS server. Inter-nal clients will not be able to access anything on the outside using TCP or UDP port 53, the normal DNS ports.
An internal DNS server acting as a ‘caching only’ should be installed, and this server should be the only one allowed to use the DNS ports through the Firewall-1. All internal DNS requests must be sent to this computer.
The following rule should be installed:
Source: Internal DNS server
Destination: Internet
Service DNS (UDP port 53)
Action: Allow
Track: (log during installation, after confirmed operation may be set to no log)
Time: Any

DNS queries from internal (DMZ) DNS servers to the outside (Internet)

If an internal DNS server exists, there may also be a possibility to do a zone transfer from the internet to the internal DNS server.  This may reveal information on IP address structure and naming structure within the company to unauthorized users on the outside.
Only UDP based DNS queries should be enabled from the internal DNS server to the Internet.
By using a ‘caching only’ DNS server internally, and leaving the primary and secondary DNS information for the GM.xx domain at the external ISP’s DNS servers, security for DNS is properly maintained.

Protecting the Firewall-1 system

Most firewall systems are heavily protected against attacks from external connections. However many companies fail to protect the firewall itself from internal users/hosts, making the firewall open to DoS (Denial-of-Service) attacks. These attacks may stop the firewall for a shorter period of time.
The rule base should start with these rules:
Rules that apply to the management of Firewall-1 (FW-1 control connections) – if there is to be no remote management then this rule should not exist.
One rule that denies all access to the firewall, regardless of source, service and time. This rule should have ‘Action’ set to ‘Drop’, and ‘Track’ set to ‘Alarm’.

Last rule in the rule base

By default, the rule ‘any – any – any- drop’ applies to Firewall-1. This means that ‘if no rule has accept-ed the packet, the packet will not be accepted’. This works the way it is supposed to be (except for those areas mentioned in chapter 4.1), but there is no logging or alarms. This is a severe security weak-ness, since there will exist no logfiles to prove unauthorised access or attempts to misuse the system.
The last rule in the rulebase should always be:
‘Any – Any – Any – Drop – Log’ as a minimum.

Anti-spoofing and use of IP addresses

Anti-spoofing is configured in the Firewall-1 object properties under the ‘manage network objects’ menu. Anti-spoofing is important to implement, otherwise it may be possible to send non-authorised packets through Firewall-1.
For the best protection, private IP addresses should be used internally, official IP addresses should be used for publicly available hosts in DMZ zones, and on the external connections.
Private IP addresses are defined in RFC’s on the Internet, and defines these addresses for internal usage:
Class A: 10.0.0.0 – 10.255.255.255 subnet mask 255.0.0.0
Class B: 172.16.0.0 – 172.31.255.255 subnet mask 255.255.0.0
Class C: 192.168.0.0 – 192.168.255.255 subnet mask 255.255.255.0
In many cases this can not be done due to different reasons (both administrative and technical). In such cases it will be especially important to configure the anti-spoofing options correctly, and set off alarms on any attempt where spoofed packets are being received.

Using alternative domain names to hide the true identity when using services like WWW and FTP

Most companies allow their internal users to access the World Wide Web. At the same time they tell their users of the fact that the company’s name (domain name) will be in the logs of each and every site they visit. This may hurt the company’s public image, if their domain name gets associated with sites containing controversial material like racism, pornography etc.
We recommend using this type of hiding the true identity, especially those accessing the Internet through the RAS services provided by the GM site.
 By using multiple IP addresses, internal proxy servers and HIDE IP address translation for the proxy servers, the company may register one or more alternative domain names and use them to ‘hide’ their internal webusers behind alternative domain names.
As an example:
All mail will be sent out on the Internet from the domain GM.xx
All FTP and WWW traffic will come from STRANGEDOMAIN.NET, which is registered on Company XXX, or eventually a smaller subsidiary.
The alternative domain may easily be traced to GM.xx for security reasons, but log files on websites will only know of STRANGEDOMAIN.NET.

Differences in using ‘Drop’ and ‘Reject’ in the ‘Action’ setting for each rule

Under the ‘Action’ field in the Rule Base there exists two options for stopping packets. Although both options does stop the packet from going through the firewall, there is an important difference between these two options.
- REJECT will stop the packet, and send a message back to the sender that the packet was not ac-cepted.
- DROP does what it says; it drops the packet, but no message will be sent back to the sender.
DROP is the recommended setting.
REJECT may reveal the firewalls existence, and when a portscanning is done towards the firewall or any of its protected objects, the firewall will inform the portscanner which ports are not available on the target system. This is considered a severe security risk.
By using DROP the sender will not get any reply for those ports that are scanned. However, open ports will reply.
All ports that are open to the internet should normally be ports that ‘everyone’ are allowed to access. To get a complete list of open ports, open a DOS prompt and run the command ‘netstat’. All listening and currently open ports will be shown.
REJECT may be used under certain conditions:
If internal users are accessing SMTP/POP3 accounts on external systems (their private mailboxes with an ISP), the remote mailserver may attempt to do and IDENT request back to the firewall. This request is initiated from the server, and will cause the connection to ‘hang’ for up to 30 seconds, since the pack-et is dropped by the firewall. By inserting a rule that specifically REJECTS Identd requests from the external mailserver, this can be avoided.

Unnecessary services should be removed.

These include ALL services that allow some kind of remote operation/control of the Windows NT con-figuration. If possible, the Firewall-1 systems should be moved within reasonable physical distance for the Firewall-1 administrators.
It should be impossible to do any type of administration of the Windows NT system remotely, only Fire-wall-1 administration. All administrative work that needs to be done at the computer should be per-formed by logging in to the local console.

Risk of losing log data, or log data being manipulated.

Even if log data are being fetched remotely from the Firewall-1, it is important that all log data are also being saved safely on the firewall system. We recommend using WORM drives (Write Once Read Many) for backup of log files frequently.
We also recommend having a local printer attached to each firewall, for the purpose of directly printing log information as evidence, if necessary.
Log data that are being sent/fetched from the firewall by any other system should also be stored at se-cure systems/media, such as WORM drives.