Change tcpsyn to tcp:syn

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3483 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2006-02-13 17:57:42 +00:00
parent 7b629ea428
commit fd082e81c9
6 changed files with 79 additions and 76 deletions

View File

@ -113,8 +113,13 @@
# that you cannot specify an ipset name in both the
# SOURCE and DEST columns.
#
# PROTO Protocol - Must be "tcp", "udp", "icmp", a number, or
# "all".
# PROTO Protocol - Must be "tcp", "tcp:syn", "udp", "icmp",
# "ipp2p", "ipp2p:udp", "ipp2p:all" a number, or "all".
# "ipp2p*" requires ipp2p match support in your kernel
# and iptables.
#
# "tcp:syn" implies "tcp" plus the SYN flag must be
# set and the RST,ACK and FIN flags must be reset.
#
# DEST PORT(S) Destination Ports. A comma-separated list of Port
# names (from /etc/services), port numbers or port

View File

@ -67,3 +67,8 @@ Changes in 3.1.x.
30) Correct typo in help file ("help drop").
31) Added 'tcpsyn'
-------------------------------------------------------------------------------
3.1.7
32) Change 'tcpsyn' to 'tcp:syn'

View File

@ -3756,7 +3756,7 @@ add_an_action()
tcp|TCP|6)
do_ports
;;
tcpsyn)
tcp:syn)
proto="$proto --syn"
do_ports
;;
@ -5175,7 +5175,7 @@ process_rule() # $1 = target
tcp|TCP|6)
do_ports
;;
tcpsyn)
tcp:syn)
proto="tcp --syn"
do_ports
;;

View File

@ -214,11 +214,14 @@
# contain the port number on the firewall that the
# request should be redirected to.
#
# PROTO Protocol - Must be "tcp", "udp", "icmp", "ipp2p",
# "ipp2p-udp", "ipp2p-all" a number, or "all".
# PROTO Protocol - Must be "tcp", "tcp:syn", "udp", "icmp",
# "ipp2p", "ipp2p:udp", "ipp2p:all" a number, or "all".
# "ipp2p*" requires ipp2p match support in your kernel
# and iptables.
#
# "tcp:syn" implies "tcp" plus the SYN flag must be
# set and the RST,ACK and FIN flags must be reset.
#
# DEST PORT(S) Destination Ports. A comma-separated list of Port
# names (from /etc/services), port numbers or port
# ranges; if the protocol is "icmp", this column is

View File

@ -1,4 +1,4 @@
Shorewall 3.1.6
Shorewall 3.1.7
Note to users upgrading from Shorewall 2.x or 3.0
@ -29,74 +29,12 @@ Note to users upgrading from Shorewall 2.x or 3.0
Problems Corrected in 3.1.6
1) Syntax errors reported in response to "shorewall help <command>" have
been eliminated.
None.
2) The 'allow', 'drop' and 'reject' commands no longer produce iptables
errors when executed while Shorewall is not started.
Other changes in 3.1.7
3) Shorewall now correctly handles devices in /etc/shorewall/tcdevices that
are actually bridge ports.
4) A typo in the output of "help drop" has been corrected.
Other changes in 3.1.6
1) In macro files, you can now use the reserved words SOURCE and DEST
in the columns of the same names. When Shorewall expands the
macro, it will substitute the SOURCE from the macro invocation for
SOURCE and the DEST from the invocation for DEST. This allows you
to write macros that act in both directions (from source to destination
and from destination to source).
Example:
macro.FOO:
PARAM SOURCE DEST udp 500
PARAM DEST SOURCE udp 500
/etc/shorewall/rules:
FOO/ACCEPT fw net
Resulting rules:
ACCEPT fw net udp 500
ACCEPT net fw udp 500
This new feature has been used to implement the SMBBI macro.
SMBBI is the same as the SMB macro with the exception that
it passes SMB traffic in both directions whereas SMB only
passes that traffic in one direction.
2) "shorewall check -e" is now supported and uses the
/etc/shorewall/capabilities file to determine the capabilities of
the target system.
3) When "shorewall check" or "shorewall compile" is run by a user other
than root, Shorewall now automatically uses the /etc/shorewall/capabilities
file to determine the capabilities of the target system.
4) Shorewall now includes a 'shorecap' program. The RPM installs the
program in the documentation directory. The install.sh script does
not install the program.
The shorecap program can be used to create an /etc/shorewall/capabilities
file on a remote system. The file can then be copied to the local
system where it can be used when compiling firewall programs targeted for
the remote system.
For instructions about running shorecap, see the comments at the top
of the program file (it's a simple shell script).
5) In the /etc/shorewall/rules file and in actions, you may now specify
'tcpsyn' in the PROTO column. 'tcpsyn' is equivalent to 'tcp' but also
requires that the SYN flag is set and the RST, FIN and ACK flags be
off ("--syn" is added to the iptables rule).
As part of this change, Shorewall no longer adds the "--syn" option
to TCP rules that specify QUEUE as their target.
1) 'tcpsyn' has been changed to 'tcp:syn' (tcpsyn was added in 3.1.6).
This new syntax is easier to extend in the future than was the old.
Migration Considerations:
@ -229,6 +167,22 @@ file>
- All scripts associated with a given chain such as Action
chains
c) If you run the "shorewall compile" or "shorewall check" commands under
a user other than 'root', then you must supply
/etc/shorewall/capabilities.
d) To aid in building /etc/shorewall/capabilities, a 'shorecap' program
is provided. The RPM installs the program in the documentation
directory. The install.sh script does not install the program.
The program can be run on the target system to produce a
capabilities file taylored for that system. The capabilities
file can then be copied to the local system where it can be used
when compiling firewall programs targeted for the remote system.
For instructions about running shorecap, see the comments at the
top of the program file (it's a simple shell script).
If you need to interject run-time code into the generated script then
you need to write it to file descriptor 3. Here is an example of creating
tap device tap0 and adding it to bridge xenbr0; the text will be indented
@ -376,3 +330,39 @@ file>
VERBOSITY=0 in shorewall.conf, then you will need to include -vvv in
commands that display log records in order to have MACs displayed.
4) In macro files, you can now use the reserved words SOURCE and DEST
in the columns of the same names. When Shorewall expands the
macro, it will substitute the SOURCE from the macro invocation for
SOURCE and the DEST from the invocation for DEST. This allows you
to write macros that act in both directions (from source to destination
and from destination to source).
Example:
macro.FOO:
PARAM SOURCE DEST udp 500
PARAM DEST SOURCE udp 500
/etc/shorewall/rules:
FOO/ACCEPT fw net
Resulting rules:
ACCEPT fw net udp 500
ACCEPT net fw udp 500
This new feature has been used to implement the SMBBI macro.
SMBBI is the same as the SMB macro with the exception that
it passes SMB traffic in both directions whereas SMB only
passes that traffic in one direction.
5) In the /etc/shorewall/rules file and in actions, you may now specify
'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to 'tcp' but also
requires that the SYN flag is set and the RST, FIN and ACK flags be
off ("--syn" is added to the iptables rule).
As part of this change, Shorewall no longer adds the "--syn" option
to TCP rules that specify QUEUE as their target.

View File

@ -265,13 +265,13 @@
# contain the port number on the firewall that the
# request should be redirected to.
#
# PROTO Protocol - Must be "tcp", "tcpsyn", "udp", "icmp",
# PROTO Protocol - Must be "tcp", "tcp:syn", "udp", "icmp",
# "ipp2p", "ipp2p:udp", "ipp2p:all" a number, or "all".
# "ipp2p*" requires ipp2p match support in your kernel
# and iptables.
#
"tcpsyn" implies "tcp" plus the SYN flag must be
set and the RST,ACK and FIN flags must be reset.
# "tcp:syn" implies "tcp" plus the SYN flag must be
# set and the RST,ACK and FIN flags must be reset.
#
# DEST PORT(S) Destination Ports. A comma-separated list of Port
# names (from /etc/services), port numbers or port