Category Archives: Linux

Is this machine the central log server for your organization? If so, edit the file /etc/sysconfig/syslog.

Add or correct the following line:
SYSLOGD_OPTIONS=”-m 0 -r -s example.com “

Where example.com is the name of your domain.
If the machine is not a log server, edit /etc/sysconfig/syslog, and instead add or correct the line:
SYSLOGD_OPTIONS=”-m 0″

By default, RHEL5’s syslog does not listen over the network for log messages. The -r flag enables syslogd to listen over a network, and should be used only if necessary. The -s example.com flag strips the domain name example.com from each sending machine’s hostname before logging messages from that host, to reduce the amount of redundant information placed in log files.

Edit /etc/syslog.conf. Add or correct the line:

*.*                        @loghost.example.com
Where loghost.example.com is the name of your central log server.

It is particularly important that logs be stored on the local host in addition to being sent to the loghost, because syslogd uses the UDP protocol to send messages over a network. UDP does not guarantee reliable delivery, and moderately busy sites will lose log messages occasionally, especially in periods of high traffic which may be the result of an attack. In addition, remote syslogd messages are not authenticated, so it is easy for an attacker to introduce spurious messages to the central log server. Also, some problems cause loss of network connectivity,which will prevent the sending of messages to the central server. For all of these reasons, it is better to store log messages both centrally and on each host, so that they can be correlated if necessary.

Edit the file /etc/login.defs to specify password expiration settings for new accounts.Add or correct the following lines:
PASS_MAX_DAYS 60
PASS_MIN_DAYS 7
PASS_MIN_LEN 14
PASS_WARN_AGE 7

For each existing human user USER , modify the current expiration settings to match these:
# chage -M 60 -m 7 -W 7 USER

Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS MAX DAYS and apply it to existing accounts with the -M flag.
Continue reading

1. Ensure that the group wheel exists, and that the usernames of all administrators who should be allowed
to execute commands as root are members of that group.
# grep ^wheel /etc/group
2. Edit the file /etc/pam.d/su. Add, uncomment, or correct the line:
auth required pam_wheel.so use_uid

The su command allows a user to gain the privileges of another user by entering the password for that user’s account. It is desirable to restrict the root user so that only known administrators are ever allowed to access the root account.
This restricts password-guessing against the root account by unauthorized users or by accounts which have been compromised.
By convention, the group wheel contains all users who are allowed to run privileged commands.The PAM module pam wheel.so is used to restrict root access to this set of users.

Do not perform the steps in this section on the root account. Doing so might cause the system to
become inaccessible.

Using /etc/passwd, obtain a listing of all users, their UIDs, and their shells, for instance by running:
# awk -F: ‘{print $1 “:” $3 “:” $7}’ /etc/passwd
Identify the system accounts from this listing. These will primarily be the accounts with UID numbers less
than 500, other than root.
For each identified system account SYSACCT , lock the account:
# usermod -L SYSACCT
and disable its shell:
# usermod -s /sbin/nologin SYSACCT
Continue reading

The yum update utility can be run by hand from the command line, called through one of the provided  front-end tools,or configured to run automatically at specified intervals.

Manually Check for Package Updates
The following command prints a list of packages that need to be updated:
# yum check-update
To actually install these updates, run:
# yum update

Configure Automatic Update Retrieval and Installation with Cron
The yum-updatesd service is not mature enough for an enterprise environment, and the service may introduce unnecessary overhead. When possible, replace this service with a cron job that calls yum directly.

Disable the yum-updatesd service:
# chkconfig yum-updatesd off
Create the file yum.cron, make it executable, and place it in /etc/cron.daily:
#!/bin/sh
/usr/bin/yum -R 120 -e 0 -d 0 -y update yum
/usr/bin/yum -R 10 -e 0 -d 0 -y update
This particular script instructs yum to update any packages it finds. Placing the script in /etc/cron.
daily ensures its daily execution. To only apply updates once a week, place the script in /etc/cron.weekly instead.

To ensure that the system can cryptographically verify update packages (and also connect to the Red Hat Network to receive them if desired),
run the following command to ensure that the system has the Red Hat GPG key properly installed: $rpm -q –queryformat “%{SUMMARY}\n” gpg-pubkey
The command should return the string:    gpg(Red Hat, Inc. (release key <security@redhat.com>)

To verify that the Red Hat GPG key itself has not been tampered with, its fingerprint can be compared to the one from Red Hat’s web site at http://www.redhat.com/security/team/key. The following command can be used to print the installed release key’s fingerprint, which is actually contained in the file referenced below:
$ gpg –quiet –with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
More information on package signing is also available at https://fedoraproject.org/keys.

The first step in configuring a system for updates is to register with the Red Hat Network (RHN).
For mostsystems,this is done during the initial installation. Successfully registered systems will appear on the RHN web site.
If the system is not listed, run the Red Hat Network Registration tool, which can be found in the
Applications menu under System Tools
or on the command line:
# rhn_register
Follow the prompts on the screen. If successful, the system will appear on the RHN web site and be subscribed to one or more software update channels.
Additionally, a new daemon, rhnsd, will be enabled.

If the system will not have access to the Internet, it will not be able to directly subscribe to the RHN update repository.
Updates will have to be downloaded from the RHN web site manually. The command line tool yum and the graphical front-ends pirut and pup can be
configured to handle this situation.

Requirements:
CPU – PII or more…
OS – Any Linux distribution.

Software – – Iptables
Network Interface Cards(NIC): 2
Here is my considerations:
Replace xx.xx.xx.xx with your WAN IP
Replace yy.yy.yy.yy with your LAN IP
(i.e. 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 as suggested by itjagat.com)
WAN = eth0 with public IP xx.xx.xx.xx
LAN = eth1 with private IP yy.yy.yy.yy/ 255.255.0.0

Step by Step Procedure:
Continue reading

Page 1 of 212