Intro to securing Free BSD Part 2
This is the second tutorial in my new series of Free BSD. Most of this is for passwords and I think it's pretty cool, and I of course have another planned as this is only the very tip of it. The next one I do is going to have things like Telnet and SSH, and Kerberos, and other things.
If you find anything here that is wrong, PLEASE let me know. I'd rather look like an ass, than be part of a problem known as misinformation. I learned pretty much everything about Free BSD security from two books:
The Complete Free BSD
Free BSD Unleashed.
I didn't copy and paste anything as I typed this all by hand and I wasn't copying, but I did learn this from those two books which I've recommended to people for the last 2 years.
Intro to securing Free BSD Part 2
# = root prompt
Password Policies -
If your users have insecure passwords, which is very likely, other security precautions you put in place are probably not going to work as well as they could or should.
Being a Free BSD admin isn't always easy. The only thing you can do to fight this problem is to make a password policy. This should make your users use passwords that can't be guessed easy.
Users look at password policies the same way they look at most things: "It's only making my job harder". When you tell users not to make passwords easy, they generally won't listen, and use passwords like "Password" or something like their usernames.
If you choose to make passwords expire, most users either try to use the same password, or they may just add something to the same password. They don't want to and for some reason seem to have it in their heads that they don't need to, have a great password.
This is something you could of course rectify by getting into their account and sending their boss email from them telling him he's a crap eater, but that's a bit of fun...
Convenience makes security nothing, and security makes convenience go away as well. You have one but not the other. Most users don't understand or care about security at all.
When a user chooses a new password using the passwd command, a few loose checks are performed. By default passwords in Free BSD must be at least 6 charachters, but that is about the only thing stopping a user from using less.
Learn to use the login.conf program to set a minimum password length and require periodic updates in "forcing password expiration" which I can talk about a little more.
Ensuring secure passwords with Crack -
The first step in maintaining a password security policy with users is to stop users from using bad passwords in the first place. One way of doing this is to try and guess passwords yourself.
A tool called Crack is in ports and can be used to try and crack the passwords for you which should weed out the easily guessed ones. If crack cracks any passwords you should contact those users and get them to adhere to the password rules you've set.
Or change their password for them into something that looks like audible line noise.
To use the crack program :
cd /usr/local/crack
# ./Crack -fmt bsd /etc/master.passwd
Crack then does a few things to set itself up and then it goes.
If you want to check what it found:
# ./Reporter -quiet
***Passwords cracked so far***
138138138:Guessed luser [BadPassword] Luser Abuser [/etc/master.passwd /bin/tcsh]
---- done ----
Crack reports only the users whose passwords it cracked.
Once you're done using Crack, put the pipe away... Get it? Pipe? LOL... OK anyway, when you're all done, clean up the files with these two commands:
# make tidy
# rm run/F-merged
Forcing Password Expiration -
By default passwords in Free BSD do not expire. One common part of a secure password policy is to require users to change their passwords every s often.
To do this in Free BSD:
Edit /etc/login.conf
This file controls system things like how many processes, the maximum allowed process size... Lots of stuff.
Each of the controls here can be assigned a class of users.You can assign users to classes with the chfn command.Users aren'tn associated with any particular class so that makes it true that the values in the default class apply to everybody:
default:\
:passwd_format=md5:\
:copyright=/etc/COPYRIGHT:\
:welcome=... etc etc etc
I'm not going to type out all of these but that shows you the top.
the backslashes "escape" the line breaks, allowing you to specify all these properties on different lines trying to keep the file actually readable.
To set a password expiration date you put an extra line into default which you should add at the top for ease of editing:
default:\
:passwordime=138d:\
:passwordformat=md5:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
This tells it to expire passwords after 138 days. You can use more than just days though, 2w would be 2 weeks, 3y would be 3 years and 12h would be 12 hours.
default:\
:passwordime=138w:\
:passwordformat=md5:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
This would be 138 weeks.
I don't recommend this, but you should at least every 2 months if you don't get attacks in, and if you're in a business setting, or govt setting, every month at least.
Now, because /etc/login.conf is a database that must be compiled into a hash table (as with the tables in /etc/mail, which you would use if you were admin for a Sendmail system, in which you have my sympathy), you must run the cap_mkdb program to generate the hash table and enable your changes:
# cap_mkdb /etc/login.conf
From now on the log in procedure will require users to choose a new password every X number of days where X = whatever you set it to.
Another thing I recommend you do while you're editing this:
:minpasswordlen=12:\
Add that to default, and now the minimum password length on the system is 12 Characters. It's not to bad really making a password that good. Be lucky you're not on MY systems where I am root, for passwords are bigger than my mouth. Minimum password length on my FTP server is 15 and if I can crack it, I rm -rf /home/you.
TheHorse recently made a post to AntiOnline with a study he was perorming on users who write down passwords if they are to hard to remember. This itself could be a tutorial and I've probably posted this information before, but making a good password that's VERY hard to crack is actually quite easy.
Making a good password -
A common misconception is that if you make a password out of an actual word, it's OK as long as you change the characters to leet speak. For example:
imleetyo
This is a bad password, and someone using it probably needs smacked....With a brick...In the face...Twice.
But a person on AO said in the QuickiTip contest that this was a good idea, taking normal words, changing them, and using it as a password. So the bad password I just showed, would become:
1M1337y0
That could seem like a nice password at first... But most password crackers actually have that in their arsenal. They take words to crack like fish, and try f1sh too. So that makes choosing passwords like this fairly bad.
The best way I know of, is by using things you like and making a password out of a sentence and some dates. Now, I need to point out, that if you did ONE of these only, it's not good. If you make a password a date, that can be guessed, but mix that with a sentence using only the first or last letters of each word, and you have a good password.
The Misfits are the best band on Earth and created their first album in 1977. One of there songs is called We Are 138.
The Misfits
1977
We Are 138
By taking the first and last letter of each word there, you have:
TeMs17WeAe138
Now THAT is a password.
If you like James Bond, it's easy as well:
James Bond is code name 007.
JsBdisceNe07
Passwords like this can stop attackers from getting in easier.
Now if you're some Yuppie who likes Sum41, well that's OK too.
Sum41 suck ass and every 12 year old now thinks spiked hair makes you a punk.
Sm41skAsadey12yRodNwtssdhrmsyuapnk
Another good password.
Initial passwords -
When you're setting up a new user account, a lot of people seem to make passwords like "Changeme" or "temp123" or "Icouldn'tGetaGoodJob" or "Changethis".
This itself is bad enough but what if one of your users stopped imitating a paper weight one day and realised you use the same temp password for EVERY new account?
I know I for one would do a few things to make a point of how bad this is. There is of course more to this than shown, like this:
# md5 -s "oiwjedoijwedoijrvi"
This is another way in creating a new password. You can use the first letters in the string it gives you as the new user's password. This can be done with a small PERL script as well, using an MD5 hash on the output of rand() to generate a new password.
One time passwords with S/Key -
This is something you'd find in a Govt situation where passwords and good authentication are a must.
S/Key allows you to assign one time passwords to your users. With this comes a responcibility. The security burden is now on the user's shoulders.
The idea here is that each user gets a set of passwords or a way to generate them as needed, and, they are only valid log in passwords for ONE log in. Meaning after someone logs in with that passwd, it's not useable anymore.
The key program is what generates the passwords. Pretty much any platform has a way of doing this.
When a user tries logging on, the server pops up with a "challenge" phrase, and a number.
The user then uses the key program to generate a password which only works for THIS login. The password is never used again.
Every time a user logs in they must do this and enter the new number as the new password for every log in.
All in all, you could transmit your password in clear text without a worry, it's not like anyone could use it.
Example:
What if you had a user named "Luser" and you didn't want them to log in with a Unix passwd remotely. Well, S/Key;
# Keyinit
Adding Luser:
Reminder - Only use this method if you are directly connected.
Blah Blah Blah
Enter Secret Password:
Again secret Password:
ID Luser s/key is 99 st28077
COL APT...
If User is not securely connected to the server as with Telenet, they should use keyinit -s. Without the -s, keyinit incorporates the key program into it's own operation... The User enters in the the secret key generating password, which should NOT be the same as the Unix pass, and which is only used for claculating the one time password, and it is transmitted over the net to the server.
Not to be done over something like Telnet as the thing can be grabbed by a sniffer. The -s makes the key local.
After this is done, and a log in in /etc/skeykeys, you must create the file /etc/skey.access if it's not there already and add the following line:
deny user LuserName
The /etc/skey.access file tells Free BSD when a remote user is allowed to use their Unix password, and when to use S/Key to get on.
A line in skey.access specifies a rule begining with permit allowing the Unix or S/Key password. You can add as many conditions as you want.
Type man skey.access for more, mainly all because I'm just not typing all those conditions.
The deny user luser above denies the user from using a Unix password.
Another nice feature of S/Key comes with su. This way Root passwds won't be over the network.
