Resource sharing, like file systems and printers, in Microsoft Windows systems, is accomplished using a protocol called the Server Message Block or SMB. For working with such shared resources over a network consisting of Windows systems, an RHEL system must support SMB. The technology used for this is called SAMBA. This provides integration between the Windows and Linux systems. In addition, this is used to provide folder sharing between Linux systems. There are two parts to SAMBA, a Samba Server and a Samba Client.

When an RHEL system accesses resources on a Windows system, it does so using the Samba Client. An RHEL system, by default, has the Samba Client installed.

When an RHEL system serves resources to a Windows system, it uses the package Samba Server or simply Samba. This is not installed by default and has to be exclusively set up.

Installing SAMBA on Linux Redhat/CentOS

Whether Samba is already installed on your RHEL, Fedora or CentOS setup, it can be tested with the following command:"

The result could be - “package samba is not installed,” or something like “samba-3.5.4-68.el6_0.1.x86_64” showing the version of Samba present on the system.

To install Samba, you will need to become root with the following command (give the root password, when prompted):

Then use Yum to install the Linux Samba package:

This will install the samba package and its dependency package, samba-common.

Before you begin to use or configure Samba, the Linux Firewall (iptables) has to be configured to allow Samba traffic. From the command-line, this is achieved with the use of the following command:

Configuring Linux SAMBA

The Samba configuration is meant to join an RHEL, Fedora or CentOS system to a Windows Workgroup and setting up a directory on the RHEL system, to act as a shared resource that can be accessed by authenticated Windows users.

To start with, you must gain root privileges with (give the root password, when prompted):

Edit the Samba configuration file:

The smb.conf [global] Section

An smb.conf file is divided into several sections. the [global] section, which is the first section, has settings that apply to the entire Samba configuration. However, settings in the other sections in the configuration file may override the global settings.

To begin with, set the workgroup, which by default is set as “MYGROUP”:

Since most Windows networks are named WORKGROUP by default, the settings have to be changed as:

Configure the Shared Resource

In the next step, a shared resource that will be accessible from the other systems on the Windows network has to be configured. This section has to be given a name by which it will be referred to when shared. For our example, let’s assume you would like share a directory on your Linux system located at /data/network-applications.  You’ll need to entitle the entire section as [NetApps] as shown below in our smb.conf file:

When a Windows user browses to the Linux Server, they’ll see a network share labeled
“NetApps”.

This concludes the changes to the Samba configuration file.

Create a Samba User

Any user wanting to access any Samba shared resource must be configured as a Samba User and assigned a password. This is achieved using the smbpasswd  command as a root user. Since you have defined “administrator” as the user who is entitled to access the “/data/network-applications” directory of the RHEL system, you have to add “administrator” as a Samba user.

Different Linux systems can be used in many ways. This is the main idea behind operating different services at different operating levels. For example, the Graphical User Interface can only be run if the system is running the X-server; multiuser operation is only possible if the system is in a multiuser state or mode, such as having networking available. These are the higher states of the system, and sometimes you may want to operate at a lower level, say, in the single user mode or the command line mode.

Such levels are important for different operations, such as for fixing file or disk corruption problems, or for the server to operate in a run level where the X-session is not required. In such cases having services running that depend on higher levels of operation, makes no sense, since they will hamper the operation of the entire system.

Each service is assigned to start whenever its run level is reached. Therefore, when you ensure the startup process is orderly, and you change the mode of the machine, you do not need to bother about which service to manually start or stop.

The main run-levels that a system could use are:

The system and service manager for Linux is now “systemd”. It provides a concept of “targets”, as in the table above. Although targets serve a similar purpose as runlevels, they act somewhat differently. Each target has a name instead of a number and serves a specific purpose. Some targets may be implemented after inheriting all the services of another target and adding more services to it.

Backward compatibility exists, so switching targets using familiar telinit RUNLEVEL command still works. On Fedora installs, runlevels 0, 1, 3, 5 and 6 have an exact mapping with specific systemd targets. However, user-defined runlevels such as 2 and 4 are not mapped that way. They are treated similar to runlevel 3, by default.

For using the user-defined levels 2 and 4, new systemd targets have to be defined that makes use of one of the existing runlevels as a base. Services that you want to enable have to be symlinked into that directory.

The most commonly used runlevels in a currently running linux box are 3 and 5. You can change runlevels in many ways.

A runlevel of 5 will take you to GUI enabled login prompt interface and desktop operations. Normally by default installation, this would take your to GNOME or KDE linux environment. A runlevel of 3 would boot your linux box to terminal mode (non-X) linux box and drop you to a terminal login prompt. Runlevels 0 and 6 are runlevels for halting or rebooting your linux respectively.

Although compatible with SysV and LSB init scripts, systemd:

• Provides aggressive parallelization capabilities.
• Offers on-demand starting of daemons.
• Uses socket and D-Bus activation for starting services.
• Keeps track of processes using Linux cgroups.
• Maintains mount and automount points.
• Supports snapshotting and restoring of the system state.
• Implements an elaborate transactional dependency-based service control logic.

Systemd starts up and supervises the entire operation of the system. It is based on the notion of units. These are composed of a name, and a type as shown in the table above. There is a matching configuration file with the same name and type. For example, a unit avahi.service will have a configuration file with an identical name, and will be a unit that encapsulates the Avahi daemon. There are seven different types of units, namely, service, socket, device, mount, automount, target, and snapshot.

To introspect and or control the state of the system and service manager under systemd, the main tool or command is “systemctl”. When booting up, systemd activates the default.target. The job of the default.target is to activate the different services and other units by considering their dependencies. The ‘system.unit=’ command line option parses arguments to the kernel to override the unit to be activated. For example,

systemd.unit=rescue.target is a special target unit for setting up the base system and a rescue shell (similar to run level 1);

systemd.unit=emergency.target, is very similar to passing init=/bin/sh but with the option to boot the full system from there;

systemd.unit=multi-user.target for setting up a non-graphical multi-user system;

systemd.unit=graphical.target for setting up a graphical login screen.

How to Enable/Disable Linux Services

Following are the commands used to enable or disable services in CentOS, Redhat Enterprise Linux and Fedora systems:

Activate a service immediately e.g postfix:

To deactivate a service immediately e.g postfix:

You might have noticed the 'FAILED' message. This is normal behavior as we shut down the postfix service with our first command (service postfix stop), so shutting it down a second time would naturally fail!

Determine which Linux Services are Enabled at Boot

2. Locate and stop Cisco Systems, Inc. VPN Service;

3. Stop and disable Internet Connection Sharing (ICS) Service;

4. Restart Cisco System, Inc. VPN Service.

Launch the Cisco VPN Client again, and the problem is now gone!

Keep in mind that we are running Cisco Systems VPN Client version 5.0.07.0440 on Windows 7 Ultimate 64-bit edition, but we faced the same problem with other versions as well.

Boot Disk

One of the foremost requisites of a secure Linux server is the boot disk. Nowadays, this has become rather simple as most Linux distributions are on bootable CD/DVD/USB sticks. Other options are, to use rescue disks such as the ‘TestDisk’, ‘SystemRescueCD’, ‘Trinity Rescue Kit’ or ‘Ubuntu Rescue Remix’. These will enable you to gain access to your system, if you are unable to gain entry, and also to recover files and partitions if your system is damaged. They can be used to check for virus attacks and to detect rootkits.

Next requirement is for patching your system. Distributions issue notices for security updates, and you can download and patch your system using these updates. RPM users can use the ‘up2date’ command, which automatically resolves dependencies, rather than the other rpm commands, since these only report dependencies and do not help to resolve them.

Patch Your System

While RedHat/CentOS/Fedora users can patch their systems with a single command, 'yum update',   Debian users can patch their systems with the ‘sudo apt-get update’ command, which will update the sources list. This should be followed by the command ‘sudo apt-get upgrade’, which will install the newest version of all packages on the machine, resolving all the dependencies automatically.

New vulnerabilities are being discovered all the time, and patches follow. One way to learn about new vulnerabilities is to subscribe to the mailing list of the distribution used.

Disable Unnecessary Services

Your system becomes increasingly insecure as you operate more services, since every service has its own security issues. For improving the overall system performance and for enhancing security, it is important to detect and eliminate unnecessary running services. To know which services are currently running on your system, you can use commands like:

To disable services, you can either stop a running service or change the configuration in a way that the service will not start on the next reboot. To stop a running service, RedHat/CentOS users can use the command -

You can also remove a service from the startup script by using the following commands which will remove the httpd (Apache Web server) service: