Kernel
Tunable Security Parameters
The
following list shows tunable kernel parameters you can use to secure your Linux
server against attacks.
For each tunable kernel parameters I will show the entry that needs to be added to the /etc/sysctl.conf configuration file to make the change permanent after reboots. To activate the configured kernel parameters immediately at runtime, use:
For each tunable kernel parameters I will show the entry that needs to be added to the /etc/sysctl.conf configuration file to make the change permanent after reboots. To activate the configured kernel parameters immediately at runtime, use:
#
sysctl -p
Enable TCP SYN Cookie Protection
A "SYN Attack" is a denial of service attack that consumes all the resources on a machine. Any server that is connected to a network is potentially subject to this attack.
To enable TCP SYN Cookie Protection, edit the /etc/sysctl.conf file and add the following line:
net.ipv4.tcp_syncookies = 1
Disable IP Source Routing
Source Routing is used to specify a path or route through the network from source to destination. This feature can be used by network people for diagnosing problems. However, if an intruder was able to send a source routed packet into the network, then he could intercept the replies and your server might not know that it's not communicating with a trusted server.
To enable Source Route Verification, edit the /etc/sysctl.conf file and add the following line:
net.ipv4.conf.all.accept_source_route = 0
Disable ICMP Redirect Acceptance
ICMP redirects are used by routers to tell the server that there is a better path to other networks than the one chosen by the server. However, an intruder could potentially use ICMP redirect packets to alter the hosts's routing table by causing traffic to use a path you didn't intend.
To disable ICMP Redirect Acceptance, edit the /etc/sysctl.conf file and add the following line:
net.ipv4.conf.all.accept_redirects = 0
Enable IP Spoofing Protection
IP spoofing is a technique where an intruder sends out packets which claim to be from another host by manipulating the source address. IP spoofing is very often used for denial of service attacks. For more information on IP Spoofing, I recommend the article IP Spoofing: Understanding the basics.
To enable IP Spoofing Protection, turn on Source Address Verification. Edit the /etc/sysctl.conf file and add the following line:
net.ipv4.conf.all.rp_filter = 1
Enable Ignoring to ICMP Requests
If you want or need Linux to ignore ping requests, edit the /etc/sysctl.conf file and add the following line:
net.ipv4.icmp_echo_ignore_all = 1
This
cannot be done in many environments.
Enable Ignoring Broadcasts Request
If you want or need Linux to ignore broadcast requests, edit the /etc/sysctl.conf file and add the following line:
Enable Ignoring Broadcasts Request
If you want or need Linux to ignore broadcast requests, edit the /etc/sysctl.conf file and add the following line:
net.ipv4.icmp_echo_ignore_broadcasts = 1
Enable Bad Error Message Protection
To alert you about bad error messages in the network, edit the /etc/sysctl.conf file and add the following line:
net.ipv4.icmp_ignore_bogus_error_responses = 1
Enable Logging of Spoofed Packets, Source Routed Packets, Redirect Packets
To turn on logging for Spoofed Packets, Source Routed Packets, and Redirect Packets, edit the /etc/sysctl.conf file and add the following line:
net.ipv4.conf.all.log_martians = 1
References for Kernel Tunable Parameters
Network Security with /proc/sys/net/ipv4
IP Spoofing: Understanding the basics
Checking File Permissions and Ownership
Default
umask
The umask (user file-creation mode mask) command is a shell built-in command which determines the default file permissions for newly created files. This can be overwritten by system calls but many programs and utilities make use of umask.
By default, Red Hat sets umask to 022 or 002 which is fine. If the name of the user account and the group account is the same and the UID is 100 or larger, then umask is set to 002, otherwise it's set to 022, see /etc/bashrc for bash shells.
The umask (user file-creation mode mask) command is a shell built-in command which determines the default file permissions for newly created files. This can be overwritten by system calls but many programs and utilities make use of umask.
By default, Red Hat sets umask to 022 or 002 which is fine. If the name of the user account and the group account is the same and the UID is 100 or larger, then umask is set to 002, otherwise it's set to 022, see /etc/bashrc for bash shells.
$
id
uid=509(test)
gid=510(test) groups=100(users),510(test) context=user_u:system_r:unconfined_t
$
umask
0002
$
#
id
uid=0(root)
gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=root:system_r:unconfined_t
#
umask
0022
#
Here
is an example how umask works:
$
umask 000
$
touch file1
$
ls -l file1
-rw-rw-rw- 1 oracle oinstall 0 Dec 26 19:24 file1
$
umask 002
$
touch file2
$
ls -l file2
-rw-rw-r-- 1 oracle oinstall 0 Dec 26 19:24 file2
$
umask 022
$
touch file3
$
ls -l file3
-rw-r--r-- 1 oracle oinstall 0 Dec 26 19:25 file3
$
For
the bash shell you can find the setting of umask in /etc/bashrc. The
/etc/bashrc file is for system-wide aliases and functions and is invoked by
~/.bashrc.
SUID/SGID Files
When the SUID (set user ID) or SGID (set group ID) bits are set on an executable, it executes with the UID or GID of the owner of the executable rather than that of the person executing it. This means that e.g. all executables that have the SUID bit set and are owned by root are executed with the UID of root. A good example is the passwd command that allows ordinary users to update the password field in the /etc/shadow file which is owned by root.
But SUID/SGID bits can be misused when the SUID/SGID executable has a security hole. Therefore, you might want to search the entire system for SUID/SGID executables and document it. For example, ensure that code developers don't set SUID/SGID bits on their programs if it's not an absolute requirement. Very often you can use workarounds like removing just the executable bit for world/others. However, a better approach is to change the design of the software if possible.
To search the entire system for SUID or SGID files, you can run the following command:
SUID/SGID Files
When the SUID (set user ID) or SGID (set group ID) bits are set on an executable, it executes with the UID or GID of the owner of the executable rather than that of the person executing it. This means that e.g. all executables that have the SUID bit set and are owned by root are executed with the UID of root. A good example is the passwd command that allows ordinary users to update the password field in the /etc/shadow file which is owned by root.
But SUID/SGID bits can be misused when the SUID/SGID executable has a security hole. Therefore, you might want to search the entire system for SUID/SGID executables and document it. For example, ensure that code developers don't set SUID/SGID bits on their programs if it's not an absolute requirement. Very often you can use workarounds like removing just the executable bit for world/others. However, a better approach is to change the design of the software if possible.
To search the entire system for SUID or SGID files, you can run the following command:
find
/ -path /proc -prune -o -type f -perm +6000 -ls
The
-prune option in this example is used to skip the /proc filesystem.
World-Writable Files
World-writable files are a security risk since it allows anyone to modify them. Additionally, world-writable directories allow anyone to add or delete files.
To locate world-writable files and directories, you can use the following command:
World-Writable Files
World-writable files are a security risk since it allows anyone to modify them. Additionally, world-writable directories allow anyone to add or delete files.
To locate world-writable files and directories, you can use the following command:
find
/ -path /proc -prune -o -perm -2 ! -type l -ls
The
"! -type l" parameter skips all symbolic links since symbolic links
are always world-writable. However, this is not a problem as long as the target
of the link is not world-writable, which is checked by the above find command.
World-Writable directories with sticky bit such as the /tmp directory do not allow anyone except the owner of a file to delete or modify it in this directory. The sticky bit makes files stick to the user who created it and it prevents other users from deleting and renaming the files. Therefore, depending on the purpose of the directory world-writable directories with sticky are usually not an issue. An example is the /tmp directory:
World-Writable directories with sticky bit such as the /tmp directory do not allow anyone except the owner of a file to delete or modify it in this directory. The sticky bit makes files stick to the user who created it and it prevents other users from deleting and renaming the files. Therefore, depending on the purpose of the directory world-writable directories with sticky are usually not an issue. An example is the /tmp directory:
$
ls -ld /tmp
drwxrwxrwt
18 root root 16384 Dec 23 22:20 /tmp
The
"t" mode, which denotes the sticky bit, allows files to be deleted
and renamed only if the user is the owner of this file or the owner of the
directory.
Unowned Files
Files not owned by any user or group might not necessarily be a security problem in itself. However, unowned files could pose a security problem in the future. For example, if a new user is created and the new users happens to get the same UID as the unowned files have, then this new user will automatically become the owner of these files.
To locate files not owned by any user or group, use the following command:
Unowned Files
Files not owned by any user or group might not necessarily be a security problem in itself. However, unowned files could pose a security problem in the future. For example, if a new user is created and the new users happens to get the same UID as the unowned files have, then this new user will automatically become the owner of these files.
To locate files not owned by any user or group, use the following command:
find
/ -path /proc -prune -o -nouser -o -nogroup
Checking
Accounts
Checking
for Unlocked Accounts
It is important that all system and vendor accounts that are not used for logins are locked.
To get a list of unlocked accounts on your system, you can check for accounts that do NOT have an encrypted password string starting with "!" or "*" in the /etc/shadow file. If you lock an account using passwd -l, it will put a '!!' in front of the encrypted password, effectively disabling the password. If you lock an account using usermod -L, it will put a '!' in front of the encrypted password. Many system and shared accounts are usually locked by default by having a '*' or '!!' in the password field which renders the encrypted password into an invalid string.
Hence, to get a list of all unlocked (encryptable) accounts, run:
It is important that all system and vendor accounts that are not used for logins are locked.
To get a list of unlocked accounts on your system, you can check for accounts that do NOT have an encrypted password string starting with "!" or "*" in the /etc/shadow file. If you lock an account using passwd -l, it will put a '!!' in front of the encrypted password, effectively disabling the password. If you lock an account using usermod -L, it will put a '!' in front of the encrypted password. Many system and shared accounts are usually locked by default by having a '*' or '!!' in the password field which renders the encrypted password into an invalid string.
Hence, to get a list of all unlocked (encryptable) accounts, run:
#
egrep -v '.*:\*|:\!' /etc/shadow | awk -F: '{print
$1}'
Also
make sure all accounts have a 'x' in the password field in /etc/passwd. The
following command lists all accounts that do not have a 'x' in the password
field:
#
grep -v ':x:' /etc/passwd
A
'x' in the password fields means that the password has been shadowed, i.e. the
encrypted password has to be looked up in the /etc/shadow file. If the password
field in /etc/passwd is empty, then the system will not lookup the shadow file
and it will not prompt the user for a password at the login prompt.
Checking for Unused Accounts
All system or vendor accounts that are not being used by users, applications, by the system or by daemons should be removed from the system. You can use the following command to find out if there are any files owned by a specific account:
Checking for Unused Accounts
All system or vendor accounts that are not being used by users, applications, by the system or by daemons should be removed from the system. You can use the following command to find out if there are any files owned by a specific account:
#
find / -path /proc -prune -o -user <account> -ls
The
-prune option in this example is used to skip the /proc filesystem.
If you are sure that an account can be deleted, you can remove the account using the following command:
If you are sure that an account can be deleted, you can remove the account using the following command:
#
userdel -r <account>
Without
the "-r" option userdel will not delete the user's home directory and
mail spool (/var/spool/mail/<user>). Note that many system accounts have
no home directory.
Single User Mode Password for root
Some admins suggest to add the following line to the /etc/inittab file to ensure that a root password is required for Single User Mode logons:
Single User Mode Password for root
Some admins suggest to add the following line to the /etc/inittab file to ensure that a root password is required for Single User Mode logons:
~~:S:wait:/sbin/sulogin
This
works but can be circumvented easily!
At the GRUB or LILO prompt you can tell the boot loader to alternate the init
program by using the boot params "init=/bin/bash". This will place
you at a root shell prompt without a password.
Enabling
Password Aging
In
general I do not recommend that the system enforces password expiration for
system and shared accounts. This could lead to outages if an application's
account expires:
#
su oracle -c id
You
are required to change your password immediately (password aged)
Changing
password for test
(current)
UNIX password:
Rather
a corporate policy should govern password changes for system and shared
accounts. But for individual user accounts the system should expire the
passwords automatically. The following example shows how password expiration
can be setup for individual user accounts.
The following files and parameters in the table are used when a new account is created with the useradd command. These settings are recorded for each user account in the /etc/shadow file. Therefore, make sure to configure the following parameters before you create any user accounts using the useradd command:
The following files and parameters in the table are used when a new account is created with the useradd command. These settings are recorded for each user account in the /etc/shadow file. Therefore, make sure to configure the following parameters before you create any user accounts using the useradd command:
/etc/login.defs
|
PASS_MAX_DAYS
|
60
|
Maximum
number of days a password is valid.
|
/etc/login.defs
|
PASS_MIN_DAYS
|
7
|
Minimum
number of days before a user can change the password since the last change.
|
/etc/login.defs
|
PASS_MIN_LEN
|
n/a
|
This
parameter does not work. It is superseded by the PAM module
"pam_cracklib".
|
/etc/login.defs
|
PASS_WARN_AGE
|
7
|
Number
of days when the password change reminder starts.
|
/etc/default/useradd
|
INACTIVE
|
14
|
Number
of days after password expiration that account is disabled.
|
/etc/default/useradd
|
EXPIRE
|
Account
expiration date in the format YYYY-MM-DD.
|
Ensure that the above parameters are changed in the /etc/login.defs and /etc/default/useradd files.
When a user account is created using the useradd command, the parameters listed in the above table are recorded in the /etc/shadow file in the following fields:
<username>:<password>:<date>:PASS_MIN_DAYS:PASS_MAX_DAYS:PASS_WARN_AGE:INACTIVE:EXPIRE:
To
create a new user account you can execute the following command:
useradd
-c "Test User" -g users test
The
-g option specifies the primary group for this account:
#
id test
uid=509(test)
gid=100(users) groups=100(users)
The
settings in /etc/login.defs and /etc/default/useradd are recorded for the test
user in the /etc/shadow file as follows:
#
grep test /etc/shadow
test:!!:12742:7:60:7:14::
You
can change the password aging any time using the chage command.
To disable password aging for system and shared accounts, you can run the following chage command:
To disable password aging for system and shared accounts, you can run the following chage command:
#
chage -M 99999 <system_account_name>
To
get password expiration information:
#
chage -l <system_account_name>
For
example:
#
chage -l test
Minimum:
7
Maximum:
60
Warning:
7
Inactive:
14
Last
Change: Jan
11, 2005
Password
Expires: Mar 12, 2005
Password
Inactive: Mar 26, 2005
Account
Expires: Never
Enforcing
Stronger Passwords
Practical Considerations
On an audited system it is important to restrict people from using simple passwords that can be cracked too easily. However, if the passwords being enforced are too strong, people will write them down. Strong passwords that are written down are not much safer than weak passwords. Some will argue that strong passwords protect you against e.g. Dictionary Attacks and you can defeat it by locking the accounts after a few failed attempts. However, this is not always an option
Undoubtedly, it is important to practise safe password management. In my opinion, a password should have at least one digit number, one other character, and one upper case letter. But keep in mind not to make it overly complicated.
How to Enforce Stronger Passwords
The pam_cracklib module checks the password against dictionary words and other constraints. Unfortunately, however, the original Linux PAM module pam_cracklib uses a credit mechanism. E.g. if you define password length minlen=10, then you will get 1 credit for e.g. using a single digit number in your password if you defined dredit=1. This means that pam_cracklib will accept a password of the length of minlen-credit. If you don't use a digit number, then the minimum length of the password would be minlen. There was no way to tell the module that a password _must_ include a digit number.
Back in 2000 I wrote a patch for the pam_cracklib module where you can assign negative values to the pam_cracklib parameters lcredit, ucredit, dcredit, and ocredit. Using negative values will disable the credit mechanism. For example, if you define dredit=-1, then the module will only accept a password if it includes at least one digit number and if the password has a length of at least minlen.
Red Hat has finally applied my pam_cracklib patch and you don't have to patch the pam_cracklib module any more. The new pam_cracklib feature works in Red Hat Enterprise Linux 4 and Red Hat Fedora Core 3. This feature is now also included with the Red Hat Enterprise Linux 3 Update 4 and Red Hat Enterprise Linux 2.1 Update 6 release. If the Linux distribution you are using does not use the patched pam_cracklib module yet, you can find the procedure for patching pam_cracklib
In the following example I'll assume that you are using the new pam_cracklib module, or that you patched the module if your Linux distribution doesn't include the patched version yet.
The following example shows how to enforce the following password rules:
- Minimum length of password must be 8
- Minimum number of lower case letters must be 1
- Minimum number of upper case letters must be 1
- Minimum number of digits must be 1
- Minimum number of other characters must be 1
On an audited system it is important to restrict people from using simple passwords that can be cracked too easily. However, if the passwords being enforced are too strong, people will write them down. Strong passwords that are written down are not much safer than weak passwords. Some will argue that strong passwords protect you against e.g. Dictionary Attacks and you can defeat it by locking the accounts after a few failed attempts. However, this is not always an option
Undoubtedly, it is important to practise safe password management. In my opinion, a password should have at least one digit number, one other character, and one upper case letter. But keep in mind not to make it overly complicated.
How to Enforce Stronger Passwords
The pam_cracklib module checks the password against dictionary words and other constraints. Unfortunately, however, the original Linux PAM module pam_cracklib uses a credit mechanism. E.g. if you define password length minlen=10, then you will get 1 credit for e.g. using a single digit number in your password if you defined dredit=1. This means that pam_cracklib will accept a password of the length of minlen-credit. If you don't use a digit number, then the minimum length of the password would be minlen. There was no way to tell the module that a password _must_ include a digit number.
Back in 2000 I wrote a patch for the pam_cracklib module where you can assign negative values to the pam_cracklib parameters lcredit, ucredit, dcredit, and ocredit. Using negative values will disable the credit mechanism. For example, if you define dredit=-1, then the module will only accept a password if it includes at least one digit number and if the password has a length of at least minlen.
Red Hat has finally applied my pam_cracklib patch and you don't have to patch the pam_cracklib module any more. The new pam_cracklib feature works in Red Hat Enterprise Linux 4 and Red Hat Fedora Core 3. This feature is now also included with the Red Hat Enterprise Linux 3 Update 4 and Red Hat Enterprise Linux 2.1 Update 6 release. If the Linux distribution you are using does not use the patched pam_cracklib module yet, you can find the procedure for patching pam_cracklib
In the following example I'll assume that you are using the new pam_cracklib module, or that you patched the module if your Linux distribution doesn't include the patched version yet.
The following example shows how to enforce the following password rules:
- Minimum length of password must be 8
- Minimum number of lower case letters must be 1
- Minimum number of upper case letters must be 1
- Minimum number of digits must be 1
- Minimum number of other characters must be 1
pam_cracklib.so
|
minlen=8
|
Minimum
length of password is 8
|
pam_cracklib.so
|
lcredit=-1
|
Minimum
number of lower case letters is 1
|
pam_cracklib.so
|
ucredit=-1
|
Minimum
number of upper case letters is 1
|
pam_cracklib.so
|
dcredit=-1
|
Minimum
number of digits is 1
|
pam_cracklib.so
|
ocredit=-1
|
Minimum
number of other characters is 1
|
To setup these password restrictions, edit the /etc/pam.d/system-auth file and add/change the following pam_cracklib arguments highlighted in blue:
auth
required /lib/security/$ISA/pam_env.so
auth
sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth
required /lib/security/$ISA/pam_deny.so
account
required /lib/security/$ISA/pam_unix.so
account
sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100
quiet
account
required /lib/security/$ISA/pam_permit.so
password
requisite /lib/security/$ISA/pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1
password
sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok
md5 shadow
password
required /lib/security/$ISA/pam_deny.so
session
required /lib/security/$ISA/pam_limits.so
session
required /lib/security/$ISA/pam_unix.so
Now
verify that the new password restrictions work for new passwords. Simply login
to a non-root account and change the password using the passwd command. Note
that the above requirements are not enforced if you run the passwd command
under root.
NOTE: The /etc/pam.d/system-auth PAM configuration file is auto-generated and contains records which dictate a generic authentication scheme. Keep in mind that authconfig might clobber some changes you made. Since I never run authconfig I usually make changes to this file because it's used by many PAM aware applications. Otherwise I'd have to make changes to many configuration files. Changing system-auth is usually the preferred method. You might even want to disable all execution bits from the /usr/sbin/authconfig binary to prevent authconfig from clobbering your changes.
NOTE: The /etc/pam.d/system-auth PAM configuration file is auto-generated and contains records which dictate a generic authentication scheme. Keep in mind that authconfig might clobber some changes you made. Since I never run authconfig I usually make changes to this file because it's used by many PAM aware applications. Otherwise I'd have to make changes to many configuration files. Changing system-auth is usually the preferred method. You might even want to disable all execution bits from the /usr/sbin/authconfig binary to prevent authconfig from clobbering your changes.
Restricting Use of Previous Passwords
The
pam_unix module parameter remember can be used to configure the number of
previous passwords that cannot be reused. And the pam_cracklib module parameter
difok can be used to specify the number of characters hat must be different
between the old and the new password.
In the following example I will show how to tell the system that a password cannot be reused for at least 6 months and that at least 3 characters must be different between the old and new password.
Remember that in the article Enabling Password Aging we set PASS_MIN_DAYS to 7, which specifies the minimum number of days allowed between password changes. Hence, if we tell pam_unix to remember 26 passwords, then the previously used passwords cannot be reused for at least 6 months (26*7 days).
Here is an example. Edit the /etc/pam.d/system-auth file and add/change the following pam_cracklib and pam_unix arguments:
In the following example I will show how to tell the system that a password cannot be reused for at least 6 months and that at least 3 characters must be different between the old and new password.
Remember that in the article Enabling Password Aging we set PASS_MIN_DAYS to 7, which specifies the minimum number of days allowed between password changes. Hence, if we tell pam_unix to remember 26 passwords, then the previously used passwords cannot be reused for at least 6 months (26*7 days).
Here is an example. Edit the /etc/pam.d/system-auth file and add/change the following pam_cracklib and pam_unix arguments:
auth
required /lib/security/$ISA/pam_env.so
auth
sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth
required /lib/security/$ISA/pam_deny.so
account
required /lib/security/$ISA/pam_unix.so
account
sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100
quiet
account
required /lib/security/$ISA/pam_permit.so
password quisite /lib/security/$ISA/pam_cracklib.so retry=3
minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 difok=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok
md5 shadow remember=26
password
required /lib/security/$ISA/pam_deny.so
session
required /lib/security/$ISA/pam_limits.so
session
required /lib/security/$ISA/pam_unix.so
NOTE:
If the /etc/security/opasswd doesn't exist, create the file.
If the /etc/security/opasswd doesn't exist, create the file.
#
ls -l /etc/security/opasswd
-rw-------
1 root root 0 Dec 8 06:54 /etc/security/opasswd
Locking User Accounts After Too Many Login Failures
I
do not recommend that the system automatically locks system and shared accounts
after too many failed login or su attempts. This could lead to outages if the
application's account gets locked due to too many login failures like in this
example:
#
su oracle -c id
su:
incorrect password
This
could be an easy target for a denial of service attack. At Restricting
Direct Login Access for System and Shared Accounts I will show how to
disable direct logins for system or shared accounts.
In the following example I will show how to lock only individual user accounts after too many failed su or login attempts.
Add the following two lines highlighted in blue to the /etc/pam.d/system-auth file as shown below:
In the following example I will show how to lock only individual user accounts after too many failed su or login attempts.
Add the following two lines highlighted in blue to the /etc/pam.d/system-auth file as shown below:
auth
required /lib/security/$ISA/pam_env.so
auth
required /lib/security/$ISA/pam_tally.so
onerr=fail no_magic_root
auth
sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth
required /lib/security/$ISA/pam_deny.so
account
required /lib/security/$ISA/pam_unix.so
account
required /lib/security/$ISA/pam_tally.so per_user
deny=5 no_magic_root reset
account
sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100
quiet
account
required /lib/security/$ISA/pam_permit.so
password
requisite /lib/security/$ISA/pam_cracklib.so retry=3
password
sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok
md5 shadow
password
required /lib/security/$ISA/pam_deny.so
session
required /lib/security/$ISA/pam_limits.so
session
required /lib/security/$ISA/pam_unix.so
The
first added line counts failed login and failed su attempts for each user. The
default location for attempted accesses is recorded in /var/log/faillog.
The second added line specifies to lock accounts automatically after 5 failed login or su attempts (deny=5). The counter will be reset to 0 (reset) on successful entry if deny=n was not exceeded. But you don't want system or shared accounts to be locked after too many login failures (denial of service attack). To exempt system and shared accounts from the deny=n parameter, I added the per_user parameter to the module. The per_user parameter instructs the module NOT to use the deny=n limit for accounts where the maximum number of login failures is set explicitly. For example:
The second added line specifies to lock accounts automatically after 5 failed login or su attempts (deny=5). The counter will be reset to 0 (reset) on successful entry if deny=n was not exceeded. But you don't want system or shared accounts to be locked after too many login failures (denial of service attack). To exempt system and shared accounts from the deny=n parameter, I added the per_user parameter to the module. The per_user parameter instructs the module NOT to use the deny=n limit for accounts where the maximum number of login failures is set explicitly. For example:
#
faillog -u oracle -m -1
#
faillog -u oracle
Username
Failures Maximum Latest
oracle
0 -1 Fri Dec 10 23:57:55 -0600 2005
on unknown
The
faillog command with the option "-m -1" has the effect of not placing
a limit on the number of failed logins. To instruct the module to activate the
deny=n limit for this account again, run:
#
faillog -u oracle -m 0
By
default, the maximum number of login failures for each account is set to 0
which instructs pam_tally to use the deny=n parameter. The faillog manual page
on my Red Hat system says that selecting maximum number of login failures of 0
will deactivate deny=n for the account. The PAM documentation, however, says
that per_user will only work if the .fail_max field contains a non-zero value.
After testing both values setting it to -1 worked. Maybe because it's read as a
high unsigned value?
To see failed login attempts, run:
To see failed login attempts, run:
#
faillog
To
unlock an account after too many login failures, run:
#
faillog -u <user> -r
Make
sure to test these changes thoroughly on your system using e.g. ssh and su, and
make sure root does not get locked!
To lock/unlock accounts manually, you can run one of the following commands:
To lock/unlock accounts manually, you can run one of the following commands:
#
passwd -l <user>
#
usermod -L <user>
#
passwd -u <user>
#
usermod -U <user>
NOTE:
Since the /var/log/faillog is owned by root and only root can write to the /var/log/faillog file, xscreensaver and vlock won't work correctly. Each time xscreensaver or vlock is executed as a non-root user, you won't be able to do an unlock since these programs can't write to /var/log/faillog. I don't have a good solution for that. I can only think of setting the SUID bits on these programs.
Since the /var/log/faillog is owned by root and only root can write to the /var/log/faillog file, xscreensaver and vlock won't work correctly. Each time xscreensaver or vlock is executed as a non-root user, you won't be able to do an unlock since these programs can't write to /var/log/faillog. I don't have a good solution for that. I can only think of setting the SUID bits on these programs.
Restricting Direct Login Access for System and Shared
Accounts
On
an audited production system it is very important to know who switched to which
system or shared account. Therefore it is prudent to restrict direct logins for
all system and shared account where more than one individual knows the
password. All users should do a direct login using their own account and then
switch to the system or shared account.
However, there are situations where you have to allow direct logins for system or shared accounts. For example, within an Oracle RAC cluster you have to enable direct ssh logins for oracle. But in such an environment you have to protect the whole cluster as a single entity against incoming ssh connection, i.e. direct oracle logins should not work if you come from a node that is not part of the cluster. In the following example I will show how to achieve this goal as well.
Usually all system and shared accounts have one thing in common, that is they are not in the "users" group. The following example assumes that all individual user accounts are in the "users" group but system and shared accounts like root and oracle are not. If you want to go a step further, a good solution would be to implement a new 'logingroup' users group which would require users to be given explicit access.
In this example I will show how to restrict direct logins for:
However, there are situations where you have to allow direct logins for system or shared accounts. For example, within an Oracle RAC cluster you have to enable direct ssh logins for oracle. But in such an environment you have to protect the whole cluster as a single entity against incoming ssh connection, i.e. direct oracle logins should not work if you come from a node that is not part of the cluster. In the following example I will show how to achieve this goal as well.
Usually all system and shared accounts have one thing in common, that is they are not in the "users" group. The following example assumes that all individual user accounts are in the "users" group but system and shared accounts like root and oracle are not. If you want to go a step further, a good solution would be to implement a new 'logingroup' users group which would require users to be given explicit access.
In this example I will show how to restrict direct logins for:
-
SSH
(/etc/pam.d/sshd)
-
Console Login
(/etc/pam.d/login)
-
Graphical Gnome Login (/etc/pam.d/gdm
-
or for all logins (/etc/pam.d/system-auth)
To
accomplish this goal I will add the pam_access module to the PAM configuration
files listed above. This module provides logdaemon-style login access control
based on login names, host names, IP addresses, etc. The PAM module type that
has to be used in the configuration files is account. This module type does the
authorization, i.e. is the user allowed to login (e.g. time, day)? Don't
confuse the PAM module type account with auth which does the authentication,
for example checking the password. And the control flag I will use is required.
It specifies that Success is required, Failure means that it will still call
the remaining modules, but the result is already determined.
For SSH Logins add the pam_access module to /etc/pam.d/sshd as follows:
For SSH Logins add the pam_access module to /etc/pam.d/sshd as follows:
auth
required pam_stack.so service=system-auth
auth
required pam_nologin.so
account
required pam_access.so
account
required pam_stack.so service=system-auth
password
required pam_stack.so service=system-auth
session
required pam_stack.so service=system-auth
For
Console Logins add the pam_access module to /etc/pam.d/login as follows:
auth
required pam_securetty.so
auth
required pam_stack.so service=system-auth
auth
required pam_nologin.so
account
required pam_access.so
account
required pam_stack.so service=system-auth
password
required pam_stack.so service=system-auth
session
required pam_selinux.so close
session
required pam_stack.so service=system-auth
session
optional pam_console.so
session
required pam_selinux.so multiple open
For
Graphical Gnome Logins add the pam_access module to /etc/pam.d/gdm as
follows:
auth
required pam_env.so
auth
required pam_stack.so service=system-auth
auth
required pam_nologin.so
account
required pam_access.so
account
required pam_stack.so service=system-auth
password
required pam_stack.so service=system-auth
session
required pam_stack.so service=system-auth
session
optional pam_console.so
Now
add the following line to the /etc/security/access.conf configuration file:
-:ALL
EXCEPT users :ALL
The
/etc/security/access.conf configuration file is read by the pam_access module.
This entry specifies that no users are accepted except users that are in the
"users" group. Since the pam_access module has been configured for
"Authorization" (account) in the above PAM configuration files, it
denies direct logins for all accounts except the ones that are in the
"users" group.
Now on some systems like Oracle RAC clusters you have to enable direct ssh logins for oracle within the cluster. On such systems you can enable direct ssh logins for oracle within the cluster by adding/changing the following lines in /etc/security/access.conf:
Now on some systems like Oracle RAC clusters you have to enable direct ssh logins for oracle within the cluster. On such systems you can enable direct ssh logins for oracle within the cluster by adding/changing the following lines in /etc/security/access.conf:
-:ALL
EXCEPT users oracle:ALL
-:oracle:ALL
EXCEPT test1cluster.example.com test2cluster.example.com test3cluster.example.com
The
first line has been edited to include the oracle account which will allow
general direct logins. However, the second line specifies that direct logins
for oracle are only allowed from Oracle RAC nodes (test1cluster, test2cluster,
and test3cluster) that are part of the cluster.
NOTE:
In RHEL4 pam_access is already configured for crond:
NOTE:
In RHEL4 pam_access is already configured for crond:
#
grep pam_access /etc/pam.d/*
/etc/pam.d/crond:account
required pam_access.so accessfile=/etc/security/access-cron.conf
#
This
means that the above entries in /etc/security/access.conf will stop cron from
working. Note that it is very prudent to always check whether pam_access is
configured for any other service on the system!
To ensure that all users on the system can still run cron jobs you can add the following argument to pam_access in /etc/pam.d/crond:
To ensure that all users on the system can still run cron jobs you can add the following argument to pam_access in /etc/pam.d/crond:
account
required pam_access.so accessfile=/etc/security/access-cron.conf
This
ensures that the /etc/security/access.conf configuration file is not invoked by
crond. Since pam_cracklib does not grant permissions if the configuration file
does not exist, execute the following command to create an empty file:
#
touch /etc/security/access-cron.conf
Now
verify that cron jobs can be launched by any user on the system.
NOTE:
The above example will only work if there exists no "users" account in the /etc/passwd file on the system, which is usually the case. Otherwise you have to either delete the "users" account or you have to designate or create another group name.
NOTE:
The above example will only work if there exists no "users" account in the /etc/passwd file on the system, which is usually the case. Otherwise you have to either delete the "users" account or you have to designate or create another group name.
Restricting su Access to System and Shared Accounts
This
chapter shows how to restrict people from su-ing to system and shared accounts
even if they know the passwords.
Users usually don't share the passwords of their own accounts but are less hesitant to share it for shared accounts. This chapter helps to mitigate this problem.
The following example shows how to restrict su access to the root, oracle, and postgres account to a specific set of users.
NOTE: The documentation about the pam_wheel module included in many Linux distributions is wrong. For instance, in Red Hat Advanced Server 2.1 the pam_wheel module does not only restrict people from su-ing to the root account like it used to be. It restricts people from su-ing to any account.
Example for Restricting su Access to root, oracle, and postgres Accounts
Create a new group for each set of users that are allowed to su to the root, oracle, and postgres account:
Users usually don't share the passwords of their own accounts but are less hesitant to share it for shared accounts. This chapter helps to mitigate this problem.
The following example shows how to restrict su access to the root, oracle, and postgres account to a specific set of users.
NOTE: The documentation about the pam_wheel module included in many Linux distributions is wrong. For instance, in Red Hat Advanced Server 2.1 the pam_wheel module does not only restrict people from su-ing to the root account like it used to be. It restricts people from su-ing to any account.
Example for Restricting su Access to root, oracle, and postgres Accounts
Create a new group for each set of users that are allowed to su to the root, oracle, and postgres account:
#
groupadd rootmembers
#
groupadd oraclemembers
#
groupadd postgresmembers
Add
all users who are allowed to su to the root, oracle, and postgres account to
the new member groups created above.
The following requirement will be configured:
- Only admin1 should be able to su to root, oracle, and postgres.
- Only oracledba1 should be able to su to oracle.
- Only postgresdba1 should be able to su to postgres.
- No one else on the system should be able to su to any account.
The following requirement will be configured:
- Only admin1 should be able to su to root, oracle, and postgres.
- Only oracledba1 should be able to su to oracle.
- Only postgresdba1 should be able to su to postgres.
- No one else on the system should be able to su to any account.
#
usermod -G rootmembers adminuser1
#
usermod -G oraclemembers oracleuser1
#
usermod -G postgresmembers postgresuser1
As
you probably noted, I did not add adminuser1 to the other member groups.
Instead, I will show how to give people in the rootmembers group automatically
su access to the oracle and postgres account without adding them to the
oraclemembers and postgresmembers groups. I consider root admins an exception.
They should not be added to all member groups on the system.
Next add the three authentication lines highlighted in blue to the /etc/pam.d/su file as shown below:
Next add the three authentication lines highlighted in blue to the /etc/pam.d/su file as shown below:
auth
sufficient /lib/security/$ISA/pam_rootok.so
auth
required /lib/security/$ISA/pam_stack.so
service=system-auth
auth
sufficient /lib/security/$ISA/pam_stack.so service=su-root-members
auth
sufficient /lib/security/$ISA/pam_stack.so service=su-other-members
auth
required /lib/security/$ISA/pam_deny.so
account
required /lib/security/$ISA/pam_stack.so
service=system-auth
password
required /lib/security/$ISA/pam_stack.so
service=system-auth
session
required /lib/security/$ISA/pam_selinux.so close
session
required /lib/security/$ISA/pam_stack.so
service=system-auth
session
required /lib/security/$ISA/pam_selinux.so open
multiple
session
optional /lib/security/$ISA/pam_xauth.so
These
additional authentication lines specify that nobody should be able to su
to any account unless at least one of the PAM services, su-root-members
or su-other-members, returns Success. The control flag sufficient means that a
Success will bypass the remaining authentication modules and overall Success is
returned for the authentication part. Failure means that the failed
authentication PAM service is ignored. If both authentication PAM services
fail, then the last authentication module pam_deny is invoked which will deny
all requests for any available authentication module. This will cause the
authentication part to fail for the su command.
Next the new authentication PAM service configuration files /etc/pam.d/su-root-members and /etc/pam.d/su-other-members need to be created.
The file /etc/pam.d/su-root-members referenced in /etc/pam.d/su should read like:
Next the new authentication PAM service configuration files /etc/pam.d/su-root-members and /etc/pam.d/su-other-members need to be created.
The file /etc/pam.d/su-root-members referenced in /etc/pam.d/su should read like:
auth
required /lib/security/pam_wheel.so use_uid group=rootmembers
auth
required /lib/security/pam_listfile.so item=user
sense=allow onerr=fail file=/etc/security/su-rootmembers-access
The
file /etc/security/su-rootmembers-access referenced in
/etc/pam.d/su-root-members should read like:
root
oracle
postgres
The
control flag required which is specified for both modules means that both
modules have to return Success. Otherwise this PAM service will return Failure
to the "su" PAM service configured in /etc/pam.d/su. The first line
returns Success only if the user is in the rootmembers groups. The second line
allows only access (sense=allow) to those users specified in
/etc/security/rootusername, which is root, oracle, and postgres - these are the
only users that will be accepted as a user argument to su. The item=user
argument instructs pam_listfile that the entries in /etc/security/rootusername
are usernames. If an error occurs, such as an unreadable configuration file,
access is denied (onerr=fail).
NOTE: Once su access to root is working for users in the rootmembers, I recommend to avoid making any changes to the /etc/pam.d/su-root-members file in the future. Making a mistake in this file could revoke access to root for all users on the system. That's the reason why I created two PAM service files, /etc/pam.d/su-root-members for people in the rootmembers group, and /etc/pam.d/su-other-members (see below) for all other member groups since you will most probably add more member groups to this file in the future.
Next the file /etc/pam.d/su-other-members referenced in /etc/pam.d/su should be created and read like:
NOTE: Once su access to root is working for users in the rootmembers, I recommend to avoid making any changes to the /etc/pam.d/su-root-members file in the future. Making a mistake in this file could revoke access to root for all users on the system. That's the reason why I created two PAM service files, /etc/pam.d/su-root-members for people in the rootmembers group, and /etc/pam.d/su-other-members (see below) for all other member groups since you will most probably add more member groups to this file in the future.
Next the file /etc/pam.d/su-other-members referenced in /etc/pam.d/su should be created and read like:
auth
sufficient /lib/security/pam_stack.so service=su-oracle-members
auth
sufficient /lib/security/pam_stack.so service=su-postgres-members
auth
required /lib/security/pam_deny.so
If
one of the two PAM services returns Success, it will return Success to the
"su" PAM service configured in /etc/pam.d/su. Otherwise the last
module will be invoked which will deny all further requests and the
authentication fails.
Next the PAM services "su-oracle-members" and "su-postgres-members" have to be created.
The file /etc/pam.d/su-oracle-members referenced in /etc/pam.d/su-other-members should read like:
Next the PAM services "su-oracle-members" and "su-postgres-members" have to be created.
The file /etc/pam.d/su-oracle-members referenced in /etc/pam.d/su-other-members should read like:
auth
required /lib/security/pam_wheel.so use_uid group=oraclemembers
auth
required /lib/security/pam_listfile.so item=user sense=allow
onerr=fail file=/etc/security/su-oraclemembers-access
The
file /etc/security/su-oraclemembers-access referenced in
/etc/pam.d/su-oracle-members should read like:
oracle
The
file /etc/pam.d/su-postgres-members referenced in /etc/pam.d/su-other-members
should read like:
auth
required /lib/security/pam_wheel.so use_uid group=postgresmembers
auth
required /lib/security/pam_listfile.so item=user
sense=allow onerr=fail file=/etc/security/su-postgresmembers-access
The
file /etc/security/su-postgresmembers-access referenced in
/etc/pam.d/su-postgres-members should read like:
postgres
Now verify that adminuser1 can su to root, oracle, and postgres. No one else should be able to su to root. oracleuser1 should be able to su to oracle only, and postgresuser1 should be able to su to postgres only. No one else on the system should be able su to any of these accounts even if they know the password.
Preventing Accidental Denial of Service
General
Linux allows you to set limits on the amount of system resources that users and groups can use. This is also very handy if bugs in programs accidentally use up too much resources, slow down the machine, or even render the system unusable. I've seen systems where incorrect settings have allowed programs to use up too much resources which made the server unresponsible for new connections or local logins (e.g. a program uses up all file handles on the system). This could become a security issue if someone is allowed to use up all resources and causes a denial of service attack. Depending on your environment you may want to review resource limits for user accounts and groups.
Example for Restricting System Resources
The following example shows a practical use of setting or restricting system resources for an Oracle user account. For a list of system resource settings, see /etc/security/limits.conf. It would be a good idea to review the default settings of system resource.
Most shells like Bash provide control over various resources like the maximum allowable number of open file descriptors or the maximum number of processes available to a user. To see all shell limits, run:
Linux allows you to set limits on the amount of system resources that users and groups can use. This is also very handy if bugs in programs accidentally use up too much resources, slow down the machine, or even render the system unusable. I've seen systems where incorrect settings have allowed programs to use up too much resources which made the server unresponsible for new connections or local logins (e.g. a program uses up all file handles on the system). This could become a security issue if someone is allowed to use up all resources and causes a denial of service attack. Depending on your environment you may want to review resource limits for user accounts and groups.
Example for Restricting System Resources
The following example shows a practical use of setting or restricting system resources for an Oracle user account. For a list of system resource settings, see /etc/security/limits.conf. It would be a good idea to review the default settings of system resource.
Most shells like Bash provide control over various resources like the maximum allowable number of open file descriptors or the maximum number of processes available to a user. To see all shell limits, run:
ulimit
-a
For
more information on ulimit for the Bash shell, see man bash and search for
ulimit.
Important Note:
Setting "hard" and "soft" limits in the following examples might not work properly when you login to oracle using a SSH session. It should work if you log in as root and su to oracle. Resource limits should also work if the application is started automatically during the boot process. But if you experience the problem that the changed resource limits in /etc/security/limits.conf are not applied when logging in through SSH, then you may have to try to set UsePrivilegeSeparation in /etc/ssh/sshd_config to "no" and restart the SSH daemon by executing /etc/init.d/sshd restart. Unfortunately, privilege separation does not work properly with PAM on some Linux distributions. But also note that turning off privilege separation is not really recommended since it's a valuable security feature that has already prevented exploitation of SSH vulnerabilities.
For example, to change the number of file handles or open files that the Oracle user can use, you have to edit the file /etc/security/limits.conf as root and make the following changes or add the following lines, respectively:
Important Note:
Setting "hard" and "soft" limits in the following examples might not work properly when you login to oracle using a SSH session. It should work if you log in as root and su to oracle. Resource limits should also work if the application is started automatically during the boot process. But if you experience the problem that the changed resource limits in /etc/security/limits.conf are not applied when logging in through SSH, then you may have to try to set UsePrivilegeSeparation in /etc/ssh/sshd_config to "no" and restart the SSH daemon by executing /etc/init.d/sshd restart. Unfortunately, privilege separation does not work properly with PAM on some Linux distributions. But also note that turning off privilege separation is not really recommended since it's a valuable security feature that has already prevented exploitation of SSH vulnerabilities.
For example, to change the number of file handles or open files that the Oracle user can use, you have to edit the file /etc/security/limits.conf as root and make the following changes or add the following lines, respectively:
oracle
soft nofile
4096
oracle
hard
nofile 63536
The
"soft limit" in the first line defines the number of file handles or
open files that the Oracle user will have after login. If the Oracle user gets
error messages about running out of file handles, then the Oracle user can
increase the number of file handles like in this example up to 63536
("hard limit") by running the following command:
ulimit
-n 63536
You
can set the "soft" and "hard" limits higher if necessary. Note
that I do not recommend to set the "hard" limit for nofile for the
oracle user equal to /proc/sys/fs/file-max. If you do that and the oracle user
uses up all the file handles, then the whole system will be out of file
handles. This could mean that you won't be able to initiate new remote logins
any more since the system won't be able to open any PAM modules which are
required for performing a login.
You also need to ensure that pam_limits is configured in the file /etc/pam.d/system-auth, or in /etc/pam.d/sshd (for SSH), /etc/pam.d/su (for su), or /etc/pam.d/login (local logins and telnet) if you don't want to enable it for all logins, or if /etc/pam.d/system-auth does not exist like on SUSE. This is the PAM module that will read the /etc/security/limits.conf file. The entry should read like:
You also need to ensure that pam_limits is configured in the file /etc/pam.d/system-auth, or in /etc/pam.d/sshd (for SSH), /etc/pam.d/su (for su), or /etc/pam.d/login (local logins and telnet) if you don't want to enable it for all logins, or if /etc/pam.d/system-auth does not exist like on SUSE. This is the PAM module that will read the /etc/security/limits.conf file. The entry should read like:
session
required /lib/security/pam_limits.so
Here
are the two "session" entries I have in my /etc/pam.d/system-auth
file:
session
required /lib/security/pam_limits.so
session
required /lib/security/pam_unix.so
Now
login to the oracle account again since the changes will become effective for
new login sessions only.
$
su - oracle
$
ulimit -n
4096
$
Note
that the ulimit options are different for other shells.
The default limit for oracle is now 4096 and the oracle user can increase the number of file handles up to 63536:
The default limit for oracle is now 4096 and the oracle user can increase the number of file handles up to 63536:
$
su - oracle
$
ulimit -n
4096
$
ulimit -n 63536
$
ulimit -n
63536
$
To
make this change permanent, add "ulimit -n 63536" (for Bash) to the
~oracle/.bash_profile file which is the user startup file for the Bash shell on
Red Hat Linux (to verify your shell run: echo $SHELL).
To do this you could simply copy/paste the following commands for the oracle's
Bash shell:
su
- oracle
cat
>> ~oracle/.bash_profile << EOF
ulimit
-n 63536
EOF
Displaying
Login Banners
It
is prudent to place a legal banner on login screens on all servers for legal
reasons and to potentially deter intruders among other things. Consult legal
counsel for the content of the banner.
If you want to print a legal banner after a user logs in using ssh, local console etc., you can use the /etc/motd file. Create the file if it doesn't exist and type in the banner that applies to your organization.
If you want to print a legal banner after a user logs in using ssh, local console etc., you can use the /etc/motd file. Create the file if it doesn't exist and type in the banner that applies to your organization.
#
cat /etc/motd
This
system is classified...
Use
of this system constitutes consent to official monitoring.
#
For
SSH you can edit the Banner parameter in the /etc/ssh/sshd_config file which
will display the banner before the login prompt.
For local console logins you can edit the /etc/issue which will display the banner before the login prompt.
For GDM you could make the following changes to require a user to acknowledge the legal banner by selecting 'Yes' or 'No'. Edit the /etc/X11/gdm/PreSession/Default file and add the following lines at the beginning of the script:
For local console logins you can edit the /etc/issue which will display the banner before the login prompt.
For GDM you could make the following changes to require a user to acknowledge the legal banner by selecting 'Yes' or 'No'. Edit the /etc/X11/gdm/PreSession/Default file and add the following lines at the beginning of the script:
if
! gdialog --yesno '\nThis system is classified...\n' 10 10; then
sleep 10
exit 1;
fi
You
have to add a sleep of 10 seconds, otherwise GDM will believe that X crashed if
the session lasted less than 10 seconds. Unfortunately, at the time of this
writing the 10 seconds timeout is hardcoded and there is no configuration parameter
to change it - I checked the source code.
Before you put a server into production or better, before you put a server on the network, you should have an integrity checker installed on your system that lets you check if unauthorized changes have been made. In this way, if an intruder compromises your system you will know what changed on your server. You should also have an Intrusion Detection Software (IDS) solution in place that alarms you about intrusions, as well as Intrusion Prevention software.
It is outside the scope of this article to cover Linux Monitoring and Intrusion Detection solutions. There are lots of interesting articles out there to read and there are several good products available on the market including open source solutions. For a powerful open source network-intrusion prevention and detection system, see Securing your system with Snort.
Connect Accounting Utilities
Here is a list of commands you can use to get data about user logins:
who Shows a listing of currently logged-in users.
w Shows who is logged on and what they are doing.
last Shows a list of last logged-in users, including login time, logout time, login IP address, etc.
lastb Same as last, except that by default it shows a log of the file /var/log/btmp, which contains all the bad login attempts.
lastlog This command reports data maintained in /var/log/lastlog, which is a record of the last time a user logged in.
ac Prints out the connect time in hours on a per-user basis or daily basis etc. This command reads /var/log/wtmp.
dump-utmp Converts raw data from /var/run/utmp or /var/log/wtmp into ASCII-parsable format.
Also check the /var/log/messages file.
Other
The following items may not necessarily be Linux security related but should be configured correctly on all audited Linux systems:
- Resolver (/etc/hosts, /etc/resolv.conf, /etc/nsswitch.conf)
- NTP (/etc/ntp.conf)
Linux PAM
Documentation
Linux System Security
Nine principles of security architecture
Securing & Optimizing Linux
Smarter Password Management
Network Intrusion Detection
SELinux - NSA's Open Source Security Enhanced Linux
Note that this document comes without warranty of any kind. But every effort has been made to provide the information as accurate as possible. I welcome emails from any readers with comments, suggestions, and corrections at webmaster_at admin@linuxhowto.in
Copyright © 2012 LINUXHOWTO.IN
Linux System Security
Nine principles of security architecture
Securing & Optimizing Linux
Smarter Password Management
Network Intrusion Detection
SELinux - NSA's Open Source Security Enhanced Linux
Note that this document comes without warranty of any kind. But every effort has been made to provide the information as accurate as possible. I welcome emails from any readers with comments, suggestions, and corrections at webmaster_at admin@linuxhowto.in
Copyright © 2012 LINUXHOWTO.IN
No comments:
Post a Comment