Apache Server Hardening: Part Four (httpd.conf)

httpd.confIn the previous article, we looked at compiling and installing Apache and discussed the benefits of mod_security. In this article, we will cover httpd.conf configuration.

httpd.conf File Configuration

The Apache web server stores all its configuration data in the httpd.conf file located in the $[ApacheServerRoot] directory, which is, in our example, /usr/local/apache. The httpd.conf file includes many directives that can be categorized into the following sections:

  • Server Directives
  • User Directives
  • Performance/Denial of Service directives
  • Server Software Obfuscation Directives
  • Access Control Directives
  • Authentication Mechanisms
  • Directory Functionality Directives
  • Logging Directives

Not all directives play a significant role with regard to security. In this article, we will discuss the directives that impact the security of your Apache server. Furthermore, because we disabled a lot of functionality at compile time, some directives that would normally be dangerous do not need to be removed, since they were not added into the compiled Apache binaries. There may also be other configuration files, called Include files, associated with the httpd.conf file. Since we have enabled mod_security, there is a long list of potential configurations to make in an Include filled called modsecurity.conf, which is usually located in the $[ApacheServerRoot]/conf directory.

In this section, I included the modsecurity.com recommended mod_security configuration. For more information about configuring this file, refer to the mod_security documentation.

Recommended modsecurity.conf file:

# Turn ModSecurity On
SecFilterEngine On

# Reject requests with status 403
SecfilterDefaultAction “deny.log.status.403”

# Some sane defaults
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecfilterCheckUnicodeEncoding Off

# Accept almost all byte values
SecFilterForceByteRange 1 255

# Server masking is optional
# SecServerSignature “OurServer”

SecUploadDir /tmp
SecUploadKeepFiles Off

# Only record the interesting stuff
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log

# You normally won’t seed debug logging
SecFilterDebugLevel 0
SecFilterDebug logs/modsec_debug_log

# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply “text/html” as Content-Type
SecFilterSelective REQUEST_METHOD “|^(GET|HEAD)$” chain
SecFilterSelective HTTP_Content-Type \

# Do not accept GET or HEAD requests with bodies
SecFilterSelective REQUEST_METHOD *^(GET|HEAD)$” chain
SecFilterselective HTTP_content-Length “!^$”

# Require Content-Length to be provided with
# every POST request
SecFilterSelective REQUEST_METHOD “^POST$” chain
SecFilterSelective HTTP_Content-Length ‘^$”

# Don’t accept transfer encodings we know we don’t handle
SecFilterSelective HTTP_Transfer-Encoding “!^$”

There are a couple directives you must configure in the httpd.conf file to ensure that the Apache web server runs using the unprivileged user account we established earlier, among other things. Inspect your httpd.conf file to verify that the following statements appear as show in the following. Recall that we decided to run Apache as wwwusr:wwwgrp.

User wwwusr
Group wwwgrp

Also, configure the serverAdmin directive with a valid alias e-mail address such as the following:

ServerAdmin hostmasteryoursecuredomain.com

This will provide a point of contact for your customers, should they experience problems with your site.

Performance-Tuning Directives in httpd.conf

there are a number of performance-tuning directives in the Apache httpd.conf file. As a security professional, you should interpret those directives as DoS prevention statements, since they control resource allocation for users of the Apache server. The following directives control the performance of an Apache server:

  • Timeout: Configures the time Apache waits to receive GET requests, the time between TCP packets for POST or PUT requests, or the time between TCP ACK statements in responses. The Apache default is 300 seconds (3 mintues), but you might want to consider reducing this timer to 60 seconds to mitigate DoS attacks.
  • KeepAlive: Configures HTTP1.1-compliant persistency for all web requests. By default, this is set to On and should remain as such to streamline web communication.
  • KeepAliveTimeout: Determines the maximum time to wait before closing an inactive, persistent connection. Here we will keep this value att the default of 15 seconds, since raising it can cause performance problems on busy servers and expose you to DoS attacks.
  • StartServers: Designates the number of child processes to start when Apache starts. Setting this value higher than the default of 5 can increase server performance, but use care not to set the value too high, because doing so could saturate system resources.
  • MinSpareServers: This setting, like the MaxSpareServers setting, allows for dynamic adjustment of Apache child processes. MinSpareServers instructs Apache to maintain the specified number of idle processes for new connections. This number should be relatively low except on very busy servers.
  • MaxSpareServers: Maintains Apache idle processes at the specified number. Like MinSpareServers, the value should be low, except for busy sites.
  • MaxClients: As its name implies, this setting determines the maximum number of concurrent requests to the Apache server. We will leave this as the default value of 256.

Once you’ve finished editing this section of your httpd.conf, you should see something similar to the following:
Timeout 60
KeepAlive On
KeepAliveTimeout 15
StartServers 5
MinSpareServers 10
MaxSpareServers 20
MaxClients 256

By default, Apache informs web users of its version number when delivering a 404 (page not found) error. Since it is good practice to limit the information you provide to would-be hackers, we will disable this feature. Recall that we already altered the Apache server signature and that we installed mod_security. Both of these actions should be enough to obfuscate our server because they both alter the default behavior. If you would like to turn off server signatures completely, you can always set the ServerSignature directive to Off and the Server tokens to Prod. this will disable Apache signatures entirely.

The Apache web server includes mechanisms to control access to server pages and functionality. The statement syntax is part of the directive and is fairly straightforward: you specify a directory structure, whether default access is permitted or denied, and the parameters that enable access to the directory if access is denied by default. There are many options for fine-grained control that you should learn by reading the Directory Directive section of the Apache Core Features document in the current version of the Apache documentation.

Regardless of the access you provide to your customers, you should secure the root file system using access control before placing your server into a production environment. In you httpd.conf file, you should create a statement in the access control directives area as follows:

<Directory />

Order, Deny, Allow
deny from all


This statement will deny access to the root file system should someone intentionally or accidentally create a symlink to /.

In the next article, we will discuss further hardening our Apache server using authentication mechanisms.

External Links:

The official Apache website

Apache Server Hardening: Part Three

Apache server hardeningIn the previous article, we discussed configuring the underlying OS and download and verifying Apache. After downloading and verifying the Apache source code, you’ll need to do some research to understand what options you want to compile into your web server. There are many modules, such as mod_access and mod_ssl, that can be added into your server to provide additional functionality and security. A full list of Apache Foundation-provided modules can be found at the Apache web site. When choosing modules, be sure you select only what you need. Compiling extra, unnecessary modules will only result in a less secure, slower web server.

You should use caution in enabling and disabling services at compile time. Before you do so, determine the dependencies of your web server code. Failure to understand what services you require to operate could result in loss of critical functionality. It might be prudent to test your configuration in a lab environment before disabling services on a production server.

Once you’ve decided which modules and configurations to use, you should accomplish one final task before building your software. Obscure the Apache version information located in the ap_release.h file located in the $[ApacheSrcDir]/include directory. To do so, use vi, gedit, or the editor of your choice and alter the following lines to change the Software Vendor (Apache Software Foundation) information:

#define AP_SERVER_BASEVENDOR “Apache Software Foundation”

In general, you’ll need to perform three steps to compile and install your Apache Web server, as follows:

  1. From the $[ApacheSrcDir] directory, run ./configure.
  2. after configuring source, run ./make to compile the software.
  3. After compiling the software, run ./make install to install the Apache web server.

During the first step, you’ll decide what is added to the Apache server at compile time.

Add/Remove Module name Purpose
Remove Status Provides potentially dangerous information via server statistics web page
Remove Info Provides potentially dangerous configuration information
Remove Include Provudes server-side include (SSI) functionality
Remove userdir Permits users to create personal homepages in ~user home directories
Add mod_ssl Provide cryptography using the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols
Add mod_log_forensic Increases granularity of logging to forensic levels
Add mod_unique_id Required for mod_log_forensic module

mod_security, a third-party Apache module available from www.modsecurity.org, provides application firewall intrusion protection and prevention. To enable mod_security, you must download and compile the software into the Apache web server. Adding mod_security increases the secure operation of your Apache web server and adds functionality including, but not limited to, the following:

  • HTTP protocol awareness
  • Anti-evasion technique prevention such as URL encoding validation and URL decoding
  • Enhanced audit logging
  • Bult-in chroot functionality
  • Buffer overflow protection
  • HTTPS filtering

We will enable mod_security in our example because it adds so many security features to our system. Once you have downloaded mod_security source from the download page of the mod_security website, perform the following steps as root:

cd $[modsecuritySrcDir]/apache2

mkdir -r $[ApacheSrcDir]/modules/security

cp mod_security.c Makefile.in config.m4 \ $[ApacheSrcDir]/modules/security

cd $[ApacheSrcDir]


Now mod_security appears like other Apache modules. When we compile Apache, we will enable it using the command -enable-security. There are many options to consider in configuring the Apache source code for compilation. To view a list of options, issue the command ./configure –help from the $[ApacheSrcDir] directory.

After successfully configuring the source code, proceed with running make and make install. You will see a message indicating successful completion of building and installing Apache. Now that we have successfully installed the Apache web server software, we will proceed to the next step: configuring the httpd.conf file for secure operation. We will cover that in the next article.

External Links:

The official Apache website

The official ModSecurity website

Apache Server Hardening: Part Two

Apache server hardeningAfter you’ve patched and hardened your OS, you’ll need to accomplish a couple quick tasks prior to obtaining, compiling and installing the Apache software. A critical part of installing Apache is to provide a user account and group that will run the web server. It is important that the user and group you select to be unique and unprivileged to reduce exposure to attack.

It is important not to run your Apache web server as the user Nobody. Although this is often a system administrator favorite and seemingly unprivileged account for running Apache and other services, the Nobody account has historically been used for root-like operations in some OSes and should be avoided.

Configuring Accounts

Choose and configure a user and group account using the following Unix OS steps. In this example, we will use wwwusr and wwwgrp as the Apache username and group, respectively.

  1. As root from the command line, type groupadd wwwgrp to add a group.
  2. Type useradd -d /usr/local/apache/htdocs -g wwwgrp -c “Apache Account” -m wwwusr to add the user.

The second step creates the user account but also creates a home directory for the user in /usr/local/apache/htdocs.

After creating the user and group accounts, you’ll need to lock down the wwwusr user account for use with Apache. By locking the account and providing an unusable shell, this action ensures that no one can actually log into the Web server using the Apache account:

  1. As root from the command line, type passwd -l wwwusr to lock the Apache account.
  2. Type usermod -s /bin/false wwwusr to configure an unusable shell account for the Apache account.

Now you’re ready to get the Apache software and begin installation.

Downloading and Verifying Apache

Because Apache is open-source software, you can freely download the binaries or source code and get going with your installation. Although there are many locations from which you could download the software, it is always best to obtain the Apache software directly from an approved Apache Foundation mirror listed at the mirror list page of official Apache site.

You’ll need to decide whether to install the server using precompiled binaries or to compile the source code yourself. From a security and functionality perspective, it is usually better to obtain the source code and compile the software, since doing so permits fine-tuning of security features and business functionality. perspective, it is usually better to obtain the source code and compile the software, since doing so permits fine-tuning of security features and business functionality. Here we will discuss compiling the Apache server from source code, starting with verifying the integrity of your download.

To verify the checksum, you will need additional software called md5sum that might be part of your OS distribution. If it is not, you can download the software as part of GNU Coreutils available at the Coreutils page of the official GNU Operating System website. To verify the Apache checksum, perform the following steps. In this example, we’ll use Apache version 2.4.9:

  1. As root from the command line, change directories to where you downloaded the Apache source code tarball and checksum file.
  2. Type cat httpd-2.4.9.tar.gz.md5 to see the exact md5 checksum string. You should see something like f72fb1176e2dc7b322be16508isl39d httpd-2.4.9.tar.gz.
  3. from the same directory, type md5sum httpd-2.4.9.tar.gz.md5 to obtain the checksum from the tarball. You should see the identical string shown in Step 2. If you do, the software you downloaded is authentic.

In the next article, we’ll cover compiling Apache.

External Links:

The Official Apache site

The official GNU Operating System site

New Website Launched

Although pfsensesetup.com remains my primary focus, I have launched a new website: eVPN Gratis. The emphasis on this new blog will be on reviews and information about free VPN services. There are only two articles posted so far, but I will be adding new articles in the upcoming weeks.

Apache Server Hardening: Part One

Apache server hardeningIn the next few articles, we will take a look at Apache server hardening. We will begin by considering OS vulnerabilities.

Apache Server Hardening: Patch the OS

Code deficiencies can exist in OSes and lead to OS and application vulnerabilities. Therefore, it is imperative that you fully patch newly deployed systems and remain current with all released functional and security patches. At regular intervals, review the published vulnerabilities at your OS manufacturer’s web site.

This table lists some popular OSes and their security sites:

Operating System Security Information Site
Oracle Solaris www.oracle.com/technetwork/server-storage/solaris11/technologies/security-422888.html
Microsoft www.microsoft.com/technet/security/default.mspx
Mac OS www.apple.com/support/security
RedHat Linux www.redhat.com/security
FreeBSD www.freebsd.org/security
OpenBSD www.openbsd.org/security.html

Because Apache is so often run on various Unix, Linux, and BSD distributions, we include patching steps here so that you can confidently deploy your Apache web server on a well-hardened foundational OS, which will facilitate Apache server hardening. In general, however, each vendor provides a full suite of tools and information designed to help you remain current of their released software updates. Become familiar with each of your vendor’s OS patching methodologies and software tools. As the security administrator, you should reserve predetermined time periods for maintenance windows during episodes of low customer activity. However, the discovery of serious OS vulnerabilities could necessitate emergency downtime while patches are applied.

Like patching, all systems used to provide services such as HTTP and HTTPS to customers should be thoroughly hardened before they are placed in a production environment. Hardening includes many steps such as the following:

  • Setting file permissions
  • Locking down accounts
  • Establishing proper OS security policies
  • Configuring host-based firewalls
  • Disabling vulnerable services

Now that we have a secure OS, it’s time to discuss how to properly and securely configure the Apache web server.

The Apache Web server is a powerful application through which you can deliver critical business functionality to customers. With this power comes the possibility of misuse and attack. To ensure that your Apache server is running securely, we have compiled a series of steps for Apache server hardening. You might also want to read additional information or review other Apache security checklist documents before deploying your Apache server. An excellent reference guide is the CIS Apache Benchmark document available at the Center for Internet Security and the NIST Apache Benchmark document available at csrc.nist.gov/checklists/repository/1043.html.

You should follow three general steps when securing the Apache web server:

  • Prepare the OS for Apache web server
  • Acquire, compile, and install the Apache web server software
  • Configure the httpd.conf file

We will cover all three of these crucial steps in future articles.

External Links:

13 Apache Web Server Security and Hardening Tips at www.tecmint.com

Apache 2.0 Hardening Guide

Apache Server Hardening & Security Guide at chandank.com

Apache Server Vulnerabilities

Apache server

The Apache Web Server

The Apache HTTP Server is a web server application based on NCSA HTTPd. Development of Apache began in early 1995 after work on the NCSA code stalled, and it quickly overtook HTTPd as the dominant web server, and has been the most popular web server in use since April 1996. As of June 2013, Apache was estimated to server 54.2 percent of all active websites, so if you come across a website, there’s a better than even chance that it’s hosted by an Apache server (this site is).

