the best damn firewall book period phần 10 doc

Protecting Mail services with ISA Server • Chapter 28 1163
Configuring the Authentication Method
When Outlook logs on to the Exchange server, the Exchange server instructs the Outlook client
to authenticate with an Active Directory domain controller.The problem is you do not want to
open the ports responsible for authentication through the ISA server.To get around this problem,
you can configure the Exchange server to perform authentication on the behalf of the Outlook
client.
To configure the Exchange server to proxy authentication requests for the Outlook client,
navigate to the following Registry key:
HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters
Add the following:
■
Value No RFR Service
■
Type REG_DWORD
■
Data 1
Note that the value does have spaces in it. At first we thought that this might have been a
typo, but we confirmed that the spaces should be included. After adding the value, restart the
Exchange server. Note that you do not need to add this value if the Exchange server is also a
domain controller.
Clients Behind NAT Servers/ISA Servers
If the Outlook client is behind a NAT server or an ISA server, it will not be able to receive new
mail notification requests.The reason is that these new mail notification requests are not part of
the existing RPC connection between Outlook and the Exchange server.The NAT server and
ISA server drop the packet because the new mail notification message is seen as an unsolicited
inbound request.
This doesn’t mean that you won’t ever get any new mail. If you send mail to the Exchange
server, a new mail notification message is sent through the active RPC channel between the
Outlook client and the Exchange server when the message is sent. However, RPC wasn’t
designed for use over the Internet. If there is an error in any of the RPC packets carrying the

new mail notification, the notification message will not go through.You can get around this by
forcing synchronization with the F9 key in Outlook 2000, or set up the Exchange account to
carry out an automatic send/receive every few minutes in Outlook 2002.The exception to this is
when you encrypt the data connection between Outlook and the Exchange server. In that case,
e-mail notification never works, and you have to click on a folder to initiate the connection.
The good news is that everything else works fine when Outlook is behind the NAT server. If
you use the Windows 2000 RRAS NAT, no further configuration is required for the NAT
routing protocol. If there is an ISA server in front of the Outlook client, you will need to con-
figure an RPC protocol definition and configure the client as a Firewall client.You must use the
Firewall client configuration because SecureNAT clients do not support secondary connections.
You need to create the following protocol definition (Figure 28.17):
www.syngress.com
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1163
1164 Part V • ISA Server
■
Primary connection TCP 135 Outbound
■
Secondary connections TCP 1025-65534 Outbound
The initial connection takes place on TCP 135.The remote ISA server (the one publishing the
Exchange server) sends back to the local ISA server (the one in front of the Outlook client) the
port number on which the Outlook client needs for subsequent requests. Since this new outgoing
connection is part of the original RPC conversation, a secondary connection to an ephemeral (high
number) port is required outbound from the local ISA server to the remote ISA server. Once you
create the RPC protocol definition, create a protocol rule using this protocol definition.
Creating the Exchange RPC Server Publishing Rule
The Exchange RPC server publishing rule uses a protocol definition provided by the RPC
application filter. If you disable the application filter, you lose the protocol definition. Perform the
following steps to create the server publishing rule:
1. In the ISA Management Console, expand the server or array name and the Publishing
node.

2. Right-click the Server Publishing Rules node and select New | Rule.
3. On the page, enter a name for the rule and click Next.
4. On the Address Mapping page, enter the IP address of the internal Exchange server and
the IP address on the external interface you want external network clients to use to
access the Exchange server. Click Next.
5. On the Protocol Settings page, select the Exchange RPC Server rule and click Next.
6. On the Client Type page, select Any Request and click Next (it’s unlikely you’ll be
able to identify a client address set to assign the external Outlook clients).
7. On the final page of the wizard, click Finish.
The rule will take effect soon after you click Finish. If you want the rule to apply right away,
restart the Firewall service.
www.syngress.com
Figure 28.17 Outbound RPC Protocol Definition
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1164
Protecting Mail services with ISA Server • Chapter 28 1165
WARNING
Configuring the Outlook client is beyond the scope of this book, and the procedures
vary depending on the version of Outlook you’re configuring. Both Outlook 2000 and
Outlook 2002 (XP) can use the Exchange RPC publishing rule to access the Exchange
server on the internal network. It is important to note that you can force the client to
use an encrypted RPC connection when connecting to the ISA server.
There is one drawback to using an encrypted channel: you will never receive notifica-
tions of new e-mail. In fact, you won’t receive notification of new e-mail even if you
schedule an automatic Send/Receive or press F9, depending on the version of Outlook.
To receive new e-mail notification messages, you must click on an existing message or
folder to initiate a connection with the Exchange server .
If you are using Outlook 2000, do not install Office Service Pack 2. There appears to
be an undocumented issue preventing Outlook 2000 SP2 clients from connecting to an
Exchange 2000 server published using the RPC server publishing rule. This problem
appears to be specific to the server publishing rule, because if you bring the client onto

the internal network, you can log on to the Exchange server without problems.
Publishing Outlook Web Access
on the Internal Network Exchange Server
The same procedures used to publish OWA on the ISA server are used when you publish OWA
on the internal network Exchange server.The only difference is that you don’t need to worry
about disabling socket pooling on the ISA server because you’ll choose to disable the IIS
W3SVC on the ISA server for security purposes.
As a review, here are the basic procedures required to publish the OWA site on the internal
network Exchange server:
■
Configure the OWA Web site on the Exchange server Configure folder permis-
sions, obtain and assigning a certificate for the Web site, configure a port for SSL con-
nections on the default Web site, and configure the sites to require an SSL connection.
■
Configure the Incoming Web Requests listener on the ISA server Create the
individual listener, export the OWA Web site certificate and import it into the ISA
Server’s machine certificate store, and bind the certificate to the Incoming Web
Requests listener.
■
Create the Web publishing rule Create the destination set used for the OWA Web
publishing rule, create the Web publishing rule, and configure the rule to bridge SSL
connections as SSL.
■
Configure the OWA client Web browser Improve performance for the OWA client
by installing a client certificate on all browser clients.
www.syngress.com
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1165
1166 Part V • ISA Server
For details of this configuration, check the relevant sections on how to publish OWA on the
ISA server.The only difference is that you use the internal IP address of the Exchange server

rather than the IP address of the internal interface of the ISA server for the redirect.
NOTE
There is a good chance that by the time you read this book, Microsoft will have released
the ISA Server Feature Pack. One of the features included in the major update to ISA
Server is an Outlook Web Access Publishing Wizard. The wizard will greatly simplify pub-
lishing of OWA sites. However, like all wizards, it will have its limitations. Check
www.isaserver.org/shinder for updates on this feature of the ISA Server Feature Pack and
other important ISA Server news and articles.
Message Screener on the
Internal Network Exchange Server
You can install the Message Screener on the internal network Exchange server.The difference
between the installations is that when the Message Screener is on the ISA server, the entire ISA
Server software package is installed on the ISA/Exchange Server computer. In contrast to the “all
but the kitchen sink” approach we covered earlier, when the Exchange server is on a dedicated
server, all you need to install is the SMTP Message Screener.You don’t need to install any other
component of the ISA Server software.
Run the ISA Server installation program as you usually would to install only the Message
Screener component on the internal network Exchange server. Select the Custom installation
option and then deselect the ISA Services and Administration tools options in the Custom
Installation dialog box (Figure 28.18).
Select the Add-in services option and click Change Option. Remove the Install H.323
Gatekeeper Service option (Figure 28.19).The only component you want is the Message
www.syngress.com
Figure 28.18 The Custom Installation Dialog Box
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1166
Protecting Mail services with ISA Server • Chapter 28 1167
Screener. Make sure that the Message Screener option is selected and complete the installation
on the Exchange server computer.You won’t see any new configuration interfaces or Start menu
items related to the Message Screener on the Exchange server. Configuration of the Message
Screener is done via the SMTP filter on the ISA server.

The next step is to configure credentials that the Message Screener software will use to com-
municate with the SMTP application filter on the ISA server. Credentials are configured using
the SMTPCRED tool, which is installed in the Program Files\Microsoft ISA Server folder on
the Exchange server’s hard disk after running the Message Screener installation.
Open the SMTPCRED tool by double-clicking it. In the Message Screener Credentials
dialog box (Figure 28.20), enter your ISA server name, the Username of the person who installed
the ISA server, the Domain to which that user account belongs, and the Password of that user.
Note that you do not need to use the credentials of the user who installed the ISA server, but it
does streamline the process and reduces troubleshooting issues encountered with the Message
Screener by an order of magnitude. Click OK after entering the information.
www.syngress.com
Figure 28.19 Selecting the Message Screener
Figure 28.20 The SMTPCRED Tool
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1167
1168 Part V • ISA Server
The last thing is to configure DCOM permissions.The Message Screener communicates with
the SMTP application filter via DCOM. While this isn’t an issue when the ISA server and the
Exchange server are on the same machine, it does become an issue when they are on different
machines.
Perform the following steps to configure the DCOM permissions:
1. Select Start | Run and type dcomcnfg.exe in the Open text box. Click OK.
2. Click the Applications tab and select VendorData class | Properties (Figure 28.21).
3. On the VendorData Class Properties dialog box, click the Security tab (Figure 28.22).
Select the Use custom access permissions and click Edit. Figure 28.22 The
VendorData Class Properties Dialog Box
4. Add the Everyone group by clicking Add and selecting the Everyone group (Figure
28.23). Click OK.
5. Repeat steps #3 and #4 to edit the Use custom launch permissions and Use
custom configuration permissions options.
6. Click OK.

7. Restart both the ISA server and the Exchange server. We suggest restarting the ISA
server first.
www.syngress.com
Figure 28.21 The DCOM Configuration Properties Dialog Box
Figure 28.23 Adding the Everyone Group
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1168
Protecting Mail services with ISA Server • Chapter 28 1169
The remainder of the configuration is the same as when you run the Message Screener on
the ISA/Exchange server computer.You will be able to screen for incoming and outgoing mes-
sages, but you will have the same limitations regarding Outlook MAPI clients sending SMTP
messages to the Internet.The solution is the same: create a second virtual SMTP server and have
the default SMTP virtual server forward mail to the second SMTP virtual server.The Internet-
bound messages sent by Outlook clients will be exposed to the SMTP Message Screener when
they are forwarded to the second SMTP virtual server.
GFI’s Mail Security and
Mail Essentials for SMTP Servers
It’s estimated that spam makes up as much as 20 percent of the total traffic moving through the
Internet. Spam clogs e-mail boxes, and contains viruses, worms, and offensive language. Spam fills
the massive disks on today’s mail servers and is a public nuisance. Spam can negatively impact
your personal and professional life: just think about how many times you’ve accidentally ignored
an important message because it got lost in a sea of spam in your inbox.
We don’t have to convince you that something needs to be done about spam. Many network
administrators use Real-time Black Hole Lists to automate spam blocking on their networks.The
problem with RBLs is they are maintained by third parties. If there is one thing we learned during
the dot com bomb, it’s that inappropriate trust in third parties can put your business in jeopardy.
There are several types of RBLs. Legitimate RBLs look for open mail relays on the Internet
and blacklist the IP addresses of the open relays.The blacklisting is based on the assumption that
eventually, a spammer will find the open relay and use it to send spam.The problem with this
approach is that the open relay will be blacklisted even if no spam has ever been sent through it.
It’s sort of like the police taking you into custody for a shooting because you have two hands,

one of which might have held a gun.
The other type of RBL is based on user reports. One user of the service reports that he
received mail that he thinks is spam.That user tells three of his friends to make the same report.
BANG! The domain from which the alleged spam is sent is blocked by the RBL. Suppose you
send someone an e-mail message inviting him to your birthday party. He didn’t ask for that mes-
sage, so he reports you as a spammer, and he gets three of his antisocial friends to send in the
same report. A couple of days later, you find that some people aren’t getting mail from you. Why?
Your domain or account has been blocked by the RBLs that blindly trust user reports.
This type of spam blocking has to be the most egregious form of censorship we’ve seen in
decades. Everyone hates spam, we really hate spam, but we hate the idea of a third party cen-
soring what should be sent to our network.That’s our job, our responsibility, and our mail. It’s not
the job of some anonymous RBL to decide what’s legitimate.
The SMTP Message Screener goes a long way to resolving the spam problem.You can block
mail based on text strings.The problem is that you don’t have much flexibility with the SMTP
Message Screener. For example, you can’t:
■
Easily save the keyword entries in the Message Screener
■
Check for e-mail viruses using the Message Screener
www.syngress.com
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1169
1170 Part V • ISA Server
■
Check for viruses in e-mail attachments using the Message Screener
■
Import a list of keywords from a text file into the Message Screener
■
Check for non-virus-related e-mail exploits with the Message Screener
■
Check for whole words in the Message Screener (you can only check for text strings)

