Security – Page 3 – 2000Trainers.com

Change Your Wireless Router’s Password

The first and most important tip towards securing a wireless network is to change the default password of your access point. When vendors ship these hardware devices, the password to allow full administrator access is almost always very basic examples include “admin”, or even the manufacturer’s name in many cases – and are well documented online. For this reason, you should always assume that if you leave the default password as is, anyone can easily access, control, and configure your access point, allowing them unrestricted access to your network. In fact, without changing the default password for your access points, every other tip in this article is a moot point, since external users could easily connect to and undo or revise any security features you might have implemented.

To that end, some access point hardware provides a configurable option that does not allow access to the administrative console of the device from wireless clients. If your access point supports this feature, you should definitely enable it, thus restricting administrative access to wired connections only.

Security Issues on Wireless Networks

Security in the wired world has typically focused on keeping users from the outside world (the Internet) out of private networks through the implementation of firewalls, both hardware- and software-based. Unfortunately, security issues with wireless networks are much more complex, since it’s typically not users from the Internet who pose the most direct threat. Instead, the biggest risk on a wireless network relates to users within close proximity who can connect to and associated with your internal access points, and from there interact with your network just like any other inside user. In this case, there’s no need for the user to get past any type of firewall – by associating with your access point, they’re already in, connected to the internal network. Scared yet? If not, you should be.

As part of trying to make the implementation and integration of wireless networking equipment as streamlined and straightforward as possible, almost all access point hardware devices ship with the least restrictive security settings possible. In fact, almost all security settings are disabled by default. If the default settings of an access point are left as is, it is exceptionally simple for any external user within range (even with limited know-how) to discover and associate with your access points. Operating systems like Windows XP make it even easier to connect to different wireless networks via their scanning processes by default, any known wireless network within range will be listed as a network that can be connected to, assuming that network hasn’t be properly secured.

Knowing that many wireless networks are not secured, a new pastime has emerged with outside users running specialized software in an attempt to discover said networks. One of the most popular utilities for doing so is a freebie called Network Stumbler (www.networkstumbler.com), a tool that will scan for networks within range, and outline whether security features like encryption are in use on these networks.

A wireless network sniffer called AirSnort can even go as far as to attempt to crack the encryption key used to secure data, and can even be used in conjunction with a GPS to literally map and store the location of the network for future reference. Sometimes referred to as war driving, there are literally users out there in automobiles with laptops, GPS equipment, and external antennas mapping out available wireless networks.

If this wasn’t bad enough, the information often makes its way into a variety of online databases, announcing open networks to the world. Whether the person attempting access to your network is driving around with a laptop or simply in the office or home next to you makes little difference. The critical consideration is that you’ll want to implement the security features available to you, and make it a priority.

Securing Wireless Networks

Over the course of the past three years, wireless technologies have taken the networking world by storm. Where once a length of Ethernet cable tethered most users, they can now roam freely within most home and office environments, connecting to both internal systems and the Internet from laptops and PDAs with few constraints. While this newfound mobility helps to eliminate many of the inconveniences typically associated with accessing a home or business network, it also brings with it numerous challenges from a security perspective.

While securing a wireless network isn’t terribly difficult, the unfortunate reality is that the majority of wireless networks aren’t properly secured. In a best-case scenario, external users might only use your unsecured wireless network to “borrow” access to the Internet. At worst, these users could end up with completely free reign on your network, with the ability to access sensitive files and information. If you’re currently thinking about implementing a wireless network or already have one installed, properly securing it needs to be a priority.

Securing Mail Servers with GFI Mail Security for Exchange/SMTP

Implementing network security is like trying to chase a moving target at the best of times. Some companies spend tens of thousands of dollars per year reactively trying to solve problems as they occur. If you had the unfortunate experience of having to react to the Klez worm or the Love Bug virus, you certainly understand what I’m talking about. The days where you could rely on updated desktop virus definitions alone are unfortunately long gone. Securing a network is a constantly evolving challenge. Where most companies today would consider it incomprehensible to not have a properly configured firewall, many of these same companies still overlook the single biggest source of their problems – their email systems.

As the Love Bug virus showed, companies also still rely on their users to exercise good judgment when it comes to dealing with things like potentially malicious attachments. Disabling VBScript on their systems may be a great first step, but what’s your plan for dealing with HTML emails that include embedded ActiveX controls? With 25 critical security updates already released by Microsoft this year, the need for centralized email security has never been clearer. Instead of spending your precious hours trying to fix the security leaks that have already entered your network, secure the source – the free-for-all known as your mail server.

If your company is running Exchange 2000, one product definitely worth a look is GFI Software’s GFI MailSecurity for Exchange/SMTP. Not only does this application provide you with complete control of incoming, outgoing, and internal mail, but it also does so in a manner completely transparent to users. MailSecurity is much more than just virus-checking software. The list below outlines some of the capabilities that we’ll explore further in this article.

Content and Attachment Checking. MailSecurity provides the ability to scan email messages that include specific words or attachments. Whether you’re looking to ensure that messages containing VBScript attachments are blocked, trying to filter spam, or want to stop certain users from sending or receiving attachments at all, this feature is a must-have.
Quarantining. Emails that include checked content, attachments, or viruses can be quarantined. Quarantined messages can then be sent to an administrator, a user’s manager, or even a mail-enabled Exchange public folder, prior to being manually approved or rejected. You also have the option of automatically deleting emails that meet the conditions of the rules you’ve specified.
Virus Scanning. MailSecurity can also scan all incoming, outgoing, and even internal attachments for viruses. Not to be outdone, the program uses two virus-checking engines by default – Norman Virus Control and BitDefender. If two virus engines are still not enough, you have the option of adding the McAfee engine as well.
Email Exploit Engine. If you think that it’s only email attachments that you need to worry about, think again. Over the course of the last few months, some of the most serious problems to work their way into the enterprise are those associated with active content or scripting, via HTML emails. MailSecurity protects against these types of exploits as well, using their industry-first email exploit engine.

Whether you’re looking to secure your mail server or a way to control what your users can do with their email, MailSecurity has something to offer. You hopefully already have a firewall. It’s time to consider something similar for your mail server.

The installation of MailSecurity requires Windows 2000 Service Pack 1. It also requires Exchange 2000 Service Pack 1 to take advantages of Microsoft’s new Virus Scanning API (VS API). VS API allows messages to be scanned within the Exchange message store, ensuring that scanning occurs before a user’s mail client accesses a potentially malicious attachment. The VS API is also much more efficient in how it deals with attachments – if sent to multiple users, it will only be scanned once prior to delivery, rather than multiple times according to the number of recipients.

The installation of MailSecurity is exceptionally straightforward and not worth exploring in detail. Once installed, MailSecurity is managed using the MailSecurity Configuration tool, which is implemented as an MMC snap-in. The interface of the console is shown below.

Figure

Content and Attachment Checking

GFI MailSecurity provides you with the ability to “police” your mail server by controlling both the content of email messages and the associated attachments that are allowed to pass through. For example, it’s generally a good idea to block potentially malicious attachments like .exe, .vbs, and .js files. MailSecurity takes care of all three (and more) in the default attachment-checking rule that we’ll look at shortly.

Content checking rules allow you to control the types of messages that can be sent or received on your mail server according to the words they contain. For example, you might choose to create rules that search messages for profanity, or common spam keywords. Not only is MailSecurity capable of searching for these words in the body of a message and subject line, but also in attachments if so configured. Consider the options shown on the screen below.

Figure

Once a rule has been specified, you need to associate it with an action, and optionally a group of users. Consider the screen shot below, which shows the Action tab for my new rule that checks all messages for the words “racist” or “university diploma”. The top of the page allows me to block the message and perform an action. Possible actions include quarantining the message, deleting the message, or moving it to a folder. Another course of action would be to specify multiple rules, which could then have different actions associated with them, or apply to different users. For example, you might delete messages considered spam immediately.

Figure

Notice the option to inform a manager. If you’ve ever looked at the properties of a user account in Active Directory, your may have noticed that you have the ability to configure the manager of a user within the properties of an account. In cases where this option is selected and the rule is matched, MailSecurity will query Active Directory, find the manager associated with a user, and forward the message to the manager, allowing them to approve or reject the message. If approved, the message will be sent. If rejected, the message is deleted. In cases where the Manager attribute is not set in a user’s account, the message will be sent to the configured administrator.

After specifying an action, you can use the Users/Folders tab to control to whom this rule will apply. By default, a rule will apply to all users. For a more granular level of control, you can select the individual users to whom the rule should apply.

Figure

Attachment checking rules are something that every company will want to implement. The default attachment checking rule is set to deny commonly malicious attachments, such as those shown in the list below.

Notice that inbound, outbound, and internal emails can be selected as checking options. Select inbound to check attachments that originate from outside of your organization. Outbound attachments are those sent from users found in Active Directory to outside persons. Internal checking is used to check attachments sent to and from users within your organization. Remember that not all malicious code originates from the outside world. Ensuring that your users are not purposely or inadvertently sending potentially harmful attachments to others should also be a primary consideration. The actions associated with attachment rules are similar to those seen earlier with content checking. Users who are to be impacted by the rule can similarly be specified.

MailSecurity is also a great tool for retaking control of your Exchange server. Every company has users who waste significant server resources in sending and receiving personal attachments like jokes, MP3 files, or similar. You can use MailSecurity to block these attachments, for all users or a subset thereof. Trying to circumvent the rule by renaming the extensions of files won’t work either – MailSecurity is capable of detecting files with renamed extensions.

Quarantining

After first installing MailSecurity, consider quarantining messages that have been filtered by the content and attachment checking rules, rather than deleting them outright. Quarantining gives you the opportunity to manually approve or reject messages that have been filtered. To that end, it doesn’t necessarily need to fall on your shoulders alone – messages can be quarantined by sending them to the administrator, a user’s manager, or a mail-enabled public folder. The mail-enabled public folder is a great option, especially if distributing your workload is a priority (as it always should be!). As a test, I configured MailSecurity to block and quarantine all messages with .exe attachments. I then sent an email from my personal account to the Administrator, which included the attachment test.exe. The administrator received the message shown below.

Figure

Notice that test.exe is not attached. Instead, the email includes an ErrorReport.txt file, which alerts the recipient to the fact that the attachment is not included, on account of the configured rules.

Within seconds of receiving the original email, a notification email about the quarantined attachment arrives for the administrator’s approval. It provides details about the message, and allows the administrator to approve or reject the attachment. If approved, the attachment will be forwarded to the recipient. Rejecting the message will delete it, allowing you to optionally send notification to the originating sender.

Figure

While approving or rejecting individual messages may be reasonable in a small environment, it would be more practical to be able to approve or reject multiple messages simultaneously in a larger environment. Another tool is provided for this purpose – the GFI Moderator Client. This tool allows you to view all quarantined messages, and provides the ability to approve or reject multiple messages at once. The tool also provides a listing of critical messages (any errors that may have occurred) and notification messages (such as those relating to the update of virus definition files).

Virus Checking

When it comes to protecting systems against viruses, there’s no such thing as being too careful. While desktop anti-virus packages are still an important part of a sound security strategy, updates can be troublesome to maintain, especially in larger environments. If IT departments have learned anything over the last two years, it’s that the latest definitions cannot always be relied upon for complete protection. With antivirus software vendors taking anywhere from less than a day to more than a week to update their definitions, the chances of a new virus infecting systems increases, bringing you back to reactive security management. That’s a big part of the reason why attachment and content checking is so important – they offer the possibility of being able to block and remove potentially malicious payloads. For example, blocking all .vbs files ensures that even new VBScript exploit attachments will be blocked from reaching desktop systems.

MailSecurity offers a higher degree of virus checking than any other product that I’ve come across. By default, it ships with two ICSA-certified virus engines – Norman Virus Control and BitDefender. The benefit of multiple engines should be obvious – since different vendors get updates out in varying time periods, chances are good that at least one of the engines will catch a new virus. To that end, the McAfee engine is also available as an add-on feature.

Figure

Like content and attachment scanning, inbound, outbound, and internal messages can be configured for virus scanning. Virus-infected emails are automatically quarantined for review by the administrator. Another great feature of MailSecurity is its ability to block Word and Excel documents that contain macros. This feature can be turned on or off for a given virus engine, as shown below.

Figure

Managing virus updates is also a simple procedure, since MailSecurity will automatically download new definitions from the GFI FTP automatically once configured to do so. Just to be safe, MailSecurity checks for new updates every 2 hours, allowing you to rest assured that you’ll have updates immediately, once they become available.

HTML Email Exploit Checking

One of the most remarkable features in MailSecurity is its ability to check for exploits hidden within HTML emails. Given that many companies have implemented ways to disable users from running VBScript attachments, virus creators have been getting more creative, embedding malicious scripts and controls within HTML emails instead. Not only does MailSecurity check for a wide range of known exploits, but it will also check for script code in all HTML email messages. When code is found, it is stripped from the message, and the “safe” message is passed to the recipient.

While many products claim to be able to protect your mail servers, I still haven’t seen anything as comprehensive and as easy to use as GFI MailSecurity for Exchange/SMTP. Think of how much time and money your company spent over the last two years battling various viruses, worms, and malicious content. Then think about how much easier your life would have been if you had software that was automatically quarantining any virus-infected or potentially malicious files before they ever reached your users. With pricing starting at $295, the time and energy saved by GFI MailSecurity will certainly pay for itself many times over, even if it denies only one major virus or worm from affecting your systems over the course of a year.

You can spend your time plugging holes, or you can deal with the problem at the source. Hopefully it won’t take much longer for companies to look at their mail server in the same way that they look at their firewall.

Linux Security Fundamentals

This article will cover the basic principals behind Linux security. As with any secure system, fundamental Linux security is achieved with user authentication and file permissions. This article will discuss the basics of user and group management, as well as file permissions.

Creating User Accounts

User accounts are created by making entries in the /etc/passwd file. In early versions of Unix, administrators would manually add lines to this file whenever a new user account was required. Since that time, many utilities to ease this process have been developed, with the most common being the [useradd] command. Recent distributions of Linux include the linuxconf utility, a GUI tool that mimics the functionality of Windows’ User Manager. Most distributions also include the text version of linuxconf.

Here are some common parameters for the [useradd] command:

-u: User ID number to use, similar to a SID. Any user with a user ID number of 0 is considered root. Generally system users have this number set greater than 500. If you do not provide this value, it will default to an incrementing number greater than 500.

-g: Group the user belongs to. Linux recognizes a primary group membership. Although you can belong to many groups, when you create a file, your primary group is set as the group owner of the file. If you omit this value, Linux will automatically create a group with the same name as the user and set that group as the primary group.

-G: Additional group memberships, comma separated

-s: Preferred logon shell. Provide this value as a path to the shell. For example, a C programmer might have a shell value of /bin/csh

-d: Path to users’ home directory, if other than /home. The home directory is created as a copy of /etc/skel, if it exists. Any files or scripts in this directory are automatically copied to the new users’ home.

-e: Expiration date on account, if any

All of these parameters are optional. The general syntax is as follows:

useradd -s value username

Each parameter is separated by a space, and the last value is the name of the user. Parameters take the default value when they are not provided. Default values for the [useradd] command are stored in the /etc/default/useradd file. Any modifications to this file affect future executions of the [useradd] command. You can directly modify this file with a tool such as vi, or you can run the [useradd] command with the –D option. This switch will interpret any information you provide as default values, and will write those values to the useradd file.

Before a user can log on a password value must be set. To do this use the [passwd] command. When a regular user runs this command they must adhere to strict security rules governing passwords. In order for Linux to accept the password, it must be at least 6 characters long, not be based on any variation of a dictionary word, and contain multi-case characters, with at least one special character or number.

The modern passwd utility works though the Linux-PAM API.

Pages: 12345

Encrypting File System (EFS)

Although the idea behind the Encrypting File System (EFS) in Windows 2000 seems pretty straightforward, there is a great deal more to it than first meets the eye. The purpose of this article is to explain how EFS actually works, and to provide practical configuration advice for system admins.

Why use EFS? The simple answer is that relying on NTFS permissions alone is sometimes not enough. There are simply too many utilities that will allow a user to bypass NTFS security on the market, such as NTFSDOS. Beyond the utilities, imagine the scenario with a mobile user. If the user’s laptop were stolen, the thief would only need to either remove the hard drive and place it into another W2K system, or reinstall W2K and take ownership of the folder as the new administrator account. In either scenario, highly confidential data is not safe. If you’re looking for more security EFS may be the answer you’re looking for, and you can’t beat the price.

I’m going to try not to bore you with the details of what you probably already know. Here’s the useful beginner stuff, just to get it out of the way:

EFS can only be used on NTFS formatted volumes.
EFS cannot encrypt files if any of the following attributes are set: Read-only, System or Compressed.
If you have ‘write’ permissions to a file, you can encrypt it.
If the user who encrypted the file moves it to a FAT volume, the file is no longer encrypted.
EFS encryption is relatively transparent to the user. To encrypt a file, the user need only set the encryption attribute on the file, or save it to an encrypted folder.
EFS is file-system encryption. That means that when an EFS-encrypted file moves over the network, it is NOT encrypted.
EFS does not prevent a user with the appropriate NTFS permissions from deleting a file.
To encrypt many files at once, use Cipher.exe from the command line.
When an encrypted file is opened, so are temporary copies if they exist.
Users cannot share encrypted files.
Only the user who encrypted a file can open it (with exceptions, of course!)

The last item on the list is important. Although the only person who can open an EFS-encrypted file is officially the person who encrypted it, there is still a back door of s orts – the recovery agent. The recovery agent is by default the domain Administrator account (more on this later, but there can be more than one), and can open files that were EFS-encrypted by another user. The reason for this is simple. If a user somehow loses their private key, or snaps and go encryption-crazy on their last day on the job, we have a way to recover their files.

Pages: 1234

Object Permissions and ACLs

Although the concepts of permissions and ACLs were just discussed, you’ll need to know a little more about them. First of all, every object in Active Directory has an associated ACL. This controls who can do what to an object. By default, the ACL associated with an object is hidden, but can be viewed in the object’s properties after choosing to view Advanced Features from the View menu item in Active Directory Users and Computers.

After this has been done, access the ACL from the security tab in the object’s properties. The list of ACEs will be different based on the type of object, and will control what users can and cannot do with respect to that object. As a best practice, you should note that it is generally not a good idea to change the ACL of individual objects. Instead, change the ACL on a parent object, and by default these changes will be inherited by all child objects.

You will note that a DACL has two main columns in which ACEs can be modified – Allow and Deny. The rule is simple – the effective permissions that will apply to a user when accessing an object are the combination of all permissions that apply to the user, but an explicit deny always overrides an allow. The deny permissions should be used for special cases, such as when you want to give all users in the Help Desk group the ability to change object information for user accounts, but need to explicitly deny a single user who is a member of that group the same privilege.

Note also that the ACL that you see when viewing the permissions on an object is the standard list. If you click on the Advanced button, you are presented with a list of users and groups and their associated permissions.

By choosing an entry from the list and then choosing View/Edit, you can access an even more granular level of permissions for the object, which includes controlling how inheritance settings will be applied to the object by default, as shown below.

Using IPSec to Secure TCP/IP Traffic

Windows 2000 supports IPSec, which can provide for secure network communication between clients by encrypting IP-based data and using Kerberos for authentication. The beauty of IPSec is that is not application-based encryption (which would require that an application on both the sending and receiving computer supported encryption) but rather network-stack based. As such, any TCP/IP-based application is capable of utilizing IPSec, because encryption (and decryption) actually happens in the protocol stack. As such, the encryption is completely application-independent and totally transparent to the user.

Windows 2000 supports IPSec in two modes – transport mode and tunnel mode. In tunnel mode, two endpoints (IP addresses) must be defined, and IPSec will encrypt data (it can also be used for authentication of systems only) that travels through the tunnel. This setup is commonly used in connecting remote offices via VPNs over the Internet. Note that the systems communicating need not necessarily be Windows 2000-based, since IPSec is an open standard. In transport mode, policies can defined which designate when and how IPSec encryption should be used on the network. For example, you could specify that only traffic moving from a client to TCP ports 80 or 23 on a server must be encrypted, and that all other traffic need not be. Similarly, you could specify that a client must initiate encrypted communication with a server or the server will not respond. The level and degree of IPSec use on your network is only dictated by your own needs (don’t forget that any encryption will create CPU overhead).

Pages: 12

Security Templates

Another MMC snap-in, Security Templates, allows you to view and configure template settings, as well create new templates. Templates files are in an .inf format, readable in any text editor. A small example of the password policy settings of a template file are shown below:
[System Access] ;---------------------------------------------------------------- ;Account Policies - Password Policy ;---------------------------------------------------------------- MinimumPasswordAge = 0 MaximumPasswordAge = 42 MinimumPasswordLength = 0 PasswordComplexity = 0 PasswordHistorySize = 0 RequireLogonToChangePassword = 0 ClearTextPassword = 0

Windows 2000 provides a number of templates by default. You should have an understanding on the provided template files and why you would use them. The names of templates provide an idea of when/how they are to be used. The last two letters in the template file name (before the .inf extension) usually tell you which type of system a template is meant for – WS for a workstation, DC for a domain controller, SV for a server. For example, the hisecws.inf identifies the template as applying highly secure settings to a workstation. Beyond this, there are five main security levels outlined in the default templates, with each outlined below:

Basic*.inf – Basic. These templates apply the default security configuration to a system. These would be useful if you set too high a level of security on a system and wanted to return settings back to the default.

Compat*.inf – Compatible. Windows 2000 gives members of the Users group more strict security settings than in NT 4.0. As such, some applications (such as those certified for NT 4 but not Windows 2000) may not function correctly (or potentially at all) on Windows 2000. When this template is applied, applications run under the Power Users level of privilege, even though the user may not have that level of access.

Secure*.inf – Secure. Contains settings recommended for securing a system except for those relating to files, folders, and registry keys, which are configured securely by default.

Hisec*.inf – Highly Secure. Provides settings to provide a much higher level of protection, including network security. In this configuration, a system can only communicate with other Windows 2000-based systems, for example.

Dedica*.inf – Dedicated Domain Controller. Contains recommended security settings for a domain controller that is not also acting as an application server.

Template files are stored in %systemroot%\security\templates by default.

Security Configuration and Analysis

Windows 2000 provides an MMC snap-in tool for analyzing the security configuration of a system. The Security Configuration and Analysis snap-in allows you to compare the current configuration of a system with settings found in security template files, pointing out inconsistencies between the two settings. Although a system can be configured using this tool, it is usually better to export settings to a template file, which can then be deployed to multiple systems using Group Policy in an Active Directory environment. However, settings can be configured on a system-by-system basis if required.

The Security Configuration and Analysis tool requires a working database in which to store system configuration information for the purpose of the comparison. This file has an .sdb extension, and must be opened (or created if starting from scratch) prior to importing a security template for the purpose of comparison. After the .sdb file has been created, one of the pre-defined security templates provided with Windows 2000 can be imported, as can any templates that you have created. Imagine that you wanted to check and see whether a certain system on your network met the requirements of your pre-defined enterprise-wide security settings that you have stored in a template. You could simply open a new .sdb file, and then import the template and compare the security settings to those on the system. The analysis will literally show which settings meet, do not meet, or are not defined in the template you imported. As shown below, the password policy on my system does not meet many of the requirements mapped out in a provided template called securews.inf (more on templates coming up).

Pages: 12