SnapGear SG565 Router Manual PDF (Setup & Configuration Guide)

Page 236 / 249 Scroll up to view Page 231 - 235

Appendix B – Terminology

231

x.509 Certificates

An x.509 certificate includes the format of the certificate, the serial

number of the certificate, the algorithm used to sign the certificate, the

name of the CA that issued the certificate, the name and public key of

the entity requesting the certificate, and the CA's signature.x.509

certificates are used to authenticate the remote party against a

Certificate Authority's (CA) certificate.

The CA certificate must have

signed the local certificates that are used for tunnel authentication.

Certificates need to be uploaded into the CyberGuard SG appliance

before a tunnel can be configured to use them (see Certificate

Management).

Page 237 / 249

Appendix C – System Log

232

Appendix C – System Log

Access Logging

It is possible to log any traffic that arrives at or traverses the CyberGuard SG appliance.

The only logging that is enabled by default is to take note of packets that were dropped.

While it is possible to specifically log exactly which rule led to such a drop, this is not

configured by default.

All rules in the default security policy drop packets.

They never

reject them.

That is, the packets are simply ignored, and have no responses at all

returned to the sender.

It is possible to configure reject rules if so desired.

All traffic logging performed on the CyberGuard SG appliance creates entries in the

syslog (

/var/log/messages

- or external syslog server) of the following format:

klogd:

IN=

OUT=

<outgoing

interface>

MAC=

SRC=

DST=

<destination IP

>

SPT=

DPT=

Where:

if non-empty, hints at cause for log entry

will be empty, or one of eth0, eth1 and similar

as per incoming interface

MAC addresses associated with the packet

packet claims it came from this IP address

packet claims it should go to this IP address

packet claims it came from this TCP port

packet wants to go to this TCP port

Depending on the type of packet and logging performed some of the fields may not

appear.

Page 238 / 249

Appendix C – System Log

233

Commonly used interfaces are:

eth0

the LAN port

eth1

the WAN/Internet port

ppp

X

e.g.

ppp0

or

ppp1

– a PPP session

ipsec

X

e.g.

ipsec0

, an IPSec interface

The firewall rules deny all packets arriving from the WAN port by default.

There are a few

ports open to deal with traffic such as DHCP, VPN services and similar.

Any traffic that

does not match the exceptions however is dropped.

There are also some specific rules to detect various attacks (smurf, teardrop, etc.).

When outbound traffic (from LAN to WAN) is blocked by custom rules configured in the

GUI, the resultant dropped packets are also logged.

The

for all these rules is varied according to their type.

Currently used prefixes for traffic arriving:

Default Deny

Packet didn't match any rule – drop it

Invalid

Invalid packet format detected

Smurf

Smurf attack detected

Spoof

Invalid IP address detected

SynFlood

SynFlood attack detected

Custom

Custom rule dropped outbound packet

Page 239 / 249

Appendix C – System Log

234

A typical

Default Deny:

will thus look similar to the following:

Mar 27 09:31:19 2003 klogd: Default deny: IN=eth1

OUT=MAC=00:d0:cf:00:ff:01:00:e0:29:65:af:e9:08:00

SRC=140.103.74.181 DST=12.16.16.36 LEN=60 TOS=0x10 PREC=0x00

TTL=64 ID=46341 DF PROTO=TCP SPT=46111 DPT=139 WINDOW=5840

RES=0x00 SYN URGP=0

That is, a packet arriving from the WAN (

IN=eth1

) and bound for the CyberGuard SG

appliance itself (

OUT=<nothing>

) from IP address 140.103.74.181

(

SRC=140.103.74.181

), attempting to go to port 139 (

DPT=139

, Windows file sharing)

was dropped.

If the packet is traversing the CyberGuard SG appliance to a server on the private

network, the outgoing interface will be eth0, e.g.:

Mar 27 09:52:59 2003 klogd: IN=eth1 OUT=eth0 SRC=140.103.74.181

DST=10.0.0.2 LEN=60 TOS=0x10 PREC=0x00 TTL=62 ID=51683 DF

PROTO=TCP SPT=47044 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Packets going from the private network to the public come in eth0, and out eth1, e.g.:

Mar 27 10:02:51 2003 klogd: IN=eth0 OUT=eth1 SRC=10.0.0.2

DST=140.103.74.181 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=62830 DF

PROTO=TCP SPT=46486 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Creating Custom Log Rules

Additional log rules can be configured to provide more detail if desired.

For example, by

analyzing the rules in the

Rules

menu, it is possible to provide additional log messages

with configurable prefixes (i.e. other than

Default Deny:

) for some allowed or denied

protocols.

Depending on how the

LOG

rules are constructed it may be possible to differentiate

between inbound (from WAN to LAN) and outbound (from LAN to WAN) traffic.

Similarly,

traffic attempting to access services on the CyberGuard SG appliance itself can be

differentiated from traffic trying to pass through it.

The examples below can be entered on the Command Line Interface (telnet), or into the

Rules

Web Management Console web administration pages.

Rules entered on the CLI

are not permanent however, so while it may be useful for some quick testing, it is

something to be wary of.

Page 240 / 249

Appendix C – System Log

235

To log permitted inbound access requests to services hosted on the CyberGuard SG

appliance, the rule should look something like this:

iptables -I INPUT -j LOG -p tcp --syn -s

<X.X.X.X/XX>

-d

<Y.Y.Y.Y/YY>

--dport

<Z>

--log-prefix

This will log any TCP (

-p tcp

) session initiations (

--syn

) that arrive from the IP

address/netmask

X.X.X.X/XX

(

-s ...

) and are going to

Y.Y.Y.Y/YY

, destination port Z (

--

dport

).

For example, to log all inbound access requests from anywhere on the Internet

(0.0.0.0/0) to the PPTP service (port 1723) on the CyberGuard SG appliance (IP address

1.2.3.4):

iptables -I INPUT -j LOG -p tcp --syn -s 0.0.0.0/0 -d 1.2.3.4

--dport 1723 --log-prefix "Internet PPTP access: "

To find the resultant log entry in the logs, simply search for the prefix, in this instance

"Internet PPTP access: "

.

If for example site 192.0.1.2 attempted to access the CyberGuard SG appliance’s PPTP

port, the resultant log message would look something like this:

<12> Jan 24 17:19:17 2000 klogd: Internet PPTP access: IN=eth0

OUT= MAC=00:d0:cf:00:07:03:00:50:bf:20:66:4d:08:00 SRC=

DST=1.2.3.4 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=43470 DF

PROTO=TCP SPT=4508 DPT=1723 WINDOW=64240 RES=0x00 SYN URGP=0

Note how

OUT

is set to nothing.

This indicates that the packet was attempting to reach a

service on the CyberGuard SG appliance, rather than attempting to pass through it.

A very similar scenario occurs for logging access requests that are attempting to pass

through the CyberGuard SG appliance.

It merely requires replacing the

INPUT

keyword

with

FORWARD

.

Thus, to log permitted inbound requests to services hosted on a server behind the

CyberGuard SG appliance, or outbound requests to services on a public network server,

use:

iptables -I FORWARD -j LOG -p tcp --syn -s

<X.X.X.X/XX>

-d

<Y.Y.Y.Y/YY>

--dport

<Z>

--log-prefix

Rate

Popular SnapGear Models

Famous Router IPs

Famous Router Companies

Bookmark Our Site

Share