Lokkit in action under Ubuntu.

Using Lokkit

Lokkit is an ncurses-based menu for configuring your netfilter firewall that is part of the GNOME desktop. Lokkit is available for most major distributions and can be installed by default on some (such as Fedora). It asks a small number of simple questions and writes a firewall rule set for you. To start Lokkit, type lokkit in a terminal window. [If you don't have lokkit, you can install it from the repos using the apt-get command: sudo apt-get install lokkit]. If you want to review the firewall settings without running the firewall, type:

sudo lokkit -n

To see what services/ports can be managed/opened using lokkit, type:

sudo lokkit –list-services

You can navigate the menus using the Tab key and the space bar to toggle the equivalent of radio buttons, such as the Enable and Disabled options shown here. If you select Enabled on this screen, the default ruleset is applied. To edit any custom settings, press Tab until the Customize button is highlighted and then press Enter.

Lokkit does provide a little more flexibility than the Security Level configuration GUI discussed previously; however, it is still limited. By selecting an interface in Trusted Devices, all traffic from that interface will be permitted. This would typically be used to select the inside interface and designate it as trusted. You do have the option of enabling MASQUERADE. The interface you select is the one that will NAT outbound traffic; therefore, you would generally select your external interface. Some pre-defined services are available, and you can enter your own service information in the “Other ports” section. Once you are satisfied with your choices, press OK and then Enter. This will take you back to the main screen, where you press OK and then Enter to apply the changes.

If you attempt to configure an interface for MASQUERADE, it must also be marked as trusted or Lokkit will generate an error, Bear in mind that although MASQUERADE is limited, it has enough flexibility to configure a firewall similar to a typical home firewall/router device. This makes Lokkit a handy little utility to have in your repertoire should you need to configure a simple firewall quickly. The value of this utility is also increased, because it is available for a wide number of Linux distributions.

External Links:

Lock it down quickly with Lokkit at techrepublc.com

Linux Firewall – The Second Line of Defense at Linuxtopia

The post netfilter Operation: Part Nine (Lokkit) appeared first on pfSense Setup HQ.

The Firestarter GUI in action.

Firestarter is a GUI front end for netfilter and iptables, and its goal is to make it simple for the average user to configure their firewall and protect themselves. Firestarter runs on many Linux distributions and the installation is supported by many automated package management systems (such as yum, apt-get and portage). Firestarter is an excellent choice if your needs are relatively simple for your firewall configuration. To install it manually, download it from www.fs-security.com/download.php. Once it is installed, the first time you start the GUI interface you will need to perform some initial configuration. Follow these steps to configure Firestarter:

1. Start the Firestarter GUI. In Fedora, this is done by navigating to Applications -> System Tools -> Firestarter. This will start the Firewall wizard. Click Forward on the Welcome to Firestarter screen.
2. On the next screen, select your Internet-connected network device from the “Detected device(s):” dropdown box, and place a checkbox in the “IP address is assigned via DHCP” box. When you are done, click Forward.
3. The next screen is the “Internet connection sharing setup” screen, which is basically where you enable NAT. If you want to NAT all of the outbound packets to the external IP address, place a check in the “enable internet connection sharing” checkbox. When this checkbox is enabled, you can select the local area network device. If you only have two interfaces, it should be selected by default. When finished, press Forward.
4. On the final screen, leave the “Start firewall now” box checked and click Save. This will install a service to start Firestarter each time the system boots up. Firestarter will also change the default action for the chains to DENY; therefore, you must explicitly configure any ports you want to permit through the firewall.

The Firestarter GUI is fairly straightforward. The Status tab gives you high-level information such as sent and received data counters per interface and a list of active connections. By clicking the Stop Firewall button, all of the iptables chains are flushed and the default action is changed to ACCEPT. This can be useful for troubleshooting issues to see if they are related to your firewall configuration.

The “Events” tab lists recent blocked connection attempts. The “Policy” tab is where you configure certain rules to permit desired traffic.

For example, if there was a Web server running on the Linux host, you could use the “Policy” tab to permit inbound connection to TCP port 80. The “Editing” dropdown box allows you to choose between inbound and outbound rules to edit. For the Web server example, we selected “Inbound traffic policy“. The policy group you select when you click “Add Rule” determines where the policy is placed. Here are the functions of the various policy groups:

1. Allow Connections From Host: This is used to configure a given IP address, hostname, or network. When you enter the IP information and create a rule in this policy group, all traffic from the configured source is permitted.
2. Allow Service: The allow service policy group is used to permit individual services. You can configure the source to be anyone including a specific IP, or network, or all local area network (LAN) clients. The LAN clients option permits the service through the firewall with a source address that is on the same subnet as the inside network adapter.
3. Forward Service: This option is used only when you are NATing. This allows the firewall to forward a specific port or range of ports, so that a service hosted on an internal NAT-ed device can receive inbound connections from the external network.

The “Outbound traffic policy” window shows a different set of policy groups. There are also the additional radio buttons to select “Permissive by default“, “blacklist traffic“, or “Restrictive by default“, “whitelist traffic“. If you select the restrictive configuration, the default target for the table is DENY, and any rules you create will be PERMIT rules.

The function of the different policy groups toggle between “allow” and “deny” based on whether you select restrictive or permissive mode. The policy groups are outlined here:

1. Allow/Deny Connections to Host: This policy group is used to globally permit or deny outbound access to a given host, IP address, or network range. This policy uses the destination to match the rule. You can use this policy group in permissive mode to list certain Web sites you do not want anyone to have access to.
2. Allow/Deny Connection from LAN Host: This policy group is used to permit or deny all access from a particular host, IP address or network range. This policy uses the source to match the rule.
3. Allow/Deny Service: This policy group permits or denies traffic based on its destination port and source. When you are using permissive mode, this policy group can be used to block all access to the bittorrent ports. The traffic source can be anyone: the firewall itself, LAN clients, or an arbitrary IP, hostname or network range.

Configuring the policies will satisfy the bulk of what you need to accomplish, but there are some additional configuration options available by navigating to Edit -> Preferences. Selecting Interface -> Events allows you to configure some useful options. The “Skip redundant entries’ checkbox only makes one event entry for sequential event entries. This helps prevent the event windows from being flooded by repetitive alerts. You also have the option of entering certain hosts or ports as being exempt from triggering the vent log. After making your selections, click Accept.

Another preferences setting of note is under Firewall -> Network Settings. This allows you to enable Internet connection sharing (the same as during the initial wizard), and enable the firewall host as a Dynamic Host Configuration Protocol (DHCP) server. This allows you to configure the Linux host similarly to a home firewall, which generally acts as a DHCP server in addition to performing NAT and acting as a firewall. The ICMP filtering window also allows you to filter ICMP packets. By default, the permit and deny rules configured by Firestarter apply to TCP and UDP, but not ICMP. This screen allows you to permit the desired types of ICMP traffic. Generally speaking, it is better not to allow any ICMP from the Internet to your firewall or internal network unless absolutely necessary.

One final setting you want to configure is under Firewall -> Advanced Options. In the broadcast traffic section, check both options under Broadcast traffic. In general, you should not permit broadcast traffic to go through your firewall, as doing so poses a security risk. You also want to check the option to “Block traffic from reserved addresses on public interfaces,” which is a common filtering tactic. Because the “private” addresses outlined in RFC 1918 should not be routed through the Internet, there is never a reason to receive traffic sourced from any of those addresses on your outside interface. If you do, it is almost always a hacker attempting to bypass a poorly configured firewall.

Short of any advanced packet mangling, there isn’t much you cannot accomplish using Firestarter as your configuration tool. If you need to implement a more advanced configuration, you could use an alternate tool, or generate the configuration using Firestarter and use those chains as a starting point to add your own more advanced options.

External Links:

The official Firestarter web site

Configuring firewalls with Firestarter at Tech Republic

Firestarter – A High-Level Graphical Interface Iptables Firewall for Linux Systems at tecmint.com

Install the Firestarter Firewall on Ubuntu Linux at howtogeek.com

The post netfilter Operation: Part Ten (Firestarter) appeared first on pfSense Setup HQ.

Easy Firewall Generator in action.

Easy Firewall Generator

Easy Firewall Generator is not a GUI per se, but it does help simplify your netfilter configuration and avoid the need to be familiar with the iptables syntax. By using the Web page at http://easyfwgen.morizot.net/gen/index.php, you can enter the relevant information and click the Generate Firewall button. As you select options, if additional information is needed click the Generate Firewall button and the page will refresh and provide the additional input fields. When all of the required information has been entered, the page will change to a text page that can be copied and pasted for iptables to read as a saved configuration. In Fedora, the iptables configuration is stored in /etc/sysconfig/iptables. Although this method requires you to replace the default iptables configuration file used by your distribution, it is fairly painless, and supportes all of the same basic functionality as Firestarter.

Firewall Builder

Firewall Builder is the most complete GUI offering for managing netfilter firewalls with features and capabilities comparable to some commercial firewall products. As is almost always the case, this functionality and capability come at a price: as far as netfilter GUIs are concerned, Firewall Builder is not the easiest to configure and use. If you want or need its superior management capabilities, however, the extra effort is well worth it. (Download firewall builder from www.fwbuilder.org). Firewall Builder manages netfilter firewall as well as ipfilter, OpenBSD PF, and Cisco PIX firewalls. Firewall builder runs on many popular operating systems including Red Hat, Mandrake, Suse, FreeBSD, Mac OS X, and Windows XP/Vista/7/8.

Firewall Builder 5.1 on startup under Windows.

Firewall Builder operates differently than all of the GUIs covered so far. It uses an object-based approach. Essentially, you must define an object to represent any entity that you want to use in the firewall rules. In most cases this means a source, a destination, and a service port at a minimum. Both the configuration and the GUI bear a strong resemblance so that of the Checkpoint Firewall GUI. Once the objects are defined, you can drag or drop them into the rules in order to permit or deny communications between the two.

As of this writing, the current version of Firewall Builder is 5.1. Under Windows, navigating to Start -> Programs -> Firewall Builder 5.1 -> FWBuilder, which opens the main Firewall Builder window. Firewall Builder can also easily be installed under Linux. Under Mint Linux, I was able to install Firewall Builder using the apt-get command, like so:

sudo apt-get install fwbuilder

Once fwbuilder is installed, it can be accessed by clicking on the start menu, then navigating to Internet -> Firewall Builder, which will bring up the main Firewall Builder window.

In the next article, we will cover how to configure firewall rules in Firewall Builder.

External Links:

The official Firewall Builder website

Getting Started With Firewall Builder at howtoforge.com

The post netfilter Operation: Part Eleven (Easy Firewall Generator and Firewall Builder) appeared first on pfSense Setup HQ.

Firewall Builder on startup.

In the previous article, I introduced Firewall Builder, including some notes on installation under Windows and Linux. In this article, I will step through the process of adding a firewall object and configuring it.

Firewall Builder: Creating a Firewall Object

In this example, I installed Firewall Builder under Linux Mint. Initially, there are three main options in the main dialog area: “Create New Firewall“, “Import Existing Configuration“, and “Watch ‘Getting Started’ Tutorial“. click on “Create New Firewall“, which will open the New Firewall dialog box.

The New Firewall dialog box.

In the New Firewall dialog box, enter the name for the new firewall (in this case OFFICE01). For the firewall software, select iptables from the dropdown box. For the OS, choose Linux 2.4/2.6 and click Next. The next window allows you to configure the interfaces on the firewall. You can do it manually, or if the firewall is running SNMP, you can discover them via SNMP. Here, we select Configure interfaces manually and click Next. This will bring up the manual configuration window. Enter the relevant information for each network interface. The name must correspond to the actual interface name (which is the same as if you had entered ifconfig on the Linux host), such as eth0. The Label is a human friendly name for easy reference such as OUTSIDE. When you are done entering the information for a given interface click Add. When you have entered the information for all interfaces (typically at least an INSIDE and OUTSIDE), click Finish. You must designate one of the interfaces on the firewall as the management interface, typically the INSIDE interface. Do this by navigating to the firewall in the object tree. As you select each interface in the object tree, there is a “Management interface” checkbox in the dialog area. Check this box for the interface you want to use. This will be the interface that Firewall Builder uses to connect and upload the firewall rules to.

Firewall Builder: Adding a Network

The button for adding new networks/hosts/services/etc is in the upper left, adjacent to the back arrow button.

Now that you have the basic firewall defined, you need to define something for it to talk to. In this case, we will assume that 192.168.1.0/24 is you internal network, and you want to allow outbound Web browsing and access to an internal Web server (WEB1). For starters, you need to create an object to represent the internal network. Follow these steps to create the network object:

1. Click on the “plus” button in the main window (it’s adjacent to the back arrow) and select New Network from the dropdown list.
2. Enter INTERNAL for the name of the network, and use 192.168.1.0 for the Address field. Enter 255.255.255.0 for the Netmask.
3. Next, we’ll create an internal Web server at 192.168.1.2. Again, click on the “plus” button, only this time select New Host.
4. Enter WEB1 for the name of the object. Click the Use preconfigured template host objects check box and click Next.
5. Select PC with one interface and click Finish.
6. Next, you may have to navigate the object tree (in order to make the object tree visible, you may have to go to the View menu and unselect Editor Panel). Expand the object tree to User -> Objects -> Hosts -> WEB1 -> eth0 -> WEB1. Edit the IP address to be 192.168.1.2 and click Apply.
7. Next, define the appropriate services to allow Web-browsing. Click on the “plus” button again, and this time select New Service.
8. Enter HTTP for the name. Leave the source port ranges at zero, but change the destination port range to start and end at 80.
9. Repeat the previous two steps for HTTPS on port 443 for secure Web pages.

Now that we have created the network object, in the next article, we will cover defining the firewall rules to allow inbound web traffic and uploading the rules to the firewall.

External Links:

The official Firewall Builder web site

Using Firewall Builder on Linux to Create Firewalls from Scratch on linux.com

Firewall Builder Tutorial: The Basics on YouTube

The post netfilter Operation: Part Twelve (Firewall Builder continued) appeared first on pfSense Setup HQ.

Adding inbound and outbound rules for the web server in Firewall Builder.

In the last article, we discussed the process of setting up a firewall object in Firewall Builder and adding a network to it, as well as adding a web server to the network. This seems like a lot of additional effort; however, the real advantage of an object-oriented approach is seen when it comes time to configure the rules. With all of the appropriate objects in place, let’s define the rules to permit the inbound HTTP traffic.

1. Create a new rule by either navigating to Rules -> Insert New Rule from the menu at the top of the window, or click on the large plus (+) beneath the top menu.
2. Allow inbound HTTP to WEB1. Click on WEB1 in the object tree and drag it to the destination cell for rule 0.
3. Now drag the HTTP and HTTPS service from the object pane to the Service cell in rule 0.
4. Right-click the big red dot in the Action column and select Accept. This allows the inbound Web traffic to access WEB1.
5. To allow outbound Internet access. create another rule by either navigating to Rules -> Insert New Rule or by clicking on the big plus (+) beneath the menu.
6. Drag and drop HTTP and HTTPS from the object tree into the Service column of rule one.
7. Drag the Network object INTERNAL from the object tree to the Source column of the new rule.
8. Right-click on the Action column for rule 1 and change the action to ACCEPT.
9. Although our rules seem simple at the moment, let’s apply them to see show things work. First, save your work by navigating to File -> Save or File -> Save As.
10. Next, right-click the OFFICE01 Firewall and select Compile.
11. When the “Select Firewalls for compilation” window comes up, OFFICE01 should be checked. When satisfied with your selection, click Next. When the compilation is complete you should see “Success” in the “Progress” column. After verifying that the compilation was successful, click Finish.

Compiling and Uploading the Firewall Rules

Compiling the firewall rules.

The next step is to tell Firewall Builder where to find the SSH executables, because this is how Firewall Builder uploads the configuration to the firewalls. You need to have SSH working on both the firewall and the Firewall Builder console, assuming they are on different systems.

1. Select Edit -> Preferences from the menu.
2. Select the Installer tab and click the Browse button.
3. Navigate to the location of your desired SSH utility and click Open. Note that if you are using Windows for the Firewall Builder host, you cannot select PUTTY.EXE; you must use the command-line PuTTY program PLINK.EXE. In Linux, you can leave the default setting (ssh).
4. After selecting the SSH executable, click OK.
5. Right-click the OFFICE01 firewall in the object tree, and select Install.
6. Select the firewalls you wish to install, and click Next.
7. Enter the username and password for the SSH connection.
8. All other fields are optional; however, it is recommended that you check “Store a copy of the fwb on the firewall.” When satisfied with your choices, click Ok.

After the upload completes, you will get a status of “Success”. Checking your firewall (iptables -L) shows you the new rules that are listed.

// ]]>

One point that should be made is that you have to be careful when configuring the rules. It is always a good idea to creat the rules to permit administrative access before any others. This is because as soon as you configure the default policies to DROP, your SSH connection will no longer be permitted unless you have it added to the access list. And if you forget to do this, you could find that you no longer have remote access to your firewall after applying the policy. If that happens, you won’t even be able to remotely connect to update the policy and change the ACLs.

External Links:

The official Firewall Builder site

The post netfilter Operation: Part Thirteen (Firewall Builder, continued) appeared first on pfSense Setup HQ.

Adding inbound and outbound NAT rules in Firewall Builder.

As you can probably see, once you have completed the up-front work of defining your objects, adding or modifying rules is simple. Additionally, unlike the other free GUI solutions, Firewall Builder allows you to centrally and securely administer all of your (supported) firewalls from one location.

Notice that the default chains have rules matching the rule you configured in Firewall Builder, with a target of RULE_<RULE_NUMBER>. These additional chains are used to configure the logging. there s also a rule at the beginning of all chains to ACCEPT traffic related to an established session. This is generally desirable but is still configurable. To remote this automatically generated rule, select the firewall in the object tree and click on Firewall Settings in the dialog area. There is a checkbox that is selected by default called “Accept ESTABLISHED and RELATED packets before the first rule.” Although the Firewall Builder policies you’ve configured can handle any basic rules you might need, there are still a few more issues to cover. If you need to NAT with your Linux firewall, configuring it with Firewall Builder is easy. Follow these steps so that your firewall with NAT all the traffic from the internal network to the DHCP address used on the outside interface. This configuration is also known as source.nat because it is the source address that is being changed.

1. In the Object Tree, select NAT.
2. Move your mouse to the pane to the right of the Object Tree, right-click and select Insert Rule.
3. Drag your INTERNAL network object from the object tree to the Original Src column in the new NAT policy.
4. Drag the external interface on the firewall from the object tree to the “Translated Source” column in the NAT policy.

Now, save, compile and install the new policy. Now traffic originating from the internal network will be NAT-ed to the IP on the external interface. Although this source NAT configuration will allow all your internal users to reach the internet, you will need to use destination NAT if Internet users need to reach an internal server. Because the internal server is using a private IP address (which is not routable on the Internet), you need to translate this destination to an IP address that the external users can reach. To configure packets destined for the firewall’s single public IP address to an inside resource using destination NAT, follow these steps:

1. In the Object Tree, select NAT.
2. Right-click on rule number zero of the existing NAT ule and select Add rule at Bottom.
3. Drag the firewall OUTSIDE interface into the Original Destination column of the new rule.
4. Drag the appropriate services (HTTP and HTTPS) into the Original Service column of the new rule.
5. Drag the internal server into the translated destination column of the new rule.

Firewall Builder: Creating a Time Policy

Creating a time policy with Firewall Builder.

Another nice feature is being able to create a time policy. In this example, we’ll alter the rules so the internal systems can only surf the web from noon to 1:00 PM:

1. In the Object Tree, right-click Time, and select New Time Interval.
2. In the “Name” field, we’ll call this rule LUNCH.
3. In the two time fields provided, enter a time for the rule to START and a time for the rule to STOP. In this case we will enter 12:00 and 13;00 and leave the date field as zeros. You can check off every day of the week at the below the time fields, so the time interval applies to all days. When done, click Apply.
4. Drag the LUNCH time interval from the Object Tree to te Time column of rule #1.

Now, rule #1 (which permits outbound web surfing) will only be active from noon to 1:00 PM. The ability to configure the rules to be active based on the time of day is a very powerful feature. If the organization is a strictly 8 AM to 5 PM type of place, you could configure the firewall to disable all access during non-business hours. Alternatively, certain non-business-related protocols could be enabled after the normal business day ends.

External Links:

The official Firewall Builder site

The post netfilter Operation: Part Fourteen (Firewall Builder, conclusion) appeared first on pfSense Setup HQ.

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.4.1.29.5.i386.deb

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

The post NoMachine Server Installation and Configuration appeared first on pfSense Setup HQ.

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

The post NoMachine Client Installation and Configuration appeared first on pfSense Setup HQ.

After 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

The post Apache Server Hardening: Part Two appeared first on pfSense Setup HQ.

In 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”
#define AP_SERVER_BASEPRODUCT “Apache”

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.

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]

./buildconf

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

The post Apache Server Hardening: Part Three appeared first on pfSense Setup HQ.

In 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 \
“|(^application/x-222-form-urlencoded$|^multipart/form-data;)”

# 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

</Directory>

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

The post Apache Server Hardening: Part Four (httpd.conf) appeared first on pfSense Setup HQ.

Apache User Authentication

Apache also includes several ways in which you can authenticate customers using your web server such as LDAP, SecureID, and basic .htaccess, to name a few examples. To use authentication mechanisms beyond basic .htaccess, you must compile additional functionality when you’re building Apache. Like access control, authentication mechanisms are specified as part of the directive.

The two steps to enabling basic .htaccess user authentication are:

1. Creating an htpasswd file to store user credentials.
2. Adding a directive to the httpd.conf file to protect a directory structure.

This is different than adding a login form on a web page and creating your own authentication. Let’s use an example to demonstrate how easy it can be to add authentication. In our example, we will secure a directory called /securedir and permit only customers Homer and Marge access to the files in that directory.

First, let’s create an htpasswd file somewhere not in the web server document root by issuing the following command:

htpasswd -c /usr/local/apache/passwdfile homer
New password: *****
Re-type new password: *****
Adding password for user homer

Next, we’ll add Marge to the list as well. This time we don’t need to use the -c argument, since our htpasswd file already exists:

htpasswd /usr/local/apache/passwdfile marge
New password: *****
Re-type new password: *****
Adding password for user marge

Now that we’ve established our customer accounts, we’ll finish by adding a directive to the httpd.conf file to protect the /securedir directory as follows:

<Directory /usr/local/apache/htdocs/secure>
AuthType Basic
AuthName “Access for authenticated customers only”
AuthUserfile /usr/local/apache/passwdfile
require user marge homer

</Directory>

Now, when anyone attempts to access the /securedir directory, they’ll be prompted for a username and password. Because we specifically require only Marge and Homer, only they will be permitted to use the directory structure, if they authenticate properly.

You can also restrict access based on a domain or IP address. The following directive will do this:

Order deny, allow
Deny from all
Allow from allowable-domain.com
Allow from XXX.XXX.XXX
Deny from evil-domain.com

You can specify the first three (or one or two) octets of an IP address defining the allowable domain.

Although this example involves modifying the httpd.conf file to control directory access, there is another way. You can create an .htaccess and .htpasswd file in the directory to which you want to control access. The .htaccess file should contain the same directive we described above. The .htpasswd file must be created using htpasswd. In the above example, to add access for Homer and Marge, we would first create (or clobber if it already exists) the password file /securedir/.htpasswd:

htpasswd -c .htpasswd homer

Now that we have created .htpasswd, we can add user marge to the existing password file (which contains one user, homer):

htpasswd .htpasswd marge

Within the directive is a subdirective called Options that controls functionality for the directory structures specified in the directive. The available options are listed below:

Many of the listed options are not relevant to our installation, since we disabled Includes and CGI during compile time. Regardless, a good default directive disabling most options is shown here:

<Directory “/usr/local/apache/htdocs”>
Order, allow, deny
Allow from all
Options -FollowSysLinks -ExecCGI -Includes -Indexes \
-MultiViews
AllowOverride None

</Directory>

At this point, your Apache server should be relatively secure. In the next article, we will discuss some Apache logging directives so that we can better monitor our server.

External Links:

Authentication and Authorization at the official Apache website

Apache Web Login Authentication at yolinux.com

The post Apache Server Hardening: Part Five appeared first on pfSense Setup HQ.

Additional Directives

Within the directive is a subdirective called Options that controls functionality for the directory structures specified in the directive. The available options are listed below.

Many of the listed options are not relevant to our installation, since we disabled Includes and CGI during compile time. Regardless, here is a good default directive disabling most options:

<Directory “/usr/local/apache/htdocs”>
Order allow,deny
Allow from all
Options -FollowSysLinks -ExecCGI -Includes -Indexes \
-MultiViews
AllowOverride None

</Directory>

At this point, your Apache server should be relatively secure. Now, we move on to configuring logging options.

There are many reasons to configure logging on you Apache server. Whether helping you see top page hits, hours of typical high volume traffic, or simply understanding who is using your system, logging plays an important part of any installation. More importantly, logging can provide a near-real-time and historic forensic toolkit during or after security events.

to ensure that your logging directives are set up correctly, we will provide an example of the logging options in the Apache web server. Apache has many options with which you should familiarize yourself by reading the Apache mod_log_config documentation page. This will help you understand the best output data to record in logs. Also, recall that we compiled Apache with mod_log_forensic, which provides enhanced granularity and logging before and after each successful page request.

An example logging configuration file is shown here:

ErrorLog /var/log/apache/error.log
LogLevel Info
 Logformat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”\”%{forensic-id}n\” %T %v” full
CustomLog /var/log/apache/access.log combined
ForensicLog /var/log/apache/forensic.log

The example provides a customized logging format that includes detailed output and places all the log files in the /var/log/apache directory.

After you have installed and configured your Apache server, you will need to do some quick cleanup of files that could represent a security threat. In general, you should not leave the source code you used to compile Apache on the file system. It is a good idea to tar the files up and move them to a secure server. Once you’ve done so, remove the source code from the Apache web server.

Removing Directories and Setting Permissions

You’ll also want to remove some of the default directories and files installed by the Apache web server. To do so, execute the following commands on your web server. If you have added content into your document root directory, you will want to avoid the first command:

rm -fr /usr/local/apache/htdocs/*
rm -fr /usr/local/apache/cgi-bin
rm -fr /usr/local/apache/icons

After removing files, let’s ensure that our Apache files have proper ownership and permissions before starting our server.

As we discussed previously, the Apache web server should be run as an unprivileged and unique account. In our example, we used the user wwwusr and the group wwwgrp to run our server. Let’s make sure our permissions are properly set by running the following commands:

chown -R root:wwwgrp /usr/local/apache/bin
chmod -R 550 /usr/local/apache/bin
chown -R root:wwwgrp /usr/local/apache/conf
chmod -R 660 /usr/local/apache/conf
chown -R root:wwwgrp /usr/local/apache/logs
chmod -R 664 /usr/local/apache/logs
chown -R root /usr/local/apache/htdocs
chmod -R 664 /usr/local/apache/htdocs

Monitoring Your Server

Even with the best defenses and secure configurations, breeches in your systems and applications could occur. Therefore, you cannot simply set up a hardened Apache web server and walk away thinking that everything will be just fine. Robust and comprehensive monitoring is perhaps the most important part of securely operating servers and applications on the Internet.

In Apache, there are several things to consider that will help you to identify and react to potential threats. Your primary source of data will be through Apache and OS logs. Even with small web sites, however, sifting through this information can be a challenge. One of the first things to consider is intergrating your Apache logs with other tools to help organize and identify potential incidents within the log file. Many open source and commercial products are available to aid you in securing your site. One such open source tool is called Webalizer, available at the http://www.webalizer.org/, which features graphical representation of your Apache log file contents.

SNMP polling and graphing constitute another methodology commonly employed for secure monitoring. Often, it is extremely difficult to gauge the severity or magnitude of an even without visualization of data from logs or SNMP counters. One tool you might consider using is a module called mod_apache_snmp, available at Sourceforge. The module can provide real-time monitoring of various metrics including, but not limited to:

• Load average
• Server uptime
• Number of errors
• Number of bytes and requests served

You might consider other commercial SNMP-based solutions especially for enterprise-scale deployments. These tools help expedite monitoring deployment and usually include enhanced functionaility to automatically alter you when important thresholds, such as web site concurrent connections, are crossed.

External Links:

The official Apache web site

The official Webalize web site

The official Mod-Apache-Snmp web site

The post Apache Server Hardening: Part Six appeared first on pfSense Setup HQ.

In a previous article, we covered the Nmap utility. You can save Nmap logs in a number of formats, including plain text or machine-readable, and import them into another program. However, if these options aren’t enough for you, Nlog can help you make sense of your Nmap output. Running it on very large networks can be a lifesaver, because perusing hundreds of pages of Nmap output looking for nefarious activity can be tedious.

The Nlog program helps you organize and analyze your Nmap output. It presents them in a customizable web interface using CGI scripts. Nlog makes it easy to sort your Nmap data in a single searchable database. On larger networks, this kind of capability is vital to making Nmap useful. H.D. Moore put together these programs and made them available. You can find more information about Nlog at securiteam.com. You can download Nlog at packetstormsecurity.com.

Nlog is also extensible. You can add other scripts to provide more information and run additional tests on the open ports it finds. The author provides several of these add-ons and instructions on how to create your own. Nlog requires Perl and works on log files generated by Nmap 2.0 and higher.

Installing Nlog

Follow these steps to install and prepare Nlog:

1. Download the files from the Nlog web site.
2. Unpack the Nlog files using the tar-zxvf command. It will unzip and neatly organize all the files for Nlog in a directory called nlog-1.6.0 (or other numbers, depending on the version number).
3. You can use the installer script provided to automatically install and prepare the program. Note that you need to edit the program before you run it. Go to the Nlog directory and, using a text editor program such as vi or emacs, open the file installer.sh and enter the variables where indicated for you system. Edit the following parameters with the correct values for your installation.

   CGIDIR=/var/www/cgi/
   HTMLDIR=/var/www/
   

   Put the path to your CGI directory. The above represents the correct values on a default Mandrake installation. Make sure you enter the correct ones for your system. For other Linux systems, find the path to this directory by using the locate command. This useful command will find any files with the text you insert after it.

4. Save the file, then run it by typing:

   ./install.sh

   The installation script automatically copies the CGI files to your CGI directory and the main HTML file to your HTML directory. It also changes the permissions on those files so they can be executed by your web browser.

5. For the final step, go into the /html directory and edit the nlog.html file. In the POST statement, change the reference to the cgi files to your cgi files, which should be the same one used above (/var/www/cgi/). Save the file and you are ready to go.

Running Nlog

Nlog can be used as follows:

1. The first thing you must do is create a Nlog database file to view. You do this by converting an existing Nmap log file. Make sure you save your Nmap logs with the machine-readable option (-m on the command line) to be able to use them in Nlog. You can then use a script provided with Nlog to convert the Nmap log into the database format that Nlog uses. To convert a Nmap machine readable log, run the log2db.pl script using this command:

   Ip2db.pl logfile 
   

   Replace logfile with your log file name and location.

2. To combine multiple log files into a single database, use the following commands:

   cat * > /PATH/temp.db
   cat * > /PATH/temp.db | sort -u > /PATH/final.db
   

3. Replace /PATH with the path to your Nmap files and final.db with the name you want to use for the combined Nmap database. This sorts the files into alphabetical order and eliminates any duplicates.
4. Start your web browser and go to the web directory (/var/www/ from the previous section).
5. Select the Nmap database file you want to view and click Search.
6. You can now open your Nmap database and sort it based on the following criteria:
   • Hosts by IP address
   • Ports by number
   • Protocols by name
   • State (open, closed, filtered)
   • OS match

   You can also use any combination of these criteria. For example, you could search for any web servers (http protocol) on Windows systems with a state of open.

In the next article, we will look at Nlog add-ons and creating Nlog extensions.

External Links:

Download Nlog at packetstormsecurity.com

2003 archive of secureaustin.com (the former official site of H.D. Moore, creator of Nlog)

The post Nlog: A Utility for Analyzing Nmap Logs appeared first on pfSense Setup HQ.

In the previous article, we discussed installing and using Nlog. In this article, we will discuss using add-ons and writing your own Nlog extensions.

Nlog Add-Ons

As mentioned earlier, Nlog is easily extensible and you can write add-ons to do other tests or functions on any protocols or ports found. In fact, there are several included with the program. If there is an add-on available, there will be a hypertext line next to the port and you can click on it to run the subprogram.

Nlog Built-in Extensions

If you examine these add-on scripts, you will observe that they are all just basic Perl programs. If you are experienced with Perl, you can write your own extensions to execute just about any function against your scanned hosts. For example, you can retrieve and display the HTTP header for any web servers found so you can more easily idenfiy it. You don’t need to go overboard with this, because programs like Nessus can do much more comprehensive testing, but if you just need a banner or some small bit of information, then using Nlog is a good solution.

Nlog comes with a sample custom add-on called nlog-bind.pl. This scrupt is designed to poll a DNS server and tell you what version of BIND (the Berkeley Internet Naming Domain) it is running. However, this script is not finished; it is provided as an exercise to create your own add-ons. The sample script is in /nlog*/extras/bind/. The following procedure guides you through finishing the script. You can use that format to create any custom script of your own.

