Messages in this thread Patch in this message | | | From | Paul Rusty Russell <> | Subject | [PATCH] More Documentation/Changelog fixes | Date | Mon, 21 Sep 1998 00:46:02 -0700 |
| |
Linus, please apply.
In order:
1) CONFIG_IP_FIREWALL_NETLINK no longer pumps the first 128 bytes for every blocked packet; it must be set on a per-rule by `ipchains'.
2) CONFIG_IP_TRANSPARENT_PROXY required ipchains, not ipfwadm, to set up redirection.
3) CONFIG_IP_ALWAYS_DEFRAG is still a good idea for packet filtering firewalls, but second and furthur fragments are no longer accepted by default.
Rusty. --- linux/Documentation/Configure.help.~1~ Mon Sep 21 00:17:49 1998 +++ linux/Documentation/Configure.help Mon Sep 21 00:34:57 1998 @@ -2080,9 +2080,9 @@ IP: firewall packet netlink device CONFIG_IP_FIREWALL_NETLINK - If you say Y here, then the first 128 bytes of each packet that hit - your Linux firewall and was blocked are passed on to optional user - space monitoring software that can then look for attacks and take + If you say Y here, then you can use the ipchains tool to tell the + Linux firewall to pass (all or part of) certain packets to optional + user space monitoring software that can then look for attacks and take actions such as paging the administrator of the site. To use this, you need to create a character special file under /dev @@ -2090,9 +2090,6 @@ and you need (to write) a program that reads from that device and takes appropriate action. - With the ipchains tool you can specify which packets you want to go - to this device, as well as how many bytes from each packet. - IP: kernel level autoconfiguration CONFIG_IP_PNP This enables automatic configuration of IP addresses of devices and @@ -2171,7 +2168,7 @@ server". This makes the local computers think they are talking to the remote end, while in fact they are connected to the local proxy. Redirection is activated by defining special input firewall - rules (using the ipfwadm utility) and/or by doing an appropriate + rules (using the ipchains utility) and/or by doing an appropriate bind() system call. IP: masquerading @@ -2283,14 +2280,14 @@ This option is highly recommended if you have said Y to "IP: masquerading" because that facility requires that second and further fragments can be related to TCP or UDP port numbers, which are only - stored in the first fragment. When using "IP: firewalling" support , - you might also want to say Y here, to have a more reliable firewall - (otherwise second and further fragments will always be accepted by - the firewall). When using "IP: transparent proxying", this option is - implicit, although it is safe to say Y here. Only say Y here if - running either a firewall that is the sole link to your network or a - transparent proxy; never ever say Y here for a normal router or - host. + stored in the first fragment. Similarly, when using "IP: + firewalling" support, you might also want to say Y here, to allow + creation of a more reliable firewall (setting up firewalling without + having to worry about fragments is far easier). When using "IP: + transparent proxying", this option is implicit, although it is safe + to say Y here. Only say Y here if running either a firewall that is + the sole link to your network or a transparent proxy; never ever say + Y here for a normal router or host. IP: aliasing support CONFIG_IP_ALIAS -- .sig lost in the mail.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |