Originally Posted by xj25vm
and slightly out of date in places.
Since one line reads "Linux 2.4.32 Last login: Wed Jun 27 20:23:42 -0700 2001 on tty2
", yeah, I'd say it's showing its age. I found it has
- no mention of 'sulogin' in /etc/inittab for runlevel S,
- change mode on cronjobs but no mention of /etc/cron.allow white-listing,
- /etc/rc.d/rc.local: would be easier to populate /etc/ethers with IP-MAC pairs then 'arp -f /etc/ethers' or something,
- /var/spool/cron/crontabs/root "Cron should mail the results to root.
": root should be an alias in /etc/aliases to an unprivileged account a human
reads. (Also see adding user accounts in /etc/mail/aliases instead of a single "root: jdenton" at the end),
- touch /etc/at.allow: "Don't allow anyone to use at.
": no (security) reasons I know of why to deny select
users to use 'at',
- /usr/sbin/httpd: if you use SSL then ensure you deny null and "weak" ciphers (and using a WAF like mod_security wouldn't be bad),
- /etc/login.defs: after you chown'd and chattr'd the hell out of the system, using "NO_PASSWORD_CONSOLE" is a nice way to weaken system security (FFS),
- "ifconfig eth0 mtu 68" (WTF?),
- it doesn't touch HIDS (Samhain, Aide, Integrit, whateverelse) nor NIDS (Snort, Prelude, OSSEC), and
- its iptables rule set is almost nonexistent. While it is not the most terse documentation around, and certainly not adapted to your distribution of choice, I think you could start with worse documents than the "Securing Debian" manual as checklist
. Also it would be beneficial to take a baseline snapshot of a pristine installed OS and then run GNU/Tiger on it for local checks and say OpenVAS for remote ones (or whatever equivalent tool). This way you can test and compare
qualitative changes in security posture which beats just following some recipe without testing results