login.defs

package: shadow-utils

title: login.defs(5)

summary: shadow password suite configuration

text:
# login.defs(5)

## NAME
login.defs - shadow password suite configuration

## DESCRIPTION
The /etc/login.defs file defines the site-specific configuration for the shadow password suite. This file is required. Absence of this file will not prevent system operation, but will probably result in undesirable operation.

This file is a readable text file, each line of the file describing one configuration parameter. The lines consist of a configuration name and value, separated by whitespace. Blank lines and comment lines are ignored. Comments are introduced with a "#" pound sign and the pound sign must be the first non-white character of the line.

Parameter values may be of four types: strings, booleans, numbers, and long numbers. A string is comprised of any printable characters. A boolean should be either the value yes or no. An undefined boolean parameter or one with a value other than these will be given a no value. Numbers (both regular and long) may be either decimal values, octal values (precede the value with 0) or hexadecimal values (precede the value with 0x). The maximum value of the regular and long numeric parameters is machine-dependent.

The following configuration items are provided:

CHFN_RESTRICT (string)

This parameter specifies which values in the gecos field of the /etc/passwd file may be changed by regular users using the chfn program. It can be any combination of letters f, r, w, h, for Full name, Room number, Work phone, and Home phone, respectively. For backward compatibility, yes is equivalent to rwh and no is equivalent to frwh. If not specified, only the superuser can make any changes. The most restrictive setting is better achieved by not installing chfn SUID.

CREATE_HOME (boolean)

Indicate if a home directory should be created by default for new users. This setting does not apply to system users, and can be overridden on the command line.

CRYPT_PREFIX (string), CRYPT_ROUNDS (number)

The password hashing method and iteration count to use for group passwords that may be set with gpasswd. Please refer to crypt(3) for information on supported password hashing methods.

DEFAULT_HOME (boolean)

Indicate if login is allowed if we can't cd to the home directory. Default is no. If set to yes, the user will login in the root (/) directory if it is not possible to cd to her home directory.

ENCRYPT_METHOD (string)

This defines the system default encryption algorithm for encrypting passwords (if no algorithm are specified on the command line). It can take one of these values: DES (default), MD5. MD5 and DES should not be used for new hashes, see crypt(5) for recommendations.

Note: this parameter overrides the MD5_CRYPT_ENAB variable.

Note: This only affect the generation of group passwords. The generation of user passwords is done by PAM and subject to the PAM configuration. It is recommended to set this variable consistently with the PAM configuration.

ENV_PATH (string)

If set, it will be used to define the PATH environment variable when a regular user login. The value is a colon separated list of paths (for example /bin:/usr/bin) and can be preceded by PATH=. The default value is PATH=/bin:/usr/bin.

ENV_SUPATH (string)

If set, it will be used to define the PATH environment variable when the superuser login. The value is a colon separated list of paths (for example /sbin:/bin:/usr/sbin:/usr/bin) and can be preceded by PATH=. The default value is PATH=/sbin:/bin:/usr/sbin:/usr/bin.

ERASECHAR (number)

Terminal ERASE character (010 = backspace, 0177 = DEL). The value can be prefixed "0" for an octal value, or "0x" for an hexadecimal value.

FAIL_DELAY (number)

Delay in seconds before being allowed another attempt after a login failure.

FAKE_SHELL (string)

If set, login will execute this shell instead of the users' shell specified in /etc/passwd.

GID_MAX (number), GID_MIN (number)

Range of group IDs used for the creation of regular groups by useradd, groupadd, or newusers. The default value for GID_MIN (resp. GID_MAX) is 1000 (resp. 60000).

GROUPNAME_MAX (number)

Maximum number of characters for group names. This value can't be greater than 32. If not specified, 32 characters will be assumed.

HOME_MODE (number)

The mode for new home directories. If not specified, the UMASK is used to create the mode. useradd and newusers use this to set the mode of the home directory they create.

HUSHLOGIN_FILE (string)

If defined, this file can inhibit all the usual chatter during the login sequence. If a full pathname is specified, then hushed mode will be enabled if the user's name or shell are found in the file. If not a full pathname, then hushed mode will be enabled if the file exists in the user's home directory.

KILLCHAR (number)

Terminal KILL character (025 = CTRL/U). The value can be prefixed "0" for an octal value, or "0x" for an hexadecimal value.

LASTLOG_UID_MAX (number)

Highest user ID number for which the lastlog entries should be updated. As higher user IDs are usually tracked by remote user identity and authentication services there is no need to create a huge sparse lastlog file for them. No LASTLOG_UID_MAX option present in the configuration means that there is no user ID limit for writing lastlog entries.

LOG_OK_LOGINS (boolean)

Enable logging of successful logins.

LOG_UNKFAIL_ENAB (boolean)

Enable display of unknown usernames when login failures are recorded. Note: logging unknown usernames may be a security issue if an user enter her password instead of her login name.

LOGIN_RETRIES (number)

Maximum number of login retries in case of bad password. This will most likely be overridden by PAM, since the default pam_unix module has its own built in of 3 retries. However, this is a safe fallback in case you are using an authentication module that does not enforce PAM_MAXTRIES.

LOGIN_TIMEOUT (number)

Max time in seconds for login.

MAIL_DIR (string)

The mail spool directory. This is needed to manipulate the mailbox when its corresponding user account is modified or deleted. If not specified, a compile-time default is used. The parameter CREATE_MAIL_SPOOL in /etc/default/useradd determines whether the mail spool should be created.

MAIL_FILE (string)

Defines the location of the users mail spool files relatively to their home directory.

The MAIL_DIR and MAIL_FILE variables are used by useradd, usermod, and userdel to create, move, or delete the user's mail spool.

MAX_MEMBERS_PER_GROUP (number)

Maximum members per group entry. When the maximum is reached, a new group entry (line) is started in /etc/group (with the same name, same password, and same GID). The default value is 0, meaning that there are no limits in the number of members in a group.

This feature (split group) permits to limit the length of lines in the group file. This is useful to make sure that lines for NIS groups are not larger than 1024 characters.

If you need to enforce such limit, you can use 25.

Note: split groups may not be supported by all tools (even in the Shadow toolsuite). You should not use this variable unless you really need it.

MD5_CRYPT_ENAB (boolean)

Indicate if passwords must be encrypted using the MD5-based algorithm. If set to yes, new passwords will be encrypted using the MD5-based algorithm compatible with the one used by recent releases of FreeBSD. It supports passwords of unlimited length and longer salt strings. Set to no if you need to copy encrypted passwords to other systems which don't understand the new algorithm. Default is no. This variable is superseded by the ENCRYPT_METHOD variable or by any command line option used to configure the encryption algorithm.

This variable is deprecated. You should use ENCRYPT_METHOD.

Note: This only affect the generation of group passwords. The generation of user passwords is done by PAM and subject to the PAM configuration. It is recommended to set this variable consistently with the PAM configuration.

NONEXISTENT (string)

If a system account intentionally does not have a home directory that exists, this string can be provided in the /etc/passwd entry for the account to indicate this. The result is that pwck will not emit a spurious warning for this account.

PASS_MAX_DAYS (number)

The maximum number of days a password may be used. If the password is older than this, a password change will be forced. If not specified, -1 will be assumed (which disables the restriction).

PASS_MIN_DAYS (number)

The minimum number of days allowed between password changes. Any password changes attempted sooner than this will be rejected. If not specified, 0 will be assumed (which disables the restriction).

PASS_WARN_AGE (number)

The number of days warning given before a password expires. A zero means warning is given only upon the day of expiration, a value of -1 means no warning is given. If not specified, no warning will be provided.

PASS_MAX_DAYS, PASS_MIN_DAYS and PASS_WARN_AGE are only used at the time of account creation. Any changes to these settings won't affect existing accounts.

REGEXP_NAME (string)

Regular expression to which user/group names must match. If not defined or empty then traditional check will be performed. Note that leading digits are still not allowed regardless of defined regular expression. The names that differ by letter case only are also prohibited.

SAFE_PWDB_FIELDS (boolean)

If yes then non-ASCII characters in the password database files are not allowed.

SULOG_FILE (string)

If defined, all su activity is logged to this file.

SU_NAME (string)

If defined, the command name to display when running "su -". For example, if this is defined as "su" then a "ps" will display the command is "-su". If not defined, then "ps" would display the name of the shell actually being run, e.g. something like "-sh".

SUB_GID_MIN (number), SUB_GID_MAX (number), SUB_GID_COUNT (number)

If /etc/subuid exists, the commands useradd and newusers (unless the user already have subordinate group IDs) allocate SUB_GID_COUNT unused group IDs from the range SUB_GID_MIN to SUB_GID_MAX for each new user. The default values for SUB_GID_MIN, SUB_GID_MAX, SUB_GID_COUNT are respectively 100000, 600100000 and 65536.

SUB_UID_MIN (number), SUB_UID_MAX (number), SUB_UID_COUNT (number)

If /etc/subuid exists, the commands useradd and newusers (unless the user already have subordinate user IDs) allocate SUB_UID_COUNT unused user IDs from the range SUB_UID_MIN to SUB_UID_MAX for each new user. The default values for SUB_UID_MIN, SUB_UID_MAX, SUB_UID_COUNT are respectively 100000, 600100000 and 65536.

SYS_GID_MAX (number), SYS_GID_MIN (number)

Range of group IDs used for the creation of system groups by useradd, groupadd, or newusers. The default value for SYS_GID_MIN (resp. SYS_GID_MAX) is 101 (resp. GID_MIN-1).

SYS_UID_MAX (number), SYS_UID_MIN (number)

Range of user IDs used for the creation of system users by useradd or newusers. The default value for SYS_UID_MIN (resp. SYS_UID_MAX) is 101 (resp. UID_MIN-1).

SYSLOG_SG_ENAB (boolean)

Enable "syslog" logging of sg activity.

SYSLOG_SU_ENAB (boolean)

Enable "syslog" logging of su activity - in addition to sulog file logging.

TCB_AUTH_GROUP (boolean)

If yes, newly created tcb shadow files will be group owned by the auth group.

TCB_SYMLINKS (boolean)

If yes, the location of the user tcb directory to be created will not be automatically set to /etc/tcb/user, but will be computed depending on the UID of the user, according to the following algorithm:

```
if ( UID is less than 1000) {

  use /etc/tcb/user
} else if ( UID is less than 1000000) {

  kilos = UID / 1000

  use /etc/tcb/:kilos/user

  make symlink /etc/tcb/user to the above directory
} else {

  megas = UID / 1000000

  kilos = ( UID / megas * 1000000 ) / 1000

  use /etc/tcb/:megas/:kilos/user

  make symlink /etc/tcb/user to the above directory
}

```

TTYGROUP (string), TTYPERM (number)

The terminal permissions: the login tty will be owned by the TTYGROUP group, and the permissions will be set to TTYPERM. TTYGROUP can be either the name of a group or a numeric group identifier.

If TTYGROUP is not defined, then the group ownership of the terminal is set to the user's primary group. If TTYPERM is not defined, then the permissions are set to 0600.

If you have a write program which is "setgid" to a special group which owns the terminals, define TTYGROUP to the group number and TTYPERM to 0620. Otherwise leave TTYGROUP commented out and assign TTYPERM to either 622 or 600.

TTYTYPE_FILE (string)

If defined, file which maps tty line to TERM environment parameter. Each line of the file is in a format something like "vt100 tty01".

UID_MAX (number), UID_MIN (number)

Range of user IDs used for the creation of regular users by useradd or newusers. The default value for UID_MIN (resp. UID_MAX) is 1000 (resp. 60000).

UMASK (number)

The file mode creation mask is initialized to this value. If not specified, the mask will be initialized to 022. useradd and newusers use this mask to set the mode of the home directory they create if HOME_MODE is not set.

It is also used by pam_umask as the default umask value.

USERDEL_CMD (string)

If defined, this command is run when removing a user. It should remove any at/cron/print jobs etc. owned by the user to be removed (passed as the first argument). The return code of the script is not taken into account.

Here is an example script, which removes the user's cron, at and print jobs:

```
#! /bin/sh
# Check for the required argument.
if [ $# != 1 ]; then
	echo "Usage: $0 username"
	exit 1
fi
# Remove cron jobs.
crontab -r -u $1
# Remove at jobs.
# Note that it will remove any jobs owned by the same UID,
# even if it was shared by a different username.
AT_SPOOL_DIR=/var/spool/cron/atjobs
find $AT_SPOOL_DIR -name "[^.]*" -type f -user $1 -delete \;
# Remove print jobs.
lprm $1
# All done.
exit 0

```

USERGROUPS_ENAB (boolean)

If set to yes, userdel will remove the user's group if it contains no more members, and useradd will create by default a group with the name of the user.

USERNAME_MAX (number)

Maximum number of characters for user names. This value must be less than or equal to the length of an user name in utmp login records (usually 32 characters). If not specified, 32 characters will be assumed.

USE_TCB (boolean)

If yes, the tcb(5) password shadowing scheme will be used.

## CROSS REFERENCES
The following cross references show which programs in the shadow password suite use which parameters.

chage

USE_TCB

chfn

CHFN_RESTRICT SAFE_PWDB_FIELDS

chgpasswd

ENCRYPT_METHOD MAX_MEMBERS_PER_GROUP MD5_CRYPT_ENAB

chpasswd

gpasswd

ENCRYPT_METHOD MAX_MEMBERS_PER_GROUP MD5_CRYPT_ENAB CRYPT_PREFIX CRYPT_ROUNDS

groupadd

GID_MAX GID_MIN MAX_MEMBERS_PER_GROUP REGEXP_NAME SYS_GID_MAX SYS_GID_MIN GROUPNAME_MAX

groupdel

MAX_MEMBERS_PER_GROUP

groupmems

MAX_MEMBERS_PER_GROUP

groupmod

MAX_MEMBERS_PER_GROUP GROUPNAME_MAX REGEXP_NAME

grpck

MAX_MEMBERS_PER_GROUP

grpconv

MAX_MEMBERS_PER_GROUP

grpunconv

MAX_MEMBERS_PER_GROUP

lastlog

LASTLOG_UID_MAX

login

CONSOLE_GROUPS DEFAULT_HOME ERASECHAR FAIL_DELAY FAKE_SHELL HUSHLOGIN_FILE KILLCHAR LOGIN_RETRIES LOGIN_TIMEOUT LOG_OK_LOGINS LOG_UNKFAIL_ENAB TTYGROUP TTYPERM TTYTYPE_FILE USERGROUPS_ENAB

newgrp / sg

SYSLOG_SG_ENAB

newusers

ENCRYPT_METHOD GID_MAX GID_MIN MAX_MEMBERS_PER_GROUP MD5_CRYPT_ENAB HOME_MODE PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE REGEXP_NAME SUB_GID_COUNT SUB_GID_MAX SUB_GID_MIN SUB_UID_COUNT SUB_UID_MAX SUB_UID_MIN SYS_GID_MAX SYS_GID_MIN SYS_UID_MAX SYS_UID_MIN UID_MAX UID_MIN UMASK

pwck

PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE TCB_AUTH_GROUP TCB_SYMLINKS USE_TCB

pwconv

PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE USE_TCB

pwunconv

USE_TCB

su

CONSOLE_GROUPS DEFAULT_HOME ENV_PATH ENV_SUPATH SULOG_FILE SU_NAME SYSLOG_SU_ENAB

useradd

CREATE_HOME GID_MAX GID_MIN HOME_MODE LASTLOG_UID_MAX MAIL_DIR MAX_MEMBERS_PER_GROUP PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE REGEXP_NAME SAFE_PWDB_FIELDS SUB_GID_COUNT SUB_GID_MAX SUB_GID_MIN SUB_UID_COUNT SUB_UID_MAX SUB_UID_MIN SYS_GID_MAX SYS_GID_MIN SYS_UID_MAX SYS_UID_MIN UID_MAX UID_MIN UMASK USERNAME_MAX GROUPNAME_MAX TCB_AUTH_GROUP TCB_SYMLINK USE_TCB

userdel

MAIL_DIR MAIL_FILE MAX_MEMBERS_PER_GROUP USERDEL_CMD USERGROUPS_ENAB TCB_SYMLINKS USE_TCB

usermod

LASTLOG_UID_MAX MAIL_DIR MAIL_FILE MAX_MEMBERS_PER_GROUP USERNAME_MAX REGEXP_NAME SAFE_PWDB_FIELDS TCB_SYMLINKS USE_TCB

vipw

USE_TCB

## BUGS
Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by passwd(1), or less used by login(1), and su(1). Please refer to the corresponding PAM configuration files instead.

## SEE ALSO
gpasswd(1), login(1), passwd(1), su(1), crypt(3), passwd(5), shadow(5), pam(8).


shadow

title: shadow(5)

summary: shadowed password file

text:
# shadow(5)

## NAME
shadow - shadowed password file

## DESCRIPTION
shadow is a file which contains the password information for the system's accounts and optional aging information.

This file must not be readable by regular users if password security is to be maintained.

Each line of this file contains 9 fields, separated by colons (“:”), in the following order:

login name

It must be a valid account name, which exists on the system.

encrypted password

This field may be empty, in which case no passwords are required to authenticate as the specified login name. However, some applications which read the /etc/shadow file may decide not to permit any access at all if the password field is empty. A password field which starts with an exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked.

Refer to crypt(3) for details on how this string is interpreted.

If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means).

date of last password change

The date of the last password change, expressed as the number of days since Jan 1, 1970 00:00 UTC. The value 0 has a special meaning, which is that the user should change her password the next time she will log in the system.

An empty field means that password aging features are disabled.

minimum password age

The minimum password age is the number of days the user will have to wait before she will be allowed to change her password again. An empty field and value 0 mean that there is no minimum password age.

maximum password age

The maximum password age is the number of days after which the user will have to change her password. After this number of days is elapsed, the password may still be valid. The user should be asked to change her password the next time she will log in.

An empty field means that there are no maximum password age, no password warning period, and no password inactivity period (see below).

If the maximum password age is lower than the minimum password age, the user cannot change her password.

password warning period

The number of days before a password is going to expire (see the maximum password age above) during which the user should be warned. An empty field and value 0 mean that there are no password warning period.

password inactivity period

The number of days after a password has expired (see the maximum password age above) during which the password should still be accepted (and the user should update her password during the next login). After expiration of the password and this expiration period is elapsed, no login is possible for the user. The user should contact her administrator.

An empty field means that there are no enforcement of an inactivity period.

account expiration date

The date of expiration of the account, expressed as the number of days since Jan 1, 1970 00:00 UTC. Note that an account expiration differs from a password expiration. In case of an account expiration, the user shall not be allowed to login. In case of a password expiration, the user is not allowed to login using her password.

An empty field means that the account will never expire.

The value 0 should not be used as it is interpreted as either an account with no expiration, or as an expiration on Jan 1, 1970.

reserved field

This field is reserved for future use.

## FILES
/etc/passwd

User account information.

/etc/shadow

Secure user account information.

/etc/shadow-

Backup file for /etc/shadow. Note that this file is used by the tools of the shadow toolsuite, but not by all user and password management tools.

## SEE ALSO
chage(1), login(1), passwd(1), passwd(5), pwck(8), pwconv(8), pwunconv(8), su(1), sulogin(8).


sc.conf

package: shapercontrol

title: sc.conf(5)

summary: configuration file for sc(8).

text:
# sc.conf(5)

## NAME
sc.conf - configuration file for sc(8).

## DESCRIPTION
The sc.conf is parsed using "AppConfig" module and has a simple "variable = value" form. Expansion for internal and environment variables is enabled (see AppConfig(3) for details). The file may contain extra tabs and newlines for formatting. Comments begin with the # character and end at the end of line, like in shell or Perl scripts.

## OPTIONS
tc

Location of tc(8) executable.

out_if, in_if

Names of the interfaces that will be used for shaping of output and input traffic, respectively. Possible values: interface name or "disable" keyword, which disables rule generation.

limit_method

Rate limiting method. The hybrid method uses shaping for download and policing for upload, and all the rules are created on the in_if interface. This is suitable, when NAT is performed on the outbound interface. Possible values: shaping, policing, hybrid.

Default value: shaping.

debug

Debug modes. Possible values:

0

no debug (default value),

1

print command lines with nonzero return values,

2

print all command lines without execution.

Default value: 0.

verbose

When enabled, turns on verbose messages and disables piping of tc(8) rules. Possible values:

0

no verbose messages (default)

1

enable verbose messages (i.e. for results of `sync' command)

2

disable batch loading of rules for tc(8)

3

do 1 + 2

Default value: 0.

quiet

Suppress output. Does not affect messages caused by "verbose" flag. Possible values: boolean.

Default value: 0.

colored

Colorize output using ANSI escape sequences. Autodetection of non-tty handles is supported. Possible values: boolean.

Default value: 1.

joint

Perform add, change and delete operations on rules and database with a single command.

network

This variable contains the list of networks for classid calculation. These networks must cover all IPs which you are going to use in shaping rules. Possible values: a list of networks with masks from 16 to 31.

Total number of hosts in the specified networks should not exceed the maximum number of child classes: 65533 (from 2 to fffd, because fffe is reserved for default class, and ffff is for ingress policer).

Default value: 10.0.0.0/16.

filter_network

Network list for hashing filters generation. To improve the classification performance you may specify here a summarized network just like in case of supernetting (route aggregation). For example, if you have the following networks

```
        network = 10.0.0.0/20 10.0.253.0/24 10.0.254.0/24

```

you should specify a single 10.0.0.0/16 network to classify traffic by a single hashing filter

```
        filter_network = 10.0.0.0/16

```

Possible values: a list of networks with mask from 16 to 31, that includes the networks specified in network parameter.

Default value: same as network parameter.

default_policy

Default traffic policy for shaper. Possible values: block-all, block or pass.

block-all = block all traffic including shaper itself

block = block all IP's, except for shaper's interfaces (default)

pass = allow all traffic

Default value: block.

bypass_int

List of internal networks and IPs, whose traffic is transmitted without shaping. Possible values: space-separated list of networks with masks from 16 to 32.

Default value: empty.

bypass_ext

List of external networks and IPs, whose traffic is transmitted without shaping. Possible values: space-separated list of networks with masks from 16 to 32.

Default value: empty.

policer_burst_ratio

Ratio between the size of policer buffer size and bandwidth rate. Possible values: floating-point number.

Default value: 0.2.

quantum

Amount of bytes a stream is allowed to dequeue before the next queue gets a turn. Possible values: integer numbers >= MTU of the interface.

Default value: 1500.

rate_unit

Default rate unit. Possible values: see sc(8) or tc(8) manpage for list of units.

Default value: kibit.

rate_ratio

Ratio between bandwidth rates in rules and in the database.

rule_rate = db_rate * rate_ratio This coefficient is used only for load and sync commands.

Possible values: floating-point number.

Default value: 1.0.

root_qdisc

Root queueing discipline. Possible values: htb or hfsc.

Default value: htb.

leaf_qdisc

Leaf queueing discipline with parameters. This string will be used as a tail of corresponding "tc qdisc ..." command line. Possible values: all classless qdiscs supported by tc(8).

Default value: pfifo limit 100.

db_host

Database host. Possible values: IP-address or domain name.

Default value: 127.0.0.1.

db_driver

Database driver. Possible values: all database drivers supported by Perl DBI module. See output of "sc help" command for the list of available drivers.

Default value: SQLite.

db_user

Username to use when connecting to database. Possible values: depends on database server.

Default value: user.

db_pass

The password to use when connecting to database. Remember that specifying a password on the command line is insecure. Possible values: arbitrary string.

Default value: password.

db_name

Database name to use. Possible values: arbibrary string (should be a valid filename in case of SQLite driver).

Default value: sc.db.

Database queries

create

Create table with "ip" and "rate" columns.

load

Select all data from table.

list

Select data for one IP.

add

add a new entry.

del

delete an existing entry.

change

modify an existing entry.

Syslog options

enable

Output errors and warnings to syslog. Possible values: boolean.

Default value: 1.

options

Possible values (comma-separated):

ndelay

open the connection immediately

nofatal

just emit warnings instead of dying if the connection to syslog can't be established

perror

write the message to standard error output as well to the syslog

pid

include PID with each message

Default value: <empty string>.

facility

Possible values: see Sys::Syslog(3), section "Facilities". Default value: user.

## SEE ALSO
sc(8), tc(8), tc-htb(8), tc-hfsc(8), tc-u32(8), tc-pfifo(8), AppConfig(3), Sys::Syslog(3). http://lartc.org/howto/lartc.adv-filter.hashing.html, http://ace-host.stuart.id.au/russell/files/tc/doc/cls_u32.txt.

## AUTHOR
Stanislav Kruchinin <stanislav.kruchinin@gmail.com>


uuencode

package: sharutils

title: uuencode(5)

summary: format of an encoded uuencode file

text:
# uuencode(5)

## NAME
uuencode - format of an encoded uuencode file

## DESCRIPTION
Files output by uuencode(1) consist of a header line, followed by a number of body lines, and a trailer line. The uudecode(1) command will ignore any lines preceding the header or following the trailer. Lines preceding a header must not, of course, look like a header.

The header line is distinguished by having the first 5 characters be begin followed by a space, or else a hyphen and either base64 or encoded or both (also separated with a hyphen). The base64 option says the file has been encoded using base64. The encoded option says the output file name has been base64 encoded. It is never encoded with traditional uuencoding. This is a GNU extension. These are followed by a mode (in octal), and a string which names the remote file. The mode is separated from the begin clause and the file name by a single space character.

### Traditional uuencoding
The traditional uuencoded file body consists of a number of lines, each at most 62 characters long (including the trailing newline). These consist of a character count letter, followed by the encoded characters, followed by a newline. The character count is a single printing character, and represents an integer, the number of bytes the rest of the line represents. Such integers are always in the range from 0 to 63 and can be determined by subtracting the character space (octal 40) from the character.

Groups of 3 bytes are stored in 4 characters, 6 bits per character. All are offset by a space to make the characters printing. The last line may be shorter than the normal 45 bytes. If the size is not a multiple of 3, this fact can be determined by the value of the count on the last line. Extra garbage will be included to make the character count a multiple of 4. The body is terminated by a line with a count of zero. This line consists of one ASCII space.

The trailer line consists of end on a line by itself.

### base64 encoding
base64 encoded files follow the specified format for the body, but also include a begin-base64 header and a trailer line of four = characters.

## EXAMPLES

```
begin-base64-encoded 644 VE9ETw==
```

This introduces a base64 encoded file named, TODO with that name encoded using base64 encoding.

```
begin-encoded 644 5$]$3P``
```

This introduces an encoded file named, TODO with that name encoded using uuencoding. The encoding is a lot less friendly. Please prefer base64 encoding.

## CONFORMING TO
IEEE Std 1003.1, plus extensions

The -encoded suffix to the begin header line is a GNU extension. Recipients must have the GNU uudecode program to decode them.

## SEE ALSO
uuencode(1), uudecode(1), base64(1GNU)

## HISTORY
The uuencode file format appeared in BSD 4.0 .


shorewall-accounting

package: shorewall

title: shorewall-accounting(5)

summary: Shorewall Accounting file

text:
# shorewall-accounting(5)

## NAME
accounting - Shorewall Accounting file

## SYNOPSIS
/etc/shorewall[6]/accounting

## DESCRIPTION
Accounting rules exist simply to count packets and bytes in categories that you define in this file. You may display these rules and their packet and byte counters using the shorewall show accounting command.

Beginning with Shorewall 4.4.18, the accounting structure can be created with three root chains:

•accountin: Rules that are valid in the INPUT chain (may not specify an output interface).

•accountout: Rules that are valid in the OUTPUT chain (may not specify an input interface or a MAC address).

•accounting: Other rules.

The new structure is enabled by sectioning the accounting file in a manner similar to the rules file[1]. The sections are INPUT, OUTPUT and FORWARD and must appear in that order (although any of them may be omitted). The first non-commentary record in the accounting file must be a section header when sectioning is used.

Warning

If sections are not used, the Shorewall rules compiler cannot detect certain violations of netfilter restrictions. These violations can result in run-time errors such as the following:

iptables-restore v1.4.13: Can't use -o with INPUT

Beginning with Shorewall 4.4.20, the ACCOUNTING_TABLE setting was added to shorewall.conf and shorewall6.conf. That setting determines the Netfilter table (filter or mangle) where the accounting rules are added. When ACCOUNTING_TABLE=mangle is specified, the available sections are PREROUTING, INPUT, OUTPUT, FORWARD and POSTROUTING.

Section headers have the form:

?SECTION section-name

When sections are enabled:

•A jump to a user-defined accounting chain must appear before entries that add rules to that chain. This eliminates loops and unreferenced chains.

•An output interface may not be specified in the PREROUTING and INPUT sections.

•In the OUTPUT and POSTROUTING sections:

•An input interface may not be specified

•Jumps to a chain defined in the INPUT or PREROUTING sections that specifies an input interface are prohibited

•MAC addresses may not be used

•Jump to a chain defined in the INPUT or PREROUTING section that specifies a MAC address are prohibited.

•The default value of the CHAIN column is:

•accountin in the INPUT section

•accountout in the OUTPUT section

•accountfwd in the FORWARD section

•accountpre in the PREROUTING section

•accountpost in the POSTROUTING section

•Traffic addressed to the firewall goes through the rules defined in the INPUT section.

•Traffic originating on the firewall goes through the rules defined in the OUTPUT section.

•Traffic being forwarded through the firewall goes through the rules from the FORWARD sections.

The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax):

ACTION - {COUNT|DONE|chain[:{COUNT|JUMP}]|ACCOUNT(table,network)|[?]COMMENT comment}

What to do when a matching packet is found. COUNT

Simply count the match and continue with the next rule

DONE

Count the match and don't attempt to match any other accounting rules in the chain specified in the CHAIN column.

chain[:COUNT]

Where chain is the name of a chain; shorewall will create the chain automatically if it doesn't already exist. If a second chain is mentioned in the CHAIN column, then a jump from this second chain to chain is created. If no chain is named in the CHAIN column, then a jump from the default chain to chain is created. If :COUNT is included, a counting rule matching this entry will be added to chain. The chain may not exceed 29 characters in length and may be composed of letters, digits, dash ('-') and underscore ('_').

chain:JUMP

Like the previous option without the :COUNT part.

ACCOUNT(table,network)

This action implements per-IP accounting and was added in Shorewall 4.4.17. Requires the ACCOUNT Target capability in your iptables and kernel (see the output of shorewall show capabilities). table

is the name of an accounting table (you choose the name). All rules specifying the same name will have their per-IP counters accumulated in the same table.

network

is an IPv4 network in CIDR notation (e.g., 192.168.1.0/24). The network can be as large as a /8 (class A).

One nice feature of per-IP accounting is that the counters survive shorewall restart. This has a downside, however. If you change the network associated with an accounting table, then you must shorewall stop; shorewall start to have a successful restart (counters will be cleared).

The counters in a table are printed using the iptaccount utility. For a command synopsis, type:

iptaccount --help

As of February 2011, the ACCOUNT Target capability and the iptaccount utility are only available when xtables-addons[2] is installed. See https://shorewall.org/Accounting.html#perIP[3] for additional information.

INLINE

Added in Shorewall 4.5.16. Allows free form iptables matches to be specified following a ';'. In the generated iptables rule(s), the free form matches will follow any matches that are generated by the column contents.

NFACCT({object[!]}[,...])

Added in Shorewall 4.5.7. Provides a form of accounting that survives shorewall stop/shorewall start and shorewall restart. Requires the NFaccnt Match capability in your kernel and iptables. object names an nfacct object (see man nfaccnt(8)). Multiple rules can specify the same object; all packets that match any of the rules increment the packet and bytes count of the object. Prior to Shorewall 4.5.16, only one object could be specified. Beginning with Shorewall 4.5.16, an arbitrary number of objects may be given.

With Shorewall 4.5.16 or later, an nfacct object in the list may optionally be followed by ! to indicate that the nfacct object will be incremented unconditionally for each packet. When ! is omitted, the object will be incremented only if all of the matches in the rule succeed.

NFLOG[(nflog-parameters)] - Added in Shorewall-4.4.20.

Causes each matching packet to be sent via the currently loaded logging back-end (usually nfnetlink_log) where it is available to accounting daemons through a netlink socket.

?COMMENT

The remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word ?COMMENT.

CHAIN - {-|chain}

The name of a chain. If specified as - the accounting chain is assumed when the file is un-sectioned. When the file is sectioned, the default is one of accountin, accountout, etc. depending on the section. This is the chain where the accounting rule is added. The chain will be created if it doesn't already exist. The chain may not exceed 29 characters in length.

SOURCE - {-|any|all|interface|interface:address|address}

Packet Source. The name of an interface, an address (host or net) or an interface name followed by ":" and a host or net address. An ipset name is also accepted as an address.

DEST - {-|any|all|interface|interface:address|address}

This column was formerly named DESTINATION. Packet Destination.

Format same as SOURCE column.

PROTO - {-|{any|all|protocol-name|protocol-number|ipp2p[:{udp|all}]}[,...]}

This column was formerly named PROTOCOL A protocol-name (from protocols(5)), a protocol-number, ipp2p, ipp2p:udp or ipp2p:all

Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols.

DPORT - {-|any|all|ipp2p-option|port-name-or-number[,port-name-or-number]...}

Destination Port number. Service name from services(5) or port number. May only be specified if the protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). You may place a comma-separated list of port names or numbers in this column if your kernel and iptables include multi-port match support.

If the PROTOCOL is ipp2p then this column must contain an ipp2p-option ("iptables -m ipp2p --help") without the leading "--". If no option is given in this column, ipp2p is assumed.

This column was formerly named DEST PORT(S).

SPORT - {-|any|all|port-name-or-number[,port-name-or-number]...}

Service name from services(5) or port number. May only be specified if the protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). You may place a comma-separated list of port numbers in this column if your kernel and iptables include multi-port match support.

Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DPORT. Use of '=' requires multi-port match in your iptables and kernel.

This column was formerly labelled SOURCE PORT(S).

USER - [!][user-name-or-number][:group-name-or-number][+program-name]

This column was formerly named USER/GROUP and may only be non-empty if the CHAIN is OUTPUT. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given).

Examples:

joe

program must be run by joe

:kids

program must be run by a member of the 'kids' group

!:kids

program must not be run by a member of the 'kids' group

+upnpd

\#program named upnpd

Important

The ability to specify a program name was removed from Netfilter in kernel version 2.6.14.

MARK - [!]value[/mask][:C]

Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field.

!

Inverts the test (not equal)

value

Value of the packet or connection mark.

mask

A mask to be applied to the mark before testing.

:C

Designates a connection mark. If omitted, the packet mark's value is tested.

IPSEC - option-list (Optional - Added in Shorewall 4.4.13 but broken until 4.5.4.1 )

The option-list consists of a comma-separated list of options from the following list. Only packets that will be encrypted or have been decrypted via an SA that matches these options will have their source address changed. reqid=number

where number is specified using setkey(8) using the 'unique:number option for the SPD level.

spi=<number>

where number is the SPI of the SA used to encrypt/decrypt packets.

proto=ah|esp|ipcomp

IPSEC Encapsulation Protocol

mss=number

sets the MSS field in TCP packets

mode=transport|tunnel

IPSEC mode

tunnel-src=address[/mask]

only available with mode=tunnel

tunnel-dst=address[/mask]

only available with mode=tunnel

strict

Means that packets must match all rules.

next

Separates rules; can only be used with strict

yes or ipsec

When used by itself, causes all traffic that will be encrypted/encapsulated or has been decrypted/un-encapsulated to match the rule.

no or none

When used by itself, causes all traffic that will not be encrypted/encapsulated or has been decrypted/un-encapsulated to match the rule.

in

May only be used in the FORWARD section and must be the first or the only item the list. Indicates that matching packets have been decrypted in input.

out

May only be used in the FORWARD section and must be the first or the only item in the list. Indicates that matching packets will be encrypted on output.

If this column is non-empty and sections are not used, then:

•A chain NAME appearing in the ACTION column must be a chain branched either directly or indirectly from the accipsecin or accipsecout chain.

•The CHAIN column must contain either accipsecin or accipsecout or a chain branched either directly or indirectly from those chains.

•These rules will NOT appear in the accounting chain.

In all of the above columns except ACTION and CHAIN, the values -, any and all may be used as wildcard'gs. Omitted trailing columns are also treated as wildcard'g.

## FILES
/etc/shorewall/accounting

/etc/shorewall6/accounting

## SEE ALSO
shorewall-logging(5)[4]

https://shorewall.org/configuration_file_basics.htm#Pairs[5]

shorewall(8)

## NOTES
1.

rules file

https://shorewall.org/manpages/shorewall-rules.html

2.

xtables-addons

http://xtables-addons.sourceforge.net/

3.

https://shorewall.org/Accounting.html#perIP

https://shorewall.org/Accounting.html#perIP

4.

shorewall-logging(5)

https://shorewall.org/manpages/shorewall-logging.htm

5.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-actions

title: shorewall-actions(5)

summary: Shorewall action declaration file

text:
# shorewall-actions(5)

## NAME
actions - Shorewall action declaration file

## SYNOPSIS
/etc/shorewall[6]/actions

## DESCRIPTION
This file allows you to define new ACTIONS for use in rules (see shorewall-rules(5)[1]). You define the iptables rules to be performed in an ACTION in /etc/shorewall/action.action-name.

Columns are:

NAME

The name of the action. ACTION names should begin with an upper-case letter to distinguish them from Shorewall-generated chain names and be composed of letters, digits or numbers. If you intend to log from the action then the name must be no longer than 11 characters in length if you use the standard LOGFORMAT.

OPTIONS

Added in Shorewall 4.5.10. Available options are: audit

Added in Shorewall 5.0.7. When this option is specified, the action is expected to have at least two parameters; the first is a target and the second is either 'audit' or omitted. If the second is 'audit', then the first must be an auditable target (ACCEPT, DROP or REJECT).

builtin

Added in Shorewall 4.5.16. Defines the action as a rule target that is supported by your iptables but is not directly supported by Shorewall. The action may be used as the rule target in an INLINE rule in shorewall-rules[1](5). Beginning with Shorewall 4.6.0, the Netfilter table(s) in which the builtin can be used may be specified: filter, nat, mangle and raw. If no table name(s) are given, then filter is assumed. The table names follow builtin and are separated by commas; for example, "FOOBAR builtin,filter,mangle" would specify FOOBAR as a builtin target that can be used in the filter and mangle tables.

Beginning with Shorewall 4.6.4, you may specify the terminating option with builtin to indicate to the Shorewall optimizer that the action is terminating (the current packet will not be passed to the next rule in the chain).

inline

Causes the action body (defined in action.action-name) to be expanded in-line like a macro rather than in its own chain. You can list Shorewall Standard Actions in this file to specify the inline option.

Caution

Some of the Shorewall standard actions cannot be used in-line and will generate a warning and the compiler will ignore inline if you try to use them that way: DropSmurfs

IfEvent

Invalid (Prior to Shorewall 4.5.13)

NotSyn (Prior to Shorewall 4.5.13)

RST (Prior to Shorewall 4.5.13)

TCPFlags

logjump

Added in Shorewall 5.0.8. Performs the same function as nolog (below), with the addition that the jump to the actions chain is logged if a log level is specified on the action invocation. For inline actions, this option is identical to nolog.

mangle

Added in Shorewall 5.0.7. Specifies that this action is to be used in shorewall-mangle(5)[2] rather than shorewall-rules(5)[1].

nat

Added in Shorewall 5.0.13. Specifies that this action is to be used in shorewall-snat(5)[3] rather than shorewall-rules(5)[1]. The mangle and nat options are mutually exclusive.

noinline

Causes any later inline option for the same action to be ignored with a warning.

nolog

Added in Shorewall 4.5.11. When this option is specified, the compiler does not automatically apply the log level and/or tag from the invocation of the action to all rules inside of the action. Rather, it simply sets the $_loglevel and $_logtag shell variables which can be used within the action body to apply those logging options only to a subset of the rules.

proto=protocol

Added in Shorewall 5.1.10. Specifies that the action is only usable with the specified protocol (name or number). When the action is invoked with no protocol specified in the PROTO column, or if the action is used as a Policy Action, the named protocol will be assumed. If a protocol is specified in the PROTO column of an invocation, then it must match the named protocol. The proto option has no effect if the inline or builtin option is specified. A warning is issued if proto is specified along with builtin.

dport=portorservice

Added in Shorewall 5.2.6. Requires that the proto option be previously given and indicates that this action may only be applied to flows with the specified protocol and portorservice. portorservice may be a valid port number or the name of a service defined in /etc/services to be usable with the specified protocol. If a port or service is specified in the DPORT column of an invocation, then it must match the named portorservice.

section

Added in Shorewall 5.1.1. When specified, this option causes the rules file section name and a comma to be prepended to the parameters passed to the action (if any). Note that this means that the first parameter passed to the action by the user is actually the second parameter to the action. If the action is invoked out of the blrules file, 'BLACKLIST' is used as the section name. Given that neither the snat nor the mangle file is sectioned, this parameter has no effect when mangle or nat is specified.

state={UNTRACKED|NEW|ESTABLISHED|RELATED|INVALID}

Added in Shorewall 5.0.7. Reserved for use by Shorewall in actions.std.

terminating

Added in Shorewall 4.6.4. When used with builtin, indicates that the built-in action is termiating (i.e., if the action is jumped to, the next rule in the chain is not evaluated).

## FILES
/etc/shorewall/actions

/etc/shorewall6/actions

## SEE ALSO
https://shorewall.org/Actions.html[4]

shorewall(8)

## NOTES
1.

shorewall-rules(5)

https://shorewall.org/manpages/shorewall-rules.html

2.

shorewall-mangle(5)

https://shorewall.org/manpages/shorewall-mangle.html

3.

shorewall-snat(5)

https://shorewall.org/manpages/shorewall-snat.html

4.

https://shorewall.org/Actions.html

https://shorewall.org/Actions.html


shorewall-addresses

title: shorewall-addresses(5)

text:
# shorewall-addresses(5)

## NAME
addresses - Specifying addresses within a Shorewall configuration

## DESCRIPTION
In both Shorewall and Shorewall6, there are two basic types of addresses:

Host Address

This address type refers to a single host. In IPv4, the format is i.j.k.l where i through l are decimal numbers between 1 and 255.

In IPv6, the format is a:b:c:d:e:f:g:h where a through h consist of 1 to 4 hexadecimal digits (leading zeros may be omitted). a single series of 0 addresses may be omitted. For example 2001:227:e857:1:0:0:0:0:1 may be written 2001:227:e857:1::1.

Network Address

A network address refers to 1 or more hosts and consists of a host address followed by a slash ("/") and a Variable Length Subnet Mask (VLSM). This is known as Classless Internet Domain Routing (CIDR) notation. The VLSM is a decimal number. For IPv4, it is in the range 0 through 32. For IPv6, the range is 0 through 128. The number represents the number of leading bits in the address that represent the network address; the remainder of the bits are a host address and are generally given as zero.

Examples:

IPv4: 192.168.1.0/24

IPv6: 2001:227:e857:1:0:0:0:0:1/64

In the Shorewall documentation and manpages, we have tried to make it clear which type of address is accepted in each specific case.

Because Shorewall uses a colon (":") as a separator in many contexts, IPv6 addresses are best written using the standard convention in which the address itself is enclosed in square brackets:

[2001:227:e857:1::1]

[2001:227:e857:1::]/64

## SPECIFYING SOURCE AND DEST
Entries in Shorewall configuration files often deal with the source (SOURCE) and destination (DEST) of connections and Shorewall implements a uniform way for specifying them.

A SOURCE or DEST consists of one to three parts separated by colons (":"):

1.ZONE — The name of a zone declared in /etc/shorewall/zones or /etc/shorewall6/zones. This part is only available in the rules file (/etc/shorewall/rules, /etc/shorewall/blrules,/etc/shorewall6/rules and /etc/shorewall6/blrules).

2.INTERFACE — The name of an interface that matches an entry in /etc/shorewall/interfaces (/etc/shorewall6/interfaces). Beginning with Shorweall 5.2.1, the interface may be preceded with '!' which matches all interfaces except the one specified.

3.ADDRESS LIST — A list of one or more addresses (host or network) or address ranges, separated by commas. In an IPv6 configuration, this list must be included in square or angled brackets ("[...]" or "<...>"). The list may have exclusion.

Examples.

1.All hosts in the net zone — net

2.Subnet 192.168.1.0/29 in the loc zone — loc:192.168.1.0/29

3.All hosts in the net zone connecting through ppp0 — net:ppp0

4.All hosts interfaced by eth3 — eth3

5.Subnet 10.0.1.0/24 interfacing through eth2 — eth2:10.0.1.0/24

6.Host 2002:ce7c:92b4:1:a00:27ff:feb1:46a9 in the loc zone — loc:[2002:ce7c:92b4:1:a00:27ff:feb1:46a9]

7.The primary IP address of eth0 in the $FW zone - $FW:&eth0

8.All hosts in Vatican City - net:^VA (Requires the GeoIP Match capability).

## IP ADDRESS RANGES
If you kernel and iptables have IP Range match support, you may use IP address ranges in Shorewall configuration file entries; IP address ranges have the syntax <low IP address>-<high IP address>.

Example: 192.168.1.5-192.168.1.12.

## SEE ALSO
For more information about addressing, see theSetup Guide[1].

## NOTES
1.

Setup Guide

https://shorewall.org/manpages/shorewall_setup_guide.htm#Addressing


shorewall-arprules

title: shorewall-arprules(5)

summary: Shorewall ARP rules file

text:
# shorewall-arprules(5)

## NAME
arprules - Shorewall ARP rules file

## SYNOPSIS
/etc/shorewall/arprules

## DESCRIPTION
IPv4 only.

This file was added in Shorewall 4.5.12 and is used to describe low-level rules managed by arptables (8). These rules only affect Address Resolution Protocol (ARP), Reverse Address Resolution Protocol (RARP) and Dynamic Reverse Address Resolution Protocol (DRARP) frames.

The columns in the file are as shown below. MAC addresses are specified normally (6 hexadecimal numbers separated by colons).

ACTION

Describes the action to take when a frame matches the criteria in the other columns. Possible values are: ACCEPT

This is the default action if no rules matches a frame; it lets the frame go through.

DROP

Causes the frame to be dropped.

SNAT:ip-address

Modifies the source IP address to the specified ip-address.

DNAT:ip-address

Modifies the destination IP address to the specified ip-address.

SMAT:mac-address

Modifies the source MAC address to the specified mac-address.

DMAT:mac-address

Modifies the destination MAC address to the specified mac-address.

SNATC:ip-address

Like SNAT except that the frame is then passed to the next rule.

DNATC:ip-address

Like DNAT except that the frame is then passed to the next rule.

SMATC:mac-address

Like SMAT except that the frame is then passed to the next rule.

DMATC:mac-address

Like DMAT except that the frame is then passed to the next rule.

SOURCE - [interface[:[!]ipaddress[/ipmask][:[!]macaddress[/macmask]]]]

Where interface

Is an interface defined in shorewall-interfaces(5).

ipaddress

is an IPv4 address. DNS names are not allowed.

ipmask

specifies a mask to be applied to ipaddress.

macaddress

The source MAC address.

macmask

Mask for MAC address; must be specified as 6 hexadecimal numbers separated by colons.

When '!' is specified, the test is inverted.

If not specified, matches only frames originating on the firewall itself.

Caution

Either SOURCE or DEST must be specified.

DEST - [interface[:[!]ipaddress[/ipmask][:[!]macaddress[/macmask]]]]

Where interface

Is an interface defined in shorewall-interfaces(5).

ipaddress

is an IPv4 address. DNS Names are not allowed.

ipmask

specifies a mask to be applied to frame addresses.

macaddress

The destination MAC address.

macmask

Mask for MAC address; must be specified as 6 hexadecimal numbers separated by colons.

When '!' is specified, the test is inverted and the rule matches frames which do not match the specified address/mask.

If not specified, matches only frames originating on the firewall itself.

If both SOURCE and DEST are specified, then both interfaces must be bridge ports on the same bridge.

Caution

Either SOURCE or DEST must be specified.

OPCODE - [[!]opcode]

Optional. Describes the type of frame. Possible opcode values are: 1

ARP Request

2

ARP Reply

3

RARP Request

4

RARP Reply

5

Dynamic RARP Request

6

Dynamic RARP Reply

7

Dynamic RARP Error

8

InARP Request

9

ARP NAK

When '!' is specified, the test is inverted and the rule matches frames which do not match the specified opcode.

## EXAMPLE
The eth1 interface has both a public IP address and a private address (10.1.10.11/24). When sending ARP requests to 10.1.10.0/24, use the private address as the IP source:

```
#ACTION                SOURCE                  DEST                ARP OPCODE
SNAT:10.1.10.11        -                       eth1:10.1.10.0/24   1
```

## FILES
/etc/shorewall/arprules

## SEE ALSO
shorewall(8)


shorewall-blrules

title: shorewall-blrules(5)

summary: shorewall Blacklist file

text:
# shorewall-blrules(5)

## NAME
blrules - shorewall Blacklist file

## SYNOPSIS
/etc/shorewall[6]/blrules

## DESCRIPTION
This file is used to perform blacklisting and whitelisting.

Rules in this file are applied depending on the setting of BLACKLIST in shorewall.conf[1](5).

The format of rules in this file is the same as the format of rules in shorewall-rules (5)[2]. The difference in the two files lies in the ACTION (first) column.

ACTION- {ACCEPT|BLACKLIST|blacklog|CONTINUE|DROP|A_DROP|REJECT|A_REJECT|WHITELIST|LOG|QUEUE|NFQUEUE[(queuenumber)]|[?]COMMENT|action|macro[(target)]}[:{log-level|none}[!][:tag]]

Specifies the action to be taken if the packet matches the rule. Must be one of the following. BLACKLIST

Added in Shorewall 4.5.3. This is actually a macro that expands as follows:

•If BLACKLIST_LOGLEVEL is specified in shorewall.conf[1](5), then the macro expands to blacklog.

•Otherwise it expands to the action specified for BLACKLIST_DISPOSITION in shorewall.conf[1](5).

blacklog

May only be used if BLACKLIST_LOGLEVEL is specified in shorewall.conf[1](5). Logs, audits (if specified) and applies the BLACKLIST_DISPOSITION specified in shorewall.conf[1] (5).

ACCEPT|CONTINUE|WHITELIST

Exempt the packet from the remaining rules in this file.

DROP

Ignore the packet.

A_DROP

Audited version of DROP. Requires AUDIT_TARGET support in the kernel and ip6tables.

REJECT

disallow the packet and return an icmp-unreachable or an RST packet.

A_REJECT

Audited versions of REJECT. Require AUDIT_TARGET support in the kernel and ip6tables.

LOG

Simply log the packet and continue with the next rule.

QUEUE

Queue the packet to a user-space application such as ftwall (http://p2pwall.sf.net). The application may reinsert the packet for further processing.

NFLOG[(nflog-parameters)]

queues matching packets to a back end logging daemon via a netlink socket then continues to the next rule. See shorewall-logging(5)[3].

NFQUEUE

Queues the packet to a user-space application using the nfnetlink_queue mechanism. If a queuenumber is not specified, queue zero (0) is assumed.

?COMMENT

The rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of "shorewall show <chain>". To stop the comment from being attached to further rules, simply include ?COMMENT on a line by itself.

action

The name of an action declared in shorewall-actions[4](5) or in /usr/share/shorewall/actions.std.

macro

The name of a macro defined in a file named macro.macro. If the macro accepts an action parameter (Look at the macro source to see if it has PARAM in the TARGET column) then the macro name is followed by the parenthesized target (ACCEPT, DROP, REJECT, ...) to be substituted for the parameter. Example: FTP(ACCEPT).

The ACTION may optionally be followed by ":" and a syslog log level (e.g, REJECT:info or Web(ACCEPT):debug). This causes the packet to be logged at the specified level.

If the ACTION names an action declared in shorewall-actions[4](5) or in /usr/share/shorewall/actions.std then:

•If the log level is followed by "!' then all rules in the action are logged at the log level.

•If the log level is not followed by "!" then only those rules in the action that do not specify logging are logged at the specified level.

•The special log level none! suppresses logging by the action.

You may also specify NFLOG (must be in upper case) as a log level.This will log to the NFLOG target for routing to a separate log through use of ulogd (shorewall-logging.htm[3]).

Actions specifying logging may be followed by a log tag (a string of alphanumeric characters) which is appended to the string generated by the LOGPREFIX (in shorewall.conf[1](5)).

For the remaining columns, see shorewall-rules (5)[2].

## EXAMPLES
IPv4 Example 1:

Drop 6to4 packets from the net.

```
DROP          net:192.88.99.1            all
```

IPv4 Example 2:

Don't subject packets from 70.90.191.120/29 to the remaining rules in the file.

```
WHITELIST     net:70.90.191.120/29       all
```

IPv6 Example 1:

Drop Teredo packets from the net.

```
DROP          net:[2001::/32]            all
```

IPv6 Example 2:

Don't subject packets from 2001:DB8::/64 to the remaining rules in the file.

```
WHITELIST     net:[2001:DB8::/64]        all
```

## FILES
/etc/shorewall/blrules

/etc/shorewall6/blrules

## SEE ALSO
https://shorewall.org/blacklisting_support.htm[5]

https://shorewall.org/configuration_file_basics.htm#Pairs[6]

shorewall(8)

## NOTES
1.

shorewall.conf

https://shorewall.org/manpages/shorewall.conf.html

2.

shorewall-rules (5)

https://shorewall.org/manpages/shorewall-rules.html

3.

shorewall-logging(5)

https://shorewall.org/manpages/shorewall-logging.html

4.

shorewall-actions

https://shorewall.org/manpages/shorewall-actions.html

5.

https://shorewall.org/blacklisting_support.htm

https://shorewall.org/blacklisting_support.htm

6.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-conntrack

title: shorewall-conntrack(5)

summary: shorewall conntrack file

text:
# shorewall-conntrack(5)

## NAME
conntrack - shorewall conntrack file

## SYNOPSIS
/etc/shorewall[6]/conntrack

## DESCRIPTION
The original intent of the notrack file was to exempt certain traffic from Netfilter connection tracking. Traffic matching entries in the file were not to be tracked.

The role of the file was expanded in Shorewall 4.4.27 to include all rules that can be added in the Netfilter raw table. In 4.5.7, the file's name was changed to conntrack.

The file supports three different column layouts: FORMAT 1, FORMAT 2, and FORMAT 3 with FORMAT 1 being the default. The three differ as follows:

•in FORMAT 2 and 3, there is an additional leading ACTION column.

•in FORMAT 3, the SOURCE column accepts no zone name; rather the ACTION column allows a SUFFIX that determines the chain(s) that the generated rule will be added to.

When an entry in the following form is encountered, the format of the following entries are assumed to be of the specified format.

?FORMAT

format

where format is either 1,2 or 3.

Format 3 was introduced in Shorewall 4.5.10.

Comments may be attached to Netfilter rules generated from entries in this file through the use of ?COMMENT lines. These lines begin with ?COMMENT; the remainder of the line is treated as a comment which is attached to subsequent rules until another ?COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line containing only ?COMMENT.

The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax).

ACTION - {NOTRACK|CT:helper:name[(arg=val[,...])|CT:ctevents:event[,...]|CT:expevents:new|CT:notrack|DROP|LOG|ULOG(ulog-parameters):NFLOG(nflog-parameters)|IP[6]TABLES(target)}[log-level[:log-tag]][:chain-designator]

This column is only present when FORMAT >= 2. Values other than NOTRACK or DROP require CT Targetsupport in your iptables and kernel.

•NOTRACK or CT:notrack Disables connection tracking for this packet. If a log-level is specified, the packet will also be logged at that level.

•CT:helper:name Attach the helper identified by the name to this connection. This is more flexible than loading the conntrack helper with preset ports. If a log-level is specified, the packet will also be logged at that level. Beginning with Shorewall 4.6.10, the helper name is optional

At this writing, the available helpers are:

amanda

Requires that the amanda netfilter helper is present.

ftp

Requires that the FTP netfilter helper is present.

irc

Requires that the IRC netfilter helper is present.

netbios-ns

Requires that the netbios_ns (sic) helper is present.

RAS and Q.931

These require that the H323 netfilter helper is present.

pptp

Requires that the pptp netfilter helper is present.

sane

Requires that the SANE netfilter helper is present.

sip

Requires that the SIP netfilter helper is present.

snmp

Requires that the SNMP netfilter helper is present.

tftp

Requires that the TFTP netfilter helper is present.

May be followed by an option list of arg=val pairs in parentheses:

•ctevents=event[,...] Only generate the specified conntrack events for this connection. Possible event types are: new, related, destroy, reply, assured, protoinfo, helper, mark (this is connection mark, not packet mark), natseqinfo, and secmark. If more than one event is listed, the event list must be enclosed in parentheses (e.g., ctevents=(new,related)).

•expevents=new Only generate a new expectation events for this connection.

•ctevents:event[,...] Added in Shorewall 4.6.10. Only generate the specified conntrack events for this connection. Possible event types are: new, related, destroy, reply, assured, protoinfo, helper, mark (this is connection mark, not packet mark), natseqinfo, and secmark.

•expevents=new Added in Shorewall 4.6.10. Only generate new expectation events for this connection.

•DROP Added in Shorewall 4.5.10. Silently discard the packet. If a log-level is specified, the packet will also be logged at that level.

•IP6TABLES(target) IPv6 only.

Added in Shorewall 4.6.0. Allows you to specify any iptables target with target options (e.g., "IP6TABLES(AUDIT --type drop)"). If the target is not one recognized by Shorewall, the following error message will be issued:

ERROR: Unknown target

(target)

This error message may be eliminated by adding target as a builtin action in shorewall-actions[1](5).

•IPTABLES(target) IPv4 only.

Added in Shorewall 4.6.0. Allows you to specify any iptables target with target options (e.g., "IPTABLES(AUDIT --type drop)"). If the target is not one recognized by Shorewall, the following error message will be issued:

ERROR: Unknown target

(target)

This error message may be eliminated by adding target as a builtin action in shorewall-actions[1](5).

•LOG Added in Shoreawll 4.6.0. Logs the packet using the specified log-level and log-tag (if any). If no log-level is specified, then 'info' is assumed.

•NFLOG Added in Shoreawll 4.6.0. Queues the packet to a backend logging daemon using the NFLOG netfilter target with the specified nflog-parameters.

•ULOG IPv4 only. Added in Shoreawll 4.6.0. Queues the packet to a backend logging daemon using the ULOG netfilter target with the specified ulog-parameters.

When FORMAT = 1, this column is not present and the rule is processed as if NOTRACK had been entered in this column.

Beginning with Shorewall 4.5.10, when FORMAT = 3, this column can end with a colon followed by a chain-designator. The chain-designator can be one of the following:

P

The rule is added to the raw table PREROUTING chain. This is the default if no chain-designator is present.

O

The rule is added to the raw table OUTPUT chain.

PO or OP

The rule is added to the raw table PREROUTING and OUTPUT chains.

SOURCE (formats 1 and 2) – {zone[:interface][:address-list]}

where zone is the name of a zone, interface is an interface to that zone, and address-list is a comma-separated list of addresses (may contain exclusion - see shorewall-exclusion[2] (5)). Beginning with Shorewall 4.5.7, all can be used as the zone name to mean all zones.

Beginning with Shorewall 4.5.10, all- can be used as the zone name to mean all off-firewall zones.

SOURCE (format 3 prior to Shorewall 5.1.0) – {-|interface[:address-list]|address-list}

Where interface is an interface to that zone, and address-list is a comma-separated list of addresses (may contain exclusion - see shorewall-exclusion[2] (5)).

SOURCE (format 3 on Shorewall 5.1.0 and later) - {-|[source-spec[,...]]}

where source-spec is one of the following: interface

Where interface is the logical name of an interface defined in shorewall-interface[3](5).

address[,...][exclusion]

where address may be:

•A host or network IP address.

•A MAC address in Shorewall format (preceded by a tilde ("~") and using dash ("-") as a separator.

•The name of an ipset preceded by a plus sign ("+"). See shorewall-ipsets[4](5).

exclusion is described in shorewall-exclusion[2](5).

interface:address[,...][exclusion]

This form combines the preceding two and requires that both the incoming interface and source address match.

exclusion

See shorewall-exclusion[2] (5)

Beginning with Shorewall 5.1.0, multiple source-specs separated by commas may be specified provided that the following alternative forms are used: (address[,...][exclusion])

interface:(address[,...][exclusion])

(exclusion)

DEST (Prior to Shorewall 5.1.0) – {-|interface[:address-list]|address-list}

where address-list is a comma-separated list of addresses (may contain exclusion - see shorewall-exclusion[2] (5)).

DEST (Shorewall 5.1.0 and later) - {-|dest-spec[,...]}

where dest-spec is one of the following: interface

Where interface is the logical name of an interface defined in shorewall-interface[3](5).

address[,...][exclusion]

where address may be:

•A host or network IP address.

•A MAC address in Shorewall format (preceded by a tilde ("~") and using dash ("-") as a separator.

•The name of an ipset preceded by a plus sign ("+"). See shorewall-ipsets[4](5).

exclusion is described in shorewall-exclusion[2](5).

interface:address[,...][exclusion]

This form combines the preceding two and requires that both the outgoing interface and destination address match.

exclusion

See shorewall-exclusion[2] (5)

Beginning with Shorewall 5.1.0, multiple source-specs separated by commas may be specified provided that the following alternative forms are used: (address[,...][exclusion])

interface:(address[,...][exclusion])

(exclusion)

PROTO – protocol-name-or-number[,...]

A protocol name from /etc/protocols or a protocol number. tcp and 6 may be optionally followed by :syn to match only the SYN packet (first packet in the three-way handshake). Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols and either proto or protos is accepted in the alternate input format.

Beginning with Shorewall 5.1.11, when tcp or 6 is specified and the ACTION is CT, the compiler will default to :syn. If you wish the rule to match packets with any valid combination of TCP flags, you may specify tcp:all or 6:all.

DPORT - port-number/service-name-list

A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. This column was formerly labelled DEST PORT(S).

SPORT - port-number/service-name-list

A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DPORT column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DPORT. Use of '=' requires multi-port match in your iptables and kernel.

This column was formerly labelled SOURCE PORT(S).

USER – [user][:group]

This column was formerly named USER/GROUP and may only be specified if the SOURCE zone is $FW. Specifies the effective user id and or group id of the process sending the traffic.

SWITCH - [!]switch-name[={0|1}]

Added in Shorewall 4.5.10 and allows enabling and disabling the rule without requiring shorewall restart. The rule is enabled if the value stored in /proc/net/nf_condition/switch-name is 1. The rule is disabled if that file contains 0 (the default). If '!' is supplied, the test is inverted such that the rule is enabled if the file contains 0.

Within the switch-name, '@0' and '@{0}' are replaced by the name of the chain to which the rule is a added. The switch-name (after '...' expansion) must begin with a letter and be composed of letters, decimal digits, underscores or hyphens. Switch names must be 30 characters or less in length.

Switches are normally off. To turn a switch on:

echo 1 >

/proc/net/nf_condition/switch-name

To turn it off again: echo 0 >

/proc/net/nf_condition/switch-name

Switch settings are retained over shorewall restart. When the switch-name is followed by =0 or =1, then the switch is initialized to off or on respectively by the start command. Other commands do not affect the switch setting.

## EXAMPLE
IPv4 Example 1:

```
#ACTION                       SOURCE            DEST               PROTO            DPORT             SPORT               USER
CT:helper:ftp(expevents=new)  fw                -                  tcp              21
```

IPv4 Example 2 (Shorewall 4.5.10 or later):

Drop traffic to/from all zones to IP address 1.2.3.4

```
?FORMAT 2
#ACTION                       SOURCE             DEST               PROTO           DPORT             SPORT               USER
DROP                          all-:1.2.3.4       -
DROP                          all                1.2.3.4
```

or

```
?FORMAT 3
#ACTION                       SOURCE             DEST               PROTO           DPORT             SPORT               USER
DROP:P                        1.2.3.4            -
DROP:PO                       -                  1.2.3.4
```

IPv6 Example 1:

Use the FTP helper for TCP port 21 connections from the firewall itself.

```
FORMAT 2
#ACTION                       SOURCE            DEST               PROTO            DPORT             SPORT               USER
CT:helper:ftp(expevents=new)  fw                -                  tcp              21
```

IPv6 Example 2 (Shorewall 4.5.10 or later):

Drop traffic to/from all zones to IP address 2001:1.2.3::4

```
FORMAT 2
#ACTION                       SOURCE             DEST               PROTO            DPORT             SPORT               USER
DROP                          all-:2001:1.2.3::4 -
DROP                          all                2001:1.2.3::4
```

or

```
FORMAT 3
#ACTION                       SOURCE             DEST               PROTO            DPORT             SPORT               USER
DROP:P                        2001:1.2.3::4      -
DROP:PO                       -                  2001:1.2.3::4
```

## FILES
/etc/shorewall/conntrack

/etc/shorewall6/conntrack

## SEE ALSO
https://shorewall.org/configuration_file_basics.htm#Pairs[5]

shorewall(8)

## NOTES
1.

shorewall-actions

https://shorewall.org/manpages/shorewall-actions.html

2.

shorewall-exclusion

https://shorewall.org/manpages/shorewall-exclusion.html

3.

shorewall-interface

https://shorewall.org/manpages/shorewall-interfaces.html

4.

shorewall-ipsets

https://shorewall.org/manpages/shorewall-ipsets.html

5.

https://shorewall.org/configuration_file_basics.htm#Pairs

https://shorewall.org/configuration_file_basics.htm#Pairs


shorewall-ecn

title: shorewall-ecn(5)

summary: Shorewall ECN file

text:
# shorewall-ecn(5)

## NAME
ecn - Shorewall ECN file

## SYNOPSIS
/etc/shorewall/ecn

## DESCRIPTION
IPv4 only.

Use this file to list the destinations for which you want to disable ECN (Explicit Congestion Notification). Use of this file is deprecated in favor of ECN rules in shorewall-mangle[1](8).

The columns in the file are as follows.

INTERFACE - interface

Interface through which host(s) communicate with the firewall

HOST(S) (Optional) - [-|address-or-address-range[,address-or-address-range]...]

Comma-separated list of host and/or network addresses. If left empty or supplied as "-", 0.0.0.0/0 is assumed. If your kernel and iptables include iprange match support then IP address ranges are also permitted.

## FILES
/etc/shorewall/ecn

## SEE ALSO
shorewall(8)

## NOTES
1.

shorewall-mangle

https://shorewall.org/manpages/shorewall-mangle.html


shorewall-exclusion

title: shorewall-exclusion(5)

text:
# shorewall-exclusion(5)

## NAME
exclusion - Exclude a set of hosts from a definition in a shorewall configuration file.

## SYNOPSIS
!address-or-range[,address-or-range]...

!zone-name[,zone-name]...

## DESCRIPTION
The first form of exclusion is used when you wish to exclude one or more addresses from a definition. An exclamation point is followed by a comma-separated list of addresses. The addresses may be single host addresses (e.g., 192.168.1.4) or they may be network addresses in CIDR format (e.g., 192.168.1.0/24). If your kernel and iptables include iprange support, you may also specify ranges of ip addresses of the form lowaddress-highaddress

No embedded white-space is allowed.

Exclusion can appear after a list of addresses and/or address ranges. In that case, the final list of address is formed by taking the first list and then removing the addresses defined in the exclusion.

Beginning in Shorewall 4.4.13, the second form of exclusion is allowed after all and any in the SOURCE and DEST columns of shorewall-rules[1](5). It allows you to omit arbitrary zones from the list generated by those key words.

Warning

If you omit a sub-zone and there is an explicit or explicit CONTINUE policy, a connection to/from that zone can still be matched by the rule generated for a parent zone.

For example:

/etc/shorewall/zones:

```
#ZONE          TYPE
z1             ip
z2:z1          ip
...
```

/etc/shorewall/policy:

```
#SOURCE         DEST          POLICY
z1              net           CONTINUE
z2              net           REJECT
```

/etc/shorewall/rules:

```
#ACTION         SOURCE        DEST        PROTO         DPORT
ACCEPT          all!z2        net         tcp           22
```

In this case, SSH connections from z2 to net will be accepted by the generated z1 to net ACCEPT rule.

In most contexts, ipset names can be used as an address-or-range. Beginning with Shorewall 4.4.14, ipset lists enclosed in +[...] may also be included (see shorewall-ipsets[2] (5)). The semantics of these lists when used in an exclusion are as follows:

•!+[set1,set2,...setN] produces a packet match if the packet does not match at least one of the sets. In other words, it is like NOT match set1 OR NOT match set2 ... OR NOT match setN.

•+[!set1,!set2,...!setN] produces a packet match if the packet does not match any of the sets. In other words, it is like NOT match set1 AND NOT match set2 ... AND NOT match setN.

## EXAMPLES
IPv4 Example 1 - All IPv4 addresses except 192.168.3.4

!192.168.3.4

IPv4 Example 2 - All IPv4 addresses except the network 192.168.1.0/24 and the host 10.2.3.4

!192.168.1.0/24,10.1.3.4

IPv4 Example 3 - All IPv4 addresses except the range 192.168.1.3-192.168.1.12 and the network 10.0.0.0/8

!192.168.1.3-192.168.1.12,10.0.0.0/8

IPv4 Example 4 - The network 192.168.1.0/24 except hosts 192.168.1.3 and 192.168.1.9

192.168.1.0/24!192.168.1.3,192.168.1.9

Example 5 - All parent zones except loc

any!loc

## FILES
/etc/shorewall/hosts

/etc/shorewall/masq

/etc/shorewall/rules

/etc/shorewall/tcrules

## SEE ALSO
shorewall(8)

## NOTES
1.

shorewall-rules

https://shorewall.org/manpages/shorewall-rules.html

2.

shorewall-ipsets

https://shorewall.org/manpages/shorewall-ipsets.html


shorewall-files

title: shorewall-files(5)

summary: Shorewall Configuration Files

text:
# shorewall-files(5)

## NAME
files - Shorewall Configuration Files

## SYNOPSIS
/etc/shorewall[6]/*

## DESCRIPTION
The following are the Shorewall[6] configuration files:

•/etc/shorewall/shorewall.conf and /etc/shorewall6/shorewall6.conf[1] - used to set global firewall parameters.

•/etc/shorewall[6]/params[2] - use this file to set shell variables that you will expand in other files. It is always processed by /bin/sh or by the shell specified through SHOREWALL_SHELL in /etc/shorewall/shorewall.conf.

•/etc/shorewall[6]/zones[3] - partition the firewall's view of the world into zones.

•/etc/shorewall[6]/policy[4] - establishes firewall high-level policy.

•/etc/shorewall[6]/initdone - An optional Perl script that will be invoked by the Shorewall rules compiler when the compiler has finished it's initialization.

•/etc/shorewall[6]/interfaces[5] - describes the interfaces on the firewall system.

•/etc/shorewall[6]/hosts[6] - allows defining zones in terms of individual hosts and subnetworks.

•/etc/shorewall[6]/masq[7] - directs the firewall where to use many-to-one (dynamic) Network Address Translation (a.k.a. Masquerading) and Source Network Address Translation (SNAT). Superseded by /etc/shorewall[6]/snat in Shorewall 5.0.14 and not supported in Shorewall 5.1.0 and later versions.

•/etc/shorewall[6]/mangle[8] - supersedes /etc/shorewall/tcrules in Shorewall 4.6.0. Contains rules for packet marking, TTL, TPROXY, etc.

•/etc/shorewall[6]/rules[9] - defines rules that are exceptions to the overall policies established in /etc/shorewall/policy.

•/etc/shorewall[6]/nat[10] - defines one-to-one NAT rules.

•/etc/shorewall6/proxyarp[11] - defines use of Proxy ARP.

•/etc/shorewall6/proxyndp[12] - defines use of Proxy NDP.

•/etc/shorewall[6]/routestopped - defines hosts accessible when Shorewall is stopped. Superseded in Shorewall 4.6.8 by /etc/shorewall/stoppedrules. Not supported in Shorewall 5.0.0 and later versions.

•/etc/shorewall[6]/tcrules[13]- The file has a rather unfortunate name because it is used to define marking of packets for later use by both traffic control/shaping and policy routing. This file is superseded by /etc/shorewall/mangle in Shorewall 4.6.0. Not supported in Shorewall 5.0.0 and later releases.

•/etc/shorewall[6]/tos[14] - defines rules for setting the TOS field in packet headers. Superseded in Shorewall 4.5.1 by the TOS target in /etc/shorewall/tcrules (which file has since been superseded by /etc/shorewall/mangle). Not supported in Shorewall 5.0.0 and later versions.

•/etc/shorewall[6]/tunnels[15] - defines tunnels (VPN) with end-points on the firewall system.

•/etc/shorewall[6]/blacklist[16] - Deprecated in favor of /etc/shorewall/blrules. Lists blacklisted IP/subnet/MAC addresses. Not supported in Shorewall 5.0.0 and later releases.

•/etc/shorewall[6]/blrules — Added in Shorewall 4.5.0. Define blacklisting and whitelisting. Supersedes /etc/shorewall/blacklist.

•/etc/shorewall[6]/init - shell commands that you wish to execute at the beginning of a “shorewall start”, "shorewall reload" or “shorewall restart”.

•/etc/shorewall[6]/start - shell commands that you wish to execute near the completion of a “shorewall start”, "shorewall reload" or “shorewall restart”

•/etc/shorewall[6]/started - shell commands that you wish to execute after the completion of a “shorewall start”, "shorewall reload" or “shorewall restart”

•/etc/shorewall[6]/stop- commands that you wish to execute at the beginning of a “shorewall stop”.

•/etc/shorewall[6]/stopped - shell commands that you wish to execute at the completion of a “shorewall stop”.

•/etc/shorewall/ecn[17] - disable Explicit Congestion Notification (ECN - RFC 3168) to remote hosts or networks. Superseded by ECN entries in /etc/shorewall/mangle in Shorewall 5.0.6.

•/etc/shorewall/accounting[18] - define IP traffic accounting rules

•/etc/shorewall[6]/actions[19] and /usr/share/shorewall[6]/action.template allow user-defined actions.

•/etc/shorewall[6]/providers[20] - defines alternate routing tables.

•/etc/shorewall[6]/rtrules[21] - Defines routing rules to be used in conjunction with the routing tables defined in /etc/shorewall/providers.

•/etc/shorewall[6]/tcdevices[22], /etc/shorewall[6]/tcclasses[23], /etc/shorewall[6]/tcfilters[24] - Define complex traffic shaping.

•/etc/shorewall[6]/tcrules[13] - Mark or classify traffic for traffic shaping or multiple providers. Deprecated in Shorewall 4.6.0 in favor of /etc/shorewall/mangle. Not supported in Shorewall 5.0.0 and later releases.

•/etc/shorewall[6]/tcinterfaces[25] and /etc/shorewall[6]/tcpri[26] - Define simple traffic shaping.

•/etc/shorewall[6]/secmarks[27] - Added in Shorewall 4.4.13. Attach an SELinux context to selected packets.

•/etc/shorewall[6]/vardir[28] - Determines the directory where Shorewall maintains its state.

•/etc/shorewall/arprules[29] — Added in Shorewall 4.5.12. Allows specification of arptables rules.

•/etc/shorewall/mangle[8] -- Added in Shorewall 4.6.0. Supersedes/etc/shorewall/tcrules.

•/etc/shorewall[6]/snat[30] - directs the firewall where to use many-to-one (dynamic) Network Address Translation (a.k.a. Masquerading) and Source Network Address Translation (SNAT). Superseded /etc/shorewall[6]/masq in Shorewall 5.0.14

•/usr/share/shorewall[6]/actions.std - Actions defined by Shorewall.

•/usr/share/shorewall[6]/action.* - Details of actions defined by Shorewall.

•/usr/share/shorewall[6]/macro.* - Details of macros defined by Shorewall.

•/usr/share/shorewall[6]/modules — Specifies the kernel modules to be loaded during shorewall start/restart.

•/usr/share/shorewall[6]/helpers — Added in Shorewall 4.4.7. Specifies the kernel modules to be loaded during shorewall start/restart when LOAD_HELPERS_ONLY=Yes in shorewall.conf.

## CONFIG_PATH
The CONFIG_PATH option in shorewall[6].conf(5)[20] determines where the compiler searches for configuration files. The default setting is CONFIG_PATH=/etc/shorewall:/usr/share/shorewall which means that the compiler first looks in /etc/shorewall and if it doesn't find the file, it then looks in /usr/share/shorewall.

You can change this setting to have the compiler look in different places. For example, if you want to put your own versions of standard macros in /etc/shorewall/Macros, then you could set CONFIG_PATH=/etc/shorewall:/etc/shorewall/Macros:/usr/share/shorewall and the compiler will use your versions rather than the standard ones.

## COMMENTS
You may place comments in configuration files by making the first non-whitespace character a pound sign (“#”). You may also place comments at the end of any line, again by delimiting the comment from the rest of the line with a pound sign.

Example 1. Comments in a Configuration File

```
# This is a comment
ACCEPT  net     $FW      tcp     www     #This is an end-of-line comment
```

Important

Except in shorewall.conf(5)[1] and params(5)[2], if a comment ends with a backslash ("\"), the next line will also be treated as a comment. See Line Continuation below.

## BLANK LINES
Most of the configuration files are organized into space-separated columns. If you don't want to supply a value in a column but want to supply a value in a following column, simply enter '-' to make the column appear empty.

Example:

```
#INTERFACE         BROADCAST            OPTIONS
br0                -                    routeback
```

## LINE CONTINUATION
Lines may be continued using the usual backslash (“\”) followed immediately by a new line character (Enter key).

```
ACCEPT  net     $FW      tcp \↵
smtp,www,pop3,imap  #Services running on the firewall
```

Important

What follows does NOT apply to shorewall-params(5)[31] and shorewall.conf(5)[1].

In certain cases, leading white space is ignored in continuation lines:

1.The continued line ends with a colon (":")

2.The continued line ends with a comma (",")

Example (/etc/shorewall/rules):

```
#ACTION     SOURCE          DEST            PROTO           DPORT
ACCEPT      net:\

            206.124.146.177,\

            206.124.146.178,\

            206.124.146.180\

                            dmz             tcp             873
```

The leading white space on the first through third continuation lines is ignored so the SOURCE column effectively contains "net:206.124.146.177,206.124.147.178,206.124.146.180". Because the third continuation line does not end with a comma or colon, the leading white space in the last line is not ignored.

Important

A trailing backslash is not ignored in a comment. So the continued rule above can be commented out with a single '#' as follows:

```
#ACTION     SOURCE          DEST            PROTO           DPORT
#ACCEPT     net:\

            206.124.146.177,\

            206.124.146.178,\

            206.124.146.180\

                            dmz             tcp             873
```

## ALTERNATIVE SPECIFICATION OF COLUMN VALUES
Some of the configuration files now have a large number of columns. That makes it awkward to specify a value for one of the right-most columns as you must have the correct number of intervening '-' columns.

This problem is addressed by allowing column values to be specified as column-name/value pairs.

There is considerable flexibility in how you specify the pairs:

•At any point, you can enter a left curly bracket ('{') followed by one or more specifications of the following forms: column-name=value

column-name=>value

column-name:value

The pairs must be followed by a right curly bracket ("}"). The value may optionally be enclosed in double quotes.

The pairs must be separated by white space, but you can add a comma adjacent to the values for readability as in:

{ proto=>udp, port=1024

}

•You can also separate the pairs from columns by using a semicolon: ; proto:udp,

port:1024

In Shorewall 5.0.3, the sample configuration files and the man pages were updated to use the same column names in both the column headings and in the alternate specification format. The following table shows the column names for each of the table-oriented configuration files.

Note

Column names are case-insensitive.

File

Column names

accounting

action,chain, source, dest, proto, dport, sport, user, mark, ipsec, headers

conntrack

action,source,dest,proto,dport,sport,user,switch

blacklist

networks,proto,port,options

blrules

action,source,dest,proto,dport,sport,origdest,rate,user,mark,connlimit,time,headers,switch,helper

ecn

interface,hosts. Beginning with Shorewall 4.5.4, 'host' is a synonym for 'hosts'.

hosts

zone,hosts,options. Beginning with Shorewall 4.5.4, 'host' is a synonym for 'hosts'.

interfaces

zone,interface,broadcast,options

maclist

disposition,interface,mac,addresses

mangle

action,source,dest,proto,dport,sport,user,test,length,tos,connbytes,helper,headers

masq

interface,source,address,proto,port,ipsec,mark,user,switch

nat

external,interface,internal,allints,local

netmap

type,net1,interface,net2,net3,proto,dport,sport

notrack

source,dest,proto,dport,sport,user

policy

source,dest,policy,loglevel,limit,connlimit

providers

table,number,mark,duplicate,interface,gateway,options,copy

proxyarp and proxyndp

address,interface,external,haveroute,persistent

rtrules

source,dest,provider,priority

routes

provider,dest,gateway,device

routestopped

interface,hosts,options,proto,dport,sport

rules

action,source,dest,proto,dport,sport,origdest,rate,user,mark,connlimit,time,headers,switch,helper

secmarks

secmark,chain,source,dest,proto,dport,sport,user,mark

tcclasses

interface,mark,rate,ceil,prio,options

tcdevices

interface,in_bandwidth,out_bandwidth,options,redirect

tcfilters

class,source,dest,proto,dport,sport,tos,length

tcinterfaces

interface,type,in_bandwidth,out_bandwidth

tcpri

band,proto,port,address,interface,helper

tcrules

mark,source,dest,proto,dport,sport,user,test,length,tos,connbytes,helper,headers. Beginning with Shorewall 4.5.3, 'action' is a synonym for 'mark'.

tos

source,dest,proto,dport,sport,tos,mark

tunnels

type,zone,gateway,gateway_zone. Beginning with Shorewall 4.5.3, 'gateways' is a synonym for 'gateway'. Beginning with Shorewall 4.5.4, 'gateway_zones' is a synonym for 'gateway_zone'.

zones

zone,type,options,in_options,out_options

Example (rules file):

```
#ACTION         SOURCE            DEST            PROTO   DPORT
DNAT            net               loc:10.0.0.1    tcp     80    ; mark="88"
```

Here's the same line in several equivalent formats:

```
{ action=>DNAT, source=>net, dest=>loc:10.0.0.1, proto=>tcp, dport=>80, mark=>88 }
; action:"DNAT" source:"net"  dest:"loc:10.0.0.1" proto:"tcp" dport:"80" mark:"88"
DNAT { source=net dest=loc:10.0.0.1 proto=tcp dport=80 mark=88 }
```

Beginning with Shorewall 5.0.11, ip[6]table comments can be attached to individual rules using the comment keyword.

Example from the rules file:

```
        ACCEPT net $FW { proto=tcp, dport=22, comment="Accept \"SSH\"" }
```

As shown in that example, when the comment contains whitespace, it must be enclosed in double quotes and any embedded double quotes must be escaped using a backslash ("\").

## TIME COLUMNS
Several of the files include a TIME column that allows you to specify times when the rule is to be applied. Contents of this column is a list of timeelements separated by apersands (&).

Each timeelement is one of the following:

timestart=hh:mm[:ss]

Defines the starting time of day.

timestop=hh:mm[:ss]

Defines the ending time of day.

contiguous

Added in Shoreawll 5.0.12. When timestop is smaller than timestart value, match this as a single time period instead of distinct intervals. See the Examples below.

utc

Times are expressed in Greenwich Mean Time.

localtz

Deprecated by the Netfilter team in favor of kerneltz. Times are expressed in Local Civil Time (default).

kerneltz

Added in Shorewall 4.5.2. Times are expressed in Local Kernel Time (requires iptables 1.4.12 or later).

weekdays=ddd[,ddd]...

where ddd is one of Mon, Tue, Wed, Thu, Fri, Sat or Sun

monthdays=dd[,dd],...

where dd is an ordinal day of the month

datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]

Defines the starting date and time.

datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]

Defines the ending date and time.

Examples:

To match on weekends, use:

weekdays=Sat,Sun

Or, to match (once) on a national holiday block:

datestart=2016-12-24&datestop=2016-12-27

Since the stop time is actually inclusive, you would need the following stop time to not match the first second of the new day:

datestart=2016-12-24T17:00&datestop=2016-12-27T23:59:59

During Lunch Hour

The fourth Friday in the month:

weekdays=Fri&monthdays=22,23,24,25,26,27,28

Matching across days might not do what is expected. For instance,

weekdays=Mon&timestart=23:00&timestop=01:00

Will match Monday, for one hour from midnight to 1 a.m., and then again for another hour from 23:00 onwards. If this is unwanted, e.g. if you would like 'match for two hours from Montay 23:00 onwards' you need to also specify the contiguous option in the example above.

## SWITCHES
here are times when you would like to enable or disable one or more rules in the configuration without having to do a shorewall reload or shorewall restart. This may be accomplished using the SWITCH column in shorewall-rules[32] (5) or shorewall6-rules[32] (5). Using this column requires that your kernel and iptables include Condition Match Support and you must be running Shorewall 4.4.24 or later. See the output of shorewall show capabilities and shorewall version to determine if you can use this feature.

The SWITCH column contains the name of a switch. Each switch is initially in the off position. You can turn on the switch named switch1 by:

echo 1 >

/proc/net/nf_condition/switch1

You can turn it off again by:

echo 0 >

/proc/net/nf_condition/switch1

If you simply include the switch name in the SWITCH column, then the rule is enabled only when the switch is on. If you precede the switch name with ! (e.g., !switch1), then the rule is enabled only when the switch is off. Switch settings are retained over shorewall reload.

Shorewall requires that switch names:

•begin with a letter and be composed of letters, digits, underscore ('_') or hyphen ('-'); and

•be 30 characters or less in length.

Multiple rules can be controlled by the same switch.

Example:

Forward port 80 to dmz host $BACKUP if switch 'primary_down' is on.

```
#ACTION     SOURCE          DEST        PROTO       DPORT        SPORT     ORIGDEST   RATE      USER      MARK    CONNLIMIT     TIME     HEADERS    SWITCH
DNAT        net             dmz:$BACKUP tcp         80           -         -          -         -         -       -             -        -          primary_down
```

## FILES
/etc/shorewall[6]/*

## NOTES
1.

/etc/shorewall/shorewall.conf

and /etc/shorewall6/shorewall6.conf

https://shorewall.org/manpages/shorewall.conf.html

2.

/etc/shorewall[6]/params

https://shorewall.org/manpages/shorewall-params.html

3.

/etc/shorewall[6]/zones

https://shorewall.org/manpages/shorewall-zones.html

4.

/etc/shorewall[6]/policy

https://shorewall.org/manpages/shorewall-policy.html

5.

/etc/shorewall[6]/interfaces

https://shorewall.org/manpages/shorewall-interfaces.html

6.

/etc/shorewall[6]/hosts

https://shorewall.org/manpages/shorewall-hosts.html

7.

/etc/shorewall[6]/masq

https://shorewall.org/manpages/shorewall-masq.html

8.

/etc/shorewall[6]/mangle

https://shorewall.org/manpages/shorewall-mangle.html

9.

/etc/shorewall[6]/rules

https://shorewall.org/manpages/shorewall-rules.html

10.

/etc/shorewall[6]/nat

https://shorewall.org/manpages/shorewall-nat.html

11.

/etc/shorewall6/proxyarp

https://shorewall.org/manpages/shorewall-proxyarp.html

12.

/etc/shorewall6/proxyndp

https://shorewall.org/manpages/shorewall-proxyndp.html

13.

/etc/shorewall[6]/tcrules

https://shorewall.org/manpages/shorewall-tcrules.html

14.

/etc/shorewall[6]/tos

https://shorewall.org/manpages/shorewall-tos.html

15.

/etc/shorewall[6]/tunnels

https://shorewall.org/manpages/shorewall-tunnels.html

16.

/etc/shorewall[6]/blacklist

https://shorewall.org/manpages/shorewall-blacklist.html

17.

/etc/shorewall/ecn

https://shorewall.org/manpages/shorewall-ecn.html

18.

/etc/shorewall/accounting

https://shorewall.org/manpages/shorewall-accounting.html

19.

/etc/shorewall[6]/actions

https://shorewall.org/manpages/shorewall-actions.html

20.

/etc/shorewall[6]/providers

https://shorewall.org/manpages/???

21.

/etc/shorewall[6]/rtrules

https://shorewall.org/manpages/shorewall-rtrules.html

22.

/etc/shorewall[6]/tcdevices

https://shorewall.org/manpages/shorewall-tcdevices.html

23.

/etc/shorewall[6]/tcclasses

https://shorewall.org/manpages/shorewall-tcclasses.html

24.

/etc/shorewall[6]/tcfilters

https://shorewall.org/manpages/shorewall-tcfilters.html

25.

/etc/shorewall[6]/tcinterfaces

https://shorewall.org/manpages/shorewall-tcinterfaces.html

26.

/etc/shorewall[6]/tcpri

https://shorewall.org/manpages/shorewall-tcpri.html

27.

/etc/shorewall[6]/secmarks

https://shorewall.org/manpages/shorewall-secmarks.html

28.

/etc/shorewall[6]/vardir

https://shorewall.org/manpages/shorewall-vardir.html

29.

/etc/shorewall/arprules

https://shorewall.org/manpages/shorewall-arprules.html

30.

/etc/shorewall[6]/snat

https://shorewall.org/manpages/shorewall-snat.html

31.

shorewall-params(5)

https://shorewall.org/manpages/shorewall-params.html

32.

shorewall-rules

https://shorewall.org/manpages/shorewall-rules.html