■
Creating conditional content checking rules for e-mail
It’s our opinion that the only valid way to control spam is by using a keyword method. We’ve
found that the most effective way to prevent spam from getting to user mailboxes is to create a
list of keywords that don’t apply to the legitimate business or personal communications. Using
this method, you can control over 99 percent of the spam entering your network.
While the ISA Server SMTP Message Screener is better than nothing, we’ve found that the
best tool for this job is GFI Software’s MailSecurity, which can be used to block spam in both
small and large organizations. MailSecurity is easy to set up, and you can import your spam filter
list easily from a text file. It also detects e-mail viruses and attachments, and auto-updates its virus
definition list on a daily basis.
MailSecurity Versions
There are two versions of MailSecurity. One plugs into your Exchange 2000 server and inspects
the contents of the message store.The other version is for SMTP mail gateways and inspects mail
as it moves through the gateway.The main advantage of the Exchange Server version is that it
can inspect mail sent between internal users.The main advantage of the SMTP relay version is
that it has more information about each e-mail and can decide better what mail is considered
inbound and outbound. MailSecurity can be configured to inspect only inbound, only outbound,
or both inbound and outbound e-mail.
We typically install an SMTP relay on all networks that have an Exchange 2000 server. For
that reason we consider the SMTP gateway version the best choice. Note that you can use both
versions.You can install the SMTP gateway version on your SMTP relay, and you can install the
Exchange Server 2000 version on your Exchange server and you don’t have to buy any more
licenses for filtering based on keyword, user, or domain.You do need to pay extra for a mainte-
nance contract and automatic anti-virus updates.
Installing MailSecurity for SMTP Gateways
Installing MailSecurity for SMTP gateways is straightforward:
1. Download the installation file from www.gfi.com/mailsecurity/index.html and run the
mailsecurity.exe installation package.The Welcome to the GFI MailSecurity for
Exchange/SMTP Installation Wizard page will be displayed (Figure 28.24). Click Next

to continue.
www.syngress.com
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1170
Protecting Mail services with ISA Server • Chapter 28 1171
2. The License Agreement page appears. Select the I accept the license agreement
option and click Next.
3. On the User Information page, enter your name, company name, and serial number (if
you have one; otherwise, use Evaluation as your key). Click Next.
4. On the Administrator Email page (Figure 28.25), enter the MailSecurity adminis-
trator e-mail address. Notification messages can be sent to the administrator e-mail
account you enter here.You can add more administrators or change the one you enter
here later. Click Next.
5. On the Destination Folder page, select the location of the program files and click Next.
6. This brings you to the Mail Server page shown in Figure 28.26. If your SMTP relay is on
a DMZ segment, enter the IP address on the external interface of the ISA server used by
the SMTP server publishing rule that’s publishing the internal network Exchange server.
7. If the SMTP relay is on your internal network, enter the IP address of your Exchange
server.The default port TCP 25 will work in the majority of cases. However, if you want
MailSecurity to send to an alternate port, just type the alternate port number in the on
port text box.The setup program will create a remote domain in the IIS SMTP service
for the domain you enter in the Local domain text box. If you are managing multiple
www.syngress.com
Figure 28.24 The Welcome Page
Figure 28.25 The Administrator Email Dialog Box
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1171
1172 Part V • ISA Server
mail domains, you should manually create those remote domains after the installation is
complete.
7. Click Next to continue.
8. Identify the type of mail server that is running MailSecurity (see Figure 28.27). In this

example, we’re installing MailSecurity on an SMTP relay, so the second option is correct.
Click Next to continue, and click Next one more time to start installing the application.
9. Click Finish when you get notification that the application has been installed successfully.
10. Open the Internet Information Services console after you’re finished installing
MailSecurity. Expand the Default SMTP Virtual Server node and click the Domains
node.You’ll see that a new remote domain was created and configured to use your
internal mail server as a smart host. If you configure MailSecurity on a DMZ SMTP
relay, you’ll see the IP address used on the external interface of the ISA server in your
SMTP server publishing rule. If you host multiple mail domains, create a remote domain
for each domain you host and have them use your mail server as a smart host. Make
sure that your server is not configured as an open relay by setting the appropriate relay
settings on the Default SMTP Virtual Server (Figure 28.28).
www.syngress.com
Figure 28.26 The Mail Server Information Page
Figure 28.27 Choosing the Mail Server Type
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1172
Protecting Mail services with ISA Server • Chapter 28 1173
Configuring MailSecurity
1. Select Start | Programs | GFI MailSecurity | MailSecurity Configuration.
Figure 28.29 shows all the features in an MMC console.
2. Click the Content Checking node in the left pane, then double-click the Default
Content Checking Rule.This is where you create your e-mail content checking rules.
You can create rules that look for a particular keyword, or you can create rules based on
keywords with conditions. In Figure 28.30, you’ll see some keyword rules that have
conditions. For example, we want to block all mail that has the keywords “special offer.”
However, we don’t want to block special offers from GFI.
3. Notice that you have the option to check inbound and outbound mails.You can also
block PGP encrypted mail.This will prevent mail encrypted with PGP from bypassing
your content checking rules.This is a valuable feature, as users might try to use PGP to
send out proprietary information about corporate projects. For example, you might be

working on a project and use an internal code name for that project. No one on the
outside should know the project or its code name. If users sent mail encrypted by PGP,
www.syngress.com
Figure 28.28 Remote Domain Configuration
Figure 28.29 MailSecurity Configuration
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1173
1174 Part V • ISA Server
they would get around your keyword filters.You can also check the attachment content.
This prevents attachments with forbidden content from reaching users’ mailboxes.
4. You can monitor incoming mail in real time and see what mail was allowed and which
ones where caught by the content checking rules.The GFI Monitor (Figure 28.31)
shows you mail as it’s being processed.
5. The Moderator Client (Figure 28.32) allows you to see the actual messages caught by
the content checking rules. When you double-click the blocked message, you’ll see the
reason why the message was caught, some details about the message, and files associated
with the message.You can right-click the content file and open the message. Plain text
messages are saved as text files, and HTML messages are saved as HTML files.The
HTML files are safe to open because dangerous scripts and viruses are removed.
www.syngress.com
Figure 28.30 Configuring Keywords
Figure 28.31 GFI Monitor Displaying Actions in Real Time
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1174
Protecting Mail services with ISA Server • Chapter 28 1175
6. Click the Attachment Checking node in the left pane, and then double-click on the
Default Attachment Checking Rule (Figure 28.33) in the right pane.This option allows
you to block attachments for inbound or outbound mail (or both).There’s a built-in list of
attachments that can be blocked, and you can easily add your own custom attachments.
7. Now for the best feature of MailSecurity: the virus scanning engines. MailSecurity
allows you to scan mail for viruses using multiple scanning engines. If one of the virus
scanning engines doesn’t catch a virus, it’ll try again with another scan engine.This pro-

vides a high level of security for both incoming and outgoing e-mail.This redundant
virus scanning method unique to MailSecurity.
8. Notice that you have the option to scan inbound mail, outbound mail, or both.You also
can block Word documents that have macros. Word macro viruses are a big problem, so
blocking them can go a long way toward protecting your users from Word macro
exploits. In Figure 28.34, you see the options for automatically downloading and
installing virus definition updates.
9. The system automatically downloads virus definitions, and we’ve never had a problem
getting them to download from behind the ISA server.The system uses FTP to down-
load the updates, so you need to create an FTP protocol rule to allow the mail server to
download the updates. If you run MailSecurity on the ISA server, you’ll need to create
www.syngress.com
Figure 28.32 The Moderator Client
Figure 28.33 Attachment Checking Options
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1175
1176 Part V • ISA Server
packet filters to allow for PORT mode FTP communications between the ISA server
and the GFI FTP server (Figure 28.35).
10. Click the E-mail Exploit Engine node in the left pane of the console. In the right pane
(Figure 28.36), you’ll see an impressive list of e-mail exploits MailSecurity checks for.
The e-mail exploit engine is disabled by default, so you have to right-click the node in
the left pane of the console and click Enable. We don’t see any reason not to run the e-
mail exploit engine, so we recommend that you always enable it and allow MailSecurity
to check for all of the included exploits. If for some reason you need to disable
checking for a particular exploit, you can right-click it and click Disable.
www.syngress.com
Figure 28.34 The Virus Checking Engines
Figure 28.35 Configuring FTP Virus Definitions Download Options
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1176
Protecting Mail services with ISA Server • Chapter 28 1177

11. Some e-mails are so obviously spam that you don’t need to ever look at them.This type
of blatant spam can be deleted without you ever needing to review it in the Moderator
Client console.The Anti-spam feature allows you to enter keywords that are never
included in legitimate e-mails. As with the content checking feature mentioned earlier,
you can have MailSecurity check the mail body or subject line for these uniquely inap-
propriate or offensive keywords. When a message matches the keywords in the Anti-
Spam dialog box, the mail can be deleted immediately or put in a folder for later
checking (Figure 28.37).
For both content checking and anti-spam rules, you can choose what action to take on the
e-mail (See Figure 28.38). For the content checking option, you can quarantine the mail, delete
it, or move it to a particular folder for evidence collection.You also have the option to notify
users that they sent or received a forbidden mail.You can also inform the user’s manager.The
manager is defined in the user account properties in the Active Directory.
www.syngress.com
Figure 28.36 Checking for E-Mail Exploits
Figure 28.37 Whacking Spam with the Anti-Spam Feature
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1177
1178 Part V • ISA Server
We have found the performance of MailSecurity acceptable. If you have a large number of rules
and enable all the virus engines and exploit checking, it might take a few seconds to evaluate a
single e-mail. If you have a busy mail server, you’ll want to make sure to load it up with RAM and
a fast processor. However, if you don’t require instantaneous delivery of e-mail from the relay to the
main mail server, you’re in good shape.The engine doesn’t choke or die when it’s busy, it just slows.
However, all the mail gets checked and cleaned before making its way to your server.
You need to put together a list of keywords that are specific for your organization in order to
see the best results with your e-mail checking rules.This can take a week or two. One thing that
we find useful is to create a Hotmail account and then subscribe that Hotmail account to a
number of different Web sites.You can also post messages to USENET message boards and put
that account in the return address.This will get the account quickly subscribed to a large number
of spammer lists.You can use the spam sent to your Hotmail inbox for ideas on what keywords to

put into the MailSecurity keyword database. If you want to get a head start on your list, check
out our list of keywords, which we update weekly, at ftp.tacteam.net/isaserver/spamlist.tx_.
www.syngress.com
Figure 28.38 Deciding What Action to Take with Filtered Mail
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1178
Protecting Mail services with ISA Server • Chapter 28 1179
Summary
In this chapter, we reviewed the techniques used to publish SMTP and Exchange mail services.
In the first part, you learned how to publish SMTP and Exchange mail services on the ISA
server. Publishing Exchange 2000 services on the ISA server has been a long misunderstood sub-
ject that has never, until the publication of this book, been adequately explained to the public.
There are a number of procedures you must go through in order to prevent conflict so you’ll be
able to get all the services to work together and publish the Exchange services among the
Exchange services, the ISA server, and the Internet Information server.
We also covered how to publish Exchange mail services on the internal network.The proce-
dures are very similar and in many ways much easier because you don’t need to run IIS services
on the ISA server.You can also leverage the automation provided by the Secure Mail Services
Wizard to make your server publishing rules and protocol rules. Publishing mail services on the
internal network is the preferred configuration because you don’t have to worry about weak-
nesses in any of the Exchange services compromising your firewall.
www.syngress.com
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1179
252_BDFW_28.qxd 9/19/03 2:03 PM Page 1180
1181
Intrusion Detection
Part VI
252_BDFW_29.qxd 9/19/03 3:24 PM Page 1181
252_BDFW_29.qxd 9/19/03 3:24 PM Page 1182
Introducing Snort
Best Damn Topics in this Chapter:

■
What Is Snort?
■
Snort System Requirements
■
Exploring Snort’s Features
■
Using Snort on Your Network
■
Security Considerations with Snort
Chapter 29
1183
252_BDFW_29.qxd 9/19/03 3:24 PM Page 1183
1184 Part VI • Intrusion Detection
Introduction
Snort is a full-fledged open-source Network-based Intrusion Detection System (NIDS) that has
many capabilities.These capabilities include packet sniffing and packet logging in addition to
intrusion detection. In addition to all of the basic Snort Features, you can set up Snort to send
real-time alerts.This provides you with the ability to receive alerts in real time, rather than having
to continuously monitor your Snort system.
An Intrusion Detection System (IDS) is used as a “burglar alarm” for your network or host. If
there is an anomaly detected (in the case of Snort, by using signatures), the system administrator
is notified in various ways.Those ways include e-mail, network messages (like Windows pop-ups
or UNIX write), or the syslog facility.
Snort is like a vacuum that takes particular items (in this case, packets) and allows you to per-
form different tasks, such as watching the items as they get sucked up (packet sniffer), putting the
items into a container (packet logger), or sorting them and determining when a particular item
has gone through your NIDS.
So why is Snort so popular? Providing packet sniffing and logging functions is an elementary
part of Snort, but Snort’s beefiness comes from its intrusion detection capabilities—which

matches packet contents to an intrusion rule. Snort might be considered a lightweight NIDS. A
lightweight IDS is one that has a small footprint and can run on various operating systems (OSs).
Additionally, Snort provides functionality only before found in commercial-grade network IDSs
such as Network Flight Recorder (NFR) and ISS RealSecure.
Snort’s popularity runs parallel to the increasing popularity of Linux and other free OSs such
as the BSD-based OSs, NetBSD, OpenBSD, and FreeBSD. Just because Snort’s roots are in open
source does not mean that it’s not available for other commercial OSs. On the contrary, you can
find ports of Snort available for Solaris, HP-UX, IRIX, and even Windows.
Snort is a signature-based IDS, and uses rules to check for errant packets in your network.A
rule is a set of requirements that would trigger an alert. For example, one snort rule to check for
peer-to-peer file sharing services checks for the string “GET” not connecting to a service run-
ning on port 80. If a packet matches that rule, that packet creates an alert. Once an alert is trig-
gered, the alert can go a number of places, such as a log file, a database, or to an SNMP trap.
NOTE
Snort’s logo is a pig, and many references are piggish in nature.
In this chapter, you’ll get an understanding of what Snort is, what its features are, and how to
use it on your network.Additionally, you’ll learn about the history of Snort, and how it came to
be such a popular IDS.You’ll also learn the importance of securing your Snort system, and some
of the pitfalls of Snort. However, as you will see, Snort’s advantages far exceed its pitfalls.
www.syngress.com
252_BDFW_29.qxd 9/19/03 3:24 PM Page 1184
Introducing Snort • Chapter 29 1185
NOTE
There are commercial solutions for Snort as well, but they are out of scope for this
chapter. Although Snort is available for free under the GNU Public License (GPL), there
are commercial solutions available for Snort through Sourcefire.
What Is Snort?
In short, Snort is a packet sniffer/packet logger/network IDS. Snort has an interesting history that
began with a man named Marty Roesch. In November 1998, Roesch wrote a Linux-only packet
sniffer called APE. Despite the great features of APE, Roesch also wanted a sniffer that would do

the following:
■
Work on multiple OSs.
■
Use a hexdump payload dump (TCPDump later had this functionality).
■
Display all the different network packets the same way (TCPDump did not have this).
With these goals in mind, Roesch developed Snort. Snort was written as a libcap application
to provide system administrators with an alternative to TCPDump (the only other sniffer using
libcap at the time—Libcap allows Snort to be portable from a network filtering and sniffing
standpoint).
Snort became available at Packet Storm (www.packetstormsecurity.com) on December 22,
1998. At that time, Snort was only about 1,600 lines of code and had a total of two files. Roesch’s
first uses of Snort included monitoring his cable modem connection and debugging network
applications that he coded.
NOTE
The name Snort came from the fact that the application is a “sniffer and more.” In addi-
tion, Roesch said that he has too many programs called a.out, and all the popular
names for sniffers called “TCP-something” were already taken.
Snort’s first signature-based analysis (also known as rules-based within the Snort community)
became a feature in late January 1999.This was Snort’s initial foray down the path of intrusion
detection, and Snort could be used as a lightweight IDS at the time.
By the time Snort version 1.5 came out in December 1999, Roesch had decided on the
Snort architecture that is currently employed in versions up to 2.0. After version 1.5 was released,
Snort was able to use all the different plug-ins that are available today. Because of Snort’s
increasing popularity, Roesch worked to make it easier to configure and get it working in an
enterprise environment so that it would be useful to a greater number of people.
What started as a pastime for Roesch quickly became a full-time job. In an attempt to devote
a full effort to the development of Snort, Roesch started a company named Sourcefire and hired
www.syngress.com

252_BDFW_29.qxd 9/19/03 3:24 PM Page 1185
1186 Part VI • Intrusion Detection
most of the core team who developed Snort. However, Snort is still open source and will always
be open source. Sourcefire has put a lot of work into Snort, but it’s not Sourcefire’s 2.0—it’s
Snort 2.0.The current version of Snort is 2.0.1, which is a rework of the architecture and at press
time contains approximately 75,000 lines of code.
Even though Snort 2.0 is a complete rewrite and an improvement over the current Snort
implementation, Snort has gone though a more in-depth evolution. Snort did not start out with
preprocessing ability, nor did it start out with plug-ins. Over time, Snort grew to have improved
network flow, plug-ins for databases such as MySQL and Postgres, and preprocessor plug-ins that
check RPC calls and port scanning before the packets are sent to the rules to check for alerts.
NOTE
By supporting only the latest rules of the latest application, Snort ensures that users are
using only the most recent version. As of press time, the latest revision is 2.0.1, so the
rules only work with that version.
Speaking of rules, as time progressed, so did the number of rules.The size of the latest rules is
increasing with the number of exploits available.To keep the rules organized, they have been cat-
egorized into several types including P2P, backdoor, distributed denial of service (DDoS) attacks,
Web attacks, viruses, and many others.These rules are mapped to a number that is recognized as a
type of attack or exploit known as a Sensor ID (SID). For example, the SID for the SSH banner
attack is 1838.
Because of Snort’s increasing popularity, other IDS vendors are adopting a Snort rule format.
TCPDump adopted the hex encoding for packets, and community support is ever increasing.
There are at least two mailing lists for Snort:
■
One on Snort’s usage and application />snort-users
■
One dedicated entirely to the Snort rules />listinfo/snort-sigs
Snort System Requirements
Before getting a system together, you need to know a few things. First, Snort data can take up a

lot of disk space, and second, you may need to be able to monitor the system remotely. For Linux
and UNIX, this means including Secure Shell (SSH) and Apache with Secure Sockets Layer
(SSL). For Windows, this would mean Terminal Services (with limitation on which users and
machines can connect, and Internet Information Servers [IIS]).
Hardware
One of the most important things you’ll need, especially if you’re running Snort in Network-
based Intrusion Detection System (NIDS) mode, is a really big hard drive. If you’re storing the
www.syngress.com
252_BDFW_29.qxd 9/19/03 3:24 PM Page 1186
Introducing Snort • Chapter 29 1187
data as either syslog files or in a database, you’ll need a lot of space to store all the data that the
Snort’s detection engine uses to check for rule violations.
Another highly recommended hardware component for Snort is a second Ethernet interface.
One of the interfaces is necessary for typical network connectivity (SSH, Web services, and so
forth), and the other interface is for Snorting.This sensing interface that does the “snorting” is
your “Snort sensor.”
Snort does not have any particular hardware requirements that your OS doesn’t already
require to run. Running any application with a faster processor usually makes the application
work faster. However, you will be limited in the amount of data you collect by your network
connection and by your hard drive.
To run Snort, you will need to have a reasonable-sized network interface card (NIC) to col-
lect the correct amount of network packets. For example, if you are on a 100MB network, you
will need a 100MB NIC to collect the correct amount of packets. Otherwise, you will miss
packets and be unable to accurately collect alerts.
In addition, you will need a good-sized hard drive to store your data. If your hard drive is too
small, there is a good chance that you will be unable to write alerts to either your database or log
files. A good setup for a single Snort sensor may be a 9GB partition for /var.
Operating System
As stated earlier, Snort was designed to be a lightweight NIS. Currently, Snort can run on x86
systems Linux, FreeBSD, NetBSD, OpenBSD, and Windows. Other supported systems include

Sparc Solaris, PowerPC MacOS X and MkLinux, and PA-RISC HP-UX. Snort will run on just
about any modern OS today.
N
OTE
People can get into heated debates as to which OS is best, but you have to be the one
to administer the system, so you pick the OS.
There is an ongoing argument regarding the best OS on which to run Snort. A while back,
the *BSDs had the better IP stack, but since Linux has gone to the 2.4 kernel, the IP stacks are
comparable. Our favorite is NetBSD, but your mileage might vary.
Other Software
Once you have the basic OS installed, you’re ready to go. Make sure that you have the following
prerequisites before you install Snort:
■
autoconf and automake*
■
gcc*
■
lex and yacc (or the GNU implementations flex and bison, respectively)
■
The latest libcap from tcpdump.org
www.syngress.com
252_BDFW_29.qxd 9/19/03 3:24 PM Page 1187