With a wireless card that supports hostap mode, pfSense can be configured as a wireless access point. The following cards support hostap mode:

• ath(4): Supports cards based on the Atheros AR5210, AR5211 and AR5212 chipsets.
• ral(4): Ralink Technology wireless network driver – supports cards based on the Ralink RT2500, RT2501 and RT2600 chipsets.
• wi(4): Supports cards based on Lucent Hermes, Intersil PRISM-II, Intersil PRISM-2.5, Intersil Prism-3, and Symblo Spectrum24 chipsets. These cards support only 802.11b.

In the past, the access point functionality in FreeBSD has suffered from serious compatibility problems with some wireless clients. With FreeBSD 7.0 and newer, this has improved significantly; however there may still be some incompatible devices. These difficulties with client compatibility are not necessarily just a FreeBSD issue. Nevertheless, you may find that a cheap consumer-grade wireless router running in access point mode may provide better compatibility than FreeBSD’s access point capabilities. There is the possibility of finding incompatible devices with any wireless access point, and FreeBSD is no exception. With every passing release of FreeBSD, wireless compatibility improves; however, it’s probably a good idea to check the ap compatibility list at pfsense.org.

As long as your wireless cards are compatible, configuring pfSense to act as a wireless access point is fairly easy. Many of the options should be familiar if you have configured other wireless routers before, and some options may be new unless you have used some commercial-grade wireless equipment. There are many different ways to configure access points. In this article, we will cover setting up pfSense as a basic wireless access point (AP) that uses WPA2 encryption.

Configuring pfSense as a Wireless Access Point

First, ensure that the wireless card is in the router, and the antenna is firmly attached. The wireless card must be assigned as an OPT interface and enabled before the remaining configuration can be completed. You need to navigate to Interfaces -> OPTn to begin configuration. Naming the access point “WLAN” (Wireless LAN) or “Wireless” will make it easy to identify a wireless interface in the list of interfaces. If you have a unique SSID, it may be a good idea to use that in the description instead. If pfSense will be driving multiple access points, there should be some way to distinguish them.

Next, since this will be a wireless access point on a dedicated IP subnet, you will need to set the “Type” to “Static” and specify an “IP Address”and subnet mask. Since this is a separate subnet from the other interfaces, it can be any subnet that is otherwise unused. For purposes of this example, assume our subnet is 192.168.10.x.

You need to set the “Wireless Standard” setting, and there are several choices, including 802.11b, 802.11g, 802.11g turbo, 802.11a, and possibly others. Here, assume we choose 802.11g. Set the “Mode” field to “Access Point”, and pfSense will use hostapd to act as an AP. Next you need to set the Service Set Identifier (SSID); this will be the name of the AP as seen by clients. This should be something readily identifiable, yet unique to your setup.

Another setting is “802.11 only”. This setting controls whether or not 802.11b clients are able to associate with this access point. Allowing 802.11b clients to use your wireless access point may be necessary in some environments if devices are still around that require it. Some devices such as the Nintendo DS are only compatible with 802.11b and require a mixed network in order to work. The down side of this is that you will see slower speeds as a result of allowing such devices on your network, as the access point will have to cater to the lowest common denominator when an 802.11b device is present.

Next, there is “Allow intra-BSS communication”. If you check this option, wireless clients will be able to see each other directly, instead of routing all traffic through the AP. If clients will only need access to the Internet, it is usually safer to uncheck this.

There is an option to “Disable SSID Broadcasting”. Normally, the AP will broadcast its SSID so that clients can locate and associate with it easily. However, this is considered by many network admins to be a security risk, as you are announcing to all who are listening that you have a wireless network available. In most cases the convenience outweighs the security risk. At the same time, the benefits of disabling SSID broadcasting are overblown, since it does not actually hide the network from anyone capable of using many freely available wireless security tools that easily find such wireless networks.

Next is “Wireless Channel Selection”. When selecting a channel, you want to be aware of any nearby radio transmitters in similar frequency bands. In addition to wireless access points, there are also cordless phones, Bluetooth, baby monitors, video transmitters, microwaves, and many other devices that use the same 2.4 GHz spectrum that can cause interference. The safest channel to use are 1, 6, and 11 since their frequency bands do not overlap each other. You can specify “Auto” to tell the card to pick an appropriate channel, but this does not work with all wireless cards.

Three types of encryption are supported for 802.11 networks: WEP, WPA, and WPA2. WPA2 with AES is considered the most secure. Even if you are not worried about encrypting the over-the-air traffic, it provides an additional means of access control. A WPA/WPA2 passphrase is also easier to work with and remember than a WEB key; it acts more like a password than a really long string of hexadecimal characters. Some older devices only support WEP or WPA, but most modern wireless cards and drivers will support WPA2. To enable WPA2, you need to uncheck “Enable WEP” and check “Enable WPA”, and set the “WPA Mode” to WPA2. To use WPA2+AES, set “WPA Pairwise” to AES.

This should be enough to get a wireless access point running with 802.11g with WPA2 + AES encryption. There are other settings you can use to tweak the AP’s behavior, but under most circumstances they are not necessary. Press the “Save” button to save the settings and on the next page press the “Apply Changes” button. Now your wireless access point should be up and running.

External Links:

One pfSense wireless config to rule them all at www.interspective.net

Ad Links:

The post Wireless Access Point Configuration in pfSense appeared first on pfSense Setup HQ.

In addition to strong encryption from WPA or WPA2 with AES, some users like to employ an additional layer of encryption and authentication before allowing access to network resources. The two most commonly deployed solutions used to ensure wireless network security are captive portal and VPN. These methods may be used whether you use an external access point or use an optional (OPT) interface or an internal wireless card as your access point.

Wireless Network Security: Captive Portal

By enabling captive portal on the interface where your wireless is, you can require authentication before users can access network resources, thus providing an additional layer of wireless network security. In corporate networks, this is often deployed with RADIUS authentication to Microsoft Active Directory so users can use their Active Directory credentials to authenticate while on the wireless network. I covered captive portal configuration in two separate installments: part one and part two.

Wireless Network Security: VPN

Firewall rules for IPsec VPN. “WLAN net” is the network of the wireless interface, and “Wireless IP” is the IP address of the wireless interface. The rules are slightly different for OpenVPN and PPTP.

Adding captive portal provides another layer of authentication, but it does not offer any additional protection from eavesdropping of your wireless traffic. Requiring VPN before allowing access to the internal network and Internet adds yet another layer of authentication as well as an additional layer of encryption for your wireless traffic, and thus improving wireless network security. The configuration for your chosen type of VPN will be no different from a remote access configuration, but you will also need to configure the firewall rules on the pfSense interface to allow only VPN traffic from your wireless clients.

If you choose to allow only IPsec VPN traffic, you need to set up three rules on you wireless interface. Navigate to Rules -> Firewall, and click on the tab for the wireless interface. Press “plus” to add a new rule. For “Protocol”, select ICMP. For “Source”, select the wireless network; for “Destination”, select the wireless interface IP address. Enter a “Description” and leave the other settings unchanged. Press “Save” to save this rule. Press “plus” to create another rule, and keep the wireless network as the source and the wireless interface IP as the destination. Change the “Prototype” to UDP, and set the destination “Port” to 500. Add a description and press “Save” to save the rule. Press “plus” to create a third rule, and again keep the source as the wireless network and the destination as the wireless interface. Do not set a port and set the prototype to ESP. Then press “Save” to save the rule and on the next page press “Apply changes” to apply the changes.

If you want to use OpenVPN instead, keep the ICMP rule the same, but set the port for the UDP rule to 1194. You do not need a rule to pass ESP traffic. If you want to use PPTP, keep the ICMP rule, add a rule to pass TCP traffic on port 1723, and add another rule to pass GRE traffic on all ports. You do not need a rule to pass UDP or ESP traffic.

External Links:

pfSense OpenVPN Tutorial at YouTube

Secure Your Public WiFi Usage with pfSense IPsec Tunnels at Mostly Secure

