BarbWire Help
File
This target takes no special options first of all. When a
packet is perfectly matched and this target is set, it is
accepted and will not continue traversing the chain where
it was accepted in, nor any of the calling chains. Do note,
that packets that was accepted in one chain will still travel
through any subsequent chains within the other tables and
may be dropped there. There is nothing special about this
target whatsoever, and it does not require, or have the possibility,
to add options to the target.
The DROP target does just what it says, it drops packets
dead to the ground and refuses to process them anymore. A
packet that matches a rule perfectly and then has this action
taken on it will be blocked and no further processing will
be done. Note that this action may be a bit bad in certain
cases since it may leave dead sockets around on the server
and client. A better solution would be to use the REJECT target
in those cases, especially when you want to block certain
port scanners from getting to much information, such as filtered
ports and so on. Also note that if a packet has the DROP action
taken on them in a sub chain, the packet will not be processed
in any of the above chains in the structure, nor by any other
tables. The packet is in other words totally dead. The target
will not send any kind of information in either direction,
either to tell the client or the server as told previously.
The REJECT target works basically the same as the DROP target,
but it also sends back an error message to the host sending
the packet that was blocked. The REJECT target is as of today
only valid in the INPUT, FORWARD and OUTPUT chain or sub chains
of those chains, which would also be the only chains where
it would make any sense to put this target in. Note that the
chains that uses the REJECT target may only be called upon
by the INPUT, FORWARD, and OUTPUT chains, else they won’t
work. There currently is only one option which controls the
nature of how this target works, which in turn may take a
huge set of variables. Most of them are fairly easy to understand
if you have a basic knowledge of TCP/IP.
The LOG target is specially made to make it possible to log
snippets of information about packets that may be illegal,
or for pure bug hunting and error finding. The LOG target
will log specific information such as most of the IP headers
and other interesting information via the kernel logging facility.
This information may then be read with the view log window.
Note that it may be a really great idea to use the LOG target
instead of the DROP target while you are testing a rule you
are not 100% sure about on a production firewall since this
may otherwise cause severe connectivity problems for your
users. The LOG target needs a prefix, write what you wish
that can be self explanatory.
This option tells BarbWire to prefix all log messages with
a specific prefix which may then be very good to use together
with the log viewer. The prefix may be up to 29 letters long,
including white space and those kind of symbols.
-----------------------------------------------------------------------
inxxx
This match is used to match based on which interface the
packet came in on. Note that this option is only legal in
the INPUT, FORWARD and PREROUTING chains and will render an
error message when used anywhere else. The default behavior
of this match is to match all ethernet devices. We can also
invert the meaning of this option using the preceding NOT.
outxxx
The outxxx match is used to match packets depending on which
interface they are leaving on. Note that this match is only
available in the OUTPUT, FORWARD and POSTROUTING chains, in
opposite of the inxxx match. To inverse the meaning of the
match, you can use the preceding NOT. Of course, the default
behavior, if this match is left out, is to match all devices,
regardless of where the packet is going.
----------------------------------------------------------------------
The TOS match can be used to match packets based on their
TOS field. TOS stands for Type Of Service, consists of 8 bits,
and is located in the IP header. TOS is normally used to tell
intermediate hosts the preceding of the stream, and what kind
of content it has (not really, but it tells us if there is
any specific requirements for this stream such as that it
needs to be sent as fast as possible, or it needs to be able
to send as much payload as possible).
How different routers and people deal with these values depends.
Most do not care at all, while others try their best to do
something good with the packets in question and the data they
provide.
TOS
This match is used as described above, it can match packets
based on their TOS field and their value. The match takes
an hex or numeric value as an option.
At the time of writing it contained the following named values:
Minimize-Delay 16 (0x10),
Maximize-Throughput 8 (0x08),
Maximize-Reliability 4 (0x04),
Minimize-Cost 2 (0x02), and
Normal-Service 0 (0x00).
Minimize-Delay means to minimize the delay for the packets,
example of standard protocols that this includes are telnet,
SSH and FTP-control.
Maximize-Throughput means to find a path that allows as big
throughput as possible, a standard protocol would be FTP-data.
Maximize-Reliability means to maximize the reliability of
the connection and to use lines that are as reliable as possible,
some good protocols that would fit with this TOS values would
be BOOTP and TFTP.
Minimize-Cost means to minimize the cost until the packets
gets through all the way to the client/server, for example
to find the route that costs the least to travel through.
Some normal protocols that would use this would be RTSP (Real
Time Stream Control Protocol) and other streaming video/radio
protocols.
Normal-Service would finally mean any normal protocol that
has no special needs for their transfers.
-----------------------------------------------------------------------
The source option is used to specify which source the packets
should use. This option, at it simplest, takes one IP address
to which we should transform all the source IP addresses in
the IP header. If we want to balance between several IP addresses
we could use an range of IP addresses separated by a hyphen,
it would then look like, for example, 194.236.50.155-194.236.50.160.
The source IP would then be set randomly for each stream that
we open, and a single stream would always use the same IP
address for packets within that stream. There may also be
an range of ports specified that should only be used by SNAT.
All the source ports would then be mapped to the ports specified.
This would hence look as within the example above, 1024-32000
or something alike. BarbWire will always try to not make any
port alterations if it is possible, but if two hosts tries
to use the same ports, barbwire will map one of them to another
port. If no port range is specified, then all source ports
below 512 will be mapped to other ports below 512 if needed.
Those between source ports 512 and 1023 will be mapped to
ports below 1024. All other ports will be mapped to 1024 or
above. As previously stated, BarbWire will always try to maintain
the source ports used by the actual workstation making the
connection. Note that this has nothing to do with destination
ports, so if a client tries to make contact with an HTTP server
outside the firewall, it will not be mapped to the FTP control
port.
The DNAT target is used to do Destination Network Address
Translation, which means that it is used to rewrite the Destination
IP address of a packet. If a packet is matched, and this is
the target of the rule, the packet, and all subsequent packets
in the same stream will be translated, and then routed on
to the correct device, host or network. This target can be
extremely useful, for example, when you have an host running
your web server inside a LAN, but no real IP to give it that
will work on the internet. You could then tell the firewall
to forward all packets going to its own HTTP port, on to the
real web server within the LAN. We may also specify a whole
range of destination IP addresses, and the DNAT mechanism
will choose the destination IP address at random for each
stream. Hence, we will be able to deal with a kind of load
balancing by doing this.
Note that the DNAT target is only available within the PREROUTING
and OUTPUT chains in the nat table, and any of the chains
called upon from any of those listed chains. Note that chains
containing DNAT targets may not be used from any other chains,
such as the POSTROUTING chain. Note, as described previously,
that a single stream will always use the same host, and that
each stream will randomly be given an IP address that it will
always be Destined for, within that stream. We could also
have specified only one IP address, in which case we would
always be connected to the same host. Also note that we may
add an port or port range to which the traffic would be redirected
to. This is done by adding, for example, an :80 statement
to the IP addresses to which we want to DNAT the packets.
A rule could then look like --to-destination 192.168.1.1:80
for example, or like --to-destination 192.168.1.1:80-100 if
we wanted to specify a port range. As you can see, the syntax
is pretty much the same for the DNAT target, as for the SNAT
target even though they do two totally different things. Do
note that port specifications are only valid for rules that
specify the TCP or UDP protocols with the --protocol option.
This option redirects packets to your LAN IP addresses.
Only one address can be put in or a range can be specified
like so. 192.168.1.1-192.168.1.10 The source IP would then
be set randomly for each stream that we open, and a single
stream would always use the same IP address for packets within
that stream.
A port or a range of ports (22-80) can be specified in conjunction
with NAT to IP.
The MASQUERADE target is used basically the same as the SNAT
target, but it does not require any --to-source option. The
reason for this is that the MASQUERADE target was made to
work with, for example, dialup connections, or DHCP connections,
which gets dynamic IP addresses when connecting to the network
in question. This means that you should only use the MASQUERADE
target with dynamically assigned IP connections, which we
don't know the actual address of at all times. If you have
a static IP connection, you should instead use the SNAT target.
When you masquerade a connection, it means that we set the
IP address used on a specific network interface instead of
the --to-source option, and the IP address is automatically
grabbed from the information about the specific interface.
The MASQUERADE target also has the effect that connections
are forgotten when an interface goes down, which is extremely
good if we, for example, kill a specific interface. If we
would have used the SNAT target, we may have been left with
a lot of old connection tracking data, which would be lying
around for days, swallowing up worthful connection tracking
memory. This is in general the correct behavior when dealing
with dialup lines that are probable to be assigned a different
IP every time it is up'ed. In case we are assigned a different
IP, the connection is lost anyways, and it is more or less
idiotic to keep the entry around.
It is still possible to use the MASQUERADE target instead
of SNAT even though you do have an static IP, however, it
is not favorable since it will add extra overhead, and there
may be inconsistencies in the future which will thwart your
existing scripts and render them "unusable".
Note that the MASQUERADE target is only valid within the
POSTROUTING chain in the nat table, just as the SNAT target.
The MASQUERADE target takes one option specified below, which
is optional.
The REDIRECT target is used to redirect packets and streams
to the machine itself. This means that we could for example
REDIRECT all packets destined for the HTTP ports to an HTTP
proxy like squid, on our own host. Locally generated packets
are mapped to the 127.0.0.1 address. In other words, this
rewrites the destination address to our own host for packets
that are forwarded, or something alike. The REDIRECT target
is extremely good to use when we want, for example, transparent
proxying, where the LAN hosts do not know about the proxy
at all.
Note that the REDIRECT target is only valid within the PREROUTING
and OUTPUT chains of the nat table. It is also valid within
user-defined chains that are only called from those chains,
and nowhere else.
|
ontact Details: