summaryrefslogtreecommitdiffstats
path: root/sys/netinet/ip_fw.h
Commit message (Collapse)AuthorAgeFilesLines
* Add the option versrcreach to verify that a valid route to theandre2004-04-231-0/+1
| | | | | | | | | | | | | | | | | | | | source address of a packet exists in the routing table. The default route is ignored because it would match everything and render the check pointless. This option is very useful for routers with a complete view of the Internet (BGP) in the routing table to reject packets with spoofed or unrouteable source addresses. Example: ipfw add 1000 deny ip from any to any not versrcreach also known in Cisco-speak as: ip verify unicast source reachable-via any Reviewed by: luigi
* Re-remove MT_TAGs. The problems with dummynet have been fixed now.mlaier2004-02-251-1/+0
| | | | | Tested by: -current, bms(mentor), me Approved by: bms(mentor), sam
* Backout MT_TAG removal (i.e. bring back MT_TAGs) for now, as dummynet ismlaier2004-02-181-0/+1
| | | | | | not working properly with the patch in place. Approved by: bms(mentor)
* This set of changes eliminates the use of MT_TAG "pseudo mbufs", replacingmlaier2004-02-131-1/+0
| | | | | | | | | | | them mostly with packet tags (one case is handled by using an mbuf flag since the linkage between "caller" and "callee" is direct and there's no need to incur the overhead of a packet tag). This is (mostly) work from: sam Silence from: -arch Approved by: bms(mentor), sam, rwatson
* Replace the if_name and if_unit members of struct ifnet with new membersbrooks2003-10-311-1/+1
| | | | | | | | | | | | | if_xname, if_dname, and if_dunit. if_xname is the name of the interface and if_dname/unit are the driver name and instance. This change paves the way for interface renaming and enhanced pseudo device creation and configuration symantics. Approved By: re (in principle) Reviewed By: njl, imp Tested On: i386, amd64, sparc64 Obtained From: NetBSD (if_xname)
* Allow set 31 to be used for rules other than 65535.luigi2003-07-151-0/+1
| | | | | | | | | | | | | | | Set 31 is still special because rules belonging to it are not deleted by the "ipfw flush" command, but must be deleted explicitly with "ipfw delete set 31" or by individual rule numbers. This implement a flexible form of "persistent rules" which you might want to have available even after an "ipfw flush". Note that this change does not violate POLA, because you could not use set 31 in a ruleset before this change. sbin/ipfw changes to allow manipulation of set 31 will follow shortly. Suggested by: Paul Richards
* Correct some comments, add opcode O_IPSEC to match packetsluigi2003-07-041-12/+17
| | | | coming out of an ipsec tunnel.
* Change handling to support strong alignment architectures such as alpha andticso2003-06-041-5/+17
| | | | | | | | sparc64. PR: alpha/50658 Submitted by: rizzo Tested on: alpha
* Add a 'verrevpath' option that verifies the interface that a packetcjc2003-03-151-0/+2
| | | | | | | | | comes in on is the same interface that we would route out of to get to the packet's source address. Essentially automates an anti-spoofing check using the information in the routing table. Experimental. The usage and rule format for the feature may still be subject to change.
* Oops, forgot to commit this file. This is part of the fixmux2002-10-241-0/+2
| | | | for ipfw2 panics on sparc64.
* One bugfix and one new feature.luigi2002-08-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bugfix (ipfw2.c) makes the handling of port numbers with a dash in the name, e.g. ftp-data, consistent with old ipfw: use \\ before the - to consider it as part of the name and not a range separator. The new feature (all this description will go in the manpage): each rule now belongs to one of 32 different sets, which can be optionally specified in the following form: ipfw add 100 set 23 allow ip from any to any If "set N" is not specified, the rule belongs to set 0. Individual sets can be disabled, enabled, and deleted with the commands: ipfw disable set N ipfw enable set N ipfw delete set N Enabling/disabling of a set is atomic. Rules belonging to a disabled set are skipped during packet matching, and they are not listed unless you use the '-S' flag in the show/list commands. Note that dynamic rules, once created, are always active until they expire or their parent rule is deleted. Set 31 is reserved for the default rule and cannot be disabled. All sets are enabled by default. The enable/disable status of the sets can be shown with the command ipfw show sets Hopefully, this feature will make life easier to those who want to have atomic ruleset addition/deletion/tests. Examples: To add a set of rules atomically: ipfw disable set 18 ipfw add ... set 18 ... # repeat as needed ipfw enable set 18 To delete a set of rules atomically ipfw disable set 18 ipfw delete set 18 ipfw enable set 18 To test a ruleset and disable it and regain control if something goes wrong: ipfw disable set 18 ipfw add ... set 18 ... # repeat as needed ipfw enable set 18 ; echo "done "; sleep 30 && ipfw disable set 18 here if everything goes well, you press control-C before the "sleep" terminates, and your ruleset will be left active. Otherwise, e.g. if you cannot access your box, the ruleset will be disabled after the sleep terminates. I think there is only one more thing that one might want, namely a command to assign all rules in set X to set Y, so one can test a ruleset using the above mechanisms, and once it is considered acceptable, make it part of an existing ruleset.
* Fix a panic when doing "ipfw add pipe 1 log ..."luigi2002-07-171-1/+1
| | | | | Also synchronize ip_dummynet.c with the version in RELENG_4 to ease MFC's.
* Implement keepalives for dynamic rules, so they will not expireluigi2002-07-141-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | just because you leave your session idle. Also, put in a fix for 64-bit architectures (to be revised). In detail: ip_fw.h * Reorder fields in struct ip_fw to avoid alignment problems on 64-bit machines. This only masks the problem, I am still not sure whether I am doing something wrong in the code or there is a problem elsewhere (e.g. different aligmnent of structures between userland and kernel because of pragmas etc.) * added fields in dyn_rule to store ack numbers, so we can generate keepalives when the dynamic rule is about to expire ip_fw2.c * use a local function, send_pkt(), to generate TCP RST for Reset rules; * save about 250 bytes by cleaning up the various snprintf() in ipfw_log() ... * ... and use twice as many bytes to implement keepalives (this seems to be working, but i have not tested it extensively). Keepalives are generated once every 5 seconds for the last 20 seconds of the lifetime of a dynamic rule for an established TCP flow. The packets are sent to both sides, so if at least one of the endpoints is responding, the timeout is refreshed and the rule will not expire. You can disable this feature with sysctl net.inet.ip.fw.dyn_keepalive=0 (the default is 1, to have them enabled). MFC after: 1 day (just kidding... I will supply an updated version of ipfw2 for RELENG_4 tomorrow).
* Remove one unused command name.luigi2002-07-081-1/+0
|
* Implement the last 2-3 missing instructions for ipfw,luigi2002-07-051-0/+1
| | | | | | | | | | | | | | | | now it should support all the instructions of the old ipfw. Fix some bugs in the user interface, /sbin/ipfw. Please check this code against your rulesets, so i can fix the remaining bugs (if any, i think they will be mostly in /sbin/ipfw). Once we have done a bit of testing, this code is ready to be MFC'ed, together with a bunch of other changes (glue to ipfw, and also the removal of some global variables) which have been in -current for a couple of weeks now. MFC after: 7 days
* The new ipfw code.luigi2002-06-271-246/+289
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code makes use of variable-size kernel representation of rules (exactly the same concept of BPF instructions, as used in the BSDI's firewall), which makes firewall operation a lot faster, and the code more readable and easier to extend and debug. The interface with the rest of the system is unchanged, as witnessed by this commit. The only extra kernel files that I am touching are if_fw.h and ip_dummynet.c, which is quite tied to ipfw. In userland I only had to touch those programs which manipulate the internal representation of firewall rules). The code is almost entirely new (and I believe I have written the vast majority of those sections which were taken from the former ip_fw.c), so rather than modifying the old ip_fw.c I decided to create a new file, sys/netinet/ip_fw2.c . Same for the user interface, which is in sbin/ipfw/ipfw2.c (it still compiles to /sbin/ipfw). The old files are still there, and will be removed in due time. I have not renamed the header file because it would have required touching a one-line change to a number of kernel files. In terms of user interface, the new "ipfw" is supposed to accepts the old syntax for ipfw rules (and produce the same output with "ipfw show". Only a couple of the old options (out of some 30 of them) has not been implemented, but they will be soon. On the other hand, the new code has some very powerful extensions. First, you can put "or" connectives between match fields (and soon also between options), and write things like ipfw add allow ip from { 1.2.3.4/27 or 5.6.7.8/30 } 10-23,25,1024-3000 to any This should make rulesets slightly more compact (and lines longer!), by condensing 2 or more of the old rules into single ones. Also, as an example of how easy the rules can be extended, I have implemented an 'address set' match pattern, where you can specify an IP address in a format like this: 10.20.30.0/26{18,44,33,22,9} which will match the set of hosts listed in braces belonging to the subnet 10.20.30.0/26 . The match is done using a bitmap, so it is essentially a constant time operation requiring a handful of CPU instructions (and a very small amount of memmory -- for a full /24 subnet, the instruction only consumes 40 bytes). Again, in this commit I have focused on functionality and tried to minimize changes to the other parts of the system. Some performance improvement can be achieved with minor changes to the interface of ip_fw_chk_t. This will be done later when this code is settled. The code is meant to compile unmodified on RELENG_4 (once the PACKET_TAG_* changes have been merged), for this reason you will see #ifdef __FreeBSD_version in a couple of places. This should minimize errors when (hopefully soon) it will be time to do the MFC.
* Remove (almost all) global variables that were used to holdluigi2002-06-221-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | packet forwarding state ("annotations") during ip processing. The code is considerably cleaner now. The variables removed by this change are: ip_divert_cookie used by divert sockets ip_fw_fwd_addr used for transparent ip redirection last_pkt used by dynamic pipes in dummynet Removal of the first two has been done by carrying the annotations into volatile structs prepended to the mbuf chains, and adding appropriate code to add/remove annotations in the routines which make use of them, i.e. ip_input(), ip_output(), tcp_input(), bdg_forward(), ether_demux(), ether_output_frame(), div_output(). On passing, remove a bug in divert handling of fragmented packet. Now it is the fragment at offset 0 which sets the divert status of the whole packet, whereas formerly it was the last incoming fragment to decide. Removal of last_pkt required a change in the interface of ip_fw_chk() and dummynet_io(). On passing, use the same mechanism for dummynet annotations and for divert/forward annotations. option IPFIREWALL_FORWARD is effectively useless, the code to implement it is very small and is now in by default to avoid the obfuscation of conditionally compiled code. NOTES: * there is at least one global variable left, sro_fwd, in ip_output(). I am not sure if/how this can be removed. * I have deliberately avoided gratuitous style changes in this commit to avoid cluttering the diffs. Minor stule cleanup will likely be necessary * this commit only focused on the IP layer. I am sure there is a number of global variables used in the TCP and maybe UDP stack. * despite the number of files touched, there are absolutely no API's or data structures changed by this commit (except the interfaces of ip_fw_chk() and dummynet_io(), which are internal anyways), so an MFC is quite safe and unintrusive (and desirable, given the improved readability of the code). MFC after: 10 days
* Remove custom definitions (IP_FW_TCPF_SYN etc.) of TCP header flagsluigi2002-05-131-10/+0
| | | | which are the same as the original ones (TH_SYN etc.)
* Cleanup the interface to ip_fw_chk, two of the input argumentsluigi2002-05-091-3/+19
| | | | | | | | | | | | | | | were totally useless and have been removed. ip_input.c, ip_output.c: Properly initialize the "ip" pointer in case the firewall does an m_pullup() on the packet. Remove some debugging code forgotten long ago. ip_fw.[ch], bridge.c: Prepare the grounds for matching MAC header fields in bridged packets, so we can have 'etherfw' functionality without a lot of kernel and userland bloat.
* Remove __P.alfred2002-03-191-1/+1
|
* Implement matching IP precedence in ipfw(4).yar2001-12-211-1/+2
| | | | Submitted by: Igor Timkin <ivt@gamma.ru>
* MFS: sync the ipfw/dummynet/bridge code with the one recently mergedluigi2001-11-041-0/+1
| | | | into stable (mostly , but not only, formatting and comments changes).
* A few more style changes picked up whilst working on an MFC to -stable.joe2001-10-291-2/+2
|
* Fix some whitespace, and a comment that I missed in the last commit.joe2001-10-291-3/+4
|
* Clean up the style of this header file.joe2001-10-291-186/+190
|
* Two main changes here:luigi2001-09-271-62/+65
| | | | | | | | | | | | | | | + implement "limit" rules, which permit to limit the number of sessions between certain host pairs (according to masks). These are a special type of stateful rules, which might be of interest in some cases. See the ipfw manpage for details. + merge the list pointers and ipfw rule descriptors in the kernel, so the code is smaller, faster and more readable. This patch basically consists in replacing "foo->rule->bar" with "rule->bar" all over the place. I have been willing to do this for ages! MFC after: 1 week
* A bunch of minor changes to the code (see below) for readability, code sizeluigi2001-09-201-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and speed. No new functionality added (yet) apart from a bugfix. MFC will occur in due time and probably in stages. BUGFIX: fix a problem in old code which prevented reallocation of the hash table for dynamic rules (there is a PR on this). OTHER CHANGES: minor changes to the internal struct for static and dynamic rules. Requires rebuild of ipfw binary. Add comments to show how data structures are linked together. (It probably makes no sense to keep the chain pointers separate from actual rule descriptors. They will be hopefully merged soon. keep a (sysctl-readable) counter for the number of static rules, to speed up IP_FW_GET operations initial support for a "grace time" for expired connections, so we can set timeouts for closing connections to much shorter times. merge zero_entry() and resetlog_entry(), they use basically the same code. clean up and reduce replication of code for removing rules, both for readability and code size. introduce a separate lifetime for dynamic UDP rules. fix a problem in old code which prevented reallocation of the hash table for dynamic rules (PR ...) restructure dynamic rule descriptors introduce some local variables to avoid multiple dereferencing of pointer chains (reduces code size and hopefully increases speed).
* Introduce a new feature in IPFW: Check of the source or destinationphk2001-02-131-1/+4
| | | | | | | | | | | | | | | | | | | address is configured on a interface. This is useful for routers with dynamic interfaces. It is now possible to say: 0100 allow tcp from any to any established 0200 skipto 1000 tcp from any to any 0300 allow ip from any to any 1000 allow tcp from 1.2.3.4 to me 22 1010 deny tcp from any to me 22 1020 allow tcp from any to any and not have to worry about the behaviour if dynamic interfaces configure new IP numbers later on. The check is semi expensive (traverses the interface address list) so it should be protected as in the above example if high performance is a requirement.
* Sync with the bridge/dummynet/ipfw code already tested in stable.luigi2001-02-101-2/+2
| | | | | In ip_fw.[ch] change a couple of variable and field names to avoid having types, variables and fields with the same name.
* MFS: bridge/ipfw/dummynet fixes (bridge.c will be committed separately)luigi2001-02-021-0/+1
|
* o IPFW incorrectly handled filtering in the presence of previouslyrwatson2001-01-091-2/+2
| | | | | | | | | | | | | | | | | | | | reserved and now allocated TCP flags in incoming packets. This patch stops overloading those bits in the IP firewall rules, and moves colliding flags to a seperate field, ipflg. The IPFW userland management tool, ipfw(8), is updated to reflect this change. New TCP flags related to ECN are now included in tcp.h for reference, although we don't currently implement TCP+ECN. o To use this fix without completely rebuilding, it is sufficient to copy ip_fw.h and tcp.h into your appropriate include directory, then rebuild the ipfw kernel module, and ipfw tool, and install both. Note that a mismatch between module and userland tool will result in incorrect installation of firewall rules that may have unexpected effects. This is an MFC candidate, following shakedown. This bug does not appear to affect ipfilter. Reviewed by: security-officer, billf Reported by: Aragon Gouveia <aragon@phat.za.net>
* Add new fields for more granularity:billf2000-10-021-1/+28
| | | | | | | IP: version, tos, ttl, len, id TCP: seq#, ack#, window size Reviewed by: silence on freebsd-{net,ipfw}
* Remove obsolete comment.archie2000-08-221-1/+0
|
* Add tcpoptions to ipfw. This works much in the same way as ipoptions do.dan2000-06-081-0/+10
| | | | | | | | | | It also squashes 99% of packet kiddie synflood orgies. For example, to rate syn packets without MSS, ipfw pipe 10 config 56Kbit/s queue 10Packets ipfw add pipe 10 tcp from any to any in setup tcpoptions !mss Submitted by: Richard A. Steenbergen <ras@e-gerbil.net>
* Implement WF2Q+ in dummynet.luigi2000-06-081-2/+3
|
* Back out the previous change to the queue(3) interface.jake2000-05-261-1/+1
| | | | | | It was not discussed and should probably not happen. Requested by: msmith and others
* Change the way that the queue(3) structures are declared; don't assume thatjake2000-05-231-1/+1
| | | | | | | | the type argument to *_HEAD and *_ENTRY is a struct. Suggested by: phk Reviewed by: phk Approved by: mdodd
* Support for stateful (dynamic) ipfw rules. They are veryluigi2000-02-101-4/+35
| | | | | | | | similar to ipfilter's keep-state. Look at the updated ipfw(8) manpage for details. Approved-by: jordan
* Add ipfw hooks for the new dummynet features.luigi2000-01-081-1/+4
| | | | | | | Support masks on TCP/UDP ports. Minor cleanup of ip_fw_chk() to avoid repeated calls to PULLUP_TO at each rule.
* Change #ifdef KERNEL to #ifdef _KERNEL in the public headers. "KERNEL"peter1999-12-291-2/+2
| | | | | | is an application space macro and the applications are supposed to be free to use it as they please (but cannot). This is consistant with the other BSD's who made this change quite some time ago. More commits to come.
* Miscellaneous fixes/cleanups relating to ipfw and divert(4):archie1999-12-061-0/+3
| | | | | | | | | | | | | - Implement 'ipfw tee' (finally) - Divert packets by calling new function divert_packet() directly instead of going through protosw[]. - Replace kludgey global variable 'ip_divert_port' with a function parameter to divert_packet() - Replace kludgey global variable 'frag_divert_port' with a function parameter to ip_reass() - style(9) fixes Reviewed by: julian, green
* $Id$ -> $FreeBSD$peter1999-08-281-1/+1
|
* Correction: uid -> gid (comment)green1999-08-271-2/+2
|
* Implement probabilistic rule match in ipfw. Each rule can be associatedluigi1999-08-111-2/+20
| | | | | | | | | | | | | | | | | | | | | with a match probability to achieve non-deterministic behaviour of the firewall. This can be extremely useful for testing purposes such as simulating random packet drop without having to use dummynet (which already does the same thing), and simulating multipath effects and the associated out-of-order delivery (this time in conjunction with dummynet). The overhead on normal rules is just one comparison with 0. Since it would have been trivial to implement this by just adding a field to the ip_fw structure, I decided to do it in a backward-compatible way (i.e. struct ip_fw is unchanged, and as a consequence you don't need to recompile ipfw if you don't want to use this feature), since this was also useful for -STABLE. When, at some point, someone decides to change struct ip_fw, please add a length field and a version number at the beginning, so userland apps can keep working even if they are out of sync with the kernel.
* Make ipfw's logging more dynamic. Now, log will use the default limitgreen1999-08-011-1/+3
| | | | | | | | | | | | | _or_ you may specify "log logamount number" to set logging specifically the rule. In addition, "ipfw resetlog" has been added, which will reset the logging counters on any/all rule(s). ipfw resetlog does not affect the packet/byte counters (as ipfw reset does), and is the only "set" command that can be run at securelevel >= 3. This should address complaints about not being able to set logging amounts, not being able to restart logging at a high securelevel, and not being able to just reset logging without resetting all of the counters in a rule.
* Correct a really gross comment format.green1999-07-281-5/+7
|
* This is the much-awaited cleaned up version of IPFW [ug]id support.green1999-06-191-2/+8
| | | | All relevant changes have been made (including ipfw.8).
* Tidy up some stray / unused stuff in the IPFW package and friends.peter1999-04-201-9/+1
| | | | | | | | - unifdef -DCOMPAT_IPFW (this was on by default already) - remove traces of in-kernel ip_nat package, it was never committed. - Make IPFW and DUMMYNET initialize themselves rather than depend on compiled-in hooks in ip_init(). This means they initialize the same way both in-kernel and as kld modules. (IPFW initializes now :-)
* Last bits (i think) of dummynet for -current.luigi1998-12-141-3/+8
|
* Widen and change the layout of the IPFW structures flag element.phk1998-09-021-29/+29
| | | | | | This will allow us to add dummynet to 3.0 Recompile /sbin/ipfw AND your kernel.
OpenPOWER on IntegriCloud