- What to log
- Where to log
- Alerts and notifications
- What data is valuable?
As a general principle, you should log all inbound connections. This is the first step in auditing your firewall rules to verify that you've correctly configured that part of your firewall. Regardless of whether a connection succeeds or fails, you should know who is trying to connect to your internal systems. It does no good to deny services and stand blindly by while someone beats at your network door. As for outbound connections, this is a security policy and legal issue. You should identify any high-profile targets for attacks and any systems that should not originate outbound connections from inside your network (e.g., Web servers, SQL servers, etc.) and log all of their traffic regardless of success or failure. Also, your organisation can be held legally responsible for employee activities while browsing the Web. Therefore, it is essential to monitor Web usage and control access to restricted sites (e.g., porn, hacking, hate groups, etc.). You should also log all rejected connections. This would be traffic that appears to be from another IP space that originates from inside your network. This is usually a good indication that someone has decided to hack on company time or a system has been compromised. Finally, if your firewall is software-based, you should audit every system and application failure and every success and failure of security. If your firewall becomes compromised, this might be the only clue as to when and how the event happened. Where to log
Your log files will typically be stored on the firewall itself, but they should be moved either automatically or manually to another secure location on your network on a set schedule. These logs should then be written to some type of backup media (tape or CD, for example) and stored in a secure location for analysis in the event of an attack or a physical disaster. Leaving the logs on your firewall is an invitation for an attacker to tamper with them, or even worse, to flood the logs and cause the system to halt. The attacker may not gain access to the system (most firewalls fail to a closed position and don't allow traffic), but this is a crude form of denial of service (DoS). Alerts and notifications
Alerts and notifications can be configured in a variety of ways and for a variety of events. Most firewalls support automatic alert notification, but deciding how to be notified and what should trigger an alert is something that should be covered in your security policy. The most commonly used notification methods are as follows:
- Audio notification:This plays an audio alert on the firewall system. It can be useful if an IT professional sits near the firewall itself.
- Mail notification:This e-mails the text of the log file to designated individuals. Typically, this is done in clear text and can be extremely useful information for attackers if it is sent over a public network.
- Pager notification:This approach transmits a message to a designated paging device. This is extremely useful for organisations that aren't staffed 24 hours a day.
- Client notification:This launches a client program. Like a net send message, this is useful only if the recipient is logged on and is looking at his or her computer screen.
- SNMP notification:This sends an SNMP trap containing alert messages to network management stations. If you run a NOC or a central monitoring facility, this will probably be your primary method of notification.
At a minimum, alerts should be triggered by the following events:
- Unsuccessful user and host login attempts: This helps you see who is trying to compromise your security.
- Firewall rules being modified or disabled: This shows you who is trying to circumvent your security.
- Successful logins to the firewall system: See when someone is logging into the firewall.
- Critical events: This includes system reboots, system failures, etc.
- Significant data events: You should know when your system is being probed and when it is under a concerted attack.
What data is valuable?
Probes to ports that have no application services running on them: Before hackers install backdoor Trojan horse programs, they determine which ports you're already using for another service. If you see a lot of probes to suspicious ports (Doshelp.com maintains a fairly up-to-date list of Trojan ports), look up the port and find out what they're doing and verify that you're protected. Unsuccessful access attempts to your firewall and/or other high-profile systems: If you notice repeated unsuccessful attempts to access your firewall and other systems from one IP address (or group of IP addresses), then you might want to write a rule to drop all connections from that IP space (making sure that the IP address isn't being spoofed). IP addresses of the connections that are being rejected and dropped: If the IP address is spoofed, you won't be able to find the owner. Otherwise, you should resolve the domain using a "Who Is" database, contact the owner, and find out why someone from their IP space is trying to attack your systems. Suspicious outbound connections: Outbound connections coming from internal servers such as your Web servers could be an indication that a hacker is using your systems to launch attacks against other organisations or individuals. External packets with internal IP addresses:Packets with a source address internal to your network that originate from outside your network indicate that a hacker is spoofing your internal addresses to attempt to gain access to your internal network. Final word
If you read the log files every day, you'll know what connections are typical and what connections are out of the ordinary for your network. If you notice strange events and don't know what to make of them, go to the Web and research the events and/or search through your firewall vendor's FAQ to establish whether you should take any action. If your initial research comes up empty, then you should contact your firewall vendor's tech support or get in touch with a security consultant.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