1. Compile the script using the Gcc compiler with the following command from that directory:

   gcc -o bindinfo binfo-wdp.c

   This creates a binary file called bindinfo in that directory.

2. Copy this binary file to the directory where you are keeping your nlog scripts.
3. Change the permissions on it to make it executable (remember that you have to be root to issue this command):

   chmod 700 bindinfo

4. Open your nlog-config.ph file in a text editor.
5. Add this line:

   $bindinfo = "/path/to/bindinfo";

   Replace path/to/bindinfo with the location where you put the binary file.

6. Save this file.
7. Now edit nlog-search.pl. This is te Perl script that creates your search results page.
8. Find the section that looks like this:

   1: # here we place each cgi-handler into a temp var for readability.
   2: 
   3: $cgiSunRPC = "sunrpc+$cgidir/nlog-rpc.pl+SunRPc";
   4: $cgiSMB = "netbios-ssn+$cgidir/nlog-smb.pl+NetBIOS";
   5: $cgiFinger = "finger+$cgidir/nlog-finger.pl+Finger";
   6:
   7: $qcgilinks = "$cgiSunRPc $cgiSMB $cgifinger";

9. Between lines 5 and 6, add a line that looks like:

   $cgiBIND = "domain+cgidir/nlog-bind.pl+BIND";

10. Edit line 7 to look like this:

    $qcgilinks = "$cgiSunRPC $cgiSMB $cgiFinger $cgiBIND";

    Line 7 is also where you would add, in a similar fashion, links to any other scripts you had created.

11. Copy the nlog-bind.pl file from this directory into your cgi-bin directory (/var/www/cgi on Mandriva), and change the permissions (chmod0 so the application can read it.

Now when your Nmap scans find port 53 open (which is generally a DNS server), you can click on the link that Nlog creates and find out what version of BIND is running. You can write additional scripts to extend Nlog by following the logic in this example.

External Links:

Download Nlog at packetstormsecurity.com

2003 archive of secureaustin.com (the former official site of H.D. Moore, creator of Nlog)

The post Nlog Add-Ons and Extensions appeared first on pfSense Setup HQ.

Uses for Nlog and Nmap

So now you can port scan with Nmap and sort and analyze the results with Nlog. what can you do with these programs? There are, indeed, some interesting applications for port scanners. Here are some examples for you to try on your network:

1. Scan for the least common services: if you have a service or port number that is only showing up on one or two machines, chances are that it is not something that is standard for your network. It could be a Trojan horse or a banned service (e.g. a file-sharing application). It could also be a misconfigured machine running an FTP server or other type of public server. You can set Nlog to show the number of occurrences of each and sort them by the least often occurring. This will generate a list for you to check. You probably won’t want to include your company’s servers in this scan as the will have lots of one-of-a-kind services running. However, it would not hurt to scan these servers separately either to fine-tune or eliminate extraneous services.
2. Hunt for illicit/unknown web servers: Chances are that if you run one or more web servers for your company, you will see the HTTP services showing up a few times on your network. However, it is also likely that you will see it on machines where you don’t expect it. Some manufacturers of desktop computers are now loading small web servers by default on their systems for use by their technical support personnel. Unfortunately, these web servers are often barebones programs with security holes in them. You will also find web servers running on printers, routers, firewalls, and even switches and other dedicated hardware. You may need these servers to configure the hardware, but if you aren’t using these servers, you should shut them off. These mini-servers are often configured with no password protection by default and can offer a hacker a foothold onto that machine. They can also offer access to the files on the machines if an intruder knows how to manipulate them. Scan for these hidden web servers, and either turn them off or properly protect them. you should also search for ports other than 80 that are commonly used for HTTP. At the end of this article, there is a table listing some of those ports.
3. Scan for servers running on desktops: Going a step further with the last exercise, restrict the IP range to only those that are nonserver machines and set a port range from 1 to 1024. This will find desktop machines running services that are normally done by servers, such as mail, web and FTP. Unless there is a good reason for this (e.g. PCAnywhere), your desktop machines should not be running these types of services.
4. Hunt for Trojan horses: To hunt for Trojan horses on your network, run a scan of your network and translate it into the Nlog database format. Open the Nlog search page, select the ports, and set the range from 30,000 and 65,400. This is the favored range for Trojan horses because it is out of the range of normal services and so they usually will go unnoticed – that is, unless you are port scanning your network. However, just because there are some services running on high-level ports doesn’t always mean you have Trojan horses, but it is worth paying attention to services running on these high port numbers. Once you’ve narrowed it down to the machine and port numbers, you can rule them out by checking the services running on those machines or by SSHing to those port numbers and seeing if you get a service banner.
5. Check your external network exposure: Put your Nmap box outside your network, either on a dial-up or home broadband connection, and try scanning your company’s public IP addresses. By doing this you will see what services are accessible from the Internet (and thereby to any port scanner-wielding person). This is the most vulnerable part of your network, and you should take extra care to secure any services that are public-facing by using a vulnerability scanner, such as the one described in the next chapter. It will also show if your firewall is properly filtering ports that it is forwarding to internal LAN addresses.
   So you’ve seen all the cool things you can do with a port scanner like Nmap. These programs are useful for finding out what you have running and where your exposures might be. But how do you know if those exposed points might be vulnerable? Or if services that are supposed to be open are safe and secure? That goes beyond the function of a port scanner and into the realm of a vulnerability scanner.

// ]]>

Web Ports

External Links:

Download Nlog at packetstormsecurity.com

2003 archive of secureaustin.com (the former official site of H.D. Moore, creator of Nlog)

The post Uses for Nlog and Nmap appeared first on pfSense Setup HQ.

Useless Services

Like a vestigial tail, there are often applications running on our machines that no longer serve any useful purpose. These services may be part of an earlier set of libraries that the programmers built on and never bothered to take out. This is one of the downsides of ever-increasing processing power and memory capacity. Programmers used to carefully ration every byte they used and would never allow unnecessary lines in their code. However, in this age of bloatware and gigabyte-sized operating systems, it is often easier to leave legacy services in rather than risk breaking some other program that depends on them. The incredible thing is that these services are often turned on by default. Here is a list of some of those services:

Useless Services in Linux

If you are running Windows, there are other services you will probably want to disable. Here is a partial listing of those useless services:

Useless Windows in Windows

If you disable at least some of these services, your system should be harder for hackers and bots to attack, and your system will be more secure.

External Links:

Remove useless services/apps at linuxquestions.org

Useless services in CentOS VDS/VPS at nixcraft.com

Turn off Unnecessary Windows Services at www.marksanborn.net

Disable Unneeded Services in Windows at www.winhelp.us

The post Useless Services appeared first on pfSense Setup HQ.

Advanced settings in the Nessus web GUI.

Nessus Configuration: Proxy and Advanced Settings

The first thing you will see when you access Nessus is the login page. You must first enter the login name and password you created when you set up Nessus. Since Nessus uses a web-based front end, you can access the Nessus server from any computer on the local network that has a web browser, making Nessus configuration much easier. This increases the scalability of Nessus for larger organizations. You can configure scan options and make other changes, all from the web interface.

Once you are logged in, there are several settings you can change. If you click on your username (in this example, “nessusadmin”) on the right side of the page, there is a drop-down menu with several options; select “Settings”. On the left sidebar, there is an option called “Proxy”. If you did not set up a proxy during the setup process and need to do so now (for example, if your organization requires that all web traffic be directed through a corporate proxy), you can input the settings here.

Proxy Setting Options

Different Nessus configuration options can be set by clicking on the “Advanced” link in the Settings menu. Each option can be configured by editing the corresponding field and clicking the “Save” button at the bottom of the screen. In addition, the option can be removed completely by clicking on the “X” button.

By default, the Nessus GUI operates on port 8834. To change this port, edit the xmlrpc_listen_port to the desired port. The Nessus server will process the change within a few minutes.

If additional preferences are required, click on the “New Setting” button, input the name and the value, and press “Save”. Once a preference has been updated and saved, Nessus will process the changes within a couple of minutes.

Adding a new user in Nessus.

Nessus Configuration: Adding/Editing Users

During the initial setup, one administrative user is created. Using the credentials specified during the setup, you can log into the Nessus GUI. Once authenticated, click on the “Users” heading at the top. To create a new user, click “New User” on the upper right. This will open a dialog box asking for required details. Input the username and password, verify the password, and determine if the user should have administrator privileges. If a user account needs to be modified, double-click on the user.

You cannot rename a user. If you want to change the name of a user, delete the user and create a new user with the appropriate login name. To remove a user, select the check box next to the account on the list, select “Options” on the upper right, and then click “Delete User” and confirm.

A non-admin user cannot upload plugins to Nessus, cannot restart it remotely, and cannot override the max_hosts/max_checks setting in the configuration section. If the user is intended to be used by SecurityCenter, it must be an admin user. SecurityCenter maintains its own user list and sets permissions for its users.

In the next article, we will cover more Nessus configuration options.

External Links:

Nessus home page on www.tenable.com

Nessus on Wikipedia

The post Nessus Configuration: Part One appeared first on pfSense Setup HQ.

Arping in action under pfSense 2.1.3.

Arping is a computer software tool that is used to discover hosts on a computer network, and is available as a package for pfSense. The program tests whether a given IP address is in use on the local network, and it can get additional information about the device using that address. The utility is similar to the ping utility, which has been discussed on this site in an earlier posting. Whereas ping probes hosts using the Internet Control Message Protocol (a routable protocol that operates on the network layer of the OSI model), arping operates entirely on the data link layer.

There are two popular arping implementations. One of them, part of the Linux iputils suite, cannot resolve MAC addresses to IP addresses. However, the version of this utility that is available as a package for pfSense was written by Thomas Habets and can ping hosts by MAC address as well as by IP address.

Installing Arping

Installing this utility is easy. In the pfSense web GUI, navigate to System -> Packages and click on the “Available Packages” tab. Arping should be on the list. Scroll down to arping and click on the “plus” button on the right side to install arping. The pfSense package installer will ask you to confirm that you want to install arping; press the “Confirm” button. The package installer status window will provide information about the installation and let you know when installation is complete. once it is, arping should appear on the “Installed Packages” tab.

Using Arping

Once arping is installed, you can access arping by navigating to Services -> Arping. From there, you can enter a host ip or MAc address and press the “ARPing” button to ARP ping.

What is it good for, given that the utility essentially replicates the functionality of ping? One case where arping is helpful is when the host you want to ping is firewalled and will not respond to a ping request. Even a firewalled host will respond to ARP.

Another case is when you do not have network layer (layer 3) connectivity to the host you wish to ping (possibly because you want to find out if an IP is taken), but you have data link layer (layer 2) connectivity. Without network layer connectivity, you won’t be able to ping a host, but you can use ARP (since ARP is a data link layer protocol), albeit only for hosts on the local subnet. One note of caution is that on networks employing repeaters that use proxy ARP, the ARP response may be coming from a proxy host and not from the probed target.

External Links:

Arping website for Thomas Habets’ arping

Arping on Wikipedia

The post Arping with pfSense: Installation and Use appeared first on pfSense Setup HQ.

Installing Squid under pfSense 2.1.3.

Squid is a proxy server and web cache daemon. It was originally developed as part of the Harvest project at the University of Colorado Boulder. Further work on the program was completed at the University of California, San Diego (UCSD) and funded via two grants from the National Science Foundation. Duane Wessels forked the last pre-commercial version of Harvest and renamed it Squid, and Squid version 1.0.0 was released in July 1996. It has a number of uses. Under pfSense, it can be used to cache repeated requests.

Squid Proxy Installation

Installing and configuring a Squid proxy server under pfSense is relatively easy. From the pfSense web GUI, go to the top menu and navigate to System -> Preferences. Scroll down to “squid” on the list of packages, and click on the “plus” button on the right to install Squid. On the next screen, press the “Confirm” button to confirm that you want to install Squid. It will take a few minutes for the package installer to unpack and install Squid.

Squid Proxy Configuration

Once installation is complete, “Proxy Server” will show up as an option under Services. Navigate to Services -> Proxy Server to configure Squid. Most users will find the default settings to be acceptable, but there are several settings worth noting. There are 7 tabs in the Squid proxy settings: General, Upstream Proxy, Cache Mgmt, Access Control, Traffic Mgmt, Auth Settings, and Local Users.

The General settings tab in Squid proxy configuration.

General Settings: This covers the most commonly configured Squid proxy settings. The first setting, “Proxy Interface“, determines which interface or interfaces the proxy will bind to. You probably want to leave this set to “LAN” so that the proxy server is accessible to hosts connected. You probably want to leave “Allow users on interface” checked, to allow users connected to the interface selected in the Proxy Interface field to use the proxy. You probably also want to check the “Transparent proxy” check box so all requests for destination port 80 will be forwarded to the proxy server.

Upstream Proxy: If you want Squid to forward requests to an upstream proxy server, you can enable forwarding here. There are also settings to specify the IP address/hostname of the proxy, TCP and ICP port, and username and password, if the upstream proxy requires them.

Cache Mgmt: This controls a number of settings relating to the cache size. “Hard disk cache size” sets the total amount of hard disk space Squid will use to cache objects. If you have a large hard drive, you can increase this setting to cache more objects; otherwise you can probably leave it at the default value (100 MB).

“Memory cache size” is the amount of physical RAM to be used for negative cache and in-transit objects. Objects that squid cannot store in memory end up getting swapped to disk which is much slower than RAM. Squid recommends that this setting should be 50% or less of the installed RAM.

“Maximum object size” sets the maximum size of objects saved on disk. The default value is 4 KB. You can increase this parameter to save bandwidth, or lower it to improve speed. Most cache hits tend to take place on small files, although you probably want to increase this parameter from the default of 4 KB.

Access Control: This controls a number of settings regarding who is allowed to access the proxy server. In “Allowed subnets“, you can enter each subnet that is allowed to use the proxy (the proxy interface subnet specified in “General” is already an allowed subnet, so you don’t have to specify it here). “Unrestricted IPs” allows you to specify IP addresses that will not be filtered out by the other access control directives set out in this section. “Banned host addresses” allows you to specify IP addresses that are not allowed to use the proxy. “Whitelist” allows you to specify domains that will be accessible to users that are allowed to use the proxy. “Blacklist” allows you to specify domains that will be blocked to users that are allowed to use the proxy.

Traffic Mgmt: This controls a number of traffic settings. “Maximum download size” limits the maximum total download size to the size specified here (the default is no limit). “Maximum upload size” limits the maximum total upload size to the size specified here (the default is no limit). “Overall bandwidth throttling” specifies the bandwidth throttle for downloads; users will gradually have their download speed increased to this value (default is no throttling). “Per host throttling” specifies the download throttling per host (again, the default is no throttling).

The Authentication settings tab.

Auth Settings: Here, you can enable authentication of Squid proxy users. Squid supports local authentication, as well as authentication through an external LDAP, RADIUS or NT server. The default setting is “None” for no authentication.

Local Users: This allows you to set usernames and passwords for individual users. Assuming authentication is enabled and you chose the local authentication option, users will then be able to use the credentials set here to log in to the Squid proxy server.

For basic Squid proxy usage, the above may be all the information you need. If you really want to understand some of the more advanced options, though, you probably should read the Squid man page. You can use these command-line options by [1] executing a command from the Command prompt option in the Diagnostics menu; [2] SSH-ing into your pfSense box; or [3] accessing pfSense directly from the console.

To shut down Squid, issue this command:

squid -k shutdown

To restart squid, issue this command:

/usr/local/sbin/squid -D

However, it should be noted that pfSense seems to start Squid on its own if it notices Squid is not running. Some of the more interesting options are -u port (to specify a different ICP port than 3130; this can also be done from the pfSense GUI), and -z to create swap directories (useful if you have just deleted the cache and want to recreate the swap directories). There is also a loader.conf.local file in the /boot directory with settings that can be configured. The “Squid Package Tuning” document on doc.pfsense.org suggests changing the kern.ipc.nmbclusters parameter from “0″ to “32768″. This increases the amount of memory used for socket buffers, and may improve performance.

External Links:

Squid on Wikipedia

How to Set Up a Transparent Squid Proxy Server Using pfSense at hubpages.com

Squid Package Tuning at doc.pfsense.org

Proxy Servers at pfsensesolution.blogspot.com

The post Squid Proxy Configuration in pfSense appeared first on pfSense Setup HQ.