May 22nd, 2005, 12:28 PM
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 :
# ./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:
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:
: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:
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.
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:
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:
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:
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.
We Are 138
By taking the first and last letter of each word there, you have:
Now THAT is a password.
If you like James Bond, it's easy as well:
James Bond is code name 007.
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.
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.
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;
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
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.
May 22nd, 2005, 11:29 PM
Thank you Gore. I love learning about BSD,and this is great info! I am strugling with FreeBSD, and finally have started reading the FreeBSD Handbook.
May 24th, 2005, 01:14 AM
If only there was an easier while more comprehensive way to create a password policy... for example just clicking a textbox that says "enforce password complexity requirements" or something like that. With another box to set minimum password length, days until expiration, and perhaps the number of passwords a user can have before they can repeat an old one... and maybe just for good measure a box that allows the admin to set the minimum password age so that users can't bypass the old password checks to keep their password the same.
*cries* If only such a system existed! */cries*
All that aside, don't you think that password complexity requirements are a little obsolete these days? For example, if my password is "xxxxxx", sure it might be broken by a password cracker in no time... however how will the attacker gain access to the hash? Either the attacker has gained complete physical access to the system or the user has already gained at least administrative control over the system. Intelligently designed systems will have a limit on the number of incorrect login attempts a user can make. What are the odds of an attacker guessing "xxxxxx" in the first three to five attempts?
I just think that the days of requiring complicated passwords is near its end.
May 24th, 2005, 01:47 AM
Well Catch, a whole new area of authentication is going to probably be used sometime. If you think about it a password is just security by obscurity. When someone finds out about it, it's no longer secure. And security by obscurity rarely works, hell there is a quci tip about it.
I think you agree with me there.
Most users however don't have the money or any way to use anything else though such as bio stuff. You know me though, I'm a *N*X Elitist and believe it to be superior to other OSs.
Heh, Xenix was Unix, Microsoft sold that before buying DOS (Didn't the guy who wrote DOS work for Microsoft?]
I know you like some Unix, we have argued over this quite a bit, heh, probably should have done it on the forums, would have been a pretty good discussion.
I have a few questions for you:
NT is no longer supported and God knows there are more security flaws left in it. Do you think 2000 ir 2003 are better? What about XP? I know my personal fav is Server 2003. It's fast, stable, and all around a decent system I used as a desktop (I just don't think Windows is good for a server OS, any OS that has Worms should not be). That's not a shot at Microsoft or Their software, I just feel if you need to reboot for a patch, you really shouldn't use it for mission critical apps.
Heh, if you were setting up a Mission Critical server that had to be up a lot, and needed to be secure against attacks, what would you choose and how would you set it up? You know me, I'd pick SUSE Enterprise.
I have a few more tutorials I'm going to do on this secure Free BSD part and then I'm not sure after that. As long as I have Vicodin and time, I can pump out a couple more, and maybe do some more Linux security stuff, and, well, if I can, some Unix stuff and maybe even something on NTFS.
The paper I've been working on "OS" I'm goign to do a bit on ACLs for Unix and things on, but if you want, you can add some on NTs method and I'll give you credit for it, or if you want to have some friendly competition (I'm not worried about flame wars, I consider you a good friend who won't actually resort to name calling or similar if we do this) I think it would be cool.
You and me, and hell maybe we could get some other member involved. I'm sure TheHorse13 could add some good things, and a few others here, and maybe if it works well The guys can make it another AO give away contest. (I can vouge that they do send you what you have won, and that the things you buy from the AO store are in fact high quality. That coffee cup alone is worth 20 dollars and isn't even that high priced.)
How about it man?
May 24th, 2005, 01:54 AM
Or they came about it through something silly like an SQL injection or XSS redirect. But yeah one would hope admins aren't using the the same passwords in their web apps as they are their administrative software.
Either the attacker has gained complete physical access to the system or the user has already gained at least administrative control over the system.
wow my comment wasn't even remotely relevant... we're talking OS's
May 24th, 2005, 02:28 AM
I've always like 2000 more than NT4. I have not really had too much time with 2003 yet, no reason to upgrade professionally yet and too lazy to at home so far. I've yet to touch XP, so I couldn't say.
NT is no longer supported and God knows there are more security flaws left in it. Do you think 2000 ir 2003 are better? What about XP?
You never actually need to reboot when patching, that aside all mission critical applications should be run on clustered systems so rebooting doesn't matter anyhow.
I just feel if you need to reboot for a patch, you really shouldn't use it for mission critical apps.
Well, it really depends on the system requirements, but assuming a pretty generic commercial server I'd use a Win2k cluster.
Heh, if you were setting up a Mission Critical server that had to be up a lot, and needed to be secure against attacks, what would you choose and how would you set it up?
As far as the papers, I've actually been busy looking for a new job (want to relocate) but keep me posted and I'll see how much time I have.
If the attacker is able to compromise the password hashes in such a manner, this would indicate that they have relevant system (or subsystem) administrative access, which is what I said.
Or they came about it through something silly like an SQL injection or XSS redirect.
May 24th, 2005, 07:20 PM
what if the big bad budget wolf says no clusters though? And when would you personally deploy a Unix based OS over a Windows one? And what about Mac OS Server? I've never actually heard of many using that outside of a few military things. And mac's home page.
It took me a while to reply I'm trying to think fo what classes to take this semester so I can finish. If anyone reading this is in Port Huron, and you work for a college MAKE MORE UNIX AND SECURITY RELATED CLASSES!
I've aced everything my school has to offer except like two classes.
May 24th, 2005, 07:30 PM
Then tell the big bad budget wolf s/he isn't getting the 99.999% availability s/he so desparately needs
Originally posted here by gore
what if the big bad budget wolf says no clusters though?
Experience is something you don't get until just after you need it.
May 24th, 2005, 07:34 PM
Hehe, I get the 5 9s on my LAN and I give it a pretty good sized load, which is saying something because my FTP box alone which is SUSE 9.2... Well I download and upload to it all at once and it has yet to ever say stop it. I've done more than 20 GBs in one 5 hour period when I was doing my back ups (That box has a fast Cd burner so I upload back ups to that machine then do a K3B ).
May 24th, 2005, 07:43 PM
I still know nothing about BSD .... still damn ignorant ..... I guess it would help me once I get into BSD .... anyone says otherwise?
Cheers for the tut.
\"The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts\".....Spaf
Everytime I learn a new thing, I discover how ignorant I am.- ... Black Cluster