Logging scheme for small,

medium and large sites.

Server Administration
Assignment 2
N.Azam Mohamed
11426508

CO N T E N TS

SMALL SITE:

ASSUMPTION
Server Administration Logging Scheme

Logging scheme design for a small site, in this scenario I have considered a small
site is a site with 10-50 users/systems which just a LAN that uses for daily basic
needs like emails and other file transfers. On a small site most of the critical systems
will be outsourced or rented so they physically located out of the site and limited
users have access to those systems so this scheme is designed for the Local area
network that used by the daily users not system or network administrators. Since this
is a small site with very limited users most companies outsource the system
administration tasks. The most common activities on small network are initial system
startup, user login, start or stop services, connecting to networks, create, update or
delete information ect. This login scheme is appropriate for a small site that contain
with a centralized Domain controller that control this network and users with a mail
server.

WHAT NEEDS TO BE LOGGED?

1. Read, write, update or delete confidential information.
2. Initiate or accept network connection.
3. Add, delete or update users.
4. Change user permissions.
5. Change or updates in user groups.
6. Detection of any viruses from antivirus software.
These logs will include Action name, identifiers that the user login or the system
MAC & IP address, Action time stamp with date, Action result whether the action is
allowed or denied. (syslog) These logs shall be created with syslog-ng and the
instruction to create the syslog-ng is provided on section syslog configuration in this
document. These logs will help to troubleshoot system and application problems and
early warnings of any unauthorized activities in the network.

REPORTING AND STORAGE

Collected log files will be stored in centralized system and logcheck (log) will be used
to manage the logs, logcheck will check the logs for specified actions and when a
suspicious or important activity identified logcheck send mails to notify the system
administrator. Logs will be stored in a SQL database and backed up by the end of
the day and after 7 daily backups log file will be compressed and stored with a date
stamp. More information about reporting and storing with logcheck can be obtained
from www.logcheck.org.

MEDIUM SITE

ASSUMPTIONS

Page 2 N.Azam Mohamed | 11426508

Server Administration Logging Scheme

In this scenario I assume a medium site is a network with approximately 500-2000

users or devices that used by a company to record their daily transactions or for
communication purpose, usually a medium site will run their own servers with system
administrators and technicians so all logs will be monitored more closely than a small
site and these medium sites will run their own web, mail, FTP and domain controller
servers. Logs will be generated by these servers and networking devices through
syslog and syslog-ng.

WHAT NEEDS TO BE LOGGED?

1. Create, read, update, or delete confidential information, including confidential
authentication information such as passwords;
2. Initiate a network connection;
3. Accept a network connection;
4. User authentication and authorization for activities covered in #1 or #2 such
as user login and logout;
5. Grant, modify, or revoke access rights, including adding a new user or group,
changing user privilege levels, changing file permissions, changing database
object permissions, changing firewall rules, and user password changes;
6. System, network, or services configuration changes, including installation of
software patches and updates, or other installed software changes;
7. Application process startup, shutdown, or restart;
8. Application process abort, failure, or abnormal end, especially due to resource
exhaustion or reaching a resource limit or threshold (such as for CPU,
memory, network connections, network bandwidth, disk space, or other
resources), the failure of network services such as DHCP or DNS, or
hardware fault; and
9. Detection of suspicious/malicious activity such as from an Intrusion Detection
or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system.

With the above mentioned logs these elements also will be included Action type
(Action failure or success), subsystem that performing the action, identifiers for
example the system information like ip & mac address or the user information such
as user logins, date and time of the action, action results for example whether the
action allowed or denied by the system if denied description or reason for denying
the action.

REPORTING AND STORING

A medium network will generate a huge amount of logs with consumption of big
amount of memory and bandwidth so it’s recommended to analyze these logs and
make reports to take the maximum use of the logs, since this a medium site with
limited numbers of administrators its recommended to use a third party log analyzer&
viewer rather than developing the own scripts. So I recommend Log viewer software
for log analyzing and reporting purposes, log viewer Index and Search syslog log

Page 3 N.Azam Mohamed | 11426508

Server Administration Logging Scheme

files. The log viewer enables very quick searches that for any type of log message.
Create aggregation and computation reports. Monitor logs, create filters and merge
multiple logs together. Support Linux, UNIX and Windows formats. Enable smart
correlation of logs for distributed environments. The Log Reader helps to read
extremely large files without consuming memory. Once the log files are parsed by
the log viewer, the user can create aggregation reports, define log monitoring that
can send alerts via email, SNMP, JMS messages and more. XpoLog Log Viewer is
used across the application life cycle – development, test, support and production.
(logviewer)
Log files will be stored in debian linux syslog server and these large numbers of logs
will consume a huge memory so it’s recommended to rotate the logs weekly (log
rotating and configuring details provided in section syslog configuration).(debian)

LARGE SITE

ASSUMPTIONS

A large site is a network with more than 1500 users or devices that’s not limited to a LAN it connects
WANs and physically located in different geographical areas, these sites will run their own servers or
data centers with unlimited users and unlimited data transfers a day. When it comes to bigger in size
the logs get even bigger so I assume a large site shall involve more people in log monitoring and
management process their roles will be System and network administrators, Security administrators,
and incident response team, Application developers, CIO and auditors.

LOGGING POLICY

Page 4 N.Azam Mohamed | 11426508

Server Administration Logging Scheme

This large sites log can be divided in to two categories security software logs and operating system
logs. Most organizations use different type of security software’s to detect malicious activity, protect
system data and support incident response team. The common security software’s are Antivirus and
antimalware, intrusion detection and prevention systems, web proxies, vulnerability management
software’s and authentication servers. (NIST) Operating system logs are usually system events and
audit records these logs are most beneficial for identify suspicious activity on a host.
These categorized logs will provide the protection and foundation for applications and systems that
store, access or manipulate the daily organizations data’s. I recommend to use 3 rd party software’s
like e-mail servers and clients, Web servers and browsers, file servers and file sharing clients, and
database servers and clients. Some applications create their own logs while other applications use
the OS’s log services. Most commonly used logs are:

t Client requests and server responses, which can be very helpful in reconstructing sequences of
events and determining their apparent outcome. If the application logs successful user
authentications, it is usually possible to determine which user made each request. Some
applications can perform highly detailed logging, such as e-mail servers recording the sender,
recipients, subject name, and attachment names for each e-mail; Web servers recording each
URL requested and the type of response provided by the server; and business applications
recording which financial records were accessed by each user. This information can be used
to identify or investigate incidents and to monitor application usage for compliance and
auditing purposes.

a Account information such as successful and failed authentication attempts, account changes
(e.g., account creation and deletion, account privilege assignment), and use of privileges. In
addition to identifying security events such as brute force password guessing and escalation
of privileges, it can be used to identify who has used the application and when each person
has used it.

h Usage information such as the number of transactions occurring in a certain period (e.g.,
minute, hour) and the size of transactions (e.g., e-mail message size, file transfer size). This
can be useful for certain types of security monitoring (e.g., a ten-fold increase in e-mail
activity might indicate a new e-mail–borne malware threat; an unusually large outbound e-
mail message might indicate inappropriate release of information).

m Significant operational actions such as application startup and shutdown, application failures,
and major application configuration changes. This can be used to identify security
compromises and operational failures. (NIST)

STORING AND REPORTING

Log management is a challenging process in a large site since the logs should be
available and not accessible by attackers because when a network is compromised
most crackers firstly destroy the logs, since this is large site the logs will be
generated by many log sources for example network devices, security software’s,
OS, other network services and many more sometime a single action can create
multiple logs as well. These logs record large numbers of data’s daily so reviewing
all of those logs analyzing them is a real challenge on a large site.
To review these logs its recommended to convert all logs in to single format for
example a SQL data so queries can be used to analyze and identify the logs and
report them in a appropriate format via email or another required method and the

Page 5 N.Azam Mohamed | 11426508

Server Administration Logging Scheme

logs can be send to specified persons like technician or administrator to take

decisions. Log analysis is often treated as reactive something to be done after a
problem has been identified through other means rather than proactive, to identify
ongoing activity and look for signs of impending problems. So log analyzing requires
time human resource, so 3rd party software’s and in-house designed custom
software’s can be used to effectively identify and analyze the logs .
In conclusion logs will be stored in SQL database and summarized on a daily basis
and specified logs will be forward to appropriate person and by end of a week logs
will be backed up and compressed. To facilitate analysis of logs, organizations often
need to implement automated methods of converting logs with different content and
formats to a single standard format with consistent data field representations.
Inconsistent log formats and data field representations also present challenges to
people reviewing logs, who need to understand the meaning of various data fields in
each log to perform a thorough review. Developer can use cron jobs to schedule
analyze, backup and rotate logs.(linux)

LOG FILE ROTATION

The problem with log files is that over time they grow. When a system is
experiencing problems the log files can grow very large, very quickly. Periodically
trimming or removing log files is necessary. This is known as log file rotation and is
a service usually run via cron.
The most popular scheme is to rename a log file log as log.1 and to start a
new log file. Next time, log.1 is renamed to log.2, log is renamed to log.1, and a
new log file is started. This continues for N previous files.
Since dealing with log file rotation is a common problem most Unix systems have a
standard way to deal with it. On Solaris9 you
have /usr/sbin/logadm (/usr/lib/newsyslog on earlier Solaris).
On Linux you have the logrotate command. This command runs via the cron facility.
You can set your log rotation policy for any log file by editing the file logrotate.conf,
or editing files in the/etc/logrotate.d directory. Log file rotation configuration is
described in section II (tute)

SYSLOG CONFIGURATION

The files to which syslog writes each type of message received is set in
the /etc/rsyslog.conf configuration file. In older versions of Fedora this file was named/etc/syslog.conf.

This file consists of two columns. The first lists the facilities and severities of messages to expect and
the second lists the files to which they should be logged. By default,
RedHat/Fedora's /etc/rsyslog.conf file is configured to put most of the messages in the
file /var/log/messages. Here is a sample:

Page 6 N.Azam Mohamed | 11426508

Server Administration Logging Scheme

*.info;mail.none;authpriv.none;cron.none /var/log/messages

In this case, all messages of severity "info" and above are logged, but none from the mail, cron or
authentication facilities/subsystems. You can make this logging even more sensitive by replacing the
line above with one that captures all messages from debug severity and above in
the /var/log/messages file. This example may be more suitable for troubleshooting.

*.debug /var/log/messages

In this example, all debug severity messages; except auth, authpriv, news and mail; are logged to
the /var/log/debug file in caching mode. Notice how you can spread the configuration syntax across
several lines using the slash (\) symbol at the end of each line.

*.=debug;\
auth,authpriv.none;\
news.none;mail.none -/var/log/debug

Here we see the /var/log/messages file configured in caching mode to receive only info, notice and
warning messages except for the auth, authpriv, news and mail facilities.

*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages

You can even have certain types of messages sent to the screen of all logged in users. In this
example messages of severity emergency and above triggers this type of notification. The file
definition is simply replaced by an asterisk to make this occur.

*.emerg *

Certain applications will additionally log to their own application specific log files and directories
independent of the syslog.conf file. Here are some common examples:

Files:

/var/log/maillog : Mail

Page 7 N.Azam Mohamed | 11426508

Server Administration Logging Scheme

/var/log/httpd/access_log : Apache web server page access logs

Directories:

/var/log
/var/log/samba : Samba messages
/var/log/mrtg : MRTG messages
/var/log/httpd : Apache webserver messages

Note: In some older versions of Linux the /etc/rsyslog.conf file was very sensitive to spaces and
would recognize only tabs. The use of spaces in the file would cause unpredictable results. Check the
formatting of your /etc/rsyslog.conf file to be safe.(LHN)

ACTIVATING CHANGES TO THE SYSLOG CONFIGURATION FILE

Changes to /etc/rsyslog.conf will not take effect until you restart syslog. Issue this command to do so:

[root@bigboy tmp]# service rsyslog restart

In older versions of Fedora, this would be:

Page 8 N.Azam Mohamed | 11426508

Server Administration Logging Scheme

[root@bigboy tmp]# service syslog restart

This is slightly different with Ubuntu / Debian systems:

root@u-bigboy:~# /etc/init.d/sysklogd restart

(LHN)

LOG ROTATION CONFIGURATION

This is logrotate's general configuration file in which you can specify the frequency with which the files
are reused.

 You can specify either a weekly or daily rotation parameter. In the case below
the weekly option is commented out with a #, allowing for daily updates.
 The rotate parameter specifies the number of copies of log files logrotate will
maintain. In the case below the 4 copy option is commented out with a #, while
allowing 7 copies.
 The create parameter creates a new log file after each rotation
Therefore, our sample configuration file will create daily archives of all the logfiles and store them for
seven days. The files will have the following names with, logfile being current active version:

logfile
logfile.0
logfile.1
logfile.2
logfile.3
logfile.4
logfile.5
logfile.6

SAMPLE CONTENTS OF /ETC/LOGROTATE.CONF

# rotate log files weekly

#weekly

Page 9 N.Azam Mohamed | 11426508

Server Administration Logging Scheme

# rotate log files daily

daily

# keep 4 weeks worth of backlogs

#rotate 4

# keep 7 days worth of backlogs

rotate 7

# create new (empty) log files after rotating old ones

create

(LHN)

REFERENCES:

Syslog wiki (n.d), Retrieved May 15th 2010 from

http://www.syslog.org/wiki/Main/Policies (syslog)
Log check (n.d), Retrieved May 15th 2010 from http://www.logcheck.org (logcheck)
Log Viewer (n.d), Retrieved May 15th 2010 from http://www.log-viewer.com/syslog-
log-viewer/ (logviewer)
Debian linux server (n.d), Retrieved May 15th 2010 from
http://www.aboutdebian.com/syslog.htm (debian)
Karen Kent & Murugiah Souppaya (2006) Guide to Computer Security Log Management, National
Institute of Standards and Technology Gaithersburg,(NIST)
Syslog tutorial (n.d), Retrieved May 15th 2010 from
http://content.hccfl.edu/pollock/AUnix2/Logging.htm (tute)
Linux home working (n.d), Retrieved May 15th 2010 from
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch05_:_Trou
bleshooting_Linux_with_syslog (lhn)
Linux Journal (n.d), retrived May 14th 2010 from http://www.linuxjournal.com/article/5476 (linux)

Page 10 N.Azam Mohamed | 11426508

Server Administration Logging Scheme

Page 11 N.Azam Mohamed | 11426508