LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 03-02-2005, 05:35 AM   #1
ddaas
Member
 
Registered: Oct 2004
Location: Romania
Distribution: Ubuntu server, FreeBsd
Posts: 474

Rep: Reputation: 30
security checklist


Hi ,
I've made a security checklist for my linux server (it runs in an Enterprise Environment).
What do you think? Do I miss something?




General Security Policies/Procedures

1. Use strong passwords (min. 6 chars, no dictionary words)
2. Eliminate unused accounts, delete well-known accounts that are not needed
3. Make sure default file protections for newly created files do not allow group/world read/write access by using a "umask" value of 022, 027, or 077, especially on the root account
4. Set appropriate file permissions on all files
5. Do not allow direct root login
6. Write-protect the "root" account's startup files and home directory
7. Do not place the current directory (".") in your (especially root's) search path
8. Do not use root account on a regular basis
9. Do not allow set-user-id or set-group-id shell scripts on the system
10. Do not mount remote filesystems with root rw access from the local system. ro access would be enough.
11. Set the "sticky" bit on any world-writable directories
12. Ensure the appropriate permission modes are set on devices in the /dev directory
13. Install an antivirus software and an IDS. Update daily the virus definitions and IDS definitions.
Ex: - ClamAV
- SNORT
- TrimWire
14. Implement a firewall (IPTABLES)
15. Monitor the firewall and its logs
16. Make backups and test them
17. Check your systems for unauthorized use of a network monitoring program
18. Allow SSH access only from a pool of IPs, and from a group of users. Do not allow root login.
19. Install latest patches
20. Verify the digital signature of every installing program or patch
21. Only a list of knows computers should be allowed to access the network and communicate with the servers (L2 authentication)
22. Bios password for the server
23. Physical access should be restricted to the server area


Regular Tasks

24. Audit account security on regular basis with tools like cops
25. Check logs on regular basis (every day). Logging all services and send summary on mail.
26. chkrootkit on a regular basis
27. Check for disk usage
28. Check for ports running
29. Examine the /etc/passwd file and search for 0 UID
30. Check for running services and close unneeded services
31. Check the system for altered binaries
32. Check all "nonstandard" set-user-id and set-group-id programs for security
find / -user root -perm -4000
find / -group kmem -perm -2000
33. receives security bulletins and notes from organizations like CIAC and CERT
 
Old 03-02-2005, 05:53 AM   #2
Engmar
Member
 
Registered: Oct 2003
Location: The Forest
Distribution: Ubuntu, LFS, DSL
Posts: 127

Rep: Reputation: 16
Pretty comprehensive list. Does this server have a cdrom? If so, the only thing I saw not listed was to remove the drive/change boot device order in the bios.
 
Old 03-02-2005, 07:00 AM   #3
ddaas
Member
 
Registered: Oct 2004
Location: Romania
Distribution: Ubuntu server, FreeBsd
Posts: 474

Original Poster
Rep: Reputation: 30
You are right.
I forgot about the cdrom.
 
Old 06-16-2005, 07:43 AM   #4
geletine
Member
 
Registered: Apr 2005
Distribution: Slackware
Posts: 213
Blog Entries: 2

Rep: Reputation: 30
is it posible to monitor users files there use or browse and execute?
i know you can check failed logins, i am interested if you can check failed executive or other access.
i think vms does, surely *nix should.

Another question, is it possible to disable login for users after failed logins , failed executive and view(conf files etc...) attemps automatically ?


i guess anything is possible..
 
Old 06-16-2005, 02:17 PM   #5
Dr. Psy
Member
 
Registered: May 2005
Distribution: Slackware 10.1
Posts: 49

Rep: Reputation: 15
I see you mentioned 'restrict physical access' to the server area. However, not knowing exactly what that means in your situation, don't forget that if you have LILO installed, it needs to be made readable only to root [chmod 600 /etc/lilo.conf] and chattr +i /etc/lilo.conf. Also use a password in LILO by adding password=password.

If it is not password protected, any user can gain root access through physically shutting down/rebooting the system and entering

[label] init=/bin/sh (bringing the system up in 'rescue mode')
mount -oremount [root partition] (mounting the system as root)

If you password protect LILO and leave it readable to others, the file contains the password in plain text, making password protection pointless.

I'm sure you know this already as you are obviously familiar with Linux and security but thought I would mention it nonetheless.

If not of help to you, then perhaps someone else.
 
Old 06-16-2005, 02:31 PM   #6
ddaas
Member
 
Registered: Oct 2004
Location: Romania
Distribution: Ubuntu server, FreeBsd
Posts: 474

Original Poster
Rep: Reputation: 30
you are right. Having the boot loader password protected is very important.

Good advice !
 
Old 06-16-2005, 02:39 PM   #7
Shade
Senior Member
 
Registered: Mar 2003
Location: Burke, VA
Distribution: RHEL, Slackware, Ubuntu, Fedora
Posts: 1,418
Blog Entries: 1

Rep: Reputation: 46
Quote:
9. Do not allow set-user-id or set-group-id shell scripts on the system
By default, linux does not allow SUID shell scripts. Binaries are allowed, SUID scripts will not run.

--Shade
 
Old 06-16-2005, 08:59 PM   #8
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
if you are using a password on your server's bootloader then if the server is rebooted you'll be driving across town to the office to type-in the boot password... IMHO, the recommended thing to do as far as the bootloader on a server is concerned is simply to make sure it doesn't prompt - this way a person wouldn't be able to do stupid stuff by entering parameters, like boot into runlevel 1, for example...
 
Old 06-17-2005, 06:36 AM   #9
geletine
Member
 
Registered: Apr 2005
Distribution: Slackware
Posts: 213
Blog Entries: 2

Rep: Reputation: 30
lastcomm and acctcom is a good solution to monitor users executed commands.

if a user tries to execute a command she/he knows he cannot access more than once, is it possible to log them out and disable there account automatically?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
slack server checklist babyphil Slackware - Installation 8 06-14-2005 01:39 PM
Security checklist Dogit Linux - Security 6 02-25-2005 03:38 PM
vpn checklist sanw2k Linux - Networking 1 10-20-2003 04:28 AM
system checklist LLS Linux - Security 1 09-29-2003 01:32 PM
Security CheckList miso Linux - Security 4 11-25-2002 05:23 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 02:41 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration