The Domain Name System (DNS) is a hierarchical naming system for computers, services, or any resource participating in the Internet. DNS system is a database that stores and translates the human-readable domain name into the machine-readable IP address, because domain names are alphabetic, they’re easier to remember. Every time you use a domain name, therefore, a DNS service must translate the name into the corresponding IP address. For example, the domain name www.google.com might translate to 209.85.229.103.

The Internet however, is really based on IP addresses. The DNS system is, in fact, its own network. If one DNS server doesn’t know how to translate a particular domain name, it asks another one, and so on, until the correct IP address is returned. The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains, and in turn can assign other authoritative name servers for their sub-domains. This mechanism has made the DNS distributed, fault tolerant, and helped avoid the need for a single central register to be continually consulted and updated.

To view the IP address of a Windows computer type IPCONFIG in the Command prompt. On a UNIX machine type nslookup along with a machine name (such as “nslookup www.cit.ie”) to display the IP address of the machine (use the command hostname to learn the name of your machine).

How to access Linux computer from Windows Network

In order for a Windows computer to view and access a share folder on a Linux computer from a Windows network, Samba software has to be installed on a Samba server.  After which the Samba Server has to be configured. 

To Configure the Linux computer make a directory using mkdir /home/directory name, give access rights to the directory with chmod 777 /home/directory name, and then edit the /etc/samba/smb.conf and include your share directories.

Then create an account using useradd account name and change the password using passwd account name. Creation of accounts can only be done by a root user.

Use the following commands to start/on the samba: /etc/rc.d/init.d/smb start, chkconfig smb on

To map a network drive in Windows computer, Open My Computer, Click on Tools ->Map Network Drive. Choose the appropriate Drive and enter the location of the shared folder, e.g.: \\SAMBA server\share name.  This can also be done through the command prompt by issuing this command: net use S: \\SAMBA server\share name

Replace S: with the drive you would like to map the SAMBA shares under.

To access the share folder on you Windows computer, Open My Computer and you will see a new mapped drive of your SAMBA shared folder/directory.

The above process proves to be difficult using a VMWare, the easy way out is to clone a Windows machine in your VMWare and assign the Windows machine with an IP address in the same network as the Samba Server.  Make sure that you change the name of the workgroup in the Windows machine to reflect the workgroup name in the Samba Server.

./configure --enable-mods-shared="access log_config dir mime auth auth-digest" --enable-so

If you are using Apache 1.3.xx, you can edit the src/Configuration file before running make, and comment out the AddModule lines corresponding to the modules you don’t need.

Two modules you really don’t want to include are mod_autoindex, which provides automatic directory indexing, and mod_info, which can be used to leak information about the server’s configuration.

Once you have run ./configure and make, su to root and run

umask 022
make install
chown -R root:sys /usr/local/apache

to install the binary and set the necessary permissions.

After compiling and installing Apache you should set up a group and user specifically for the Apache binary, with the commands

# groupadd apache
# useradd -c "Apache Server" -d /dev/null -g apache -s /bin/false apache

This creates a regular user apache and the apache group. While Apache runs as the unprivileged nobody user by default, user nobody may be used by many processes, and if it is compromised an intruder can gain access to all processes on your system running under that UID.

Configuration

Most security violations are the result of bad configuration. You should configure your server to run with the minimum level of authorization required for clients to work effectively. For example, if you need to provide access only to certain hosts, configure Apache to listen to requests from only those hosts by editing your httpd.conf file. The rest of this article refers to changes you can make in httpd.conf.

In recent versions of Apache, the Listen directive is required (or Apache will fail upon startup) to tell Apache which port to listen on. If you only need to serve a small number of hosts, you can also use this directive to specify the IP addresses to which Apache should listen:

Listen 192.168.1.11:80
Listen 192.168.1.12:80

Otherwise, just use Listen 80, or whichever port you want Apache to listen to. Remove any AddModule directives you don’t need. The configuration file should also contain the following, and I’ll explain each line in turn below:

User apache
Group apache

HostNameLookups Off

ServerAdmin admin@myserver.com

ServerRoot "/usr/local/apache"
DocumentRoot "/var/www/htdocs"

UserDir disabled root

ServerTokens Prod
ServerSignature Off

The User and Group directives ensure that Apache runs as the specific user and group you configured earlier.

Turning HostNameLookups off provides better performance, as this ensures Apache will not try to resolve any IP addresses. It also slightly decreases the possibility of spoofing attacks.

ServerAdmin should be set to a valid email address which someone checks regularly, as this is the contact address which will be given in any error messages presented to�the client.

The ServerRoot directive tell the server�where it is installed and therefore where to find configuration files. DocumentRoot is where the Web pages of your site are stored

UserDir allows users to host personal sites in a directory under their /home directory. This should always be disabled for root, as advised by the Apache team.

By default Apache will give out information about its version and configuration. Using ServerTokens Prod will only give out the string “Apache”; the less information someone can get about your server, the more secure it is likely to be. In versions of Apache prior to 2.0.44, ServerSignature could leak the version of your server, so we turn that off. In more recent versions this is controlled by the ServerTokens directive.

Files and directories

We should now set up options for the various directories on our server.

<Directory / >
 Options None
 AllowOverride None
 Order deny,allow
 Deny from all
</Directory>

Our first entry sets up the most restrictive permissions possible for our / (root) directory. This sets a default policy to deny access to all directories. We will allow access to specific directories below. Options None makes sure that all directives such as FollowSymLinks and any others which may be enabled by default are switched off. AllowOverride None ensures that users cannot use a .htaccess file to override the default permissions set in the httpd.conf file.

If for some reason you want to use a .htaccess file to override settings in httpd.conf, simply use the AllowOverride directive within a <Directory> block. You should be careful about just what you allow users to override, however. The directive types available for AllowOverride include:

Indexes — allow users to specify indexing options for the directory
AuthConfig — allow users to set authorization directives (i.e., require a username and password)
Limit — specify host access with Allow and Deny directives

For example, AllowOverride AuthConfig Limit allows a user to place directives in a .htaccess file to require a password to access any files hosted in the directory, and Limit allows the user to specify which hosts can gain access to the directory through the Allow and Deny directives. These options can be set by the user regardless of any site-wide options you have set in httpd.conf.

Although we want to allow .htaccess files in some directories we should never let clients download and read these files. We can prevent this with the File directive:

<Files ~ "^/.ht">
    Order allow,deny
    Deny from all
</Files>

This prevents users from accessing any files on the server whose names begin with .ht.

The Allow and Deny directives within a <File> or <Directory> block can be used to limit access to certain files or directories to certain specified hosts or networks. The order in which the directives are applied is designated by the Order directive. You can use as many lines as you need, as the example below illustrates.

<Directory "/var/www/htdocs/restricted" >
 # Deny all access by default by applying the deny directive first
 Order deny,allow
 # Allow access to the local machine
 Allow from 127.0.0.1
 # Allow access to a single remote host
 Allow from 192.168.2.7
 # Allow access to a local network
 Allow from 192.168.1.
 # Deny from everyone else
 Deny from all
</Directory>

User authentication

Apache allows us to require user authentication for access to certain directories. The authentication method can be one of two types, Basic or Digest.

Basic authentication

To set up a directory that requires a user to supply a username and password we would use something like the following in our httpd.conf file:

<Directory "/var/www/htdocs/protected" >
 Order deny,allow
 Deny from all
 Allow from 192.168.1.
 AuthName "Private Information"
 AuthType Basic
 AuthUserFile /usr/local/apache/conf/passwd
 AuthGroupFile /usr/local/apache/conf/groups
 require group <group-name>
</Directory>

Firstly we have denied access to all users but those on our internal network to the directory /var/www/htdocs/protected. To require a password we use the AuthType Basic directive. Our password file is /usr/local/apache/conf/passwd, as specified by the AuthUserFile directive and, similarly, we specify a group file. The last line require group <group-name> means that a user must be a member of <group-name> in order to be allowed access to the directory.

Of course, for this to work, we must set up our password and group files. For the group file simply create a file, /usr/local/apache/conf/groups, containing the line:

group-name: user1 user2

You can specify as many groups as you wish on separate lines. List users separated by a space.

Next we create the password file with the command htpasswd -cm /usr/local/apache/conf/passwd user1. This will prompt for a password and create a user with name user1 in the file /usr/local/apache/conf/passwd. The c option will create the file if it doesn’t exist, and the m option will MD5 hash the password (SHA1 and crypt options are also available, but SHA1 does not work with some Apache versions). Subsequent users can be added using htpasswd -m /usr/local/apache/conf/passwd user1.

If you do not want to use groups you could use require valid-user user1 user2 in order to only allow access to certain users.

The disadvantage of Basic Authentication is that passwords are sent as plain text from the client to the server, meaning that it is simple for a malicious user with access to the network can obtain the password using a network traffic analyzer. Digest Authentication tries to prevent this.

Digest Authentication

In digest authentication the password is never transmitted across the network. Instead the server generates a nonce, a one-time random number, and sends it to the client’s browser, which then hashes the nonce with the user’s password and sends the resulting hash back to the server. The server then performs the same hash and compares the result. This is considerably more secure than Basic Authentication, though not so widely used. One disadvantage of Digest Authentication is that it requires setting up a different password file for each realm on the server, as the realm name is used when creating the necessary hashes. With Basic Authentication, one password file can be used across the board.

To create an area protected by Digest Authentication, we use something like the following.

<Directory "/var/www/htdocs/protected" >
 Options None
 AllowOverride None
 AuthType Digest
 AuthName "Protected Area"
 AuthDigestFile /usr/local/Apache/conf/digest_passwd
 AuthDigestGroupFile /usr/local/apache/conf/groups
 Require valid-user
 Order deny,allow
 Deny from all
</Directory>

This time we set AuthType Digest, and the AuthName "Protected Area" directive is required. In place of AuthUserFile and AuthGroupFile directives we use the AuthDigestFile and AuthDigestGroupFile directives. The group file is the same as previously, but we need to set up the password file using the command htdigest -c /usr/local/apache/conf/digest_passwd "Protected Area" user1. Note the use of the htdigest program in place of htpassword and the AuthName in the command. Again the c option creates the file if it doesn’t exist.

Logs

Having detailed logs is important if we are going to track activity on our server, whether to trace problems or potential violations. We can allow detailed logs by including the following in our httpd.conf file:

LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
ErrorLog /usr/local/apache/logs/error_log
CustomLog /usr/local/apache/logs/access_log combined

If you have several virtual hosts on your server, it is prudent to set a separate log file for each host:

NameVirtualHost *
<VirtualHost *>
DocumentRoot "/www/htdocs/myserver"
ServerName "www.myserver.com"
ErrorLog logs/mysite/error_log
CustomLog logs/mysite/access_log combined
</VirtualHost>

Immunizing the configuration file

Once we have configured the server we should do one last thing. By setting the immutable bit on the configuration file we make it much more difficult for anyone to change the configuration. Do this by running chattr +i /usr/local/Apache/conf/httpd.conf.

Apache is generally a very secure piece of software but the default configuration on many distros is often too lenient. By limiting the number of modules and using a restrictive configuration we can considerably reduce the risk of a break-in. When setting up your server, divide content into different realms and be as restrictive as possible in what options you allow for each area.

Mike Peters is a freelance consultant and programmer and long-time Linux user.

Reference: http://www.linux.com/articles/113744 - accessed 05 March, 2009

HARDENING CENTOS OPERATING SYSTEM

The CentOS 4.4 operating system environment is hardened using Bastille. Bastille is a system hardening/lockdown program that enhances the security level of a UNIX host.  Bastille configures daemons, system settings and firewalls to be make them more secure.  It switches off unnecessary services such as pwgrd and printing services, and configures client software such as rcp and rlogin for enhanced security. ¹

Bastille

With the basics of manual hardening down pat, let’s check out a free open-source tool to automate and simplify the process. Bastille will disable unnecessary services and install operating system updates as well as configure a firewall, enforce password policies, create a second root-level account and more. What’s nice is that Bastille leads the user through a simple series of yes/no questions, giving a detailed explanation of why each question is asked and what will happen if ‘yes’ is chosen. It doesn’t merely expect guesswork, nor does it blindly alter your system – instead, it genuinely hardens your computer and educates on security in the process.

Pleasantly, you’re also not locked in to Bastille’s changes should you decide some of the setting changes weren’t for you. Running RevertBastille automatically restores the state of all config files and settings to just how they were before Bastille made any changes. Obviously, if you make changes to your system manually after running Bastille, you will lose these too so it is best to test changes as soon as possible after applying to ensure you won’t harm anything else if you need to revert.

Unfortunately, Bastille is not for everyone: versions exist for Red Hat, SUSE, Debian, Gentoo and Mandrake (as well as non-Linux UNIX variants HP-UX and MacOS X). If you do run one of those systems, you really are well-advised to run Bastille.

Let’s give Bastille a run-through.

Launch Bastille by calling up a terminal prompt as root and executing. /InteractiveBastille. You are lead through a series of security steps, as follows.

1. Apply a firewall to prevent access to potentially vulnerable services, using iptables. This is a big topic which could not be adequately covered here. Fortunately, Bastille’s explanations do an admirable job. In one sense, this is redundant; if the service has been disabled as we discussed above, there won’t be anything listening on the port which can be exploited. However, you might later restore a service for testing or for internal use. Or it may be restored inadvertently. Whatever the reason, Bastille errs on the side of tougher security by protecting your system from the same exploits via more than one method.
2. Retrieve and apply available operating system patches, as discussed above.
3. Audit the system tools which have the SUID flag set and which run as the superuser, even for ordinary users. The danger of SUID apps is they perform actions with full superuser powers no matter who executes them. This is essential in some cases: for instance, if the passwd command couldn’t write back to the shadowed password file then nobody could actually change their password. However, you may not want ordinary users running the dump and restore commands, both of which come with SUID status out-of-the-box.
4. Tighten up account security. Here, Bastille first asks to create a second account with root-level access. This means you can disable root if desired, or at the very least if you exclusively use the second account, you can tell if someone else is trying to log in as root because you know it won’t be you. This section of Bastille also prompts to enforce password aging and some other items like assigning a restricted or useless shell to non-user accounts. There’s wisdom in this last point. Here’s a true story: back in 1991, I myself gained root access to the Computer Science department SunOS server at the University of Newcastle (which I reported.) It all began because I was casually looking through /etc/passwd for accounts which didn’t have a password. I logged in as sync and came across an exploit.
5. Enhance boot security. This helps restrict the computer even if someone can get physical access to it and try starting it up in single-user mode.
6. Deactivate or restrict unnecessary services, as discussed above.

From this point, the remaining modules are less significant (though still beneficial) and include disabling program compilation, limiting system usage, increasing logging, installing SSH, tightening up DNS and Apache, disabling printing and a couple of other things.

Bastille now exits, but has not yet made any changes. All your choices have been saved to a configuration file. Run ./BackEnd.pl to actually enforce them. Reboot and test out your hardened server. Any malicious attackers will find far less vulnerabilities and options against your computer.

Security is something we all need to take seriously. Many people may not even be aware that they have possible insecurities. Fortunately, the above steps are easy to understand and simple to implement.²

Running Bastille on Red Hat, SuSE and Mandrake Linux

Bastille supports a number of Linux distributions and operating systems. In the RPM-focused world, it supports
Fedora Core, Red Hat Enterprise, Red Hat Classic (Red Hat 6 through 9), SuSE and Mandrake systems. On
these systems, Bastille is primarily used via an RPM, though you can also download the raw source tarball.

Installing Bastille 2.x on Red Hat (Classic, Enterprise or Fedora Core), SuSE or Mandrake is easiest via the RPM.
You need to install the Bastille RPM as well as a supporting perl module to provide either the graphical or
text-based interface.

