+:::: =:[:[:...]]::[[len,]] .: ~: If two module sets have the same key (first element), they will be added in the order they are listed here. For others ( and definitions), only the first element will be utilized. Set definitions may come before or after they are referenced; they're all going into a database anyway, so this doesn't matter. For examples of configuration entries, see 'cfg/test.cfg'. For examples of modules, see 'modules/true.c' and 'modules/false.c'. : destination port (also the database key) : source port : remote ip address, optionally with '/' : local ip address, optionally with '/' The initial action (first character) may be specified as '+' or '-', and will be modified by the result of any modules used by the rule. '+' will accept connections by default, but will reject connections if any module (or other step along the way) fails or returns negative. '-' will reject connections by default, unless a module returns negative, in which case the connection will succeed. Note that other failures (say, a missing module, for example) will still cause the connection to be rejected. Omitted information will match anything. To match connections from any source port, for example, simply leave the source port as a null field. Example: +22::192.168.1.0/255.255.255.0::x509-22 (match any connections with a destination port of 22 and a remote host within 192.168.1.0/24. For these connections, use the X.509 module.) Note the difference in semanticcs between "source/destination" ports and "local/remote" ip addresses. This is done so that configuration files are easier to track, since "destination" ports and "remote" ip addresses are generally the two more important qualities of a peer connection and should be referenced before their counterparts. Additionally, it allows configuration database reuse, if desired, between client and server. '=' denotes a module set. Predefined module names (that is, module names that you predefine) are referenced here. You may reference as many as you like, to be executed subsequently; the list is terminated with a null module reference ('::'). is optional, and will be parsed as a comma-separated list of entries (in 'key=value' format), for lookup within the module using naw_data_get(). Multiple module sets with the same name will be accessed in the order they are listed; each module set may have a different set of data associated with it. Any module that returns false will break this chain and stop module processing. Example: =x509-22:x509:true::~x509-data,true=test =x509-22:true:: Here, module x509 will be loaded (if necessary), and executed with the data from dataset ~x509-data and true. If the x509 module succeeds, module true will be executed with the same data available to it. If module true succeeds, module true will be executed again, but this time without any data available to it. '~' denotes a module data set, so that your module set line needn't get too messy. You can use commas in data sets, and they'll wind up as part of the value; the only character that currently cannot be used is newline (this will be accommodated in the future). When referencing a data set, use the '~' in your reference, and do not append an '=' sign or value. Example: (referenced in the preceding example) ~x509-data:x509ServerKeyFile=/etc/naw/srv.key ~x509-data:x509ClientKeyFile=/etc/naw/cli.key ~x509-data:x509ServerCertFile=/etc/naw/srv.crt ~x509-data:x509ClientCertFile=/etc/naw/cli.crt ~x509-data:x509ServerCAFile=/etc/naw/ca.crt ~x509-data:x509ClientCAFile=/etc/naw/ca.crt All of the arguments associated with x509-data will be loaded in order. Note that if identical names are used (i.e., if x509ServerKeyFile were given twice), the second will not overwrite the first. Both will be loaded into memory, but only the first will be returned to modules. If a module unsets the name, the first will be removed, and the second will then be accessible. As such, it becomes like a dataset name FIFO stack, from which values may be popped. '.' is the module path, and it assigns the mnemonic reference used with a module set entry to a module path on the filesystem. This value must be an absolute pathname to the module. Note that in addition to using this pathname for dynamic library loading, libnaw also uses it as the key for this particular module in its internal module cache. All lines beginning with anything other than the characters referenced above will be ignored. MORE EXAMPLES: Given these definitions: .false:/usr/lib/naw/false.so .true:/usr/lib/naw/true.so =no:false:: =yes:true:: ... any of the following will create a default-accept rule: +:::: +::::yes -::::no (note, of course, that only the first matching rule will be used)