next up previous
Up: Firewall audit for Ottawa Previous: Firewall internals: Priveledge programs

Overall impressions

The machine has been carefully prepared, and appears to be very secure against network attacks.

There is a certain lack of depth in security on the machine: many services are still running, but not accessible due to firewall rules. It is desireable that the services not respond at all by being disabled. This guards against the possibility that there may either be bugs in the firewall rules, or that they may fail to be enabled for some reason (and this fact may not be easily detectable).

Of particular concern was the spam relaying. This should be fixed prior to making extensive use of the new domain name. Use of the domain name will attract attention, and lead to probes from spammers. The email logs should be kept seperate from the general logs and should be examined on a periodic nature to determine if there are problems with the email system: spam rejection systems have a tendancy both to miss certain types of spam, and to falsely detect spam when none exists, preventing legitimate email from flowing. http://www.abuse.net/spamtools.html and http://www.sendmail.org/antispam.html should be consulted prior to implementing any spam rejection system.

An additional concern is the lack of a detected IMAP mail server. The security policy says that this service should be available but was not found. The process and socket listsing show it to be listening. The worry is that the machine was not in its final configuration when we tested it, and the configuration may change again, introducing new problems.

It is recommended that email should not be stored on the firewall, but rather simply relayed to another internal machine. This solves both the problem of configuring the IMAP server to be accessible only to internal people.

More importantly, it solves the problem of having lots of users accessing the firewall using possibly easy to guess passwords. It is assumed that the users would not receive login passwords, or even entries in the user database on the firewall. It is too easy for an attacker to use a valid username/password (either guessed or stolen) to attack the firewall from the network. This would have been something we would have tested, but the IMAP server was not available, nor were any accounts known to exist on the firewall/mail server.

Provided that all non-essential processes and sockets are closed, Sandelman Software Works feels that the machine examined should provide a level of security that will withstand all attacks that do not involve having physical access to the machine.


next up previous
Up: Firewall audit for Ottawa Previous: Firewall internals: Priveledge programs
Michael C. Richardson
1998-11-15