DaemonForums  

Go Back   DaemonForums > FreeBSD > FreeBSD Security

FreeBSD Security Securing FreeBSD.

Reply
 
Thread Tools Display Modes
Old 16th May 2008
anomie's Avatar
anomie anomie is offline
Local
 
Join Date: Apr 2008
Location: Texas
Posts: 445
Default

Quote:
Originally Posted by starbuck
Does flagging the logs as "sappend" prevent them from being rotated? How do you get around this?
Yes, it does. You could remove the flag, then rotate the logs, then re-add the flag. But then that would imply that you're running in a securelevel < 1 (which somewhat defeats the purpose of the file flag if root can just remove it ).

So the real answer is that your log file will be growing indefinitely (until you take the steps to temporarily get to a lower securelevel and manually rotate it).

If you haven't already, check out the manpages for security(7) and chflags(1). There is a good book I reviewed here that discusses this topic in great detail.
__________________
Kill your t.v.
Reply With Quote
Old 16th May 2008
cajunman4life cajunman4life is offline
Real Name: Aaron Graves
Package Pilot
 
Join Date: May 2008
Location: Coolidge, Arizona
Posts: 203
Default

Yes, using sappend will prevent your logs from being rotated. As for a work-around... I don't know. One must mull the good vs the bad... Having your logs grow to an incredible size (for a medium to heavy load server) but being better poised to "stumble upon" someone evil, or having nice small compressed logs (but potentially not catching the evil person).

As far as secure levels, it's only something I'm beginning to look into. I hope someone else comes along and sheds some more light on this subject...
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident!
Reply With Quote
Old 16th May 2008
coppermine's Avatar
coppermine coppermine is offline
Port Guard
 
Join Date: May 2008
Posts: 40
Default

Quite vast topic. It's better to define some more pronounced direction for discussion, but the presence of this thread is good by itself.

My strategies are:
1) really strong passwords. At least 10 chars with big and small letters + numbers. Any user who actively refuses to obey this, is excluded being possible to login from outside
2) read or at least quickly skim the logs every day
3) before installing any service, I make sure that I really need this. It is worth to put services in DMZs if you have enough free boxes. Good network design to say...
4) frequently make and check the checksums with aide.
5) use sshguard to get rid of ssh login attempts
6) setup firewall with tested enough ruleset
7) whenever I see portaudit complaining about installed package security - I take the time to install it
8) if there are FreeBSD vulnerabilities published - I devote more time and inform the users about planned works.
9) and... the more important changes I am planning to do, I devote even more time to prepare and explore the consequences
10) finally, I use the handwritten journal about any more or less changes done to boxes either in hardware or in software world. It may be boring, but this book-keeping saved me more time in troubleshooting afterwards.
Reply With Quote
Old 16th May 2008
cajunman4life cajunman4life is offline
Real Name: Aaron Graves
Package Pilot
 
Join Date: May 2008
Location: Coolidge, Arizona
Posts: 203
Default

Quote:
Originally Posted by coppermine View Post
Quite vast topic. It's better to define some more pronounced direction for discussion, but the presence of this thread is good by itself.

My strategies are:
1) really strong passwords. At least 10 chars with big and small letters + numbers. Any user who actively refuses to obey this, is excluded being possible to login from outside
2) read or at least quickly skim the logs every day
3) before installing any service, I make sure that I really need this. It is worth to put services in DMZs if you have enough free boxes. Good network design to say...
4) frequently make and check the checksums with aide.
5) use sshguard to get rid of ssh login attempts
6) setup firewall with tested enough ruleset
7) whenever I see portaudit complaining about installed package security - I take the time to install it
8) if there are FreeBSD vulnerabilities published - I devote more time and inform the users about planned works.
9) and... the more important changes I am planning to do, I devote even more time to prepare and explore the consequences
10) finally, I use the handwritten journal about any more or less changes done to boxes either in hardware or in software world. It may be boring, but this book-keeping saved me more time in troubleshooting afterwards.
All very good. As far as a "journal," I've started updating a wiki on the intranet. It may be a bit overkill, but it works.
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident!
Reply With Quote
Old 17th May 2008
anomie's Avatar
anomie anomie is offline
Local
 
Join Date: Apr 2008
Location: Texas
Posts: 445
Default

Quote:
Originally Posted by cajunman4life
As far as a "journal," I've started updating a wiki on the intranet.
Me too. I fired up a wiki (dokuwiki) within a FBSD jail on one of my workstations. Nice way to stay organized.
__________________
Kill your t.v.
Reply With Quote
Old 17th May 2008
cajunman4life cajunman4life is offline
Real Name: Aaron Graves
Package Pilot
 
Join Date: May 2008
Location: Coolidge, Arizona
Posts: 203
Default

Quote:
Originally Posted by anomie View Post
Me too. I fired up a wiki (dokuwiki) within a FBSD jail on one of my workstations. Nice way to stay organized.
Heh, same here... dokuwiki is extremely simple. Extremely nice way to stay organized.
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident!
Reply With Quote
Old 17th May 2008
cajunman4life cajunman4life is offline
Real Name: Aaron Graves
Package Pilot
 
Join Date: May 2008
Location: Coolidge, Arizona
Posts: 203
Default

I just thought of something... do any of you do anything to prohibit things like forkbombs and other simple DoS attacks?

Do not try this command unless you fully know what it does:
Code:
:(){ :|:& };:
For users with bash as their shell (possibly other shells, too tired to try right now) this is a fork bomb. If your system is improperly set up, running this simple command will bring it crashing down to it's knees. I remember trying this on my Gentoo box a few years ago and nearly crying when it crashed.

Point being, this sort of attack is easily thwarted by setting values in /etc/login.conf for each user class (as appropriate). All users on my box are in the default class (except admins, which have a class called sysadmin and belong to group sysadmin), so I set max processes for default class to 20 (can be adjusted based on how many users, if any, notice the change), and set max memory usage. The default on FreeBSD was unlimited... bad idea for most users.

Also, something else... something so simple that I never really would have thought of until I stumbled across this today: http://www.arbornet.org/~cdalten/grep.html

Code:
cat < /dev/zero > /dev/null &
If you run the above command a few times, your system will not be very happy. I don't think this will really "eat resources" like the fork bomb, but the CPU goes to 100% utilization in short order. To counter this effect, set the cputime variable. For my default user class it's 60s (or 1m will have the same effect). For sysadmins it's 1h (a bit more trustworthy group, also one that may have a legitimate reason to be using lots of cpu time), and root is unlimited.

So, how many of you are rushing off to check your /etc/login.conf now?
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident!
Reply With Quote
Old 17th May 2008
harisman's Avatar
harisman harisman is offline
Fdisk Soldier
 
Join Date: May 2008
Location: Hellas (Greece)
Posts: 66
Default

It is a good practice to keep a record about the running processes and the network connections with the ps,sockstat,netstat commands when your system runs at normal conditions.
When something unusual happening, you can compare your findings with those to get an idea.
Reply With Quote
Old 17th May 2008
coppermine's Avatar
coppermine coppermine is offline
Port Guard
 
Join Date: May 2008
Posts: 40
Default

Actually, friend of mine tried to prove FreeBSD inability to stand against fork-bombs. I allowed him to run the fork-bomb as a root written by canjuman4life... result - he was disappointed. Even ran as a root, I cleaned offending processes later with not much slowed down machine.
So, the nice variables available at login.conf are very good to start tightening malicious user activities.

Last edited by coppermine; 17th May 2008 at 06:55 PM.
Reply With Quote
Old 19th June 2008
hopla hopla is offline
New User
 
Join Date: May 2008
Posts: 8
Default

Quote:
Originally Posted by coppermine View Post
1) really strong passwords. At least 10 chars with big and small letters + numbers. Any user who actively refuses to obey this, is excluded being possible to login from outside
I use pam_passwdqc to enforce strong passwords. It's in the base system (man pam_passwdqc).

I enable it by adding this line to /etc/pam.d/sshd (its the 3rd line, the others are already there)

Quote:
# password
#password sufficient pam_krb5.so no_warn try_first_pass
password requisite pam_passwdqc.so enforce=everyone min=disabled,8,8,8,8
password required pam_unix.so no_warn try_first_pass
See the man page for the meaning of the options and more.

And in /etc/adduser.conf I set
Quote:
passwdtype=random
upwexpire=0-0-0
Then when I create a new user I get a random password (by default) I can give to him. And when the user first logs in with it, he must immediately change it since its expired (upwexpire). He can then only change it to a password that is strong enough according to the rules set with pam_passwdqc.

Last edited by hopla; 19th June 2008 at 09:49 AM.
Reply With Quote
Old 19th June 2008
tanked tanked is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 56
Default

Quote:
Originally Posted by hopla View Post
I use pam_passwdqc to enforce strong passwords. It's in the base system (man pam_passwdqc).

I enable it by adding this line to /etc/pam.d/sshd (its the 3rd line, the others are already there)



See the man page for the meaning of the options and more.

And in /etc/adduser.conf I set


Then when I create a new user I get a random password (by default) I can give to him. And when the user first logs in with it, he must immediately change it since its expired (upwexpire). He can then only change it to a password that is strong enough according to the rules set with pam_passwdqc.
Excellent, I never realised something like this was in the base system, I thought I'd have to install 3rd party software to get that functionality.
Reply With Quote
Old 19th June 2008
hopla hopla is offline
New User
 
Join Date: May 2008
Posts: 8
Default

Quote:
Originally Posted by tanked View Post
Excellent, I never realised something like this was in the base system, I thought I'd have to install 3rd party software to get that functionality.
Great, my first post here in the new forum and I already got a 'Thanks' Glad I could help!
Reply With Quote
Old 19th June 2008
cajunman4life cajunman4life is offline
Real Name: Aaron Graves
Package Pilot
 
Join Date: May 2008
Location: Coolidge, Arizona
Posts: 203
Default

I have enabled the same functionality in the base system, without adding extra configs to sshd.

I've also installed and configured Tripwire. Just another layer in the security onion.
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident!
Reply With Quote
Old 20th June 2008
hopla hopla is offline
New User
 
Join Date: May 2008
Posts: 8
Default

Quote:
Originally Posted by cajunman4life View Post
I have enabled the same functionality in the base system, without adding extra configs to sshd.
How have you done that then? By using login.conf settings perhaps? Because I tried those, but never got them to work... The pam_passwdqc also seems more powerfull (not just checking if your password is long enough, but also that it contains X number of different character sets etc)
Reply With Quote
Old 20th June 2008
cajunman4life cajunman4life is offline
Real Name: Aaron Graves
Package Pilot
 
Join Date: May 2008
Location: Coolidge, Arizona
Posts: 203
Default

Quote:
Originally Posted by hopla View Post
How have you done that then? By using login.conf settings perhaps? Because I tried those, but never got them to work... The pam_passwdqc also seems more powerfull (not just checking if your password is long enough, but also that it contains X number of different character sets etc)
Comment out everything in /etc/pam.d/passwd, and place the following lines:

Code:
password        requisite       pam_passwdqc.so         min=disabled,8,8,8,8 retry=3 enforce=everyone
password        required        pam_unix.so             no_warn try_first_pass nullok
And this will enable this functionality in the system without adding anything to sshd_config. This way, no matter how anyone connects (although SSH is the only method I allow right now but that's not the point) they will be held to these rules.

PS - I was never able to get the settings in login.conf for password strength to work either. I read somewhere that they are silently ignored in favor of pam's configuration, and only exist for backwards compatibility.
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident!
Reply With Quote
Old 20th June 2008
anomie's Avatar
anomie anomie is offline
Local
 
Join Date: Apr 2008
Location: Texas
Posts: 445
Default

This PAM password enforcing information would make for a good forum 'Guide'.
__________________
Kill your t.v.
Reply With Quote
Old 20th June 2008
hopla hopla is offline
New User
 
Join Date: May 2008
Posts: 8
Default

Quote:
Originally Posted by cajunman4life View Post
And this will enable this functionality in the system without adding anything to sshd_config. This way, no matter how anyone connects (although SSH is the only method I allow right now but that's not the point) they will be held to these rules.
After close inspection (grep -ri pam_passwdqc /etc/pam.d/) it seems that I have that line added to both /etc/pam.d/sshd AND /etc/pam.d/passwd
So you're saying I can leave out the line in /etc/pam.d/sshd and everything will be exactly the same for me? Got to try that out next monday

Quote:
PS - I was never able to get the settings in login.conf for password strength to work either. I read somewhere that they are silently ignored in favor of pam's configuration, and only exist for backwards compatibility.
Well, that confirms it for me, thanks!

I agree with anomie on the forum guide, even if it was only to divert this discussion away from this thread After my testing on monday, I might just post a guide!
Reply With Quote
Old 20th June 2008
cajunman4life cajunman4life is offline
Real Name: Aaron Graves
Package Pilot
 
Join Date: May 2008
Location: Coolidge, Arizona
Posts: 203
Default

Quote:
Originally Posted by hopla View Post
After close inspection (grep -ri pam_passwdqc /etc/pam.d/) it seems that I have that line added to both /etc/pam.d/sshd AND /etc/pam.d/passwd
So you're saying I can leave out the line in /etc/pam.d/sshd and everything will be exactly the same for me? Got to try that out next monday
You should be able to leave it out of sshd, but now I don't know I don't have it in my sshd, and password enforcing still works... but I don't know how it would be affected by having it (or not). Interesting...

Quote:
Originally Posted by hopla View Post
Well, that confirms it for me, thanks!

I agree with anomie on the forum guide, even if it was only to divert this discussion away from this thread After my testing on monday, I might just post a guide!
Yea, the login.conf thing annoyed me for several days while I tried to figure out why it wasn't working, then I stumbled upon an article somewhere (I wish I saved the link) that explained why it didn't work and what to do to enforce password strength. All was well again.

As to the guide - it'll be a welcome addition
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident!
Reply With Quote
Old 20th June 2008
anomie's Avatar
anomie anomie is offline
Local
 
Join Date: Apr 2008
Location: Texas
Posts: 445
Default

@hopla & @cajunman4life,

This <profane adjective> rocks! I've been researching / testing this for the last hour or so. I love discovering something new in FreeBSD (or Linux) land. I can hardly wait to unleash this upon my users once I'm comfortable with it.

Looking forward to the guide...
__________________
Kill your t.v.
Reply With Quote
Old 20th June 2008
cajunman4life cajunman4life is offline
Real Name: Aaron Graves
Package Pilot
 
Join Date: May 2008
Location: Coolidge, Arizona
Posts: 203
Default

You know, in thinking about this, when I put it in /etc/pam.d/passwd, it changes the way the "passwd" command runs. So any time anyone tries to change their password, this policy is invoked.

What if you use "adduser" to create users on your system?

Most of the time I use vipw to create a user account (using * as password, then run "passwd <username>" to set the password). So it'll be interesting to see... adduser is a shell script so I'll take a look at it when I've got a bit of time (at work presently).
__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident!
Reply With Quote
Reply

Thread Tools
Display Modes

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 On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Basic sshd hardening anomie Guides 12 12th September 2008 03:39 AM
Can I use this link for hardening FreeBSD 7 mfaridi FreeBSD Security 1 9th July 2008 07:35 AM


All times are GMT. The time now is 02:38 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick