Network Level Firewalls example essay topic

WHAT IS A NETWORK FIREWALL? A firewall is a system or group of systems that enforces an access control policy between two or more networks. The means by which this control is accomplished varies widely, but in principle, the firewall is a pair of mechanisms, one that blocks traffic and one that permits traffic. Some firewalls emphasize blocking traffic, while others emphasize permitting traffic.

The most important thing to recognize about a firewall is that it implements an access control policy. If you don't know what kind of access you want to permit or deny, or you let someone else or some product configure a firewall based on judgment other than yours, that entity is making policy for your whole organization. WHY WOULD I WANT A FIREWALL? The Internet is a fun little playground and at the same time a hostile environment. Like any other society, it's plagued with the kind of people who enjoy the electronic equivalent of writing on other people's walls with spray paint, tearing off their mailboxes, or just sitting in the street blowing their car horns. Some people get real work done over the Internet, and some must protect sensitive or proprietary data.

Usually, a firewall's purpose is to keep the intruders out of your network while letting you do your job. Many traditional corporations and data centers have computing security policies and practices that users must follow. If a company's policies dictate how data must be protected, a firewall is very important because it embodies corporate policy. Frequently, the hardest part of hooking a large company to the Internet is not justifying the expense or effort, but instead convincing management that it's safe to do so.

A firewall not only provides real security but also plays an important role as a security blanket for management. Last, a firewall can act as your corporate ambassador to the Internet. Many corporations use their firewall systems to store public information about corporate products and services, files to download, bug-fixes, and so forth. Several of these systems (such as. uu. net, white house. gov, gatekeeper. Dec. com) have become important parts of the Internet service structure and reflect well on their organizational sponsors. WHAT CAN A FIREWALL PROTECT AGAINST?

Some firewalls permit only e-mail traffic, thereby protecting the network against any attacks other than attacks against the e-mail service itself. Other firewalls provide less strict protections or block services that are known to be problems. Generally, firewalls are configured to protect against unauthenticated interactive logins from the outside world. This protection, more than anything, helps prevent vandals from logging on to machines on your network.

More elaborate firewalls block traffic from the outside to the inside but permit users on the inside to communicate freely with the outside. The firewall can protect you against any type of network-borne attack if you unplug it. Firewalls are also important because they are a single point where you can impose security and auditing. If someone attacks a computer system by dialing in with a modem, tracing the perpetrator is impossible. In contrast, the firewall can act as an effective phone tap and tracing tool. Firewalls also provide an important logging and auditing function, summarizing topics such as the kinds and amount of traffic that passed through it and how many attempted break-ins occurred recently.

WHAT CAN'T A FIREWALL PROTECT AGAINST? Firewalls can't protect against attacks that don't go through the firewall. Many corporations that connect to the Internet are very concerned about proprietary data leaking out of the company. Unfortunately, a magnetic tape exports data just as effectively as the Internet. Many organizations whose management is terrified of Internet connections have no coherent policy about protecting dial-in access via modems. It's silly to build a steel door six feet thick when you live in a wooden house, but a lot of organizations out there buy expensive firewalls and neglect their network's other numerous back doors.

For a firewall to work, it must be a part of a consistent overall organizational security architecture. Firewall policies must be realistic and reflect the level of security in the entire network. For example, a site with top secret or classified data doesn't need a firewall at all: it shouldn't be hooking up to the Internet in the first place; at least the systems with really secret data should be isolated from the rest of the corporate network. Firewalls also can't protect you from traitors inside your company.

Although industrial spies might export information through your firewall, they " re just as likely to export it through a telephone, fax machine, or floppy disk. In fact, floppy disks are a far more likely way to leak information from your organization than a firewall! Firewalls also cannot protect you from stupidity. Users who reveal sensitive information over the telephone are good targets for social engineering.

Attackers may break into your network, completely bypassing your firewall, by finding a helpful employee inside who is fooled into granting access to a modem pool. WHAT ABOUT VIRUSES? Firewalls can't protect against viruses very well. Binary files can be encoded for transfer over networks in too many ways, and too many different architectures and viruses exist to try to search for them all.

In other words, a firewall cannot replace users's security consciousness. In general, a firewall cannot protect against a data-driven attack - attacks in which code is mailed or copied to an internal host where it is executed. This form of attack has occurred against various versions of send mail and Ghost Script (a freely-available PostScript viewer). Organizations that are deeply concerned about viruses should implement organization-wide virus control measures. Rather than screening viruses at the firewall, make sure that every vulnerable desktop has virus-scanning software that runs when the machine is booted. Blanketing your network with virus-scanning software protects against viruses that come via floppy disks, modems, and the Internet.

Trying to block viruses at the firewall protects against viruses only from the Internet, and most viruses are passed via floppy disks. WHAT ARE SOME BASIC DESIGN DECISIONS IN A FIREWALL? The lucky person who is responsible for designing, specifying, and implementing or overseeing the installation of a firewall should consider a number of basic design issues. The first and most important issue is how your company or organization wants to operate the system. Is the firewall in place to deny all services except those critical to the mission of connecting to the Internet? Or is the firewall in place to provide a nonthreatening but metered and audited method of access?

Varying positions between these two carry with them varying degrees of paranoia; the final stance of your firewall may be a political rather than an engineering decision. The second issue is the level of monitoring, redundancy, and control you want. Having established the acceptable risk level (that is, your level of paranoia), you can form a checklist of what should be monitored, permitted, and denied. In other words, you start by figuring out your overall objectives, then combine a needs analysis with a risk assessment, and sort the (almost always conflicting) requirements into a laundry list that specifies what you plan to implement. The third issue is financial. We can't address this issue in anything but vague terms, but it's important to try to quantify the cost of both buying and implementing any proposed solutions.

For example, a complete firewall product may cost $100,000 at the high end or it may be free at the low end. The free option - doing some fancy configuring on a Cisco or similar router - costs nothing but staff time and cups of coffee. Implementing a high-end firewall from scratch can cost several person-months, which may equate to $30,000 worth of staff salary and benefits. The systems management overhead is also a consideration.

Building a home-brew solution is fine, but it's important to build it so that it doesn't require constant and expensive fiddling. It's important, in other words, to evaluate firewalls not only in terms of what they cost now, but also in terms of continuing costs, such as support. On the technical side, you must make a decision. For practical purposes, we are talking about a static traffic-routing service placed between the network service provider's router and your internal network.

The traffic-routing service may be implemented at an IP level via something like screening rules in a router, or at an application level via proxy gateways and services. You need to decide whether to place an exposed stripped-down machine on the outside network to run proxy services for Telnet, FTP, news, etc., or to set up a screening router as a filter, permitting communication with one or more internal machines. Both approaches have plus ses and minuses - the proxy machine provides a greater level of audit and potential security in return for increased cost of configuration and a decreased level of service provided (because you need a proxy configured for each desired service). The old trade-off between ease-of-use and security comes back with a vengeance.

WHAT ARE THE BASIC TYPES OF FIREWALLS? Conceptually, firewalls come in two flavors: network level and application level. They are not as different as you might think, and latest technologies are blurring the distinction to the point where it's no longer clear whether one is better or worse. As always, you need to pick the type that meets your needs. Network-level firewalls generally make their decisions based on the source, destination addresses, and ports in individual IP packets. The traditional network-level firewall is a simple router because it doesn't make particularly sophisticated decisions about what a packet is talking to or where it came from.

Modern network-level firewalls are more sophisticated and now maintain internal information about the state of connections passing through them, the contents of some of the data streams, and so on. Many network-level firewalls route traffic directly though them, so to use one you usually need to have a valid IP address block. Network-level firewalls tend to be very fast and transparent to users. In Figure D. 1, you see a screened host firewall, in which a router operating at a network level controls access to and from a single host.

The single host is a bastion host - a highly-defended and secured strong-point that can resist attack. javascript: displayWindow ('images / apd -01. jpg', 500,262) javascript: displayWindow ('images / apd -01. jpg', 500,262) Figure D. 1 Screened Host Firewall Figure D. 2 shows a screened sub net firewall. In a screened sub net firewall, a router at the network level controls access to and from a whole network. It is similar to a screened host, except that it is effectively a network of screened hosts. javascript: displayWindow ('images / apd -02. jpg', 500,261) javascript: displayWindow ('images / apd -02. jpg', 500,261) Figure D. 2 Screened Subnet Firewall Application-level firewalls are generally hosts running proxy servers, which permit no traffic directly between networks and log and audit traffic passing through them. Because the proxy applications are software components running on the firewall, the proxy is a good place to do lots of logging and access control. Application-level firewalls can be used as network address translators, because traffic goes in one side and out the other after passing through an application that effectively masks the origin of the initiating connection.

Having an application in the way may affect performance in some cases and may make the firewall less transparent. Early application-level firewalls, such as those built using the TIS firewall toolkit (FWTK), are not particularly transparent, and users may require some training. Modern application-level firewalls are often fully transparent. Application-level firewalls tend to provide more detailed audit reports and enforce more conservative security models than network-level firewalls. Figure D. 3 shows a dual-homed gateway, a highly secured host that runs proxy software.

It has two network interfaces, one on each network, and blocks all traffic passing through it. javascript: displayWindow ('images / apd -03. jpg', 500,219) javascript: displayWindow ('images / apd -03. jpg', 500,219) Figure D. 3 Dual-Homed Gateway The future of firewall technology lies somewhere between network-level firewalls and application-level firewalls. It is likely that network-level firewalls will become increasingly 'aware' of the information going through them and that application-level firewalls will become increasingly low-level and transparent. The result will be a fast packet-screening system that logs and audits data as it passes through. Increasingly, both network and application firewalls incorporate encryption so they can protect traffic passing between them over the Internet. Organizations with multiple points of Internet connectivity can use firewalls with end-to-end encryption to make the Internet their 'private backbone' without worrying about someone sniffing their data or passwords. WHAT ARE PROXY SERVERS AND HOW DO THEY WORK?

The definition of a proxy is 'the authority to act on behalf of another,' and that's exactly what a proxy server does. A proxy server, sometimes called an application gateway or forwarder, is an application that mediates traffic between a protected network and the Internet. Proxies are often used instead of router-based traffic controls to prevent traffic from passing directly between networks. Many proxies contain extra logging features or support user authentication. Because proxies must understand the application protocol being used, they can also implement protocol-specific security. For example, an FTP proxy might be configurable to permit incoming FTP and block outgoing FTP.

Proxy servers are application specific. A new protocol must be developed for every new application supported. One popular set of proxy servers is the TIS firewall toolkit (FWTK), which includes proxies for Telnet, r login, FTP, X-Window, http / Web, and NNTP / Usenet news. SOCKS is a generic proxy system that can be compiled into a client-side application to make it work through a firewall. Its advantage is that it's easy to use, but it doesn't support the addition of authentication hooks or protocol-specific logging. For more information about SOCKS, point your Web browser to ftp: //ftp. nec. com / pub /security / socks. cst c.

Check the file named Files for a description of the directory's contents. WHAT ARE SOME CHEAP PACKET-SCREENING TOOLS? The Texas A&M University (TAMU) security tools include software for implementing screening routers (ftp: //net. t amu. edu / pub /security / TAMU). Karl bridge is a PC-based screening router kit (ftp: //ftp. net. ohio-state. edu / pub /k bridge). A version of the Digital Equipment Corporation kernel-screening software, screen, is available for BSD/386, NetBSD, and BSDI.

A kernel-level packet screen called ip filter is available for free for BSD-based systems. Many commercial routers support screening of various forms. WHAT ARE SOME REASONABLE FILTERING RULES FOR A CISCO ROUTER? The following example, shown in Figure D. 4, displays one possible configuration of a Cisco router as filtering router. It shows the implementation of a specific example policy; your policy will undoubtedly vary. javascript: displayWindow ('images / apd -04. jpg', 500,234) javascript: displayWindow ('images / apd -04. jpg', 500,234) Figure D. 4 Sample Cisco Router Configuration In this example, a company has Class C network address of 195.55.

55.0. The company network is connected to the Internet via an ISP. The company policy allows everybody access to Internet services, so all outgoing connections are accepted. All incoming connections go through the machine called mail host. Mail and DNS are the only incoming services. IMPLEMENTATION Here are the rules this sample implementation uses: o Allow all outgoing TCP-connections o Allow incoming SMTP and DNS to mail host o Allow incoming FTP data connections to high TCP port ( 1024) o Try to protect services that live on high port numbers The only packets checked in this configuration are packets from the Internet.

