Looking for some security advice!
Hey slackers, fellow subgenius here. :D
Anyways, I'll tell this short story why this post is here, then the detail of my question. Bare with my mild rant.
Used slack back in 04-05 etc. And loved it's ways. I felt like I was in control on a deeper level; however, (I'm not here to bash a different distro, but now that Ubuntu has become what it is, I honestly feel it's made me stupid in regards to the core of Linux control)
04-10 releases changed, and the OS kept getting a 'new' look. It just had the same name, and frankly, I've had enough of it. I kept that as short as possible from years of exposure to Ubuntu.. So...
I'm coming back to be a slackmaster and I'm sure Ivan Stang would be proud.
My initial question:
I am interested in some good OS lock down tips/urls, etc that can help me get back on my feet to a secure slack. I miss the days of my Bob Dobbs Screensaver, and I honestly feel like a nub again thanks to the other distro I mentioned.
you can use Alien Bob's slackware firewall generator to make a firewall. It's really simple. after you have the firewall generated you save it save as "rc.firewall" and save it in "/etc/rc.d" and make it executable using "chmod +x rc.firewall" and it will automatically be launched at bootup.
And always follow security update packages from the official changelogs.
I would like to add the following tutorial by Jeffrey Denton (I believe).
It is a bit dense - and slightly out of date in places. But I found lots of useful little bits for tightening things up.
- 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.
Welcome to LQ & Slackware!
Look at 'Security' section of 'Slackware-Links' .
Just a few more useful links;
Linux Documentation Project
Rute Tutorial & Exposition
Linux Command Guide
Bash Reference Manual
Advanced Bash-Scripting Guide
Linux Newbie Admin Guide
Getting Started with Linux
The above links and others can be found at 'Slackware-Links' . More than just SlackwareŽ links!
After a bit of tweaking and setups, It's up and running now. Thank you to you all, and the firewall is running great. :D
No issues, the slackware I remember.
|All times are GMT -5. The time now is 01:30 AM.|