Chapter 3 – RouteFinder Software Operation
Multi-Tech RouteFinder RF650VPN User Guide
140
2.
Known to be "problems" - messages that should cause some action (email the administrator, start
investigating the cause, etc.). For example: a message about a bad disk block at location 0x56c8a7
or something similar.
3.
Unknown
- messages that someone should examine, such as why someone is sending UDP packets
from port 20 to some arbitrary port above port 1024 (doesn't match any known protocol).
Categorizing the log data is an on-going process. When an "Unknown" message is researched and
resolved, future similar messages can more easily be categorized as either "OK" or "Problem".
The criteria for categorizing log data will change over a period of time.
The context of the log data should also be considered; an message considered "Unknown" that occurs
just once may be little cause for concern. If the same message occurs once every two minutes, the
cause for concern increases greatly. A similar level of concern would be generated if someone made
several failed login attempts as administrator, then successfully logged in as administrator, then
immediately made an outbound connection.
Typically, as the administrator moves past the basics (e.g., user logins are "OK", a "bad disk" message is
not OK) some basic rules will occur, such as:
1.
One failed login attempt is an accident, two is a coincidence, three is cause for action;
2.
Accidents do not try to "cover up" the issue (e.g., missing log files or deleted entries).
3.
Most mysteries ("Unknowns") don't mean anything. Most of the time the issue turns out to be a client
user error or a "glitch" in reporting or usage, but the administrator should still attempt to track the
issue down, but just not in "panic mode".
4.
Simple explanations are usually correct (e.g., a disk or other hardware problem is a more likely event
than a break in).
Classifying events known to be "problems" could be put into sub-categories, where you:
1.
Know what caused the event and it's not a security problem.
2.
Don't know what caused it, researched it, and may never know what caused it.
3.
Know someone tried to break in, but didn't try very hard (a "probe").
4.
Know someone tried hard to break in (an "attack").
5.
Know someone actually broke in.
Some examples of classifying "Problem" events:
You might suspect a probe if:
·
some attempts were made to access services at insecure ports, or
·
packets are sent to the same ports on every IP address within a range of IP addresses.
You might suspect an attack if:
·
there are sudden increases in outgoing or incoming traffic, or
·
log data shows login attempts on accounts in the exact same order as listed in the password file, or
·
a log shows multiple failed login attempts to valid accounts that use the Internet.
You can suspect a successful break-in when you see:
·
modified or deleted log files, or
·
services enabled which you have not enabled, or
·
unexpected logins as privileged (e.g., root) user.
Your organization's security policy should indicate the action to take for each event category (i.e., probe,
attack, successful break-in, etc.