• First, install the Bastille RPM, like so:

·                        rpm -ivh Bastille-3.2.1-0.1.noarch.rpm

• Second, if you want to use Hardening mode, you’ll need to install perl-Tk
  (for our Graphical Interface) or perl-Curses (for console/text mode).
  (Installing perl-Tk/perl-Curses isn’t necessary in Assessment mode, as it
  generates a report in both HTML and Text.)

You can usually do this most easily by getting the RPM shown in this table, installing
it via this command:

        rpm -ivh perl-Tk-a.b-c.i386.rpm

or

        rpm -ivh perl-Curses-d.e-f.i386.rpm

Alternatively, you can install these using the CPAN method, described here.

• Third, run the bastille command:

·                        bastille -x     (for Graphical Mode Hardening)

·                or

·                        bastille -c     (for Text Mode Hardening)

·                or

·                        bastille --report       (for Assessment and Reporting)

• NOTE: Just because you’re su-ing or ssh-ing into a system doesn’t mean you’re stuck in text mode.
  You can use graphical (X) programs like Bastille’s Tk interface or browsers by forwarding your X connections over the ssh connection. It’s very, very simple. Just do this:

·                   ssh -X root@remote_box   (when you were already SSH-ing)

·                OR

·                   ssh -X root@127.0.0.1    (when you would normally just su)3

Patching the OS

An essential requirement to maintaining security is to keep your operating system up-to-date. This ensures you receive updates to fix known exploits and vulnerabilities, as well as bug fixes and performance and feature enhancements.

Most Linux vendors provide information on available updates. For instance, Red Hat publish their list at www.redhat.com/security/updates/notes. (Information on Red Hat’s update and support policies, including how to sign up for automatic notification of errata is at www.redhat.com/security/updates.)

Other distro users can find links at Linux-Sec.net’s list of online security patches and updates by vendor. ²

Disable unused services

The very first step is to seal any ports you aren’t deliberately using. Although Linux is secure by design, vulnerabilities are regularly discovered and it is only sensible to mitigate risk. It’s a good idea to use nmap to check the services your computer is exposing. Check this over the Internet using your public IP address too.

The bulk of services provided by a Linux server are controlled by /etc/xinetd.conf. The xinetd process listens for many network requests and palms it off to the appropriate application. There are memory and performance reasons for doing this; instead of having many different listening servers all running from system boot, it is more efficient to launch and run xinetd instead, merely launching instances of the ssh or telnet or ftp or rlogin or other servers on demand.

/etc/xinetd.conf directs requests to configuration files found under /etc/xinetd.d. It’s a doddle to disable (or re-enable, if needed later) services: just comment out the appropriate entry in the configuration files. To disable ftp, for instance, edit /etc/xinetd.d/wu-ftpd. Add a “#” to the beginning of the “service ftp” line to comment it out. Save the file. Then restart xinetd with the command /etc/rc.d/init.d/xinetd restart. If you now try using ftp to connect to your server (from another machine, or ftp localhost on the server itself) you will find the connection fails.

Check out the services xinetd is running on your computer; other candidates you might like to consider removing are rlogin – which bypasses password authentication – and finger – which can give malicious people insight into when your computer is unattended.

If you have an older Linux system and can’t find /etc/xinetd.conf then you’ll find the same is achieved by editing the single config file /etc/inetd.conf and commenting out entries as appropriate. Then restart inetd by finding out its process ID, or PID, with ps aux | grep inetd. The second column listed is the PID. Use kill –HUP xxx where xxx is inetd’s PID. However, if you have a Linux system of this age (RedHat Linux prior to version 7.0 for example) then you have an additional safety risk beyond open ports; you should also upgrade your software to be certain you are countering all known vulnerabilities.²

Reference

1. https://secure.nixu.com/doc/Nixu_DHCP_Server_Security_White_Paper_Sept07.pdf
2. http://www.itwire.com/content/view/13976/53/ accessed 24 Feb., 2009

Red Hat Enterprise.