The rules are tested in order and stop when the first match is found. An implicit 'deny' rule at the end of the access list denies everything else. This IP access list, shown below, assumes that you are running Cisco IOS vs. 10.3 or later. 1. no ip source-route 2.! 3. interface ethernet 04. ip address 195.55. 55.15.! 6. interface serial 07. ip access-group 101 in 8.! 9. access-list 101 deny ip 195.55. 55.0 0.0. 0.25510. access-list 101 permit tcp any any established 11.!

12. access-list 101 permit tcp any host 195.55. 55.10 eq stp 13. access-list 101 permit tcp any host 195.55. 55.10 eq d ns 14. access-list 101 permit udp any host 192.55. 55.10 eq d ns 15.! 16. access-list 101 deny tcp any any range 6000 600317. access-list 101 deny tcp any any range 2000 200318. access-list 101 deny tcp any any eq 204919. access-list 101 deny udp any any eq 20420.! 21. access-list 101 permit tcp any 20 any gt 102422.!

23. access-list 101 permit icm p any any 24.! 25. snap-server community FOOBAR RO 226. line vt y 0 427. access-class 2 in 28. access-list 2 permit 195.55. 55.0 255.255. 255.0 Configuration Explanation Drop all source-routed packets because source routing can be used for address spoofing. o If an incoming packet claims to be from the local network, drop the packet. o Pass without further checking all packets that are part of an already-established TCP connection. o Block all connections to low port numbers except SMTP and DNS. o Block all services that listen for TCP connections on high port numbers. X-windows (port 6000+) and Open Windows (port 2000+) are candidates. NFS (port 2049) runs usually over UDP, but it can be run over NFS, so block it, too. o Check incoming connections from port 20 into high port numbers; they are supposed to be FTP data connections. o Limit access to the router itself (Telnet & SNMP) with access-list 2. o Block all UDP traffic to protect RPC services.

SHORTCOMING So You cannot enforce strong access policies with router access lists. Users can easily install back doors to their systems to get past 'no incoming Telnet' or 'no X' rules. Also, some crackers can install Telnet back doors on systems after they break in. o You can never be sure what services are listening for connections on high port numbers. o Checking the source port on incoming FTP data connections is a weak security method because it makes using back doors more difficult, but it doesn't prevent hackers from scanning your systems. Another drawback is that it breaks access to some FTP sites. Use Cisco code version 9.21 or later (current version is 10.3) so you can filter incoming packets and check for address spoofing. It's always best to use the most current version, because you get extra features (like filtering on source ports) and some improvements on overall filter syntax.

You still have a few ways to make your setup stronger. Block all incoming TCP connections, and tell users to use passive-FTP clients. You can also block outgoing ICMP echo-reply and destination-unreachable messages to hide your network and to prevent the use of network scanners. The Cisco FTP site has an archive of examples for building firewalls using Cisco routers (ftp: //ftp. cisco. com / pub /all-examples. tar.

Z). Those examples are a bit out-of-date, but some perl scripts are pretty useful once they " ve been adjusted for your network. HOW DO I MAKE WEB / HTTP WORK THROUGH MY FIREWALL? You have three ways to make Web / HTTP work through your firewall. o Allow 'established' connections an outward path via a router, if you are using screening routers. o Use a Web client that supports SOCKS and run SOCKS on your firewall. o Run some kind of proxy-capable Web server on the firewall.

The TIS Firewall Toolkit (FWTK) includes a proxy called http-gw, which proxies Web, gopher / gopher + and FTP. CERN http also has a proxy capability, which many sites use in combination with the server's cache of frequently accessed pages. Microsoft has a great Proxy Server that supports most of the functions you might need. Many Web clients, including Netscape, Mosaic, Spry, and Chameleon, have proxy server support built directly into them. HOW DO I MAKE DNS WORK WITH A FIREWALL? Some organizations want to hide DNS names from the outside world.

Although many experts don't think hiding DNS names is worthwhile, it is one approach that is known to work. If you have a nonstandard addressing scheme on your internal network, you have no choice but to hide those addresses. Don't fool yourself into thinking that hiding your DNS names slows down attackers. Information about what is on your network is too easily gleaned from the networking layer itself. For an interesting demonstration, ping the sub net broadcast address on your LAN and then issue the 'arp -a' command. Also note that hiding names in the DNS doesn't address the problem that host names leak out in mail headers and news articles.

If you want to hide DNS names, you have many options. The following approach is one of many. The success of this approach lies in the fact that DNS clients on a machine don't have to talk to a DNS server on that same machine. In other words, even though a DNS server is on a machine, you can redirect that machine's DNS client activity to a DNS server on another machine.

First, on the bastion host, set up a DNS server that the outside world can talk to so that it claims to be authoritative for your domains. In fact, all this server knows is what you want the outside world to know - the names and addresses of your gateways, your wildcard MX records, and so forth. This server is your public server. Then set up a DNS server on an internal machine. This server also claims to be authoritative for your domains; unlike the public server, this one is telling the truth.

This is your 'normal' name server, into which you put all your normal DNS stuff. You also set up this server to forward queries that it can't resolve to the public server (using a forward line in the named. boot table, for example). This approach assumes that a packet-filtering firewall between these two servers lets them talk DNS to each other but otherwise restricts DNS between other hosts. Finally, set up all your DNS clients (the resolve. conf file, for instance), including the ones on the machine with the public server, to use the internal server. This step is the key. An internal client asking about an internal host asks the internal server and gets an answer; an internal client asking about an external host asks the internal server, which asks the public server, which asks the Internet, and the answer is relayed back.

A client on the public server works just the same way. An external client, however, asking about an internal host gets back the restricted answer from the public server. Another trick that's useful in this scheme is to use wildcard PTR records in your IN-ADDR. ARPA domains.

That way, an address-to-name lookup for any of your non-public hosts returns a response such as 'unknown. YOUR. DOMAIN' instead of returning an error. This response satisfies anonymous FTP sites like ftp. uu. net that insist on having a name for the machines they talk to. This strategy may fail when you attempt to connect to sites that do a DNS cross-check in which the host name is matched against its address and vice versa. HOW DO I MAKE FTP WORK THROUGH MY FIREWALL?

Generally, to make FTP work through the firewall, you either set up a proxy server, such as the TIS firewall toolkit's ftp-gw or Microsoft's Proxy Server, or you permit incoming connections to the network at a restricted port range and otherwise restrict incoming connections using something like 'established's creening rules. You then modify the FTP client to bind the data port to a port within that range. Obviously, you must be able to modify the FTP client application on internal hosts. If FTP downloads are all you wish to support, you might want to consider declaring FTP a 'dead protocol' and letting your users download files via the Web instead.

The user interface certainly is nicer, and this setup gets around the ugly callback port problem. If you choose the FTP-via-Web approach, your users won't be able to FTP files out, which may be a problem, depending on your setup. A different approach is to use the FTP PASV option to indicate that the remote FTP server should permit the client to initiate connections. The PASV approach assumes that the FTP server on the remote system supports that operation.

(See RFC 1579 for more information.) Other sites prefer to build client versions of the FTP program that are linked against a SOCKS library. HOW DO I MAKE TELNET WORK THROUGH MY FIREWALL? You can support Telnet either by using an application proxy, such as the TIS firewall toolkit's tn-gw or Microsoft's Proxy Server, or by simply configuring a router to permit outgoing connections using something like the 'established's creening rules. An application proxies could be a standalone proxy running on the bastion host or a SOCKS server and a modified client. HOW DO I MAKE FINGER AND WHOIS WORK THROUGH MY FIREWALL? Many firewall administrators permit connections to the finger port from only trusted machines, which issues finger requests in the form of finger ain@firewall.

This approach works only with the standard Unix version of finger. You can restrict access to services to specific machines by using either tcp wrappers or from the TIS firewall toolkit. This approach does not work on all systems because some finger servers do not permit user@host@host fingering. Many sites block inbound finger requests for a variety of reasons, most often because of past security bugs in the finger server (the Morris internet worm made these bugs famous) and because of the risk of revealing proprietary or sensitive information in a user's finger information. In general, if your users are accustomed to putting proprietary or sensitive information in their. plan files, you have a more serious security problem than a firewall can solve. HOW DO I MAKE GOPHER, ARCHIE, AND OTHER SERVICES WORK THROUGH MY FIREWALL?

The majority of firewall administrators support gopher and Archie through Web proxies. Proxies such as the TIS firewall toolkit's http-gw converts Gopher / Gopher+ queries into HTML and vice versa. For supporting Archie and other queries, many sites rely on Internet-based Web-to-Archie servers, such as Archie Plex. The Web's tendency to make everything on the Internet look like a Web service is both a blessing and a curse.

Many new services are constantly cropping up. Often they are not designed with security in mind, and their designers cheerfully tell you that if you want to use them, you need to let port through your router. Unfortunately, not everyone can do that, and a number of interesting new toys are difficult to use for people behind firewalls. Real Audio, which requires direct UDP access, is a particularly egregious example; remember that Microsoft's Proxy Server handles Real Audio. If you find yourself faced with one of these problems, remember to find out as much as you can about the security risks that the service may present before you allow it through. It's quite possible the service has no security implications.

It's equally possible that it has undiscovered holes you could drive a truck through. WHAT ARE THE ISSUES ABOUT X-WINDOWS THROUGH A FIREWALL? X-Windows is a very useful system, but it unfortunately has some major security flaws. Remote systems that can gain or spoof access to a workstation's X display can monitor a user's keystrokes and download copies of the contents of their windows.

Although attempts have been made to overcome problems - for example, MIT 'Magic Cookie' - it is still entirely too easy for an attacker to interfere with a user's X display. Most firewalls block all X traffic. Some permit X traffic through application proxies such as the DEC CRL X proxy (FTP cry. Dec. com). The TIS FWTK includes a proxy for X, called x-gw, which a user can invoke via the Telnet proxy, to create a virtual X server on the firewall. When a user requests an X connection on the virtual X server, the user is presented with a pop-up menu asking whether it is OK to allow the connection.

Although this setup is a little unaesthetic, it's entirely in keeping with the rest of X. WHAT IS SOURCE-ROUTED TRAFFIC AND WHY IS IT A THREAT? Normally, the route a packet takes from its source to its destination is determined by the routers between the source and destination. The packet itself says only where it wants to go (the destination address) and nothing about how it expects to get there. The sender of a packet (the source) has the option to include information in the packet that tells the route the packet should follow to get to its destination; thus the name 'source routing. ' For a firewall, source routing is noteworthy, because an attacker can generate traffic that claims to be from a system 'inside' the firewall. In general, such traffic wouldn't route to the firewall properly, but with the source routing option, all the routers between the attacker's machine and the target return traffic along the reverse path of the source route.

Implementing such an attack is quite easy; so firewall builders should not discount the possibility. In practice, source-routing is used very little. In fact, its main legitimate use is in debugging network problems or routing traffic over specific links to control congestion in special situations. When building a firewall, you should block source routing at some point. Most commercial routers incorporate the specific ability to block source routing, and many versions of Unix that you might use to build firewall bastion hosts have the ability to disable or ignore source-routed traffic.

WHAT ARE ICMP REDIRECTS AND REDIRECT BOMBS? An ICMP redirect tells the recipient system to override something in its routing table. This feature is legitimately used by routers to tell hosts that the host is using a non-optimal or defunct route to a particular destination; that is, the host is sending it to the wrong router. The wrong router sends the host an ICMP Redirect packet that tells the host what the correct route should be. If you can forge ICMP Redirect packets, and if your target host pays attention to them, you can alter the host's routing tables and possibly subvert its security by changing the paths traffic uses. ICMP redirects may also be used in denial-of-service attacks, in which a host is sent a route that loses it connectivity or a host is sent an ICMP Network Unreachable packet telling it that it can no longer access a particular network.

Many firewall builders screen ICMP traffic from their network, because screening limits outsiders' ability to ping hosts and modify their routing tables. WHAT ABOUT DENIAL OF SERVICE? A denial-of-service attack occurs when someone makes your network or firewall useless by disrupting it, crashing it, jamming it, or flooding it. Denial of service is impossible to prevent because of the distributed nature of the network: every network node is connected via other networks, which in turn connect to other networks. A firewall administrator or ISP has control of only a few of the local elements within reach. An attacker can always disrupt a connection 'upstream' from where the victim controls it.

In other words, someone who wants to take a network off the air can either take the network off the air directly or take the network it connects to off the air, or the network that connects to that network off the air, ad infinitum. Hackers can deny service in many ways, ranging from the complex to the brute-force. If you are considering using the Internet for a service that is absolutely time- or mission-critical, you should consider your fallback position in the event that the network is down or damaged. Microsoft has released hot fixes that address certain types of denial-of-service attacks such as SYN Flooding and giant Ping packets.

Be sure to regularly watch for new Service Packs, because they offer new security enhancements that you should put on your systems.