The Apache server supports a variety of features. Many of these features are implemented as compiled modules which extend the core functionality. Some common language interfaces support Perl, Python, Tcl, and PHP. Other features include Secure Sockets Layer and Transport Layer Security support. Because the source code is freely available, anyone can adapt the server for specific needs, and there is a large public library of Apache server add-ons.

Although the main design goal of the Apache server is not to be the fastest web server, Apache does have performance similar to other high-performance web servers. Instead of implementing a single architecture, Apache provides a variety of MultiProcessing Modules (MPMs) which allow Apache to run in a process-based, hybrid (press and thread) or event-hybrid mode, to better match the demands of each particular infrastructure. The multi-threaded architecture implemented in Apache 2.4 should provide for performance equivalent or slightly better than event-based webservers.

Apache Server Vulnerabilities

All software systems have the same general types of vulnerability and Apache is no different. It can be adversely affected by any one of the following problems: [1] poor application configuration; [2] unsecured web-based code; [3] inherent Apache security flaws, and [4] fundamental OS vulnerabilities.

Apache has many default settings that require modification for secure operation. Nearly all configuration information for Apache Web server exists within the httpd.conf file and associated Include files. Because many configuration options exist within these files, it can be easy to make configuration errors that expose the application to attack.

The second manner in which vulnerabilities are exposed is via poorly implemented code on the Apache server. Often, Web developers are far more concerned with business functionality than the security of their code. For instance, poorly written dynamic web pages can be easy denial of service (DoS) targets for attackers, should coded limitations be absent from back-end database queries. Simply publishing confidential or potentially harmful information without authentication can provide enemies with ammunition for attack. For these reasons, you must review and understand not only the Apache application but the information and functionality being delivered via the system.

As with Microsoft’s IIS server, vulnerabilities can exist within the Apache server’s application code itself. There are many means by which hackers can breach or disable an Apache system, such as:

  • Denial of Service (DoS)
  • Buffer overflow attacks
  • Attacks on vulnerable scripts
  • URL manipulation

Occasionally, Apache security flaws are discovered and announced by Apache or by various security groups. The Apache development team is typically quick to respond and distribute patches in response to such events. For this reason, it is critical that you be vigilant in your attention to security newsgroups and to Apache’s security advisory site.

Another source of vulnerability within an Apache web server could occur as a result of foundational security flaws in the OS on which Apache is installed. Apache can be run on just about any OS. You should be very familiar with the specific security vulnerabilities for any OS on which you run Apache.

In the next article, we will discuss the merits of patching and securing the OS as a means of securing your Apache server.

External Links:

The official Apache web site

Apache HTTP Server at Wikipedia

The official Apache Software Foundation web site

Apache web server resource site

Chris Buechler Interviewed

Chris Buechler of the pfSense project was interviewed on Jupiter Broadcasting’s BSD podcast. The interview begins 13 minutes and 13 seconds into the podcast.

NoMachine Client Installation and Configuration


Running the ps command on a computer running Xvnc.

In the previous article, we covered installation of the NoMachine server under Linux Mint. In this article, we will cover installing and running the NoMachine client under Windows.

First, we have to make sure vncviewer is running on the computer running the NoMachine server. This can be done by typing vncserver in a terminal window. You can also specify several options. For example:

vncserver -geometry 800×600

would create a VNC desktop 800 pixels wide and 600 pixels deep. The following command:

vncserver :1

would create a VNC desktop with a display number of 1 (omitting this parameter causes VNC to use the next available display number). This command:

vncserver -depth 24

creates a VNC desktop with a pixel depth of 24 (true color). Other permissible values are 8, 16 and 15. Consult the vncserver man page for other options.

Once you have started vncserver, you probably want to check to make sure it is running. To do so, you can type:

ps -eaf | grep Xvnc

If XVnc is running, you should see a line similar to the one in the screenshot shown at the beginning of this article.

Downloading and Installing the NoMachine Client in Windows