Ad Links:

The post Wireless Network Security in pfSense appeared first on pfSense Setup HQ.

If you are running pfSense and are looking for an additional means of securing your network, you may consider installing snort on your pfSense system. Snort installation will be the subject of this next series of articles. Snort is an open source network intrusion prevention system (NIDS), capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching and matching, and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more. Snort has three primary uses. It can be used as a straight packet sniffer like tcpdump, a packet logger, or as a full-blown network intrusion prevention system. In sniffer mode, the program will read network packets and display them on the console. In sniffer mode, the porgram will read network packets and display them on the console. In packet logger mode, the program will monitor network traffic and analyze it against a rule set defined by the user. The program will then perform a specific action based on what has been identified.

Snort Installation Under FreeBSD 8.x

Snort installation on a  pfSense box begins with  SSHing into the system to access the shell prompt. If you have a recent version of pfSense (2.0 or newer), it should be running under FreeBSD 8.1 or newer. You will need to install the following package via pkg_add: gcc version 4.2.x (including libraries), zlib (1.2.3), libpcap (1.0.0 including libpcap-devel), pcre (8.32), bison (2.7), m4 (1.4.16), flex (2.5.4 including flex-devel), libdnet (1.11 including libdnet-devel), and tcpdump (4.0.0). Versions of these package can be newer than what is listed here. Then download the source code for snort at the official snort website. Download the archive to /usr/local/src. Type the following commands to unpack snort:

cd /usr/local/src
tar -zxvfsnort-2.9.5.5.tar.gz

Once you have unpacked snort, do the following to compile snort:

cd /usr/local/src/snort-2.9.5.5
./configure -enable-sourcefire
make
make install

Note any errors which may cause the “configure” step to abort and also check the file “config.log” which is generated from the “configure” line above.

In order to download snort rules from www.snort.org, you must be a registered user or have a paid subscription to download rules sets or VRT rules. Registered users will be able to download rule sets which are approximately one month behind what is available to paid subscription holders.

Continue snort installation by issuing the commands below to copy the configuration files to /etc/snort:

cd /etc
mkdir -p snort
cd snort
cp /usr/local/src/snort-2.9.5.5/etc/*.
tar -zvxf snortrules-snapshot-.tar.gz
touch /etc/snort/rules/white_list.rules /etc/snort/rules/black_list.rules

This will place the configuration files from the snort 2.9.5.5 unpack and the rules snapshot under the /etc/snort directory. If the rules snapshot file is newer, this is not an issue (since rules are updated on a periodic basis by the snort team). Also, the configuration files are residing in /etc/snort and the rules files will be in /etc/snort/rules and the so_and preprocessor rules will be located in /etc/snort.

In the next article, we will continue our look at snort installation under pfSense.

External Links:

The official snort web site

Ad Links:

The post Snort Installation in pfSense: Part One appeared first on pfSense Setup HQ.

In the previous two articles (part one part two), I discussed the installation of snort. In this article, I will mention some ways to improve snort security.

Improving Snort Security

One of the snort security issues is preventing unauthorized access to a privileged account. There are several ways of preventing this. First, when running snort in daemon (-D) mode, the user (-u) and group (-g) switches should be used. This will allow snort to run as a given user and group after it is initialized. Typically, most system administrators prefer to add the snort user and group to their systems, and that the snort user should be unable to login or initiate shell privileges.

style="display:inline-block;width:180px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8138242896">

Second, the source code for snort/DAQ binaries, logging directories, shared/static libraries, and configuration files should all be owned by the snort user with appropriate permissions. Finally, all binaries which are produced by the compiling and installation process of snort and DAQ should be verified using a hash function and the output stored on removable media. A cron job could be used to run this process on a regular basis with results e-mailed to a system administrator. Another alternative would be the use of a utility called tripwire for auditing installed software on a computer. All of these measures are excellent ways of increasing snort security.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

Mirroring or Copying Network Traffic to Snort

In addition, your small office/home office (SOHO) router can be used to mirror or copy network traffic to a snort sensor running on a standalone system or to a virtual machine running in VirtualBox, VMWare, or Xen. This method of improving snort security can be easily done provided you have a router that is running DD-WRT, OpenWRT, or Tomato as the firmware. If you are running Tomato, you may have to add the following to your startup script:

modprobe ipt ROUTE

Users of OpenWRT must use the Tee option for IPtable (provided by module iptables-mod-tee). The module “iptabels-mod-tee” must be loaded before the following command will work:

iptables -t mangle-A PREROUTING -j TEE -gateway x.x.x.x

Where x.x.x.x is an IP address you wish to mirror traffic to (usually a system running snort). It should be noted that in more recent versions of OpenWRT (10.03.1 and never), iptables-mod-tee does not seem to be enabled by default, and using it will require a rebuild/re-enabling of modules for OpenWRT.

Now, using DD-WRT or Tomato’s GUI (or SSHing into the router), issue the following commands:

iptables -A PREROUTING -t mangle -j ROUTE -gw x.x.x.x -tee

iptables -A POSTROUTING -t mangle -j ROUTE -gw x.x.x.x -tee

In each case, x.x.x.x is the address of the machine running snort. To stop mirroring traffic, type

iptables -F -t mangle

If you have snort running in test mode (-T option), try starting snort with /etc/rc.d/snort start (you should get a running message if snort is running properly). If there is a problem, check the output in /var/log/messages. Also, you can check the status of snort by issuing this command:

./snort status

External Links:

How to make some home routers mirror traffic to Snort at www.snort.org

DD-WRT

OpenWRT

Tomato

The post Snort Security Optimization appeared first on pfSense Setup HQ.

I thought it might be a good idea to do a series of articles on network security, and to kick it off I’m going to cover disabling unnecessary services. This article assumes your network is running Linux, at least for services.

As a Linux administrator you will want to know and define the following elements:

• The role of the server (web, database, proxy, etc.)
• Services that are required to perform a specific server role (e.g. Apache)
• Ports required to be opened (e.g. port 80 for HTTP)

All the other services should be disabled and all other ports should be closed. When these tasks are performed, the server becomes a specialized server to play only the designated role.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

To ensure network security by hardening a server, you must first disable any unnecessary services and ports. The process involves removing any unnecessary services, such as rlogin, and locking down unnecessary Transmission Control Protocol or User Datagram Protocol (TCP/UDP) ports. Once these services and ports are secure, you must then regularly maintain the system.

Network Security: Controlling Services

Different Linux distributions have different front ends to control services. For example, in Red Hat Linux, you can enable and disable services by navigating to System -> Administration -> Services and opening the Service Configuration utility. From there, you may select or deselect the services, start, stop or restart them and edit the run level of individual services. Although most modern Linux distros have enhanced their GUIs to cover most of the administrative tasks, it is important for admins to know how to perform the tasks without a GUI.

Linux has greater network security than most operating systems; even so, the Linux kernel is being constantly updated and there are undoubtedly many security vulnerabilities that have not yet been discovered. Most Linux services are not vulnerable to this exploits; however, an administrator can reduce the risk by removing unnecessary services. Virtually every Linux distribution includes many services, so it makes sense that administrators customize the system to meet their or their company’s needs, as removing unnecessary services also removes risk and thus improves network security.

style="display:inline-block;width:180px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8138242896">

No matter what distribution of Linux you are using, the /etc/inetd.d or /etc/xinetd.d directory (for some newer releases, including Red Hat). This is the default configuration file for the inetd (or xinetd) daemon. This files in this directory enable you to specify the daemons to start by default and supply the arguments that correspond to the desired style of functioning for each daemon. It controls many services, include File Transfer Protocol (FTP) and Telnet. It determines what services are available to the system what services are available to the system. inetd or xinetd is a super server listening for incoming network activity for a range of services. It determines the actual nature of the service being requested and launches the appropriate server.

The /etc/inetd.conf (or /etc/xinetd.conf) directs requests for services to the /etc/inetd.d (or /etc/xinetd.d) directory. Each service has a configuration in this directory. If a service is commented out in its specified configuration file, the service is unavailable. Because inetd/xinted is so powerful, for optimal network security only the root should be able to configure its services.

Network Security: Disabling Telnet, FTP and rlogin

While most admins find in convenient to log in remotely their Linux/Unix machines over a network for administrative purposes, in a high-network security environment, only physical access may be permitted for administering a server. In this case, you should disable the Telnet interactive login utility. Because of security vulnerabilities in FTP, you should disable it as well, and use SFTP (Secure FTP) if necessary. To accomplish these two objectives, do the following:

• Edit the /etc/inetd.d/telnet (or xinetd.d/telnet) file by opening the file, using vi or the editor of your choice
• Comment out the service telnet line by adding a number sign (#) before service telnet
• Write and quit the file
• Restart inetd or xinetd by entering:
  /etc/rc.d/init.d/inetd restart
  or for xinetd:
  /etc/rc.d/xinit.d/xinetd restart
• Attempt to log onto the system using Telnet. You should fail.
• Diable the FTP service using the same method.
• Attempt to access the system via FTP. You should fail.

The remote login (rlogin) service is enabled by default in the /etc/inetd.d/rlogin (or /etc/xinetd.d/rlogin) file. Rlogin has security vulnerabilities because it can bypass the password prompts to access a system remotely. There are two services associated with rlogin: login and RSH (remote shell). To disable these services you have to open the rlogin file and comment out the service login line, and then open the rsh file and comment out the service shell line. Restart xinetd to ensure your system is no longer offering these services. Disabling these three services will go a long way towards improving network security on your Linux server.

External links:

inetd at Wikipedia

The post Network Security: Disabling Services appeared first on pfSense Setup HQ.

In the previous article, I covered the network security benefit of disabling unused services. In this article, I will cover the concept of port blocking, and how it can be done under Linux.

TCP/IP networks assign a port to each service: e.g. HTTP, Simple Mail Transfer Protocol (SMTP), Telnet, FTP, and Post Office Protocol version 3 (POP3). This port is given a number, called a port number, used to link incoming data to the correct service. For example, if a client browser is requesting to view a server’s web page, the request will be directed to port 80 on the server. If the client starts an FTP session, the request will be directed to port 21. The web service receive the request and sends the web page to the client. Each service is assigned a port number, and each port number has a TCP and UDP port. For example, port 137 is used for the NetBIOS name service and has a TCP and a UDP port, with NetBIOS over TCP usually using UDP port 137 (TCP port 137 can be used, but rarely is).

There are two types of ports used for TCP/IP networks: well-known ports and registered ports. The well-known ports are the network services that have been assigned a specific port number (as defined by /etc/services). For example, SSH is assigned port 22, and HTTP is assigned port 80. Servers listen on the network for the requests of well-known ports. Registered ports are temporary ports, usually used by clients, and that will vary each time a service is used. You can also call registered ports ephemeral ports, because they only last for a brief time.

Port Blocking: Determining Which Ports to Block

When determining which ports to block on your server, you must first determine which services you need. In most cases, you can block all ports that are not exclusively required by those services. This is a bit tricky, because in implementing port blocking, you can easily block yourself from services you need, especially services that use ephemeral ports, as explained earlier.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

For example, if your server is an exclusive FTP server, you can block all TCP ports except ports 20 and 21, respectively. If your server is an exclusive HTTP server, you can block all ports except TCP port 80. In the case of the FTP server, you can block all UDP ports except port 20, since FTP requires UDP port 20 to be open. If you use the system as an HTTP server, in setting up port blocking you can block all UDP ports, since HTTP uses TCP services exclusively.

However, if you want to use your server as an HTTP client, or as an e-mail client or an e-mail client to a remote mail server, you will restrict the system by doing this. Clients require registered UDP ports for DNS, as well as registered TCP ports for establishing connections with web servers.

style="display:inline-block;width:180px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8138242896">

If you, for example, try to download an operating system update, and you have only opened UDP port 20, DNS requests will be blocked because DNS queries use port 53. Even if you open port 53, a different registered port may be assigned each time for the answer. In this situation, the best policy may be to open all TCP/UDP registered ports, or set up port blocking to block all of them, and download operating system updates from another computer.

Port Blocking in Red Hat and Other Linux Distros

To utilize port blocking for TCP/UDP services in Linux, you must disable the service that uses the specific port. You may use the GUI interfaces of firewall services offered by most of the Linux distros. In Red Hat Enterprise Linux (RHEL) 5, this is achieved by navigating to System -> Administration -> Security Level and Firewall, which opens up the firewall configuration utility. To allow a service to run, just check and enable the service and to block, uncheck the service. If you want to add any non-standard port or a custom port to be allowed by the firewall, then click on Other ports and add the protocol type (TCP or UDP) and add the port number.

If you don’t use RHEL, don’t despair. Regardless of which version of Linux you use, iptables is the Linux kernel firewall, and rules can be added or deleted at the command line. For example, to set the default chain policy to block, type this:

iptables -P INPUT DROP

Once you do this, you can complete your port blocking setup by selectively enable ports. For example, to allow all incoming SSH connections on eth0, type:

iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 22 -m state –state ESTABLISHED -j ACCEPT

You may, however, opt to use a frontend to iptables to implement port blocking. Shorewall is one such frontend, and its creators call it “iptables made easy”. If you use Ubuntu, the default firewall configuration tool is ufw (Uncomplicated Firewall), and it simplifies the process of using iptables. To enable ufw, type:

sudo ufw enable

The default parameter allows us to set the default policy. Let’s assume we want set the default policy to block all incoming traffic. We would type:

sudo ufw default deny in

Here, “deny” is the policy (the choices are allow, deny, or reject), and “in” indicates the direction in which traffic is blocked (choices are in or out). Since “in” is the direction the rule applies to by default, we could have just typed:

sudo ufw default deny

If we wanted to allow incoming traffic on port 80, we would type:

sudo ufw allow in to any port 80

There’s much more to ufw than what I present here, so I advise reading the documentation (especially the man page) for more information on port blocking. However, one important parameter for ufw that should be mentioned is –dry-run. When this command is invoked, ufw won’t modify anything, but will just show the changes.

External Links:

iptables at Wikipedia

Shorewall homepage

ufw manpage

Firewall at help.ubuntu.com

25 Most Frequently Used Linux IPTables Rules Examples

The post Port Blocking in Linux appeared first on pfSense Setup HQ.

In the previous article, I covered some of the features of Bastille. In this article, I will cover downloading, installing and running Bastille, and undoing changes.

Downloading Bastille

Bastille is available for free download at Sourceforge’s Bastille page. The program is offered in tarball and rpm format. It must be installed by a root user in his or her root directory. Ensure the perl/tk library installed on your system, since Bastille is a collection of Perl scripts.

The program automatically implements the administrator’s preferences based on the answers to the questions, and saves them in the /root/Bastille/config file.

If you’re using Ubuntu, you can use apt-get to install Bastille, with the following command:

sudo apt-get install bastille

Of course, if you receive an error such as WARNING: /usr/bin/perl cannot find Perl module Tk, then you need to first install the perl-tk package, with the following command:

sudo apt-get install perl

Bastille allows the same configuration to be implemented on other systems. In order to do this, administrators need to install Bastille on that machine, copy the config file and the BackEnd file to the new system’s ~/Bastille directory, and then run this command:

BastilleBackend

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

Installation and Configuration

To install and configure Bastille, do the following:

1. Log in as root.
2. Download the rpm file to your root directory.
3. Double-click on the package icon in the GUI or use this command-line command: rpm -i Bastille-versionnum.noarch.rpm
4. To run Bastille GUI, enter the following in the Bastille directory:,/bastille
5. All choices you implement in Bastille are logged to the /root/Bastille/config file. It is remommended that you make a backup of the config file before running Bastille and keep a manual log.
6. Next, the opening screen appears, identifying how to navigate through the Bastille configuration process. Select Next to access the first configuration screen.
7. Next, Bastille leads you through a series of questions. Go through the explanation given below every question and understand the changes Bastille will perform based on your choice.
8. Bastille will next ask you if you want to implement these changes. Select Save Configuration if you want to just save the configuration with applying any changes. Select Exit Without Saving if you want to discard the changes. Select Go Back and Change Configuration if you want to apply the changes.
9. If you implemented password aging to 60 says, you may want to observe the changes made to the login.def file (found in the /etc directory).
10. If you applied limits to the system resources by limiting users to 150 processes, you may want to observe the changes to the limits.conf file (found in the /etc/security directory).

style="display:inline-block;width:180px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8138242896">

Undoing Changes

If you want to undo changes made to your system by Bastille, this can be a bit tricky. At one time, all that was included with Bastille was a Perl script called Undo.pl that was designed to undo all changes except for RPM installations. This has changed, and now Bastille has an undo/revert program called RevertBastille that restores all the configuration files and other O/S state settings to exactly where they were before installing Bastille.

Of course, this will probably not be a good option if you installed Bastille a long time ago and have made a lot of changes to your system since then. For this reason, it is a good idea to keep a log of all the changes made with Bastille, so you can undo changes as needed, possibly by running through the Bastille configuration questions again and selecting different answers. Another option is to manually remove the changes by replacing each of the configuration files changed with the backup files in the Bastille directory. The backup directory is located at:

/root/Bastille/undo/backup

It should be noted that merely uninstalling Bastille will not undo the changes made by Bastille. The changes will still be written to the specific configuration files modified by Bastille, and unless you restore the original configuration files, the changes will persist.

External Links:

BastilleLinux at help.ubuntu.com

The post Implementing Bastille appeared first on pfSense Setup HQ.

In order to use sudo, the user must have already supplied a username and password. If a user attempts to run the command via sudo and that user is not in the sudoers file (at /etc/sudoers), an e-mail is automatically sent to the administrator, indicating that an unauthorized user is accessing the system.

Once a user logs in to sudo, a ticket is issued that is valid by default for five minutes. A user can update the ticket by issuing the -v falg, which will validate the ticket for another five minutes. To do this, type the following:

sudo -v

If an unauthorized user runs the -v flag, an e-mail will not be sent to the administrator. The -v flag informs the unauthorized user that they are not a valid user. If the user enters a command via sudo anyway, an e-mail will then be sent to the administrator.

style=”display:inline-block;width:728px;height:90px”
data-ad-client=”ca-pub-8834983181171783″
data-ad-slot=”8926342897″>
//

sudo logs login attempts, successful and unsuccessful, to the syslog file by default. However, this can be changed during sudo configuration. sudo also has several command line options, such as the following:

• -V: Version; prints version number and exits
• -l: List; lists the commands that are allowed and denied by the current user
• -h: Help; prints usage message and exits
• -v: Validate; updates the user’s ticket for a configured amount of time (the default is five minutes). If required, the user must re-enter the user password to update the ticket
• -k: Kill; expires the user’s ticket. Completing this option requires the user to re-enter the user password to update the ticket
• -K: Sure kill; removes the user’s ticket entirely. User must log in with username and password after running this option
• -u: User; runs the specific command as the username specified. The user specified can be any user except root. If you want to enter a uid, enter #uid instead of the username

Configuring sudo

To configure sudo, you must edit the /etc/sudoers file. The sudoers file defines which users are allowed to execute what commands. Only the root user is allowed to edit the file, and it must be edited with the visudo command. By default, the visudo command opens the sudoers file in the vi text editor. The vi commands are used to edit and write the file. You can change the default text editor used by visudo using the compile time option. Visudo uses the EDITOR environment variable. The visudo command performs the following tasks when editing the sudoers file:

• Visudo will not save any changes if a syntax error exists. It will state the line number of the error and prompt you for guidance.
• If you attempt to run visudo while the sudoers file is being edited, you will receive an error message telling you to try again at a later time.

The sudoers file consists of two different types of entries, user specifications and aliases. The following examples show you to use user specifications, which define which user is allowed to run what commands. Aliases are basically variables.

style=”display:inline-block;width:180px;height:90px”
data-ad-client=”ca-pub-8834983181171783″
data-ad-slot=”8138242896″>
//

The sudoers file contains a root entry. The user privilege specification is listed as:

root ALL=(ALL) ALL

This configuration allows the root user to issue all commands. To allow other users to run commands as root, you must enter those users in the sudoers file. You must also list the host on which they are allowed to run the commands. Finally, you must list the specific commands that those users are allowed to run as root. As an example, imagine we have a user called chris and we want to allow him to run some commands as root.

First, we open the sudoers file using the visudo command. The sudoers file will now open in vi. Locate the “User privileges specification” section. After the root entry, enter the following:

chris your-hostname = /sbin/ifconfig, /bin/kill, /bin/ls

[This will allow user chris to run the ifconfig, kill and ls commands as root. NOTE: Depending on your implementation of Linux/Unix, you may have to add your default shell to the list of commands user chris can execute as root; e.g. /bin/bash.] Press ESC, then enter wq at the to write and quit the file. Now, if you have not already, you have to create user chris. To do this, enter:

useradd chris

To create a password of user chris, enter:

passwd chris

Then enter the password when prompted. Now, you should have a user chris on your system that can run ifconfig, kill and ls as root.

External links:

The sudo project page

The post sudo: Options and Configuration appeared first on pfSense Setup HQ.

Enabling sudo logging in CentOS.

As mentioned in the introduction to sudo, the sudo command logs which users run what commands. Logging does not occur automatically. You need to set up sudo and syslogd to log commands. This involves two steps. First, you must create a sudo logfile in /var/log. Second, you must configure syslog.conf to log sudo commands. To configure sudo logging, follow these steps:

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

1. Log on as root. Create a sudo log file in /var/log. Enter:
   touch /var/log/sudo
2. Next, you need to add a line in the syslog.conf file to direct logging to your sudo logging file. Open syslog.conf by entering the following:
   vi /etc/syslog.conf
3. Enter the following line at the end of the syslog.conf file (press i to insert text). The whitespace must be created using TAB, not the SPACE BAR.
   local2.debug /var/log/sudo
4. This syslog.conf entry logs all successful and unsuccessful sudo commands to the /var/log/sudo file. You can also log to a network host by indicating the network host instead of a local directory.
5. Press ESC to write and quit the file, and enter wq at the colon.
6. Since you have modified the syslog.conf file, you need to restart syslogd. To send a HUP signal to syslogd, you must first know this sylogd process identifier (PID). To find the syslogd PID, type:
   ps aux | grep syslogd
7. The second column lists the PID number. The last column lists the process using that PID. This is the information you need to enter the appropriate kill command and restart syslogd. Type:
   kill -HUP (PID NUMBER)
8. First, you will generate log entries for user chris. Log on as user chris.
9. Enter the following ifconfig commands while logged on as user chris:
   sudo -lsudo /sbin/ifconfig eth0 down
   sudo /sbin/ifconfig etho up
10. Restart one of the httpd proceesses 9or another process of your choice) using the kill command by entering:
    ps aux | grep httpd
11. Choose an Apache (httpd) PID from the list that appears. Enter:
    sudo kill -HUP (PID NUMBER)
12. Now list the root user directory as user chris. Enter:
    sudo ls /root
13. Log on as root and view the sudo log file. All the sudo commands that chris entered should be listed.
14. You can log any root commands by simply typing sudo before each command. For example, make sure that you afre logged on as root and enter the following commands:
    sudo useradd bessie
    sudo passwd bessie
    sudo vi /hosts
15. Access and view the sudo log by entering:
    sudo cat /var/log/sudo
    All root user entries are logged, including the cat command you just entered.

Obviously, sudo is very helpful for controlling an auditing root access. It allows a system administrator to distribute root access without giving out the root password. An administrator can control what root access is needed for each user, and can customize system access based on those needs.

External Links:

Introduction to sudo at linux.com

The post sudo Logging appeared first on pfSense Setup HQ.

When you specify your targets for scanning, nmap will accept specific IP addresses, address ranges in CIDR format, and octet format (i.e. x.x.x.x). If you have a host file, which may have been generated from your ping sweep earlier, you can specify it as well using the -iL flag. There are other, more formal nmap parsing programs out there, but awk can be used to create a quick and dirty hosts file from an nmap ping sweep. Scripting can be a very powerful addition to any tool, but remember to check all the available output options to avoid doing too much work.

nmap allows the user to specify the speed of the scan, or the amount of time from probe sent to replay received, and therefore how fast packets are sent. On a fast LAN, you can optimize your scanning by setting the -T option to 4, or Aggressive, usually without dropping any packets during send. If you find that a normal scan is taking very long due to ingress filtering or a firewall device, you may want to enable Aggressive scanning. If you know that an IDS sits between you and the target, and you want to be as stealthy as possible, the using -T0 or Paranoid should do what you want; however, it will take a long time to finish a scan, perhaps several hours, depending on your scan parameters.

By default, nmap 6.40 with Auditor scans 1000 ports for common services, which will catch most open TCP ports out there. However, sneaky sysadmins may run ports on uncommon ports, practicing security through obscurity. Without scanning those uncommon ports, you may be missing these services. If you have time, or suspect that a system may be running other services, run nmap with the -p1-65535 parameter, which will scan all 65k TCP ports. Even on a LAN with responsive systems, this will take anywhere from 30 minutes to a few hours. Performing a test like this over the Internet may take even longer, which will allow more time for the system owners, or watchers, to note the excessive traffic and shut you down.

Ping Sweeping with netenum

Finally, if you have a need for a very simple ICMP ping sweep program that you can use for scriptable applications, netenum might be useful. It performs a basic ICMP ping and then replies with only the reachable targets. One quirt about netenum is that it requires a timeout to be specified for the entire test. If no timeout is specified, it outputs a CR-delimited dump of the inputted addresses. If you have tools that will not accept a CIDR formatted range of addresses, you might use netenum to simply expand that into a listing of individual IP addresses. netenum is part of the Internetwork Routing Protocol Attack Suite, which also includes such utilities as cdp (for sending Cisco router Discovery protocol messages), and ass (Automated System Scanner).

External Links:

The official nmap site

Official site for the Internetwork Routing Protocol Attack Suite (IRPAS) – netenum is part of IRPAS

The post Open Source Tools: Part Three (Even more nmap options) appeared first on pfSense Setup HQ.

In this article, we’ll begin to discuss the tools that are useful in the enumeration phase of an assessment. These port enumeration tools will scan a list of targets and ports to help determine more information about each target. The enumeration phase usually reveals program names, version numbers, and other detailed information that will eventually be used to determine vulnerabilities on these systems.

The version-scanning feature of nmap is invoked with the -sV flag. Based on a returned banner, or on a specific response to an nmap-provided probe, a match is made between the service response and the nmap service fingerprints. This is a new feature and since it interrogates discovered services, many intrusion detection system (IDS) vendors will be writing signature files for this type of behavior, so use it with caution.

Port Enumeration Tools: p0f

p0f is the only passive fingerprinting port enumeration tool included in the Auditor distribution. If you want to be extremely stealthy in your initial scan and enumeration processes, and don’t mind getting high-level results for OS fingerprinting, p0f is the tool for you. It works by analyzing the responses from your target on innocuous queries, such as Web traffic, ping replies, or normal operations. p0f gives the best estimation on an operating system based on those replies, so it may not be as precise as other active tools, but it can still give you a good starting point.

Port Enumeration Tools: Xprobe2

Another important port enumeration tool is Xprobe2, which is primarily an OS fingerprinter, but also has some basic port-scanning functionality built in to identify open or closed ports. You can also specify known open or closed ports, to which Xprobe2 performs several different TCP-, UDP-, and iCMP-based tests to determine the remote OS. The version supplied with Auditor is one version behind, but newer versions have more fingerprints. You will likely want to provide Xprobe2 with a known open or closed port for it to determine the remote OS.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

If you run across a web server and want to know the HTTP daemon running without loading up a big fingerprinting tool that might trip IDS sensors, then httprint may be your tool of choice, as it is designed for just such a purpose. It only fingerprints http servers, and does both banner grabbing as well as signature matching against a provided signatures file.

Port Enumeration Tools: IKE-scan

One of the more common VPN implementations involves the use of IPsec tunnels. Different manufacturers have slightly different usages of IPsec, which can be discovered and fingerprinted using IKE-scan. IKE stands for Internet Key Exchange, and is used to provide a secure basis for establishing an IPsec-secured tunnel. IKE-scan can be run in two different modes: Main (-M) and Aggressive (-A), each of which can identify different VPN implementations. Both operate under the principle that VPN servers will attempt to establish communications to a client that only sends the initial portion of an IPsec handshake. An initial IKE packet is sent (with Aggressive mode, a UserID is also specified), and based on the time elapsed and types of responses sent, the VPN server can be identified based on service fingerprints. In addition to the VPN fingerprinting functionality, IKE-scan includes psk-crack, which is a program used to dictionary crack pre-shared keys (psk) used for VPN logins. IKE-scan does not have fingerprints for all VPN vendors, and since the fingerprints change based on version increase, you may not find a fingerprint for your specific VPN, but you can still gain useful information such as the Authentication type and encryption algorithm used.

Sometimes, you may encounter a service that may not be easily recognizable by port number or immediate response. amap will send multiple queries and probes to a specific service, and then analyze the results, including returned banners, to identify what application or service is actually running on a specific port. There are options that allow you to minimize parallel attempts, or really stress the system with a large number of attempts, which may provide different information. You can also query a service once, and report back on the first matching banner reported, using the -1 option.

In the next article, we’ll continue our look at various port enumeration tools.

External Links:

Official p0f website

p0f on Wikipedia

X probe2 on sourceforge.net

IKE-Scan home page

The post Port Enumeration Tools: Part One appeared first on pfSense Setup HQ.

In previous blog postings, I have discussed how the open source community has created powerful packet sniffing tools, and how they can be used either to administer your network or to attack it. Because these sniffing tools are open source, and because it is relatively easy to place a Linux host on your company network, you need to consider ways to minimize improper use of packet capturing tools. Encryption solutions, such as Secure Shell (SSH) and Kerberos, are two common solutions to this problem.

Algorithms are the underlying foundation of cryptography. Thus, we will look at the basics of algorithms first, starting with symmetric and asymmetric encryption.

Cryptography Defined

Cryptography predates the computer era; as long as people have been writing down information, there has been a need to keep some information secret, either by hiding its existence or changing its meaning. Encryption, a type of cryptography, refers to the process of scrambling information so that the casual observer cannot read it. An algorithm is a set of instructions for mixing and rearranging an original message (called plaintext), with a message key to create a scrambled message, referred to as ciphertext. Similarly, a cryptographic key is a piece of data used to encrypt plaintext to ciphertext, and ciphertext to plaintext, or both, depending on the type of encryption.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

The word crypto has its origins in the Greek word kruptos, which means hidden. The objective of cryptography is to hide information so that only the intended recipients can read it. In crypto terms, the hiding of information is called encryption, and when information becomes readable, it is called decryption. A cipher is used to accomplish the encryption and decryption. The information that is being hidden is called plaintext; once it has been encrypted, it is called ciphertext. The ciphertext is transported to the intended recipient or recipients, where it is decrypted back into plaintext.

Finally, there are two different subclasses of algorithms: block ciphers and stream ciphers. Block ciphers work on blocks or chunks of text in a series. In contrast a stream cipher operates on each individual unit, either letters or bits, of a message.

There are many different encryption algorithms, and in each case, there are tradeoffs between security, speed, and ease of implementation. Here, security indicates the likelihood of an algorithm to stand up to current and future attacks, speed refers to the processing prower and time required to stand up to current and future attacks, speed refers to the processing power and time required to encrypt and decrypt a message, and ease of implementation refers to an algorithm’s predisposition (if any) to hardware or software usage. Each algorithm has different strengths and drawbacks and none of them are ideal in every way. The key algorithms fall into three main categories:

• Symmetric cryptography
• Asymmetric cryptography
• Hashing algorithms

In the next few articles, we will review each of these categories.

External Links:

Cryptography at Wikipedia

Cryptography I – enroll in a free 6-week course in cryptography at coursera.org

The post Cryptography: An Introduction appeared first on pfSense Setup HQ.

Data Encryption Standard (DES).

The most commonly used type of encryption is symmetric encryption, which is aptly named because it uses one key for both the encryption and decryption process. Symmetric encryption is also commonly referred to as secret-key encryption and shared-secret encryption, but all terms refer to the same class of algorithm.

The reason why symmetric encryption systems are abundant is speed and simplicity. The strength of symmetric algorithms lies primarily in the size of the keys used in the algorithms, as well as the number of cycles each algorithm employs. The cardinal rule is “fewer is faster”.

By definition, all symmetric algorithms are theoretically vulnerable to brute-force, which are exhaustive searches of all possible keys. Brute-force attacks involve methodically guessing what the key to a message may be. Given that all symmetric algorithms have a fixed key length, there are a large number of possible keys that can unlock a message. Brute-force attacks methodically attempt to check each key until the key that decrypts the message is found. However, brute-force attacks are often impractical, because of the amount of time necessary to search the keys is greater than the useful life expectancy of the hidden information. No algorithm is truly unbreakable, but a strong algorithm takes so long to crack that it is impractical to try. Because brute-force attacks originate from computers, and because computers are continually improving in efficiency, an algorithm that may be resistant to attacks by computers 5 to 10 years in the future.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

Data Encryption Standard

Among the oldest and most famous encryption algorithms is the Data Encryption Standard (DES), the use of which has declined with the advent of algorithms that provide improved security. DES was based on the Lucifer algorithm invested by Horst Feistel. Essentially, DES uses a single 64-bit key – 56 bits of data and 8 bits of parity – and operates on data in 64-bit chunks. This key is broken into 16 48-bit subkeys, one for each round, which are called Feistel cycles.

Each round consists of a substitution phase, wherein the data is substituted with pieces of the key, and a presentation phase, wherein the substituted data is scrambled (re-ordered). Substitution operations, sometimes referred to as confusion operations, occur within S-boxes. Similarly, permutation operations (sometimes called diffusion operations) are said to occur in P-boxes. Both of these operations occur in the “F Module”. The security of DES lies in the fact that since the substitution operations are non-linear, the resulting ciphertext does not resemble the original message. The permutation operations add another layer of security by scrambling the already partially encrypted message.

Triple DES (3DES) and DESX are methods that attempt to use the DES cipher in a way that increases in security. Triple DES uses three separate 56-bit DES keys as a single 168-bit key, though sometimes keys 1 and 3 are identical, yielding 112-bit security. DESX adds an additional 64 bits of key data. Both 3DES and DESX are intended to strengthen DES against brute-force attacks. it would take many years to decrypt 3DES encrypted date (depending on available computing power). However, 3DES is inefficient because it requires two to three times the processing overhead as a single DES.

Shortcomings of Data Encryption Standard

For Data Encryption Standard, questions were raised about the adequacy of its key size from the start, even before it was adopted as a standard, and it was the small key size which dictated a need for a replacement algorithm. In academia, various proposals for a DES-cracking machine were advanced. Although there is no known publicly acknowledged implementation of these Data Encryption Standard-cracking machines, by the late 1990s, the vulnerability of DES was practically demonstrated. In 1997, RSA Security sponsored a series of contests, offering a $10,000 prize to the first team that broke a message encrypted with DES for the contests. That contest was won by the DESCHALL Project. The feasibility of cracking DES quickly was demonstrated in 1998 when a custom DES-cracker was built by the Electronic Frontier Foundation (EFF) at the cost of approximately $250,000 (u.S.). They were able to crack a DES key using a brute-force attack in less than two days. Subsequent improvements in processing power employed by other DES crackers reduced this time to less than a day. Because of the ease with which DES could be cracked, the National Institute of Standards and Technology (NIST) selected the Advanced Encryption Standard (AES) as the authorized Federal Information Processing Standard (FIPS) 197 for all non-secret communications by the U.S. government, which became effective in May 2002.

External Links:

Data Encryption Standard (DES) on Wikipedia

The post Data Encryption Standard (DES) appeared first on pfSense Setup HQ.

The subbytes step of AES encryption.

AES Encryption

Because of the small key size of 56 bits, DES can’t withstand coordinated brute-force attacks using modern cryptanalysis; dedicated machines can now break DES within a day. Consequently, The National Institute of Standards and Technology (NIST) selected the Advanced Encryption Standard (AES) as the authorized Federal Information Processing Standard (FIPS) 197 for all non-secret communications by the U.S. government, which became effective in May 2002. AES is included in the ISO/IEC 18033-3 standard. AES has the following important characteristics:

• Private key symmetric block cipher (similar to DES)
• Stronger and faster than 3DES
• Life expectancy of at least 20 to 30 years
• Supports key sizes of 128 bits, 192 bits, and 256 bits
• Freely available to all; royalty free, non-propriety, and not patented
• Small footprint: AES can be used effectively in memory and in central processing unit (CPU) limited environments such as smart cards

It should be noted that the AES (Rjindael) algorithm was selected by NIST from a group that included four other finalists: MARS, RC6, Serpent, and Twofish. It was developed by Belgian cryptographers Dr. Joan Daemen and Dr. Vincent Rijmen. (The name Rjindael is a play on the names of the two inventors, Daemen and Rijmen.) It seems resistant to side-channel attacks such as power- and timing-based attacks, which are attacks against a hardware implementation, not against a particular algorithm. For example, power-and timing-based attacks measure the time it takes to encrypt a message or the minute echanges in power consumption during the encryption and decryption process. Occassionally, these attacks are sufficient enough to allow hackers to recover keys used by the device.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

Unlike DES, which uses Feistel cycles in each round, Rijindael uses iterative rounds like International Data Encryption Algorithm (IDEA). It is a minor revision of an earlier cipher, Proposed Encryption Standard (PES). Data operates on 128-bit chunks, which are grouped into four groups of 4 bytes each. The number of rounds is also dependent on the key size, such that 128-bit keys have 9 rounds, 192-bit keys have 11 rounds, and 256-bit keys have 13 rounds. Each round consists of a substitution step of one S-box per data bit, followed by a pseudo-permutation step in which bits are shuffled between groups. Then each group is multiplied out in a matrix fashion and the results are added to the subkey for the round.

IDEA Encryption

The European counterpart to the DES algorith is the IDEA. Unlike DES, which it was intended as a replacement for, it is a considerably faster and more secure. IDEA’s enhanced speed is due to the fact that each round consists of simpler operations than in the Feistel cycle in DES. IDEA uses simple operations like exclusive or (XOR), addition and multiplication, which are more efficient to implement in software than the substitution and permutation operations of DES. Addition and multiplication are the two simplest binary calculations for a computer to perform, and XOR is also a simple operation.

IDEA operates on 64-bit blocks with a 128-bit key, and the encryption/decryption process uses eight rounds with six 16-bit subkeys per round. The IDEA algorithm is patented both in the U.S. and in Europe, but free non-commercial use is also permitted. IDEA is widely recognized as one of the components of Pretty Good Privacy (PGP) version 2.0. It is also an optional algorithm in the OpenPGP standard. IDEA was developed in the early 1990s by cryptographers James Masey and Xuejia Lai as part of a combined research project between Ascom and the Swiss Federal Institute of Technology. The algorithm was patented in a number of countries, but was freely available for non-commercial use. “IDEA” is also a trademark. The last patents expired in 2012, and IDEA is now free to use for both commercial and non-commercial purposes.

External Links:

Advanced Encryption Standard (AES) at Wikipedia

International Data Encryption Algorithm (IDEA) at Wikipedia

The post AES and IDEA Encryption Algorithms appeared first on pfSense Setup HQ.

The biggest disadvantage to using symmetric encryption algorithms relates to key management. In order to ensure confidentiality of communication between two parties, each communicating pair needs to have a unique secret key. As the number of communicating pair needs to have a unique secret key, As the number of communicating pairs increases, there is a need to manage a number of keys related to the square of the communicators, which quickly becomes a complex problem.

Introducing Asymmetric Encryption

Asymmetric encryption algorithms were developed to overcome this limitation. Also known as public-key cryptography, these algorithms use two different keys to encrypt and decrypt information. If cleartext is encrypted with an entity’s public key, it can only be decrypted by the public key. The basic principle is that the public key can be freely distributed, while the private key must be held in strict confidence. The owner of the private key can encrypt cleartext to create cyphertext that can only be decoded with its public key, thus assuring the identity of the source, or it can use the private key to decrypt cyphertext encoded with its public key, assuring the confidentiality of the data. Although these keys are generated together and are mathematically related, the private key cannot be derived from the public key.

Instead of relying on the techniques of substitution and transportation that symmetric key cryptography uses, asymmetric encryption algorithms rely on the use of large-integer mathematics problems. Many of these problems are simple to do in one direction but difficult to do in the opposite direction. For example, it is easy to multiply two numbers together, but it is more difficult to factor them back into the original numbers, especially if the integers used contain hundreds of digits. Thus, in general, the security of asymmetric encryption algorithms is dependent not upon the feasibility of brute-force attacks, but the feasibility of performing difficult mathematical inverse operations and advances in mathematical theory that may propose new “shortcut” techniques.

Asymmetric encryption  is much slower than symmetric encryption. There are several reasons for this. First, it relies on exponentiation of both a secret and public exponent, as well as generation of a modulus. Computationally, exponentiation is a processor-intensive operation. Second, the keys used by asymmetric encryption algorithms are generally larger than those used by symmetric algorithms, because the most common asymmetric attack, factoring, is more efficient than the most common symmetric attack: brute force.

Because of this, asymmetric encryption algorithms are typically used only for encrypting small amounts of information. In subsequent articles, we will example different asymmetric algorithms, such as Diffie-Hellman, RSA, and El Gamal.

External Links:

Public-key cryptography at Wikipedia

The post Asymmetric Encryption appeared first on pfSense Setup HQ.

The firewall GUI in Fedora.

The next step is to demonstrate how to configure the netfilter firewall. This is a critical step and the firewall should only be installed and configured after the underlying OS has been installed, updated, and hardened. We assume here that you are working with an otherwise secure system and now need to configure the firewall’s functionality.

To make sure the firewall is enabled, you can run chkconfig –list, which lists all of the services and the run levels they are configured to start in. For example, you may get the following output:

chkconfig –list | grep iptables

iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off

This output tells you that iptables will start in run levels 2-5. You can set it to run in run levels 2-5 by using the chkconfig -level 2345 iptables on command. If you are using a GUI window manager, you probably have another graphical application to see this information. For example, in Fedora, you can navigate to System -> Administration -> Security Level and Firewall.

You can enable or disable the firewall by going to the Firewall Options tab and selecting Enabled or Disabled. The interface in Fedora allows you to perform limited configurations of the firewall rules (e.g., by checking the Trusted Service SSH, a rule would be added to allow inbound connections on TCP port 22). Because any graphical interface provided will likely vary from one distribution to another, we use the command line to configure the firewall.

netfilter Operation: Deleting Rules and Chains

With many Linux distributions, the netfilter firewall will become enabled, but with an empty ruleset. In others, it might come with the firewall enabled and a very liberal ruleset in place. We can start configuring a Linux firewall by deleting any default rules that are present. You can use iptables -L (or –list) to list the current rules. An empty default ruleset should look like this:

iptables -L
Chain INPUT (policy ACCEPT)
Target prot opt source destination

Chain FORWARD (policy ACCEPT)
Target prot opt source destination

Chain OUTPUT (policy ACCEPT)
Target prot opt source destination

If there are any default rules present, they can be deleted using the iptables -F command. The -F option means to flush, which is equivalent to using -flush. This will clear all rules out of any existing chains. If distribution has any additional chains created beyond the default, you can delete a custom chain by using the iptables -N customchain command. In addition to the individual rules within a chain, the built-in chains have a default policy associated with them. This policy tells netfilter what to do if a packet reaches the end of the chain without finding a match. While the default policy is to ACCEPT, it is better to change this to DROP by using the -P option, which sets the default policy for that chain, as follows:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

We will continue our look at netfilter configuration in the next article.

External Links:

Basic Fedora Linux Firewall Configuration at www.techtopia.com

The post netfilter Operation: Part Three appeared first on pfSense Setup HQ.

Simulating the Windows Firewall

Now it’s time to configure the firewall. The built-in firewall on Windows XP/Vista/7/8 is enabled by default (on XP Service Pack 2 or better). The standard configuration is to allow outbound connections from the host system and deny inbound connections unless they are explicitly configured. The Windows firewall also allows any traffic that is a reply to traffic that the host originally generated. After you execute the iptables -F command to flush out all the previously configured rules, the following commands would configure the Linux host similarly:

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

The –state extensions track the current status of the connections. By specifying ESTABLISHED or RELATED, the firewall allows packets that are starting a new session, but where the session is related to an existing session (such as an FTP data session). If you were hosting a service on this system, such as a Web server, you would need to configure the INPUT chain appropriately. This configuration would afford any Linux system a minimum level of firewall security with virtually no impact to its overall functionality.

Simulating a Consumer-Grade Home Router

With the basics of iptables configuration out of the way, let’s consider a more practical example. For a typical firewall, there is very little traffic destined to or from the firewall itself. In general, the only traffic that would fit this profile would be administrative sessions to configure the firewall itself. The vast majority of a firewall’s traffic is passing through the firewall, and will thus be checked against the FORWARD chain. The following examples would configure the Linux firewall with the same access controls as a typical home network router such as a Linksys or Netgear router/firewall. This example assumes that 192.168.1.0/24 is the internal network on interface eth0 and the external interface is eth1.

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -s 192.168.1.0/24 -i eth0 –dport 80 -j ACCEPT

iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -0 eth1 -j ACCEPT

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

One important element is to always remember that if you have configured the default policy for a chain to DROP (for example, iptables -P FORWARD DROP) that you will need to include an explicit rule to permit the return traffic. This can be done by using the following command:

iptables -A -m state –state ESTABLISHED,RELATED -j ACCEPT

So if you wanted to permit the return traffic for a FORWARD chain, you would enter:

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

Many hours of troubleshooting Linux firewalls have been spent by overlooking a rule that permits the return traffic.

We will continue our look at netfilter firewall configuration in the next article.

External Links:

Simulating windows firewall with iptables at ittopix.wordpress.com

The post netfilter Operation: Part Five appeared first on pfSense Setup HQ.

In the previous article, we began the process of simulating a home router with netfilter. We will continue that process in this article.

We began with the these iptables commands:

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -s 192.168.1.0/24 -i eth0 –dport 80 -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -o eth1 -j ACCEPT
 iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

The INPUT chain allows port 80 to go to the firewall itself from the internal network. Many of the home routers have a Web interface for configuring them, and while your configuration may not need this port open to the firewall, it is included here to help emphasize how the different chains are used. It is important to specify the input interface (using -i) so that the source IP cannot be spoofed by an external attacker. In this way, you ensure that even if a packet was generated with the proper source IP, if it came in on the outside interface (eth1) it would not match the rule and would thus not be permitted. The FORWARD rule allows any outbound traffic from the internal network to the external network. This configuration is simple to implement; however, the 192.168.1.0 IP range is a private IP range and is not routable on the Internet. Thus, this range would not allow traffic from the internal network to the Internet quite yet. To make this Linux firewall a useful replacement for a home network router, you need to enable NAT, which allows all of the systems on your internal network to appear as a single IP address when communicating on the Internet.

Enabling NAT

In principle NAT is simple, but in a complex environment it can get confusing. Basically, NAT means that the NAT device (in this case the Linux netfilter firewall) will change the IP address in apacket and retransmit that packet. Depending on your needs, you can alter the source IP address (source NAT, or SNAT), the destination IP address (destination NAT, DNAT), or both (double NAT). With a home router, the objective behind the NAT capability is to allow all of the internal hosts to communicate on the Internet using the single public IP provided by your Internet Service Provider (ISP). (In this case, SNAT is being used). As each of the hosts on your private network make a connection to an Internet server, the firewall is altering the source address to look like the public IP from your ISP. By doing this, the return traffic can find its way back to the firewall and be retranslated and sent to the originating host.

In this example, assume that the internal host has a private IP address of 192.168.1.11. The public address of the firewall is 5.5.5.5, which is provided by the ISP. If a host on the private network wants to make a connection to pfsensesetup.com. The firewall alters the source address to its own public IP address of 5.5.5.5 and sends the packet on its way. When the server replies to destination 5.5.5.5, the firewall again edits the packet, this time inserting a new destination of 192.168.1.11. All of this takes place and is transparent to the 192.168.1.11 host and the pfsensesetup.com server. When multiple hosts are using SNAT, the firewall tracks which connections belong to which private hosts using the port numbers. While the destination port of the Web server remains static (typically port 80 for the Web), the source port is usually a random port above 1024. By tracking the source port, the firewall knows which address belongs to which session. In the event that two hosts attempt to use the same source port, the NAT device edits the source port of one of the connections and replaces it with another random source port. When the return traffic is received, it translates the source port back, just like it did for the IP address. because this method of NAT relies heavily on using the source port number, it is sometimes referred to as port NAT (PNAT).

To add the SNAT functionality to the example firewall, use the following command:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT –to-source 5.5.5.5

The -r option is used to specify the table we want to modify, and -A option specifies that we are going to append this rule to the POSTROUTING chain. By specifying the outbound interface, we are ensuring that the SNAT only occurs as traffic leaves the private network, meaning only in the proper direction.

The jump target SNAT is self explanatory. The –to-source option specifies what IP address we want to use as the new source address. SNAT assumes we have a static IP address to SNAT the outgoing packets to. While this is likely the case in a corporate environment, a more appropriate solution to more closely mimic the configuration of a home router would be to use the MASQUERADE command:

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

The masquerade command does not require an IP specification, and will use the IP address of the firewall interface. You might be wondering why you would not use the masquerade target all of the time instead of the SNAT target. Because the source IP is static, the SNAT target will cause the NAT calculations to be performed once for a given session. Subsequent packets belonging to that session are handled the same way as the first. With the masquerade target, each packet is checked for the source IP to use, which requires more overhead than with SNAT. This is why SNAT is preferable if you have a static source IP address, and masquerade is your only option if you do not have a static source IP address to use.

External Links:

Linux 2.4 NAT HOWTO at www.netfilter.org

The post netfilter Operation: Part Six appeared first on pfSense Setup HQ.

By this point, you should have a relatively solid grasp of how to configure a Linux firewall. So far we have covered all of the core commands to permit and deny the traffic. Another useful command for your Linux firewall deals with logging packets. If you want to log everything passing through the firewall, use the iptables -A FORWARD -j LOG command. While simple, this would likely generate an excessive amount of logging traffic. You also might want some additional control of how the logging occurs. There are some additional options to provide this functionality. Of particular note are the –log-level and –log-prefix options.

The –log-level option allows you to specify what logging level is used for the LOG rule, The effect this log level has depends on how you have your kernel logging configured (via syslog or syslog-ng). When you combine the custom logging level of iptables with the syslog configuration, you can have syslog act in any manner of ways based on the firewall logs, including sending e-mails for certain events. The –log-prefix option allows you to insert up to a 29-letter string in front of the log entry. This can be useful for troubleshooting purposes. Some examples of information you could place in log prefix would be the name of the chain that generated the log entry such as iptables -A FORWARD -j LOG –log “from FORWARD chain.”

Saving and Restoring a Ruleset

Now that you can create a working ruleset for netfilter, you will want to save it. There are two commands of note: one for saving the configurations and one for loading a save configuration. You can use the iptables-save command to generate output that is the current active ruleset. By default, it will only generate the output to the stdout, meaning it will display in the console. To save this output, redirect it to a file. To redirect the current ruleset to a file called /etc/ruleset, you would type iptables-save > /etc/ruleset. If you want to save the current packet counts and rule counts, use the iptables-save -c > /etc/ruleset command. Individual tables can be saved separately by specifying the -t option using the iptables-save -t mangle > /etc/ruleset command.

Restoring a ruleset is accomplished using the iptables-restore command. Like iptables-save, the restore function takes only two optional arguments. The -c option will cause iptables to load the saved packet and byte counts, overwriting the current count values. The default behavior when using iptables-restore is to flush the ruleset before loading the saved ruleset, thus all previous rules are lost. If you wish to override this behavior, you can use the -n option, in which case the fules will be added to the existing ruleset, and will only overwrite if there is a duplicate rule. You can use the iptables-restore < /etc/ruleset command to pipe the saved configuration to iptables-restore.

External Links:

How to Log Linux iptables Firewall Dropped Packets to a Log File at The Geek Stuff

The post netfilter Operation: Part Seven appeared first on pfSense Setup HQ.

Firewall Options tab in the Red Hat firewall configuration GUI.

While the console commands that are used to manipulate and configure netfilter are not very complicated, the can sometimes get rather lengthy. As the length of the command line grows, the chances of an accidental error increase. Alternatively, you may not like working on the command line, in which case there are a wide variety of GUI and menu-driven interfaces available for netfilter. In most cases, these menu-driven interfaces use your input to create the appropriate iptables commands, and alleviate you having to know the various switches and options to use. There are a large number of GUI interfaces available to configure your netfilter firewall. In general simpler also means less full featured, so be aware that if you are trying to create a complex ruleset, some GUIs may not have the needed functionality.

You can start the iptables GUI provided with Red Hat-based Linux distributions by navigating to System -> Administration -> Security Level and Firewall. You can also call the program directly by running system-config-securitylevel from a terminal window. While the interface looks nice, it is limited in what it can configure. Basically, all you can do with this GUI is permit or deny certain ports. Fedora Core 5 and subsequent versions of Fedora configures the INPUT and FORWARD chains to jump a custom chain named RH-Firewall-1-INPUT. There is no ability to differentiate between ports permitted in the INPUT chain or the FORWARD chain, because all rules configured through the GUI are applied to this custom chain.

Some services are pre-defined for you. Placing a check next to SSH and clicking OK and then Yes to commit the changes would create the following rule in the RH-Firewall-1-INPUT chain:

iptables -A RH-Firewall-1 INPUT -p tcp -m state –sate NEW -m tcp –dport 22 -j ACCEPT

By expanding Other ports on the Firewall Options tab, you can enter a custom port number.

Click Add, and enter the desired port number in the dialog box. Use the drop-down menu to select TCP or UDP for the protocol and click OK.

This creates a rule identical to the SSH rule. There are no other configuration options. While this interface is adequate for a home PC that isn’t running any services, it probably will not be adequate for a corporate firewall. If you need to configure access based on the interface in use or need to configure any NAT rules, you will need to use a different GUI. While you probably won’t be needing this particular GUI as a corporate firewall, it is still useful to be familiar with it if you are running any Linux systems as workstations.

External Links:

How to edit iptables rules at fedoraproject.org – includes a section on using the Red Hat GUI configuration tool

The post netfilter Operation: Part Eight appeared first on pfSense Setup HQ.