diff options
Diffstat (limited to 'sbin/ipfw')
| -rw-r--r-- | sbin/ipfw/README | 610 | ||||
| -rw-r--r-- | sbin/ipfw/ipfirewall.4 | 206 | ||||
| -rw-r--r-- | sbin/ipfw/ipfw.1 | 527 |
3 files changed, 0 insertions, 1343 deletions
diff --git a/sbin/ipfw/README b/sbin/ipfw/README deleted file mode 100644 index 1cc296c45631..000000000000 --- a/sbin/ipfw/README +++ /dev/null @@ -1,610 +0,0 @@ -***************************************************************************** -27 Oct 94 -Hi again! -So thanx to Brian McGovern , i'v took this piece of code in hands again -and made some changes: - 1) Port to FreeBSD 2.0 , so we will not go after time. - 2) Some minor changes in kernel part to improve speed and such.. - 3) Chane in behaviour: now any recently added firewall definition - preferred on other matching but older firewalls. - REMEMBER: in any case universal IP firewall has larger preference - then special TCP/UDP/ICMP firewalls. - 4) Cosmetical changes to control programm. Now it is called ipfw. - 5) Changed ip_firewall.* to ip_fw.* in kernel,and shortened some long - variable names. - 6) From now on we have user defined *policy*,which is DENY/ACCEPT for - every packet which does not matches any of firewalls.I.e.: if any - firewall defined and packet does not match them you may set it up - so it will be anyway throwed or anyway accepted. -Mostly that's all. -Bye! - --- - -= Ugen J.S.Antsilevich =- - NetVision - Commercial Internet Provider ------------------------------------------------------[C]--- -NetVision - Home of Israeli Commercial Internet - E-mail: ugen@NetVision.net.il - HTTP: http://www.NetVision.net.il/~ugen/ - Phone: +972-4-550330 Fax: +972-4-550122 - -***************************************************************************** -10 Jul 94 -Hi again...So i sitted and stared at this nice working tool and thought to -myself that it's nice but something there it needs and have not.. -So i took a piece of file and a keyboard and typed some strings. -What it was is: - -o List facility improved...Now listing of currently installed firewall - entries does not go through kernel printf's ,which is really unnice to - one who runs it NOT from console:) - -o Really important facility of deleting entries added..Yes , till this - day you had to remove all entries and then add them one by one again - to remove actually just one.Now it's over:) - -o All this changes documented in this readme,while you will see where i - added my words just by vast number of mistaces in English.Well,i hope - you will forgive one Russian guy like me:) - -So enjoy this new code and if you think it needs some additions - you -are welcome to suggest.Also i made some more warnings , while compiling -this code,i have no a clue where do they come from,however they does not -make any bad to programm.But if you will find way to remove them,feel free -to do it and post anywhere(and notify me as i also need this:) - - Bye! Ugen J.S.Antsilevich - - -########################################################################## -# Ugen J.S.Antsilevich NetVision (Israel) System Staff Member # -#------------------------------------------------------------------------# -# Email: ugen@NetVision.net.il | Phone: 972-4-550330 # -# ugen@NetManage.co.il | Fax: 972-4-550122 # -#------------------------------------------------------------------------# -# WWW HomePage: http://www.NetVision.net.il/~ugen # -# Special : Volk@Les.Tambov.SU # -########################################################################## - - -***************************************************************************** -8 Jul 94 -OK..so first of all,this is simple port to FreeBSD by Ugen J.S.Antsilevich -Actually all i had to do is to find appropriate place in kernel source files -for ipfirewall stuff..so all your thanks should go to the author... -Anyway i am porting it now to 1.1.5 (not much job though..:) so if you want -to ask something about write to me: - -ugen@NetVision.net.il - -That's it and let the --==REAL==-- author speak... -***************************************************************************** - -Here's my ipfirewall facility. I consider it to still be beta quality mostly -because the various interfaces are pretty crude. Here's some information that -you'll probably find useful (in roughly the order in which you'll need to know -it). Some of this will be absurdly simplistic. Better safe than sorry... - -This software was written for BSD/386. The current version has been ported -to BSD/386 v1.1. The context diffs are with respect to that version of -BSD/386. If you don't have access to BSD/386 v1.1 and can't make sense out of -the diffs, contact me and I'll send you the entire files (they are copyrighted -by UC-Berkeley with very 'friendly' conditions). - -Speaking of copyrights, here's mine: - -/* - * Copyright (c) 1993 Daniel Boulet - * Copyright (c) 1994 Ugen J.S.Antsilevich - * - * Redistribution and use in source forms, with and without modification, - * are permitted provided that this entire comment appears intact. - * - * Redistribution in binary form may occur without any restrictions. - * Obviously, it would be nice if you gave credit where credit is due - * but requiring it would be too onerous. - * - * This software is provided ``AS IS'' without any warranties of any kind. - */ - -Enough introductory stuff, here we go... - - 1) The file IPFIREWALL is the configuration of kernel i use with - IPFIREWALL and GATEWAY options enabled. You may not find it useful. - About the only key things are that it enables the IPFIREWALL - option and the GATEWAY option. IPFIREWALL turns on my - stuff and GATEWAY turns your machine into an IP router. - - There is nothing magical about the name of this file or the - ident name for the kernel. - - 2) The files ip_fw.c and ip_fw.h are new files that should be - placed into the /usr/src/sys/netinet directory. - - 3) The files ip_input.c and raw_ip.c are new patched versions of the - same files , they made up for version 2.0 of FreeBSD,however it was - some pre-Beta release we worked on , so to add it to other releases - just find all parts of code surrounded by: - #ifdef IPFIREWALL - .... - #endif - and place in the appropriate places in the same files. - All those files are in /usr/src/sys/netinet directory of corse. - - 4) Add the line "netinet/ip_fw.c optional ipfirewall" to the - file /usr/src/sys/conf/files. This tells the config program to - include the netinet/ip_fw.c file if the IPFIREWALL option is - defined for a kernel. - - 5) The Makefile and ipfw.c files should go into directory probably - back in your home directory tree somewhere. If this ever becomes a - part of the system then they should go into the (newly created) - directory /usr/src/sbin/ipfw. - - 6) Build yourself a kernel, make a backup of the current kernel and - and install the new one. It should behave in a completely normal - fashion since you won't have defined any firewalls yet. - - 7) Explore the ipfw program. The smartest way to do this is to - compile the program and then run it.To do it you SHOULD be root - as the programm uses setsockopt on RAW sockets to define firewalls, - and also reads kernel symbols.If any other user will run ipw - it will detect that it isn't being run by root and will just - complain and exit. - The ipfw program takes command line parameters - and (assuming they are valid) issues a single appropriate setsockopt - call. If you're defining 5 firewalls then you'll have to run the - program 5 times. See below for a description of the command syntax - of ipfirewall. - - ==================================================================== - WARNING!!! WARNING!!! WARNING!!! WARNING!!! WARNING!!! WARNING!!! - The ipfw program can be used to put your machine into very - disfunctional state.So if you want to test it make sure you - a) Have read carifully this README till it's end. - b) First time run it from machine console,as else you can - simply shut down your own access to it. - ==================================================================== - Make sure that you never setup the program as setuid root!!! Instead, - always run it from the root command line or from "/etc/rc.local" - as part of the boot process. - - 8) Use the "ipfirewall" checkb or checkf command (see below) to pass some - test packets through the firewalls that you've defined. - - 9) You may find it useful to create a file in which the first line is - "ipfirewall flush" to flush any existing firewalls and the remaining - lines are the ipfirewall commands needed to define the firewalls that - you want to use. This will ensure that you're always working from a - known state. - - 10) If you've gotten this far then you're probably ready to let the critter - see prime time. Copy your file of ipfirewall commands into the - /etc/rc.local file and reboot the system. Once you're up, use the - ipfirewall list command to see that you've got the firewalls that you - wanted and try to test the firewall with real packets from trusted - and untrusted hosts. - -Enough of that. Here's the syntax for the ipfirewall command. It is rather -complex and yet simple at the same time (if you know what I mean). There -are seven sub-commands. Probably the easiest way to get into this is to give -you a roughly BNF style grammar for the command (curly brackets are used for -precedence, alternatives are separated by |, optional things are enclosed -in square brackets, white space is required if it appears below and must -not appear if there isn't any between the tokens below (i.e. no white space -around periods, colons or slashes, whitespace required between all other -tokens)): - - command ::= ipfirewall <list> | <flush> | <check> | <add> | <del> - - <list> ::= list - - <flush> ::= flush - - <check> ::= { checkb[locking] | checkf[orwarding] } <chkparms> - - <add> ::= { addb[locking] | addf[orwarding] } <add-del-parms> - - <del> ::= { delb[locking] | delf[orwarding] } <add-del-parms> - - <chkparms> ::= <protocol> from <ipaddr> <port> to <ipaddr> <port> - - <protocol> ::= tcp | udp - - <ipaddr> ::= <int>.<int>.<int>.<int> | <hostname> - - <hostname> ::= a host name from /etc/hosts - - <port> ::= <int> | <service> - - <service> ::= a service from /etc/services - - <int> ::= a non-negative integer - - <add-del-parms> ::= { accept | deny } { <universal_firewall> | <protocol_firewall> } - - <universal_firewall> ::= all from <masked_ipaddr> to <masked_ipaddr> - - <masked_ipaddr> ::= { <ipaddr>/<bits> } | { <ipaddr>:<ipaddr> } | <ipaddr> - - <bits> ::= integer in the range 0 to 32 inclusive - - <protocol_firewall> ::= <protocol> from <end_firewall> to <end_firewall> - - <end_firewall> ::= <masked_ipaddr> <port_list> - - <port_list> ::= [ <port>:<port> ] <sub_port_list> - - <sub_port_list> ::= <port> [ <sub_port_list> ] - -Although I think that the above grammar is complete, it isn't exactly what -one would call easy to comprehend! Here's the basic idea along with what -each of the forms mean: - - The "ipfirewall list" command prints a list of the firewalls on both the - forwarding and blocking chain in some more or less understudable format. - - The "ipfirewall flush" command empties the two firewall chains. - - The "ipfirewall addblocking" and "ipfirewall addforwarding" commands take - a firewall description and add the firewall to the appropriate firewall - chain.Take notice,that if you will add some description more then once, - it will take more then one entry in memory.It does not lead to significant - slow down of computer operation though. - - The "ipfirewall delblocking" and "ipfirewall delforwarding" commands take - a firewall description and deletes the firewall from the appropriate - firewall chain.The description must be exactly the same as it was defined - by add command.One delete command removes ALL same entries from firewall - chains. - - There are two basic kinds of firewall descriptions. Universal firewall - descriptions match all IP packets between specified pairs of hosts. - Universal firewalls only check IP addresses (i.e. they match any combination - of protocol and port numbers). Protocol-specific firewalls match either - TCP/IP or UDP/IP packets between specified pairs of hosts. In addition - to host descriptions, protocol-specific firewalls optionally take a - description of which port numbers to match. - - A host description consists of an IP address and a mask. The IP address - is specified as either a domain name or in the familiar - nn.nn.nn.nn format. The mask indicates how much of the IP address - should be looked at when vetting packets. There are two ways to - specify the mask. The first way is to suffix the IP address in the - firewall with a slash and an integer in the range 0 through 32 inclusive. - This integer is taken to be the number of high order bits of the IP - address which are to be checked (for example, 192.153.211.0/24 checks - the top 24 bits of the IP address, 192.153.211.17/32 checks all the - bits and 0.0.0.0/0 checks none of the bits (i.e. all IP addresses are - matched by this example)). The second way to specify a mask is to - suffix the IP address with a colon followed by another IP address. - This second address is the mask. Specifications equivalent to the - above three examples using this syntax would be - - 192.153.211.0:255.255.255.0 - 192.153.211.17:255.255.255.255 - 0.0.0.0:0.0.0.0 - - The first form is taken from the syntax accepted by a Telebit NetBlazer. - The second form is more along the lines of how a netmask is specified - in /etc/netmasks. Finally, if no mask is specified then a mask of all - 1's is supplied (i.e. no mask is equivalent to /32 or :255.255.255.255). - - The optional description of port numbers to mask can take three forms. - The simplest form is to omit the list in which case all port numbers - match. The next form is to specify a list of port numbers (either as - positive integers or service names from /etc/services). The final form - is actually a special case of the second form in which the first pair - of port numbers is separated by a colon instead of white space. This - pair specifies a range of port numbers (i.e. x:y specifies that all - ports between x and y inclusive should match). A port description - matches a particular port number if any of the following is true: - - - the port description is null - - the first pair of port numbers is a range and the port number - is in the range (inclusive) - - the port number is equal to any of the port numbers in the list - - There is a limit of a total of 10 port numbers in the source and - destination port lists. This limit is arbitrary and easy to increase. - It is determined by the value of the IP_FIREWALL_MAX_PORTS #define - variable in ip_firewall.h. Each increase of 1 for this value adds two - bytes to the size of each firewall. Since the size of a firewall is only - slightly over 30 bytes right now, this limit of 10 could probably - be increased by quite a bit before it became a concern. I've been - thinking of increasing it to 20 which would be longer than any - reasonable firewall would need and would only consume 20 more bytes - per firewall. The counter argument to any increase is that it is - always possible to construct an equivalent set of two or more firewalls - that behaves like a single firewall with a really long port list. - - This probably all sounds hopelessly complicated. It is actually not - all that tricky (I'm just not very good at explaining it yet). A few - examples will probably help a lot now: - - Block all IP packets originating from the host hackers-den: - - ipfirewall addb deny all from hackers-den to 0.0.0.0/0 - - Block all telnet packets to our telnet server from anywhere: - - ipfirewall addb deny tcp from 0.0.0.0/0 to mymachine/32 telnet - - Don't forward telnet, rlogin and rsh packets onto our local - class C network: - - ipfirewall addf deny tcp from 0.0.0.0/0 to ournetwork/24 telnet login shell - - Don't let anyone on the local machine or any machine inside - our local network ftp access to games.com: - - ipfirewall addb deny tcp from games.com ftp to 0.0.0.0/0 - - This last one might look a little strange. It doesn't prevent - anyone from sending packets to the games.com ftp server. What it - does do is block any packets that the games.com ftp server sends - back! - - The "ipfirewall checkblocking" and "ipfirewall checkforwarding" commands - take a description of an IP packet and check to see if the blocking - or forwarding chain of firewalls respectively accept or reject the packet. - It is used to make sure that the firewalls that you've defined work as - expected. The basic syntax is probably best understood by looking at - a couple of examples: - - ipfirewall checkb from bsdi.com 3001 to mymachine telnet - - checks to see if the blocking firewall will block a telnet packet from - a telnet session originating on bsdi.com to the host mymachine will be - blocked or not. Note that someone connecting to our telnet server - could be using practically any port number. To be really sure, the - firewall used to prevent access should be as simple as possible and/or - you should try a variety of port numbers in addition to the rather - arbitrarily chosen port of 3001. - - One final note on the check* ,add* and del* command syntax. The noise word - "to" exists in the syntax so that I can detect the end of a list of - port numbers in the from description. Since I needed a noise word to - detect this case, I added the noise word "from" in front of the from - case for consistency. - - Finally, have a look at the file "filters". It is the set of filters - that I run at home.<Danny> - Also check "scripts",where individual access restrictions written. - We use those for our dial-in PPP/SLIP users,to allow some of them - to access our internal networks,while disallowing other.This way we - open access to user's IP,when he enters the system ,and shut it - down when he leaves.All those changes may be applyed at any time, - and so entries added and deleted from firewall while system is - is working.No any side effects will arise.<Ugen> - -Now for a bit of a description of how the firewalls are applied (i.e. what -happens in the kernel): - - When an IP packet is received, the ipintr() routine in ip_input.c is - called. This routine does a bit of basic error checking. If it - detects any errors in the packet it generally drops the packet on - the floor. The idea behind the ipfirewall facility is to treat packets - that we don't want to accept as bad packets (i.e. drop them on the - floor). The ipfirewall facility intercedes in the normal processing - at two points. Just after the basic sanity checks are done, we pass - any packets not targeted at the loopback network (127.0.0.0/8) to the - firewall checker along with the chain of blocking firewalls.If the firewall - checker tells us to block the packet then we branch to the "bad:" label - in ipintr() which is where all bad packets are dropped on the floor. - Otherwise, we allow normal processing of the packet to continue. The - exact point at which we intercede was chosen to be after the basic - sanity checking and before the option processing is done. We want to - be after the basic sanity checking so that we don't have to be able - to handle complete garbage. We want to be before the option processing - because option processing is done in separate rather complex routine. - Why bother doing this special processing if we might be dropping the - packet? - - The second point at which we intercede is when a packet is about to be - forwarded to another host. All such packets are passed to the ip_forward - routine. The ipfirewall code is at the very top of this routine. If - the packet isn't targetted at the loopback interface (is it possible - that it could be when we reach this point? I doubt it but safety first) - then pass the packet to the firewall checker along with the forwarding - firewall chain. If the firewall checker indicates that the packet should - not be forwarded then we drop in (using code copied from a few lines - further into the routine which drops broadcast packets which are not - to be forwarded). - -There are a couple of consequences of this approach: - - 1) Packets which are blocked are never forwarded (something to keep - in mind when designing firewalls). - 2) Packets targeted at the loopback interface (127.0.0.0/8) are never - blocked. Blocking packets to the loopback interface seems pointless - and potentially quite confusing. It also makes a possibly common - case very cheap. - 3) The sender of a packet which is blocked receives no indication that - the packet was dropped. The Telebit NetBlazer can be configured to - silently drop a blocked packet or to send back a "you can't get there - from here" packet to the sender. Implementing the later would have - been more work (possibly quite a bit more, I don't really know). Also, - I don't see any reason to give a potential hacker any more information - than necessary. Dropping the packet into the bit bucket seems like - the best way to keep a hacker guessing.<Danny> - Well,anyway i working on this feature.It would be made optional and - configurable by some ICMP_UNREACH_ON_DROP or like this.<Ugen> - -Now for some details on how the firewall checker works: - - The firewall checker takes two parameters. The first parameter is a pointer - to the packet in question. The second parameter is a pointer to the - appropriate firewall chain. At the present time, the firewall checker passes - these parameters to a second routine which is the real firewall checker. - If the real checker says NO then an appropriate message is printed - onto the console. This is useful for debugging purposes. Whether or - not it remains in the long term depends on whether it is considered useful - for logging purposes (I'm a little reluctant to leave it in since it - provides a hacker with a way to commit a "denial of service" offense - against you by filling up your /var/log/messages file's file system - with error messages. There are ways of preventing this but ...<Danny>). - In default configuration now no information about dropped packets - printed.You may,however,define it,as i do by adding - option IPFIREWALL_VERBOSE - to your kernel configuration file.Very useful thingy!<Ugen> - - A return value of 0 from this routine (or the real firewall checker) - indicates that the packet is to be dropped. A value of 1 indicates - that the packet is to be accepted. In the early testing stages you - might want to make the top level firewall checker always return 1 even - if the real checker returns 0 just in case the real firewall checker - screws up (or your firewalls aren't as well designed as they should be). - In fact, this might be a useful optional feature (providing a way to - leave a door unlocked doesn't seem all that wise but it has to be - balanced against the inconvenience to legitimate users who might get - screwed up by poorly designed firewalls). - - The real firewall returns 1 (accept the packet) if the chain is empty. If - efficiency is a concern (which it is in this code), this check should - be done in ip_input.c before calling the firewall checker. - - Assuming that there is a firewall chain to scan through, the real firewall - checker picks up the src and dst IP addresses from the IP packet. It - then goes through the firewall chain looking for the first firewall that - matches the packet. Once a matching firewall has been found, a value of - 1 is returned if the firewall is an accept firewall and a value of 0 is - returned otherwise. - - The following processing is done for each firewall on the chain: - - 1) check the src and dst IP addresses. If they don't match then - there isn't any point in looking any further at this firewall. - This check is done by anding the packet's IP addresses the - with appropriate masks and comparing the results to the - appropriate addresses in the firewall. Note that the mask is - NOT applied to the address in the firewall. If it has any 1 - bits that are 0 bits in the mask then the firewall will never - match (this will be checked in ipfirewall soon). If the addresses - match then we continue with the next step. - - 2) If the firewall is a universal firewall then we've got a match. - Return either 0 or 1 as appropriate. Otherwise, continue with - the next step. - - 3) Examine the IP protocol from the packet. If we havn't had to - look at it before then we get it and set a local variable to - IP_FIREWALL_TCP for TCP/IP packets, IP_FIREWALL_UDP for UDP/IP - packets, IP_FIREWALL_ICMP for ICMP packets, and IP_FIREWALL_UNIVERSAL - for all other packet types. Also, if the packet is a TCP/IP or - a UDP/IP packet, save the source and destination port numbers - at this point (taking advantage of the fact that the port numbers - are stored in the same place in either a TCP/IP or a UDP/IP - packet header). If the packet is neither a TCP/IP or a UDP/IP - packet then this firewall won't match it (on to the next firewall). - If this packet's protocol doesn't match this firewall's protocol - (which can't be universal or we wouldn't be here) then on to - the next firewall. Otherwise, continue with the next step. - - 4) We're checking either a TCP/IP or a UDP/IP packet. If the - firewall's source port list is empty or the packet's source - port matches something in the source port list AND if the firewall's - destination port list is empty or the packet's destination - port matches something in the destination port list then - we've got a match (return 0 or 1 as appropriate). Otherwise, - on to the next firewall. - - As indicated above, if no packet on the chain matches the packet then - it is accepted if the first firewall was a deny firewall and it is rejected - if the first firewall was an accept packet. This is equivalent to the - default behaviour of a Telebit NetBlazer. They provide a way to override - this behaviour. I'm not convinced that it is necessary (I'm open to - suggestions). - -That's about it for the firewall checker. The ipfirewall program communicates -with the kernel part of the firewall facility by making setsockopt calls -on RAW IP sockets. Only root is allowed to open a RAW IP socket. This -ensures that only root uses ipfirewall to manipulate the firewall facility. -Also, somewhere in the kernel source or on a man page, I read that the -RAW IP setsockopt calls are intended for manipulating the IP protocol layer -as opposed to manipulating any particular instance of a socket. This seems -like a reasonable description of what the firewall setsockopt command -codes do. - -There are seven setsockopt command codes defined by the firewall facility -(in netinet/in.h). They are: - - IP_FLUSH_FIREWALLS flush (i.e. free) both firewall chains. - - IP_ADD_FORWARDING_FIREWALL add firewall pointed at by optval parm to - the end of the forwarding firewall chain. - - IP_ADD_BLOCKING_FIREWALL add firewall pointed at by optval parm to - the end of the blocking firewall chain. - - IP_DEL_FORWARDING_FIREWALL delete firewall pointed at by optval parm - from the forwarding firewall chain. - - IP_DEL_BLOCKING_FIREWALL delete firewall pointed at by optval parm - from the blocking firewall chain. - - IP_CHECK_FORWARDING_FIREWALL pass the IP packet do the firewall checker - along with the forwarding firewall chain. - Return 0 if packet was accepted, -1 (with - errno set to EACCES) if it wasn't. - - IP_CHECK_BLOCKING_FIREWALL pass the IP packet do the firewall checker - along with the blocking firewall chain. - Return 0 if packet was accepted, -1 (with - errno set to EACCES) if it wasn't. - - The IP_ADD_* and IP_DEL_* command codes do a fair bit of validity checking. - It is quite unlikely that a garbage firewall could get past them that - would cause major problems in the firewall checker. It IS possible for - a garbage packet to get past the checks which causes major grief because - it either blocks or accepts packets according to unusual rules (the rules - will conform to the ones described above but will probably come as quite - a surprise). - - The IP_CHECK_* command codes expect the optval parameter to point - to a struct ip immediately followed by a header appropriate to the protocol - value described in the ip_p field of the ip header. The exact requirements - are as follows: - - - The length of the optval parameter must be at least - - sizeof(struct ip) + 2 * sizeof(u_short) - - since this is the amount of memory that might be referenced by - the firewall checker. - - - The ip_hl field of the ip structure must be equal to - - sizeof(struct ip) / sizeof(int) - - since this value indicates that the tcp/udp/??? header immediately - follows the ip header (appropriate for the purposes that this - interface is intended for). - - Failure to follow these rules (for either the IP_ADD_*,IP_DEL_* or the - IP_CHECK_*_FIREWALL commands) will result in a return value of -1 with - errno set to EINVAL (for now, it will also result in an appropriate - message on the console). - - To read current configuration of firewalls,the kvm_read() function used. - Symbols,which you have to find are : - struct ip_firewall * ip_firewall_blocking_chain ; - struct ip_firewall * ip_firewall_forwarding_chain ; - Both are pointers to the linked list of firewall entries. - Of corse you have to be at least kmem group member,to read kernel symbols. - -That's about all that I can think of for now. There are a couple of details -that are worth reading about in the ip_firewall.h file. Other than that, let -me know how you do. If you have any problems, give me a call at home (403 -449-1835) or send me e-mail at "danny@BouletFermat.ab.ca". If you call, please -keep in mind that I live in the Canadian Mountain timezone (GMT-0600). - --Danny - -So that's it..if you want to say something to me-call me or mail: -Phone: 972-4-550-330 -E-mail ugen@NetVision.net.il -If you call,remember that i live in Israel timezone which is GMT+02. - --Ugen - diff --git a/sbin/ipfw/ipfirewall.4 b/sbin/ipfw/ipfirewall.4 deleted file mode 100644 index f11cbd54b304..000000000000 --- a/sbin/ipfw/ipfirewall.4 +++ /dev/null @@ -1,206 +0,0 @@ -.Dd November 16, 1994 -.Dt IPFW(4)/IPACCT 4 -.Os -.Sh NAME - - ipfirewall,ipfw - IP packets filter. - ipaccounting,ipacct - IP packets/traffic accounting. - -.Sh SYNOPSIS -#include <netinet/ip_fw.h> - -setsockopt(raw_socket,IPPROTO_IP,<ipfw/ipacct option>, - <struct ip|struct ipfw>,<size>) - -Ipfw options: - IP_FW_ADD_BLK - add entry to blocking chain. - IP_FW_ADD_FWD - add entry to forwarding chain. - IP_FW_CHK_BLK - check ip packet against blocking chain. - IP_FW_CHK_FWD - check ip packet against forwarding chain. - IP_FW_DEL_BLK - delete entry from blocking chain. - IP_FW_DEL_FWD - delete entry from forwarding chain. - IP_FW_FLUSH - flush all blocking & forwarding chain entries. - IP_FW_POLICY - define default ipfw policy. - -Ipacct options: - IP_ACCT_ADD - add entry to accounting chain. - IP_ACCT_DEL - delete entry from accounting chain. - IP_ACCT_FLUSH - flush all accounting chain entries. - IP_ACCT_ZERO - zero all accounting chain entries. - -Ipfw/ipacct entry structure: - #define IP_FW_MAX_PORTS 10 - -struct ip_fw { - struct ip_fw *next; - struct in_addr src, dst; - struct in_addr src_mask, dst_mask; - u_short flags; - u_short n_src_p, n_dst_p; - u_short ports[IP_FW_MAX_PORTS]; - u_long p_cnt,b_cnt; -} - -Flags values for "flags" field: - IP_FW_F_ALL - The entry should match all IP packets. - IP_FW_F_TCP - The entry should match TCP packets. - IP_FW_F_UDP - The entry should match UDP packets. - IP_FW_F_ICMP - The entry should match ICMP packets. - IP_FW_F_KIND - Mask value to separate protocol kind. - IP_FW_F_ACCEPT - This entry is accepting ( see below ) - IP_FW_F_SRNG - Source ports are range ( see below ) - IP_FW_F_DRNG - Destination ports are range ( see below ) - IP_FW_F_PRN - Print this entry ( see below ) - IP_FW_F_BIDIR - This acct entry is bidirectional ( see below ) - IP_FW_F_MASK - Mask to match all valid flag bits. - -Kernel symbols to kvm_nlist(): - struct ip_fw *ip_fw_blk_chain - chain of forwarding entries. - struct ip_fw *ip_fw_fwd_chain - chain of blocking entries. - int ip_fw_policy - default policy. - struct ip_fw *ip_acct_chain - chain of accounting entries. - -Options in the kernel configuration file: - IPFIREWALL - enable ipfirewall. - IPFIREWALL_VERBOSE - enable firewall output ( see below ) - DEBUG_IPFIREWALL - enable extensive debugging output. - IPACCT - enable ipaccounting. - -.Sh DESCRIPTION -Ipfirewall (later ipfw) is a system facility,which allows filtering -of incoming and/or forwarding packets on the protocol+source/destination -adress/ports base. -Ipaccounting (later ipacct) is a system facility,which allows counting -of incoming,outgoing and forwarding traffic by packet/byte count. - -Basic idea is that every packet checked against number of entries -in several chains.There are 3 chains: - Blocking - this chain defines whenever packet should be accepted - ever for local delivery or for forwarding. - Forwarding - this chain defines whenever packet should be accepted - for forwarding only. - Accounting - this chain defines types of packets , which should be - counted. - -Entries added to chains by means of setsockopt() call on RAW IP socket. -Options to add/remove specific entries or to flush all entries described -above. Value passed to setsockopt() is a value of struct ip_fw for -entry. If entry added , it checked by such rules that when we start -searching chain for matching entry the first matching is the best match, -[ or at least one of them :^) ]. - That means: - * First in chain entries with specific protocol and small ranges - of src/dst adresses and ports. - * Later going entries with wider ranges of ports and adresses. - * Later entries matching every port for some adress range. - * Later universal entries matching any protocol. - -While deleting entry , every entry which equal to that passed to -setsockopt() will be removed. -Flush removes all entries. - -Every entry have several fields,by which packets matched: - struct ip_fw *next - next entry in chain.(Set internally) - - struct in_addr src - source adress to be matched. - struct in_addr src_mask - source adress mask. - To match whole networks/subnets or adress groups - mask bits should be zeroed here and also - in src_mask field. Valuable bits should be set - in src_mask field. - struct in_addr dst - destination adress to be matched. - struct in_addr dst_mask - destination adress mask. - - u_short flags - flags field.See exact description of flags meaning - in description later. - - u_short n_src_p - number of source ports in "ports" array. - u_short n_dst_p - number of destination ports in "ports" array. - u_short ports[] - ports array.Overall length currently defined - to reasonable maximum - 10,and could be changed. - The packet's src port can ever match one of - ports[0] ... ports[--n_src_p] numbers,or if - flag IP_FW_F_SRNG set take port[0] as bottom - range value and ports[1] as top one.n_src_p should - be set to 2 then.If n_src_p equal to 0 , every port - match. The same rules apply to packet's dst port, - except that it matched against ports[n_src_p] ... - ... ports[n_src_p+n_dst_p--],or if IP_FW_F_DRNG set, - range is ports[n_src_p] to ports[n_srcp++]. - - u_long p_cnt - packets count for ipacct entries. - u_long b_cnt - bytes count for ipacct entries. - -Packet matching proceeds in following way: - -a) If packet entry protocol set to ALL, see c). - -b) If entry protocol set to TCP/UDP/ICMP and packet protocol - different - no match,if packet protocol and entry protocol - same - continue. - -c) If source addres pattern does not equal to packets sources adress - masked with src_mask , or destination pattern not equal to packets - destination adress masked with dst_mask - no match. - If they does and protocol set to ALL/ICMP - got match. - If they does and protocol set to TCP/UDP - continue. - -d) If src port doesn't match or dst port doesn't match - all - packet don't match. If they does - got match. - -In ipfw packet matched consequently against every chain entry. -Search continues untill first matching entry found.If IP_FW_F_ACCEPT -flag set - packet accepted.If it is not set - packet denied. -If no matching entry found , all unmatched packets ever accepted or -denied depending on global polici value. It can be set with -IP_FW_POLICY raw socket option. Deny value is 0, other values -(default 1) is accept. - -Entries can be added with IP_FW_F_PRN flag set.If kernel compiled -with IPFIREWALL_VERBOSE option,packets matching this entries will -be printed by kernel printf's. - -If some chain is empty,every packet accepted by this chain no -matter what default policy is. - -To check whenever or not packet denied by some chain , checking -options to setsockopt() can be issued. Then the argument is -a buffer representing ip packet,thus it has to be -struct ip + struct tcphdr . -Then setsockopt() return value 0 on accept or another on deny. - -Ipaccounting entries added the same way as ipfw ones.Packet checked -against all entries in chain and values of p_cnt and b_cnt in matching -entries rised.p_cnt rises by 1 and b_cnt by ip_len value of ip packet. -Thus all traffic size counted including IP headers. - -If IP_FW_F_BIDIR flag is set in accounting entry,packets counted are -those which match entry in standart way along with packets which match -entry while their source and destination addr/port pairs swapped. - -Zero option allows all accounting to be cleared. - -.Sh DIAGNOSTICS - -[EINVAL] The IP option field was improperly formed; an option - field was shorter than the minimum value or longer than - the option buffer provided.An structural error in - ip_fw structure occured (n_src_p+n_dst_p too big, - ports set for ALL/ICMP protocols etc.) - -.Sh SEE ALSO - -ip(4), setsockopt(2), kvm_nlist(3), kvm_read(3) - -.Sh BUGS - Ipfw/ipacct facilities are new and , although serious bugs has -been tracked,some less important ones expected. - This man page also uncomplete bad styled. - -.Sh HISTORY - Ipfw facility has been intitially written as package to BSDI -by Daniel Boulet <danny@BouletFermat.ab.ca>. - It has been havily modified and ported to FreeBSD 2.0 -by Ugen J.S.Antsilevich <ugen@NetVision.net.il> - Ipacct facility written for FreeBSD 2.0 -by Ugen J.S.Antsilevich <ugen@NetVision.net.il> diff --git a/sbin/ipfw/ipfw.1 b/sbin/ipfw/ipfw.1 deleted file mode 100644 index 720b259470dd..000000000000 --- a/sbin/ipfw/ipfw.1 +++ /dev/null @@ -1,527 +0,0 @@ -.\" -.\" ipfw - a utility for manipulating the configuration of an IP firewall. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" -.\" @(#)ipfw.1 -.\" -.TH ipfw 1 "October 27, 1994" "" "FreeBSD" - -.SH NAME -ipfw - a utility for manipulating the configuration of an IP firewall. -.SH SYNOPSIS -.na -.B ipfw -.RB [options] -.SH DESCRIPTION -The -.B ipfw -command is used to configure an active IP firewall, setting masks on just -what sites are allowed to connect through it, which packets are rejected, -etc. -.SH OPTIONS -The command-line syntax of this command is rather involved, and rather than -spend a lot of time that I just don't have at the moment creating a -.B real -man page, with properly formatted sections and all, I'm just going to loosely -format the README I got. This really needs an nroff expert to go through -it with a chainsaw and do a -.N REAL -job of formatting it! This all looks rather horrible at present, and -I would actually almost recommend that you simply read the man page text -directly, rather than trying to format it. Sorry, but I do NOT speak -nroff, nor do I ever wish to learn how! :-) [-jkh]. -.PP -For a sample kernel configuration file that will enable the right kernel -features necessary for firewalling, see -.I /sys/i386/conf/IPFIREWALL -. -.PP -.B WARNING!!! WARNING!!! WARNING!!! WARNING!!! WARNING!!! WARNING!!! -.PP -This utility can be used to put your machine into very dysfunctional state, -so if you want to test it then you should first make sure to read this man page -all the way through, and don't run it anywhere from the system console! -Using -.I ipfw -incorrectly is a really good way to kick yourself off your own machine -if you're logged in over a network! Also make sure to never set this -utility to be setuid root! It's a blatant security hole that way. -Instead, run it as root or from "/etc/rc.local" as part of the boot process. -It's also a good idea to use the checkb or checkf command options (see below) -to pass some test packets through the firewalls that you've defined before -going "live". -.PP -You may find it useful to create a file in which the first line is -.I firewall flush -to flush any existing firewalls before defining the explicit firewalls -that you wish to use. This will ensure that you're always working from a -known state. -.PP -The syntax for the -.BI ipfirewall -command option is rather complex and yet simple at the same time (if you know -what I mean). There are seven sub-commands, and probably the easiest way to -get into this is to give you a roughly BNF style grammar for the command -(curly brackets are used for precedence, alternatives are separated by |, -optional things are enclosed in square brackets, white space is required if -it appears below and must not appear if there isn't any between the tokens -below (i.e. no white space around periods, colons or slashes, whitespace -required between all other tokens)): -.PP -.nf - command ::= ipfirewall <list> | <flush> | <check> | <add> | <del> - <list> ::= list - <flush> ::= flush - <check> ::= { checkb[locking] | checkf[orwarding] } <chkparms> - <add> ::= { addb[locking] | addf[orwarding] } <add-del-parms> - <del> ::= { delb[locking] | delf[orwarding] } <add-del-parms> - <chkparms> ::= <protocol> from <ipaddr> <port> to <ipaddr> <port> - <protocol> ::= tcp | udp - <ipaddr> ::= <int>.<int>.<int>.<int> | <hostname> - <hostname> ::= a host name from /etc/hosts - <port> ::= <int> | <service> - <service> ::= a service from /etc/services - <int> ::= a non-negative integer - <add-del-parms> ::= { accept | deny } { <universal_firewall> | <protocol_firewall> } - <universal_firewall> ::= all from <masked_ipaddr> to <masked_ipaddr> - <masked_ipaddr> ::= { <ipaddr>/<bits> } | { <ipaddr>:<ipaddr> } | <ipaddr> - <bits> ::= integer in the range 0 to 32 inclusive - <protocol_firewall> ::= <protocol> from <end_firewall> to <end_firewall> - <end_firewall> ::= <masked_ipaddr> <port_list> - <port_list> ::= [ <port>:<port> ] <sub_port_list> - <sub_port_list> ::= <port> [ <sub_port_list> ] -.fi -.PP -Although I think that the above grammar is complete, it isn't exactly what -one would call easy to comprehend! Here's the basic idea along with what -each of the forms mean: -.PP -The -.I ipfirewall list -command prints a list of the firewalls on both the -forwarding and blocking chain in some more or less comprehensible format. -.PP -The -.I ipfirewall flush -command empties the two firewall chains. -.PP -The -.I ipfirewall addblocking -and -.I ipfirewall addforwarding -commands take a firewall description and add the firewall to the appropriate -firewall chain. Note that you'll probably need to add some descriptions more -then once, which will naturally take more then one entry in memory. It does -not lead to significant degradation of performance, so don't worry about it. -.PP -The -.I ipfirewall delblocking -and -.I ipfirewall delforwarding -commands take a firewall description and delete the firewall from the -appropriate firewall chain. The description must exactly match that given -to an earlier add command. One delete command removes ALL matching entries -from firewall chains. -.PP -There are two basic kinds of firewall descriptions. Universal firewall -descriptions match all IP packets between specified pairs of hosts. -Universal firewalls only check IP addresses (e.g. they match any combination -of protocol and port numbers). Protocol-specific firewalls match either -TCP/IP or UDP/IP packets between specified pairs of hosts. In addition -to host descriptions, protocol-specific firewalls optionally take a -description of which port numbers to match. -.PP -A host description consists of an IP address and a mask. The IP address -is specified as either a domain name or in the familiar -nn.nn.nn.nn format. The mask indicates how much of the IP address -should be looked at when vetting packets. There are two ways to -specify the mask. The first way is to suffix the IP address in the -firewall with a slash and an integer in the range 0 through 32 inclusive. -This integer is taken to be the number of high order bits of the IP -address which are to be checked (for example, 192.153.211.0/24 checks -the top 24 bits of the IP address, 192.153.211.17/32 checks all the -bits and 0.0.0.0/0 checks none of the bits (i.e. all IP addresses are -matched by this example)). The second way to specify a mask is to -suffix the IP address with a colon followed by another IP address. -This second address is the mask. Specifications equivalent to the -above three examples using this syntax would be -.PP -.nf -192.153.211.0:255.255.255.0 -192.153.211.17:255.255.255.255 -0.0.0.0:0.0.0.0 -.fi -.PP -The first form is taken from the syntax accepted by a Telebit NetBlazer. -The second form is more along the lines of how a netmask is specified -in /etc/netmasks. Finally, if no mask is specified then a mask of all -1's is supplied (i.e. no mask is equivalent to /32 or :255.255.255.255). -.PP -The optional description of port numbers to mask can take three forms. -The simplest form is to omit the list in which case all port numbers -match. The next form is to specify a list of port numbers (either as -positive integers or service names from /etc/services). The final form -is actually a special case of the second form in which the first pair -of port numbers is separated by a colon instead of white space. This -pair specifies a range of port numbers (i.e. x:y specifies that all -ports between x and y inclusive should match). A port description -matches a particular port number if any of the following is true: -.nf - - the port description is null - - - the first pair of port numbers is a range and the port number - is in the range (inclusive) - - - the port number is equal to any of the port numbers in the list -.fi -.PP -There is a limit of a total of 10 port numbers in the source and -destination port lists. This limit is arbitrary and easy to increase. -It is determined by the value of the IP_FIREWALL_MAX_PORTS #define -variable in ip_firewall.h. Each increase of 1 for this value adds two -bytes to the size of each firewall. Since the size of a firewall is only -slightly over 30 bytes right now, this limit of 10 could probably -be increased by quite a bit before it became a concern. I've been -thinking of increasing it to 20 which would be longer than any -reasonable firewall would need and would only consume 20 more bytes -per firewall. The counter argument to any increase is that it is -always possible to construct an equivalent set of two or more firewalls -that behaves like a single firewall with a really long port list. -.PP -This probably all sounds hopelessly complicated. It is actually not -all that tricky (I'm just not very good at explaining it yet). A few -examples will probably help a lot now: -.PP -Block all IP packets originating from the host hackers-den: -.PP -.nf - ipfirewall addb deny all from hackers-den to 0.0.0.0/0 -.fi -.PP -Block all telnet packets to our telnet server from anywhere: -.PP -.nf - ipfirewall addb deny tcp from 0.0.0.0/0 to mymachine/32 telnet -.fi -.PP -Don't forward telnet, rlogin and rsh packets onto our local -class C network: -.PP -.nf - ipfirewall addf deny tcp from 0.0.0.0/0 to ournetwork/24 telnet login shell -.fi -.PP -Don't let anyone on the local machine or any machine inside -our local network ftp access to games.com: -.PP -.nf - ipfirewall addb deny tcp from games.com ftp to 0.0.0.0/0 -.fi -.PP -This last one might look a little strange. It doesn't prevent -anyone from sending packets to the games.com ftp server. What it -does do is block any packets that the games.com ftp server sends -back! -.PP -The -.I ipfirewall checkblocking -and -.I ipfirewall checkforwarding -commands take a description of an IP packet and check to see if the blocking -or forwarding chain of firewalls respectively accept or reject the packet. -It is used to make sure that the firewalls that you've defined work as -expected. The basic syntax is probably best understood by looking at -a couple of examples: -.PP -.nf - ipfirewall checkb from bsdi.com 3001 to mymachine telnet -.fi -.PP -checks to see if the blocking firewall will block a telnet packet from -a telnet session originating on bsdi.com to the host mymachine will be -blocked or not. Note that someone connecting to our telnet server -could be using practically any port number. To be really sure, the -firewall used to prevent access should be as simple as possible and/or -you should try a variety of port numbers in addition to the rather -arbitrarily chosen port of 3001. -.PP -One final note on the check* ,add* and del* command syntax. The noise word -"to" exists in the syntax so that I can detect the end of a list of -port numbers in the from description. Since I needed a noise word to -detect this case, I added the noise word "from" in front of the from -case for consistency. -.PP -Finally, have a look at the file -.I "/usr/share/misc/ipfw.samp.filters" -. It is the set of filters that I run at home [Danny]. -.PP -Also check -.I "/usr/share/misc/ipfw.samp.scripts" -For examples of individual access restrictions. -We [NetVision] use those for our dial-in PPP/SLIP users to allow some of them -to access our internal networks, while disallowing others. -This way we open access for the user's IP when he enters the system and shut it -down when he leaves. All such changes may be applyed at any time, -and so entries added and deleted from firewall while the system is -is working have no other side effects [Ugen]. - -.SH "TECHNICAL DETAILS" -A bit of a description of how the firewalls are applied (i.e. what happens in -the kernel) may be instructive to the advanced firewall-builder: -.PP -When an IP packet is received, the ipintr() routine in ip_input.c is -called. This routine does a bit of basic error checking. If it -detects any errors in the packet it generally drops the packet on -the floor. The idea behind the ipfirewall facility is to treat packets -that we don't want to accept as bad packets (i.e. drop them on the -floor). The ipfirewall facility intercedes in the normal processing -at two points. Just after the basic sanity checks are done, we pass -any packets not targeted at the loopback network (127.0.0.0/8) to the -firewall checker along with the chain of blocking firewalls.If the firewall -checker tells us to block the packet then we branch to the "bad:" label -in ipintr() which is where all bad packets are dropped on the floor. -Otherwise, we allow normal processing of the packet to continue. The -exact point at which we intercede was chosen to be after the basic -sanity checking and before the option processing is done. We want to -be after the basic sanity checking so that we don't have to be able -to handle complete garbage. We want to be before the option processing -because option processing is done in separate rather complex routine. -Why bother doing this special processing if we might be dropping the -packet? -.PP -The second point at which we intercede is when a packet is about to be -forwarded to another host. All such packets are passed to the ip_forward -routine. The ipfirewall code is at the very top of this routine. If -the packet isn't targetted at the loopback interface (is it possible -that it could be when we reach this point? I doubt it but safety first) -then pass the packet to the firewall checker along with the forwarding -firewall chain. If the firewall checker indicates that the packet should -not be forwarded then we drop in (using code copied from a few lines -further into the routine which drops broadcast packets which are not -to be forwarded). -.PP -There are a couple of consequences of this approach: -.PP -1) Packets which are blocked are never forwarded (something to keep -in mind when designing firewalls). -.PP -2) Packets targeted at the loopback interface (127.0.0.0/8) are never -blocked. Blocking packets to the loopback interface seems pointless -and potentially quite confusing. It also makes a possibly common -case very cheap. -.PP -3) The sender of a packet which is blocked receives no indication that -the packet was dropped. The Telebit NetBlazer can be configured to -silently drop a blocked packet or to send back a "you can't get there -from here" packet to the sender. Implementing the later would have -been more work (possibly quite a bit more, I don't really know). Also, -I don't see any reason to give a potential hacker any more information -than necessary. Dropping the packet into the bit bucket seems like -the best way to keep a hacker guessing. [Danny] -.PP -(I am working on this feature, it would be made optional and -configurable by some ICMP_UNREACH_ON_DROP option, or such [Ugen]). -.PP -The firewall checker takes two parameters. The first parameter is a pointer -to the packet in question. The second parameter is a pointer to the -appropriate firewall chain. At the present time, the firewall checker passes -these parameters to a second routine which is the real firewall checker. -If the real checker says NO then an appropriate message is printed -onto the console. This is useful for debugging purposes. Whether or -not it remains in the long term depends on whether it is considered useful -for logging purposes (I'm a little reluctant to leave it in since it -provides a hacker with a way to commit a "denial of service" offense -against you by filling up your /var/log/messages file's file system -with error messages. There are ways of preventing this but ... [Danny]). -In default configuration now no information about dropped packets -printed.You may, however, define it as i do by adding -.I options IPFIREWALL_VERBOSE -to your kernel configuration file. Very useful thingy! [Ugen] - -.PP -A return value of 0 from this routine (or the real firewall checker) -indicates that the packet is to be dropped. A value of 1 indicates -that the packet is to be accepted. In the early testing stages you -might want to make the top level firewall checker always return 1 even -if the real checker returns 0 just in case the real firewall checker -screws up (or your firewalls aren't as well designed as they should be). -In fact, this might be a useful optional feature (providing a way to -leave a door unlocked doesn't seem all that wise but it has to be -balanced against the inconvenience to legitimate users who might get -screwed up by poorly designed firewalls). - -.PP -The real firewall returns 1 (accept the packet) if the chain is empty. If -efficiency is a concern (which it is in this code), this check should -be done in ip_input.c before calling the firewall checker. - -.PP -Assuming that there is a firewall chain to scan through, the real firewall -checker picks up the src and dst IP addresses from the IP packet. It -then goes through the firewall chain looking for the first firewall that -matches the packet. Once a matching firewall has been found, a value of -1 is returned if the firewall is an accept firewall and a value of 0 is -returned otherwise. -.PP -The following processing is done for each firewall on the chain: -.PP -1) check the src and dst IP addresses. If they don't match then -there isn't any point in looking any further at this firewall. -This check is done by anding the packet's IP addresses the -with appropriate masks and comparing the results to the -appropriate addresses in the firewall. Note that the mask is -NOT applied to the address in the firewall. If it has any 1 -bits that are 0 bits in the mask then the firewall will never -match (this will be checked in ipfirewall soon). If the addresses -match then we continue with the next step. -.PP -2) If the firewall is a universal firewall then we've got a match. -Return either 0 or 1 as appropriate. Otherwise, continue with -the next step. -.PP -3) Examine the IP protocol from the packet. If we havn't had to -look at it before then we get it and set a local variable to -IP_FIREWALL_TCP for TCP/IP packets, IP_FIREWALL_UDP for UDP/IP -packets, IP_FIREWALL_ICMP for ICMP packets, and IP_FIREWALL_UNIVERSAL -for all other packet types. Also, if the packet is a TCP/IP or -a UDP/IP packet, save the source and destination port numbers -at this point (taking advantage of the fact that the port numbers -are stored in the same place in either a TCP/IP or a UDP/IP -packet header). If the packet is neither a TCP/IP or a UDP/IP -packet then this firewall won't match it (on to the next firewall). -If this packet's protocol doesn't match this firewall's protocol -(which can't be universal or we wouldn't be here) then on to -the next firewall. Otherwise, continue with the next step. -.PP -4) We're checking either a TCP/IP or a UDP/IP packet. If the -firewall's source port list is empty or the packet's source -port matches something in the source port list AND if the firewall's -destination port list is empty or the packet's destination -port matches something in the destination port list then -we've got a match (return 0 or 1 as appropriate). Otherwise, -on to the next firewall. -.PP -As indicated above, if no packet on the chain matches the packet then -it is accepted if the first firewall was a deny firewall and it is rejected -if the first firewall was an accept packet. This is equivalent to the -default behaviour of a Telebit NetBlazer. They provide a way to override -this behaviour. I'm not convinced that it is necessary (I'm open to -suggestions). -.PP -That's about it for the firewall checker. The -.I ipfw -program communicates with the kernel part of the firewall facility by making -setsockopt calls on RAW IP sockets. Only root is allowed to open a RAW IP -socket. This ensures that only root uses -.I ipfw to manipulate the firewall facility. -Also, somewhere in the kernel source or on a man page, I read that the -RAW IP setsockopt calls are intended for manipulating the IP protocol layer -as opposed to manipulating any particular instance of a socket. This seems -like a reasonable description of what the firewall setsockopt command -codes do. -.PP -There are seven setsockopt command codes defined by the firewall facility -(in netinet/in.h). They are: -.PP -.nf - IP_FLUSH_FIREWALLS flush (i.e. free) both firewall chains. - - IP_ADD_FORWARDING_FIREWALL add firewall pointed at by optval parm to - the end of the forwarding firewall chain. - - IP_ADD_BLOCKING_FIREWALL add firewall pointed at by optval parm to - the end of the blocking firewall chain. - - IP_DEL_FORWARDING_FIREWALL delete firewall pointed at by optval parm - from the forwarding firewall chain. - - IP_DEL_BLOCKING_FIREWALL delete firewall pointed at by optval parm - from the blocking firewall chain. - - IP_CHECK_FORWARDING_FIREWALL pass the IP packet do the firewall checker - along with the forwarding firewall chain. - Return 0 if packet was accepted, -1 (with - errno set to EACCES) if it wasn't. - - IP_CHECK_BLOCKING_FIREWALL pass the IP packet do the firewall checker - along with the blocking firewall chain. - Return 0 if packet was accepted, -1 (with - errno set to EACCES) if it wasn't. - - The IP_ADD_* and IP_DEL_* command codes do a fair bit of validity checking. - It is quite unlikely that a garbage firewall could get past them that - would cause major problems in the firewall checker. It IS possible for - a garbage packet to get past the checks which causes major grief because - it either blocks or accepts packets according to unusual rules (the rules - will conform to the ones described above but will probably come as quite - a surprise). - - The IP_CHECK_* command codes expect the optval parameter to point - to a struct ip immediately followed by a header appropriate to the protocol - value described in the ip_p field of the ip header. The exact requirements - are as follows: - - - The length of the optval parameter must be at least - - sizeof(struct ip) + 2 * sizeof(u_short) - - since this is the amount of memory that might be referenced by - the firewall checker. - - - The ip_hl field of the ip structure must be equal to - - sizeof(struct ip) / sizeof(int) - - since this value indicates that the tcp/udp/??? header immediately - follows the ip header (appropriate for the purposes that this - interface is intended for). - - Failure to follow these rules (for either the IP_ADD_*,IP_DEL_* or the - IP_CHECK_*_FIREWALL commands) will result in a return value of -1 with - errno set to EINVAL (for now, it will also result in an appropriate - message on the console). - - To read current configuration of firewalls,the kvm_read() function used. - Symbols,which you have to find are : - struct ip_firewall * ip_firewall_blocking_chain ; - struct ip_firewall * ip_firewall_forwarding_chain ; - Both are pointers to the linked list of firewall entries. - Of course, you must at least be a member of group kmem to read kernel - symbols. -.fi -.PP -There are a couple of additional details that are worth reading about in -the ip_firewall.h file. Other than that, let the authors know how you do! -If you have any problems, you may call Danny Boulet at home (403 449-1835) -or send e-mail to <danny@BouletFermat.ab.ca>. If you call, please keep in -mind that Danny lives in the Canadian Mountain timezone (GMT-0600). -.PP -You may also reach some commercial users of this package (and also those -responsible for porting it to FreeBSD and adding several additional -commands), at 972-4-550-330, or via email at <ugen@NetVision.net.il>. -If you call, remember that Ugen lives in the Israel timezone, which is GMT+02. - -.SH FILES -/usr/share/misc/ipfw.samp.filters -/usr/share/misc/ipfw.samp.scripts -.SH "BUGS" -You can very easily hose your machine utterly if you don't know what you're -doing. Dieses Befehl ist nur fuer Experten! -.SH "SEE ALSO" -.BR reboot (1) , -.PP -.BR /sys/i386/conf/IPFIREWALL -.SH AUTHORS -Daniel Boulet <danny@BouletFermat.ab.ca> -.PP -Ugen J.S.Antsilevich <ugen@NetVision.net.il> -.PP -Jordan K. Hubbard <jkh@FreeBSD.org> [Crimes committed in this manpage] |