The NoMachine setup wizard.

Now we need to install the NoMachine client in Windows. First, we download the client at the NoMachine web site. Then run the NoMachine executable, either by selecting Run from the Start menu and selecting the executable, or by clicking on the executable in Windows in windows Explorer.

You will be presented with the NoMachine Setup Wizard dialog box. Click on “Next” to continue installation. The next dialog box contains the End-User License Agreement (EULA); if you agree with the terms, click on the “I accept the agreement” radio button and click “Next“. The next dialog box allows you to change the installation path; if you want to install the NoMachine client into a different directory, change it here and click “Next“. The software will install now. You may see dialog boxes which read “The software you are installing has not passed Windows Logo testing”; if so, click on “Continue Anyway” to continue. Once installation has completed, a dialog box will appear to inform you so; click on “Finish“.

From the Start menu, navigate to Programs -> NoMachine -> NoMachine to start the NoMachine client. If this is the first time you are running the program, the first window will show you how to use the program. Click on “Continue” to advance to the next screen.

If this is the first time you have run the NoMachine client, the next screen will be the “Create New Connection” wizard. Here you can enter the IP address of the computer to which you want to connect. Once you have set up the remote computer, double-click on it to connect to the computer.

After a few seconds, the NoMachine client will prompt you for login credentials. Enter your username and password; if you want NoMachine to save the password, check the “Save the password in the connection file” check box. Once you are done, click “OK“. After another few seconds, you should be connected to the remote computer. If this is the first time you have run NoMachine, there will be two screens with instructions on how to use the interface. After that, You will see a screen that gives you the following choices: [1] Display the menu panel covering all screen (the default), or [2] Display the menu panel as a window. Choose the way you want the menu panel displayed and click “OK“.

The next screen controls the option for audio streaming. Audio is forwarded to the client, but you can control whether audio is played on the remote server. Check the “Mute audio on the server while I’m connected” to mute the audio, and click on “OK“. The next screen controls the option for display resolution. If the remote machine has a different resolution than the client, you can check the “Change the server resolution to match the client when I connect” check box to make sure the resolution matches. Click the “OK” button when you are done choosing this option.

Now you should be connected to the remote desktop. If you want to change the settings for the client, hover your mouse over the upper right corner; when the page-turning icon appears, click on it and the settings will appear. There are seven options here: “Input“, “Devices“, “Display“, “Audio“, “Mic in“, “Recording“, and “Connection“. Click the icon for the settings you want to change. You can now change settings; click on “Done” when you are finished and click “Done” again to exit out of the settings screen and return to the remote desktop.

External Links:

The official NoMachine web site

NoMachine Server Installation and Configuration


Installing the NoMachine server using the Debian package installer (dpkg).

In the previous article, we introduced the X Window system and discussed different X Window remote desktop options. In this article, I will cover installation of the NoMachine remote desktop server and the various server options.

To set up the NoMachine server, download and install it whatever method is appropriate for your Linux distribution. As far as I know, it is not in any of the repos. To install the NoMachine server under Linux Mint, I downloaded NoMachine for Debian Linux and used the Debian package installer to install it:

sudo dpkg -i nomachine.

After a few minutes, the NoMachine server was installed and ready to use.Depending on the distribution you are using, the installation may be more involved. Most of the major distributions should have packages available that make the installation relatively painless.

Configuring the NoMachine Server

Once it is installed, you can launch the NoMachine server (on Linux Mint, it can be found in the Internet program group). The NoMachine server interface has two tabs: one called “Connected users” and a second for “Active transfers“. There is also a “Connections” option to toggle allowing connections. There is also a button called “Connection preferences“.


The Services tab under Connection Preferences in the NoMachine server interface.

In “Connection preferences”, there are six separate tabs: “Services“, “Security“, “Devices“, “Transfers“, “Performance“, and “Updates“. “Services” lists the network services running and allows you to configure the services. In this case, we are running the NX service on port 4000. There are two other options: “Start automatic services at startup“, which causes services marked as automatic to be started when the machine starts. “Advertise this computer on the network” causes NoMachine to broadcast the required information to let other computers discover it on the local network.

The next tab is “Security Preferences“. There are three options here: “Require permission to let remote users connect“, which if selected requires the local user to accept the connection before the remote user can connect to the desktop. The second is “Require permission to let the remote users interact with the desktop“, which if selected causes the users to connect in view-only mode. The third option is “Hide the NoMachine icon in system tray“; if this is selected, the NoMachine menu won’t be accessible in normal conditions, but notifications will be still displayed when somebody connects.

The “Devices” tab controls what devices are made available to the remote user. Disks, printers, USB devices, smart card readers, and network ports are selected by default. There is also an “Enable audio streaming and microphone forwarding” check box which is selected by default. The “Transfers” tab controls transfer preferences. Here you can allow or deny the uploading of files by remote users, and allow or deny the downloading of files. You can also disallow files bigger than a certain size for both uploads and downloads, and set the directory to which files are saved.

The “Performance” tab controls system performance and has four options. “Use a specific display encoding” allows the user to select from a dropdown list of encoding algorithms, including VP8, MJPEG and H264. “Request a specific framerate” allows the user to select a framerate from a dropdown list (a higher frame rate uses more processing power). “Use acceleration for display processing” uses the GPU and accelerated graphics (when available) for better performance. “Use lightweight mode in virtual sessions” causes virtual sessions to only use the X protocol compression, which may require less bandwidth and less computing resources.

The final tab is “Update“, which controls update preferences. There is an “Automatically check for updates” check box, as well as a button to check for updates immediately. This tab also includes information about the product, version number and platform.

Now that we have covered server configuration, in the next article we will cover accessing the system remotely using NoMachine.

External links:

The official NoMachine site

X Window System

X Window

Introducing the X Window System

X Window is the underlying management system for most Unix and Linux GUIs. It takes an entirely different architectural approach than a Microsoft Windows system, in that the X Window system is set up in a client-server architecture similar to VNC. In this model, the X server communicates with various client programs. The server accepts requests for graphical output (windows) and sends back user input (from keyboard, mouse, or touchscreen).

When reading the X Window documentation, you will find that they use the terms server and client in the reverse of what would seem intuitive, meaning the server is where the display is being generated, not the remote machine to which you are connecting. The server in this context may function as an application displaying to a window of another display system, a system program controlling the video output of a PC, or a dedicated piece of hardware. This client-server terminology (the user’s terminal being the server and the applications being the clients) often confuses new X users. But X takes the perspective of the application, rather than that of the end-user. Since X provides display and I/O services to applications, it is a server. Applications use these services; thus they are clients.

Most current implementations of the X Window system are based on the X.Org foundation, which is the open source implementation of the X11 protocol. A closely related project is the XFree86 Project, which is the open source version of the X Window system (which uses the X11 protocol). X11 is the protocol that is used to transfer information about the GUI between the server and the client. The end result of these design decisions is that much like Windows’ built-in terminal server support, two Linux systems can remote access each other via a GUI virtual desktop.

You can configure the X Window System to permit connections from remote systems without any third-party software. While this works, the evolution of desktop Window Managers and common software packages has rendered this method inefficient. A much more robust way to accomplish the same thing is using NX technology developed by NoMachine, which is a highly optimized process and protocol to make X sessions available remotely. The NoMachine remote desktop is available for free (client and server) from the official NoMachine website. Commercial versions are also available. In December 2010, NoMachine announced that forthcoming NX releases (4.0 and up) would be closed source. Fortunately, an open source version of the NX server is called FreeNX, and is available from the official FreeNX website. FreeNX does not support relaying sounds to the client, while the NoMachine server does.

External Links:

X Window System on Wikipedia

NX technology on Wikipedia

The official NoMachine web site

The official Free NX web site

© 2013 David Zientara. All rights reserved. Privacy Policy