لطفا منتظر باشید ...
Logging > iptables> Activity>
The > iptables> commands and
options described to this point in this chapter operate without creating any
special log entries. Sometimes, though, you want to have access attempts leave
a trace in your system logs. For instance, you might want to record attempts to
access sensitive ports that you've blocked, or failures related to stateful
packet inspection. Such events may indicate an attempt to break into your
system, so you may want to be made aware of them in order to be on the alert
for other activities directed against your computer.> WARNING
align=left border=0> Although logging firewall activities can be
a useful source of information, it can also slow down your firewall's
operation and provide a potential means of attack. If an attacker knows that
you're logging particular types of information, the attacker can send your
system packets with the goal of causing your system to write a lot of data to
its log files. This degrades your firewall's performance, and in an extreme
case it might cause the log file partition to run out of space, causing you
further problems. For this reason, you should use these logging options with
caution. If possible, place your system log files on a separate partition so
that if it's overrun by an out-of-control logging process, it won't cause
problems for other programs or processes.>
> The iptables>
program includes a special target, LOG>,
for logging information. Unlike some targets, a match to the LOG> target doesn't cause the system to
stop searching for matches; after matching and logging the match, the kernel
continues searching the chain to which the LOG>
target belongs. You can use this target in several different ways: >>You can log events that may not match other explicit targets. For
instance, you might include a rule to log any stateful packet inspection
violation, whether your system is configured to reject such violations.TIP
align=left border=0> Logging events that you don't necessarily want to reject can
be a useful debugging tool, because you can verify that packets are reaching
your system, and automatically log some information about these packets.
Other tools, such as packet sniffers, can fill a similar role, but you might
find this feature useful in some situations nonetheless.
> >>If your system has a default DENY>
or REJECT> policy, you can
include a firewall rule for any type of activity you want to log as if you were
explicitly blocking that access, but call the LOG>
target instead of DENY> or REJECT>. When the packet is logged, it will
be blocked by the default policy, unless some other rule lets it through. >>If your system has a default ACCEPT>
policy, you can log packets you want to block by duplicating the DENY> or REJECT>
rule for those packets and changing the first>
copy to call the LOG> target. If
you change the second copy to call the LOG>
target, the result will be ineffectual, because the ACCEPT> target will exit from the chain, leaving the LOG> target unused.As an example, consider the following firewall rules on a
default- ACCEPT> policy firewall,
which restrict access from the 172.24.0.0/16 network and log the access: # iptables -A INPUT -s 172.24.0.0/16 -j LOG>> # iptables -A OUTPUT -d 172.24.0.0/16 -j LOG>> # iptables -A INPUT -s 172.24.0.0/16 -j DROP>> # iptables -A OUTPUT -d 172.24.0.0/16 -j DROP>>
The first two commands are exact duplicates
of the last two, except for the change in the target> LOG> as opposed
to > DROP> . The position of the second and third targets could easily be
swapped; this detail is unimportant. You could also add other rules in-between
the > LOG> and > DROP> rules, but this would make it more difficult to see that the two
rules are related.> The result of a logging operation resembles
the following from a > /var/log/messages> file:> Nov 18 22:13:21 teela kernel: IN=eth0 OUT=> MAC=00:05:02:a7:76:da:00:50:bf:19:7e:99:08:00 SRC=> DST=192.168.1.2 LEN=40 TOS=0x10 PREC=0x00 TTL=64 ID=16023 DF> PROTO=TCP SPT=4780 DPT=22 WINDOW=32120 RES=0x00 ACK URGP=0>
Information included in this output includes
the following:> >> Date and time>> The entry begins with a timestamp showing when the packet arrived.> >> System name>> This computer is called > teela> .> >> Input network
interface>> The > IN=eth0> entry indicates
that the packet in question was an incoming packet on the > eth0> interface.> >> Output network
interface>> The packet in question was not an
outgoing packet, so the > OUT=> field is empty.> >> MAC addresses>> The > MAC=> entry includes two media access control
(MAC)> addresses. The first six fields of this entry are the local
system's MAC address, and the next six fields are the remote system's MAC
address. (The remote system's MAC address is not reliable for packets that have
passed through a router, such as packets from the Internet at large.)> >> Source and
destination IP addresses>> The > SRC=> and > DST=> entries
provide the source and destination IP addresses, respectively.> >> Source and
destination ports>> The > SPT=> and > DPT=> entries
specify the source and destination ports, respectively.> >> Packet information>> Additional fields provide further information about the packet,
such as its length (> LEN=>), its time-to-live (TTL) value (> TTL=>), and so on.> The > LOG> target supports
several additional options that you can use to control material that goes into
log entries. The most useful option is probably > --log-prefix> > prefix> .
This option lets you specify a string of up to 29 characters to help you
identify log entries, and hence the rule that caused the log entry to be made.> >
