Tuesday, December 20, 2016

Controlling User Access III

Implementing a Strong Password Policy


Another serious security weakness I’ve observed over the years is the
use of weak passwords. A weak password is one that can be easily
guessed or cracked. Here are some examples:



• Your last name
• Your spouse’s name
• Your mother’s maiden name
• Your child’s name
• Your birthday
• Your pet’s name
• Any word that can be found in the dictionary
• Using “password” for your password
• Single-character passwords
• Blank passwords



You would be surprised how often users use these types of passwords.
Not good! You need to train your users to use stronger passwords. A
strong password uses


• Six or more characters (the longer the better!) • A combination of
   numbers and letters

• Upper- and lowercase letters

• Words not found in the dictionary

• (Optionally) non-alphanumeric characters such as punctuation marks




For example, a password such as M3n0v3l273 is a relatively strong
password because it meets the preceding criteria. The password
management utilities that come with most Linux distributions are
configured by default to check your user passwords to make sure they
meet the criteria for strong passwords. For example, if you try to use
a weak password with the passwd command, you are prompted to use a
stronger one, as shown here:



openSUSE:~ # passwd ksanders
New Password:BAD PASSWORD: it is WAY too short
BAD PASSWORD: is too simple
Retype new password:




In addition to using strong passwords, you should also configure your
user accounts such that passwords expire after a certain period of
time. This is called password aging. Why age passwords? The longer a
user has the same password, the more likely it is to be compromised.
By forcing users to periodically rotate passwords, you keep intruders
guessing. Even if they do manage to get a user’s password, it will be
rendered useless at some point. The length of time allowed for a given
password varies from organization to organization. More
security-minded organizations may mandate a password age of 30 days or
less. Less paranoid organizations may use an age of 60 or even 90
days.




You can configure aging for your passwords using the



chage 


command.


The syntax for using chage is



chage option user



You use the following options with chage:



• –m days


Specifies the minimum number of days between password changes


–M days

Specifies the maximum number of days between password changes


–W days


Specifies the number of warning days before a password change is required




For example, in Figure 17-4, the chage command has been used to
specify a minimum password age of five days, a maximum password age of
90 days, and seven warning days for the ksanders user.




In addition, your Linux systems should not be configured to store
passwords within the /etc/ passwd file.



Many processes running in a Linux system need access to /etc/passwd to complete 
various tasks.


Storing your passwords in that file exposes them to these processes
and opens a serious security hole. Most system implementers realize
that storing passwords within /etc/passwd is a very bad idea, so you
probably won’t run into many systems configured this way anymore.



However, if you do run into such a system, you can use the



pwconv



command to move user passwords out of /etc/passwd and into 


/etc/shadow.




You should also train your users to use good common sense when working
with passwords.



One security breach I see all too often is users writing their
password on a sticky note and sticking it somewhere on their desk.


I’ve even seen system passwords written on a sticky note right on the
monitor or keyboard. I know the thought of passwords written down and
displayed in plain sight makes you cringe, but I see it over and over
and over. Some users try to hide their sticky note under the keyboard
or in a drawer, but it’s still a significant security issue. All the
intruder has to do is watch the user at login and note where she has
hidden her password, making his job a cakewalk. We had a recent issue
at my child’s middle school where this very thing happened. The
attendance secretary kept her password on a sticky note next to her
keyboard. A student noticed this and, one day after school, logged in
to her computer and used the school’s attendance tracking software to
send out automated prank phone calls to the parents of all students in
the school. This “exploit” was fairly innocuous, but it gives you an
idea of just how easy it is to defeat the most complex security
systems if users write down their passwords and leave the note in
plain sight.




The “sticky note phenomenon” is yet another reason for enforcing good
physical security. A ne’er-do-well can gain easy access to corporate
information using a password that’s posted in plain sight. Once done,
it can be very difficult to trace the breach back to the intruder.
Finally, you should train your users how to deal with social
engineering attempts. This is actually one of the easiest and most
effective tools in the intruder’s toolbox. Social engineering exploits
human weaknesses instead of technical weaknesses in the system. Here’s
how a typical social engineering exploit works.




The intruder calls an employee of an organization posing as another
employee. The intruder tells the employee that he is “Fred” from Sales
and is on the road at a client site. He needs to get a very important
file from the server and can’t remember his password. He then asks the
employee if he can use their password “just this once” to get the
files he needs.




Most employees want to be team players and help out in an emergency.
They are all too willing to hand out their password, granting the
intruder easy access to the system. Some social engineering attempts
are less direct. Instead of calling and asking for passwords, the
intruder sifts through the company garbage looking for little yellow
sticky notes with users’ passwords written on them. Some social engineering
attempts are more “in your face.” The intruder sifts through the trash to
find the name of a high-ranking person in the company. He then calls an
employee posing as that person and demands that the employee divulge their
password, threatening to fire them if they don’t comply. Pretty sneaky, huh?




In addition, you need to be diligent against the flood of phishing
e-mails that have been plaguing organizations for the last several
years. Phishing e-mails are drafted such that they appear to have come
from a legitimate organization, such as a bank, social media, or
e-commerce website. They convince the user to click a link that takes
them to a malicious website where they are tricked into revealing
sensitive information.




Phishing emails are a low-tech but very popular exploit because they
are extremely successful. This type of attack has resulted in
devastating security breaches on the part of several large
corporations in recent years. All they take to be successful is a
handful of employees who are unwise enough to open the message and
follow the instructions therein.




To detect phishing e-mails, you need to learn to recognize several key
characteristics. They may look legitimate, but there are several key
attributes that identify them as a scam. For example, it’s common for
the source address of the message to not match the domain of the
company it claims to be coming from.


In addition, the message typically tries to create a sense of urgency.
For example, it may warn that your bank account will be frozen, that your
credit card has been stolen, or even that you will be subject to arrest if you
don’t follow the instructions in the message. The key giveaway is the fact
that the hyperlinks in the message go to websites that are not associated with
the organization the message claims to be coming from. If you hover
your mouse over a link (without clicking it) you can see where the
link actually leads. If it isn’t pointing to the organization’s URL,
there’s a pretty good chance the message is an exploit.




The best way to combat social engineering is to, again, train your
users. Teach them to not write down passwords. Teach them to not throw
sensitive data in the trash—shred it instead! Teach them about social
engineering phone calls and how to deal with them. Most organizations
simply tell their employees to forward any calls asking for a password
to the help desk (that’s you). Chances are, all they will hear is a
click on the other end. Teach them how to recognize a phishing e-mail
and how to respond properly.








LX0-104 Exam Objectives (V and U, 323, 647 - 689)

No comments:

Post a Comment