exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

node2.html

node2.html
Posted Aug 17, 1999

node2.html

tags | tool, firewall
systems | unix
SHA-256 | b5c5bd271bb41a2f7dbc06a9a014da6e80eecc51c6f97dbb74352538527ec0d6

node2.html

Change Mirror Download
<HTML>
<HEAD>
<TITLE>
</TITLE>
</HEAD>
<BODY VLINK="#551A8B" TEXT="#2d5c8a" BGCOLOR="#ffffff" LINK="#0000EE" ALINK="#FF0000">

<A NAME="tex2html32" HREF="node3.html"><IMG WIDTH="37" ALT="next" SRC="next_motif.gif" HEIGHT="24" ALIGN="BOTTOM"></A> <A NAME="tex2html30" HREF="linuxfw2.html"><IMG WIDTH="26" ALT="up" SRC="up_motif.gif" HEIGHT="24" ALIGN="BOTTOM"></A> <A NAME="tex2html24" HREF="node1.html"><IMG WIDTH="63" ALT="previous" SRC="previous_motif.gif" HEIGHT="24" ALIGN="BOTTOM"></A> <BR>
<B> Next:</B> <A NAME="tex2html33" HREF="node3.html">Kernel filtering scheme</A>
<B>Up:</B> <A NAME="tex2html31" HREF="linuxfw2.html">Linux firewall facilities for </A>
<B> Previous:</B> <A NAME="tex2html25" HREF="node1.html">Introduction</A>
<BR> <P>
<H1><A NAME="SECTION00020000000000000000">IP packet filtering</A></H1>
<P>
Before describing the Linux implementation of IP packet filtering,
we will briefly introduce the underlying general concepts.
<P>
IP packet filters inspect network datagrams (IP packets) and decide
whether these packets are allowed to pass the filter or not.
These inspections may take place at several stages, like the moment
packets arrive on the system or when they are about to be forwarded to
another system.
<P>
The decision to let a filter block certain packets is usually
based on several criteria, being checked against the contents of the IP
packet and some environmental parameters:
<UL>
<LI>
Source and destination IP addresses.
This allows an administrator to restrict the traffic through
the system by allowing only packets coming from (or sent to)
a set of well-known hosts or networks.
These addresses can be found in the header of every IP packet.
<LI>
Protocol, like <EM>TCP</EM>, <EM>UDP</EM>, or <EM>ICMP</EM>, which can also be
found in the IP header.
<LI>
IP options.
One of the more well-known options is the <EM>source route</EM> option,
which can be considered to be dangerous in itself.
Packets carrying this option are often refused.
<LI>
Source and destination port numbers, associated with TCP or UDP services.
These port numbers can be found in the TCP and UDP header.
Filters using port numbers can restrict the network traffic to a limited
set of services, each of which is associated with a well-known port.
<LI>
TCP flags, being part of the TCP header.
Most packet filters allow the TCP <EM>ACK</EM> and/or <EM>SYN</EM> bits
to be checked, indicating whether a new connection is being set up
or not.
This is particularly useful when you want to allow some TCP sessions
being initiated only from one side (e.g., only from hosts in your
own network).
<LI>
ICMP message types, being defined in ICMP packets.
This enables you to restrict ICMP traffic to a limited set of
message types.
You may, for example, want to refuse
<EM>Echo Request</EM> packets (as used by the <EM>ping</EM> utility).
<LI>
User data, found in the (protocol-specific) data part of the IP packet.
This is a tricky one, which normally doesn't belong in IP packet filters,
although in some cases its use can't be avoided.
<LI>
Network device, via which a packet is received or is going to be sent.
This enables you to let a filter act differently for different
network devices (like external and internal interfaces).
<LI>
Date and time.
This can be used to limit some types of network traffic to office hours,
for example.
</UL>
Some of these criteria are easy to check, such as the ones being
part of the IP header.
Others may be more difficult to handle, such as the information
found in the TCP/UDP headers.
One IP packet, for example, may be split up in two or more IP fragments,
of which only the first fragment contains the TCP header.
Furthermore, IP packets may not pass the filter in sequence, because
session control is handled in the TCP layer.
Some packet filters address some of these problems, others don't.
<P>
An IP packet filter can react in different ways to packets, depending
on the filters and the capabilities of the filtering system.
The most obvious actions are: let the packet pass the filter normally
or drop the packet silently.
Some filters also offer the possibility to send some notification
(like an
<EM>ICMP Destination Unreachable</EM> message) back to the sender,
in case a packet is blocked by the filter.
Besides that, filters often include some logging facility, to facilitate
the network administrator in detecting if someone is trying to
break in.
<P>
There are several ways to implement packet filters in a UNIX system.
The most efficient way is to implement it in the kernel.
One of the disadvantages of this method is that it is not very flexible.
Another method is to let some user-level process do the filtering.
Such a daemon process has to get the relevant information of all IP packets
(at least part of the IP and TCP/UDP headers, possibly even the data part) via
some system call, apply its filter rules, and pass the answer back to
the kernel.
The (freely available) <EM>screend</EM> package behaves like this.
The major drawback of these implementations is the considerable overhead
generated by the system calls and process scheduling.
<P>
<HR><A NAME="tex2html32" HREF="node3.html"><IMG WIDTH="37" ALT="next" SRC="next_motif.gif" HEIGHT="24" ALIGN="BOTTOM"></A> <A NAME="tex2html30" HREF="linuxfw2.html"><IMG WIDTH="26" ALT="up" SRC="up_motif.gif" HEIGHT="24" ALIGN="BOTTOM"></A> <A NAME="tex2html24" HREF="node1.html"><IMG WIDTH="63" ALT="previous" SRC="previous_motif.gif" HEIGHT="24" ALIGN="BOTTOM"></A> <BR>
<B> Next:</B> <A NAME="tex2html33" HREF="node3.html">Kernel filtering scheme</A>
<B>Up:</B> <A NAME="tex2html31" HREF="linuxfw2.html">Linux firewall facilities for </A>
<B> Previous:</B> <A NAME="tex2html25" HREF="node1.html">Introduction</A>
<P><ADDRESS>
This version of the paper is based on Linux 2.0.25 and ipfwadm 2.3.0.
<BR>
Currently, only this multi-page HTML version is available.
In the future, also a single-page HTML version (for off-line reading)
and a PostScript version will become available.
<P>
Copyright © 1996 by X/OS Experts in Open Systems BV.
All rights reserved.
</ADDRESS>
</BODY>
</HTML>
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close