Showing posts with label addresses. Show all posts
Showing posts with label addresses. Show all posts

Monday, April 7, 2008

Filtering Based on Port Numbers

The TCP and UDP protocols use port numbers in their header information to identify applications. Although filtering based on IP addresses blocks all network traffic from a particular source, you can use filtering rules that block only specific ports. Thus, you might allow customers to interact with Web servers inside your network using the ports set aside for WWW activity—port 80, for typical WWW traffic—but block other ports, such as port 23 that is used for Telnet functions.

As another example, you might want to allow some users to use Telnet (port 23) or FTP (ports 20 and 21) to connect to servers outside the corporate network while denying this capability to others. You can do this by setting up rules in the packet filter and specifying both a host source address and a port number. Ports are a two-way path. You can block incoming connections, outgoing connections, or both for each port.

Internet 2010

Packet filtering is an integral component of most every firewall and has several advantages:

  • Usually inexpensive—If you use a router to connect to external sources, you already have th hardware—you just need to configure it.
  • Fast—It does only minimal processing on the header information and does not make decision based on multiple packets.
  • Flexible—It is easy, although some would say cumbersome, to configure as many address inclusions or exclusions as you like.

However, there are also several disadvantages to using a packet filter firewall:

  • Packet filters perform no authentication—A packet is a packet no matter "who" the sender is. The address is the only thing that counts. This is important because IP addresses, ports, and any other part of the packet can be forged using simple tools available on the Internet.
  • Most system administrators don't take advantage of a router's auditing features– You will most likely not even know that attempts were made to break in to the network; if the router does provide some kind of statistical information, you won't be able to determine where the attack came from. If you turn on logging for every packet that comes through your router, you'll experience a tremendous slowdown in network response time through the router. Selectively logging events is a better option, but then again you might miss important events. Small SOHO routers do not provide logging, so keep that in mind if you use one.
  • Packet filters operate at the network level—They are not very effective at stopping sophisticated attacks that are directed at higher-level protocols, such as TCP.
  • Internal network information is not kept from outside prying eyes—Using ordinary utilities, such as Tracert and Ping, mischievous persons can gain knowledge about your network unless you specifically block the protocol used by these utilities (ICMP).

If you had the choice, which of the following would you choose:

  • Allow everything, but deny specific addresses.
  • Deny everything, but allow selected known good addresses.

If it's not obvious that the second choice is the best, you need to stop and think about this again.

A good approach for configuring the rules to use on a packet filter is to first deny all traffic. Then, selectively enable only those addresses or services that are essential to your business. If you try to do this in reverse—allowing all traffic and then denying specific items—there's no way you can create a set of rules that covers all possible sources of mischief. You might leave out something that didn't seem important at the time you did the configuration, or a new twist on an old technology might creep up and surprise you later.

Thursday, February 28, 2008

Other IDS Features to Consider

So far you've seen that Stalker and CMDS are complementary system-level IDSs that catch a number of attacks which scanners and network sniffers cannot The next few sections summarize some other important issues to consider about system intrusion detection.

Ease of Set Up

Both Stalker and CMDS are distributed, client-server products. Depending on your network configuration, the installation and setup can be simple or complex. The usual rule of "your mileage may vary" is a good one to keep in mind.

Agent code must be installed on each CMDS target or Stalker agent. Although some autodiscovery is provided, the Server or Manager will need to be made aware of which nodes to monitor. The time it takes to configure nodes is a small constant value in most cases, but you need to multiply this value by the number of nodes you have.

Internet 2010

As with most systems that rely on host names and IP addresses for identification, the use of dynamic host configuration protocol (DHCP) or regular changes to host identifiers will require additional administration. If you treat all monitored nodes uniformly, administration is simpler. However, if you want to analyze different statistics or attack patterns on each node, your administrative workload also will increase. Any variability in your monitoring requirements per node naturally will drive configuration changes on either agents or servers/ managers.

Distributed Intrusion Detection

Neither Stalker nor CMDS track the activities of a given user across multiple systems unless the assumption is that a person will have the same UID across all systems in the enterprise. Because this assumption is highly unlikely—even though the login name might be the same, the UIDs across systems may not be equivalent—tracking the activities of a single user throughout the enterprise is not straightforward.

One solution would be to add to each audit record, when consolidated on the server, with the originating host IP address. Unfortunately, this solution does not work for systems with multiple network adapters because the node will have several IP addresses. Also, in sites where IP addresses are assigned dynamically with DHCP, relying on an IP address to be meaningful would be a mistake because it could be reassigned at a future time. The host's name would probably be more reliable. When consolidating activities across systems, CMDS relies on the host's name and UID paired together to uniquely identify a user.

Distributed systems management framework vendors, such as Tivoli, are all too aware of this identity problem in networked environments. The favored approach is to assign a framework-specific host identifier that is persistent across changes in IP addresses or other system parameters, such as the planar ROM ID. Assigning a network user name that is independent of the system on which a user operates also would be useful. However, such an extension would require changes in core parts of the OS, such as the login process and the generation of audit records, in order to track user activities across multiple systems. One research project prototyped this approach for intrusion detection across systems (Snapp et al., 1991).

Internet Blogosphere