pfSense Multi-WAN Configuration: Part Two

pfSense multi WAN

Configuring the DNS forwarder in pfSense 2.2.4.

In the first article, we covered some basic considerations with a multi-WAN setup. in this article, we will cover multi-WAN configuration.

First, the WAN interfaces need to be configured. You should set up the primary WAN the same way you would in a single WAN setup. Then for the OPT WAN interfaces, select either DHCP or static, depending on your Internet connection type. For static iP conncections, you will need to fill in the IP address and gateway.

Next, you need to configure pfSense with DNS servers from each WAN connection to ensure it is always able to resolve DNS. This is important, especially if your network uses pfSense’s DNS forwarder for DNS resolution. If you only use one ISP’s DNS servers, an outage of that WAN connection will result in a complete Internet outage regardless of your policy routing configuration.


pfSense uses its routing table to reach the configured DNS servers. This means without any static routes configured, it will use only the primary WAN interface to reach DNS servers. Static routes must be configured for any DNS server on an OPT WAN interface to reach that DNS server. Static routes must be configured for any DNS server on an OPT WAN interface, so pfSense uses the correct WAN interface to reach that DNS server.

This is required for two reasons. [1] Most ISPs prohibit recursive queries from hosts outside their network. Thus, you must use the correct WAN interface to access that ISP’s DNS server. [2] If you lose your primary WAN interface and do not have a static route defined for one of your other DNS servers, you will lose all DNS resultion ability in pfSense, since all DNS servers will be unreachable when the system’s default gateway is unreachable. If you are using pfSense as your DNS server, this will result in a complete failure of DNS for your network.

pfSense Multi-WAN: Static IPs vs. Dynamic IPs

A setup that has all static IPs on the WAN interfaces is easy to handle, as each WAN has a gateway IP that will not change. Dynamic IP WAN interfaces, on the other had, pose difficulties because their gateway is subject to change and static routes in pfSense must point to a static IP address. This usually is not a major problem, since only the IP address changes while the gateway remains the same. If your OPT WAN public IP changes subnets (and therefore gateways) frequently, use of the DNS forwarder in pfSense is not an acceptable solution for redundant DNS servcies; you will still have no reliable means of reaching a DNS server over anything other than the WAN interface.

pfSense multi-WAN

Configuring DNS servers with multiple WAN interfaces in pfSense 2.2.4.

With dynamic IP WANs, you have two alternatives. Because traffic from the inside networks is policy routed by your firewall rules, it is not subject the the limitation of requiring static routes. You can either use DNS servers on the Internet on all your internal systems, or use a DNS server or forwarder on your internal network. As long as DNS requests are initiated from inside your network and not on the firewall itself (as it is in the case of the DNS forwarder), static routes are not required and have no effect on traffic initiated inside your network when using policy routing.

A second option to consider is using one of your DNS server IPs from each Internet connection as the monitor IP for that connection. This will automatically add the appropriate static routes for each DNS server.

If you have a mix of statically and dynamically addressed WAN interfaces, then the primary WAN should be one of your dynamic IP WANs, as static routes are not required for DNS servers on the primary WAN interface.

The image on the right shows separate DNS servers with a multi-WAN setup in pfSense. In System -> General Setup, you can enter the DNS servers, and you can select the gateway used with the selected DNS server in the dropdown box on the right. As you can see, I have selected different WAN interfaces for each of the DNS servers, so the two WAN interfaces (WAN and WAN1) are not dependent on the same DNS server.


 

External Links:

Network Load Balancing on Wikipedia

Nlog Add-Ons and Extensions

NlogIn 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

Extensions Descriptions
Nlog-rpc.pl This add-on takes any RPC services that are found and attemps to find out if there are any current RPC attachments and exports for that service
Nlog-smb.pl For any nodes running NetBIOS, this script tries to retrieve shares, user lists, and any other domain information it can get. It uses the user name and login specified in the nlog-config.ph file.
Nlog-dns.pl This script runs a standard nslookup command on the IP address.
Nlog-finger.pl This runs a query against any finger service found running to see what information is sent.

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)

whois and dig Commands

whoisThe whois Command

The whois command is useful when trying to track down a contact for someone causing trouble on your network. This command queries the primary domain name servers and returns all the information that Internic (or whoever their name registrar is) has. Internic used to be the quasi-government agency that was responsible for keeping track of all the domain names on the Internet. Internic became a commercial company called Network Solutions, and was then acquired by VeriSign. Now that name registration has been opened up for competition, there are literally dozens of official name registrars. However, you can still usually find out who owns a domain by using the whois command.

This command is useful for attacks coming both from within companies or within ISP networks. Either way, you can track down the person responsible for that network and report your problems to them. They won’t always be helpful, but at least you can try. The syntax is:

whois domain-name.com

The variable domain-name.com is the domain name on which you are looking for information.

As an example, here’s the whois information for linux.com:

Domain Name: LINUX.COM
Registry Domain ID:
Registrar WHOIS Server: whois.domain.com
Registrar URL: www.domain.com
Updated Date: 2013-05-08 13:51:05
Creation Date: 1994-06-02 04:00:00
Registrar Registration Expiration Date: 2016-06-01 04:00:00
Registrar: Domain.com, LLC
Registrar IANA ID: 886
Registrar Abuse Contact Email: compliance@domain-inc.net
Registrar Abuse Contact Phone: +1.6027165396
Reseller: Dotster.com
Reseller: support@dotster-inc.com
Reseller: +1.8004015250
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Registry Registrant ID:
Registrant Name: Jim Zemlin
Registrant Organization: The Linux Foundation
Registrant Street: 660 York Street Suite 102
Registrant City: San Francisco
Registrant State/Province: CA
Registrant Postal Code: 94110
Registrant Country: US
Registrant Phone: +1.4157239709
Registrant Phone Ext:
Registrant Fax: +1.4157239709
Registrant Fax Ext:
Registrant Email: admin@linux-foundation.org
Registry Admin ID:
Admin Name: Jim Zemlin
Admin Organization: The Linux Foundation
Admin Street: 660 York Street Suite 102
Admin City: San Francisco
Admin State/Province: CA
Admin Postal Code: 94110
Admin Country: US
Admin Phone: +1.4157239709
Admin Phone Ext:
Admin Fax: +1.4157239709
Admin Fax Ext:
Admin Email: admin@linux-foundation.org
Registry Tech ID:
Tech Name: Jim Zemlin
Tech Organization: The Linux Foundation
Tech Street: 660 York Street Suite 102
Tech City: San Francisco
Tech State/Province: CA
Tech Postal Code: 94110
Tech Country: US
Tech Phone: +1.4157239709
Tech Phone Ext:
Tech Fax: +1.4157239709
Tech Fax Ext:
Tech Email: admin@linux-foundation.org
Name Server: NS1.LINUX-FOUNDATION.NET
Name Server: NS2.LINUX-FOUNDATION.NET
DNSSEC: Unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>> Last update of WHOIS database: 2013-05-08 13:51:05 <<<

Registration Service Provider:
Dotster.com, support@dotster-inc.com
+1.8004015250
This company may be contacted for domain login/passwords,
DNS/Nameserver changes, and general domain support questions.

As you can see, you can contact the technical person in charge of that domain directly. If that doesn’t work, you can always try the administrative person. The whois command usually displays an e-mail address, a mailing address, and sometimes phone numbers. It tells when the domain was created and if they’ve made recent changes to their whois listing. It also shows the domain name servers responsible for that domain name. Querying these numbers with the dig command can generate even more information about the remote network’s configuration.


Unfortunately, whois is not built into the Windows platforms, but there are plenty of web-based whois engines, including the one located on Network Solutions web site.

It should be noted that if you administer domains of your own, you should make sure your whois listing is both up-to-date and as generic as possible. Putting real e-mail addresses and names in the contact information fields gives information that an outsider can use either for social engineering or password-cracking attacks. Also, people might leave the company, making your record outdated. It is better to use generic e-mail addresses, such as dnsmaster@example.com or admin@example.com. You can forward these e-mails to the people responsible, and it doesn’t give out valuable information on your technical organization structure.

The dig Command

The dig command queries a name server for certain information about a domain. Dig is an updated version of the nslookup command, which had be depricated (but has since been revived). You can see it to determine the machine names used on a network, what the IP addresses tied to those machines are, which one is their mail server, and other useful tidbits of information. The general syntax is:

dig @server domain type

where server is the DNS server you want to query, domain is the domain you are asking about, and type is the kind of information you want on it. You will generally want to query the authoritative DNS for that domain: that is, te one listed in their whois record as being the final authority on that domain. Sometimes the company runs this server; other times its ISP runs the server.

Results of the dig command can yield valuable information, such as the host name of their mail server, their DNS server, and other important machines on their network. If you run a DNS server, you should be able to configure it to respond only to these kinds from authorized machines.

dig Record Types

Options Descriptions
AXFR Attempts to get the whole file for the domain or “zone” file. Some servers are now configured not to allow zone file transfers, so you may have to ask for specific records.
A Returns any “A” records. “A” records are individual host names on the network, such as webserver.example.com and firewall1.example.com.
MX Returns the registered mail host name for that domain. This is useful if you want to contact an administrator (try administrator@mailhost.example.com or root@mailhost.example.com).
CNAME Returns any CNAMED hosts, also known as aliases. For example: fido.example.com = www.example.com.
ANY Returns any information it can generate on the domain. Sometimes this works when AXFR doesn’t

External Links:

The whois protocol at Wikipedia

The dig command at Wikipedia

Open Source Tools: Part One (nmap)

open source toolsNow that we’ve described the concepts of port scanning, enumeration and fingerprinting, it is time to discuss implementing them with open source tools. This article will cover two categories of tools: scanning tools and enumeration tools.

Port scanners accept a target or a range as input, send a query to specified ports, and then create a list of the responses for each port. The most popular scanner is nmap, written by Fyodor, and which is available from www.insecure.org. There are several open source tools for scanning, but Fyodor’s multipurpose tool has become a standard item among penetration testers and network auditors.


Open Source Tools: Using nmap

Before scanning active targets, consider using the ping sweep functionality of nmap with the -sP option. This option will not port scan a target, but will simply report which targets are up. When invoked as root with nmap -sP ip_address, nmap will send both ICMP echo packets and TCP SYN packets to determine if a host is up. However, if you know that ICMP is blocked, and don’t want to send those unnecessary ICMP packets, you can simply modify nmap’s ping type with the -P option. For example, -P0 -PS enables a TCP ping sweet, with -P0 indicating “no ICMP ping” and -PS indicating “use TCP SYN method.” By isolating the scanning method to just one variant, you increase the speed as well, which may not be a major issue when scanning only a handful of systems, but when scanning multiple Class C networks, or even a Class B network, you may need the extra time for other testing.

If nmap can’t see the target, it won’t scan unless the -P0 (do not ping) option is used. Using the -P0 option can create problems, since nmap will scan each of the target’s ports, even if the target isn’t up, which can waste time. To strike a good balance, consider using the -P option to select another type of ping behavior. For example, the -PP option will use ICMP timestamp requests, and the -PM option will use ICMP netmask requests. Before you perform a full sweep of a network range, it might be useful to do a few limited tests on known IP addresses, such as web servers, DNS, and so on, so you can streamline your ping sweeps and reduce the number of total packets sent and the time taken for the scan.

Capturing the results of the scan is extremely important, as you will be referring to the this information later in the testing process. The easiest way to capture all the needed information is to use the -oA flag, which outputs scan results in three different formats simultaneously: plain text (file extension .nmap), greppable test (.gnmap), and XML (.xml). The gnmap format is especially important to note, because if you need to stop a scan and resume it later, nmap will require this file to continue by using the –resume switch.


In the next article, we will continue our look at open source tools by covering some of nmap’s various options.

External Links:

nmap official site

insecure.org – features nmap news and several open source tools, including security tools

pfSense Setup: Part Two

pfSense Setup

The General Setup menu in the pfSense web GUI.

If you followed the setup instructions in pfSense Setup: Part One, pfSense should be running and accessible via the web interface at 192.168.1.1 (or another IP address if you assigned a different one). You should be able to log in using the default username (admin) and password (pfsense).

You will want to change some of the basic settings in General Setup. In the web interface, browse to System | General Setup. At “Hostname”, enter your hostname (the name that will be used to access the machine by name instead of the IP address.

Below this, enter your domain (Domain in the General Settings).

DNS Servers can also be specified. By default, pfSense will act as the primary DNS server. However, other DNS servers may be used, and the place to enter them are in the four boxes for DNS servers.

Check Allow DNS server list to be overridden by DHCP/PPP on WAN. This ensures that DNS requests that cannot be resolved internally are passed on to the WAN and resolved by the external DNS servers provided by your internet service provider.


Next, select the correct time zone; you probably want to leave the default NTP time server as it is.

Next is the theme, which allows you to change the look and feel of the pfSense web GUI. You can probably keep the default theme, pfSense_ng.

pfSense Setup

pfSense’s User Manager, which has been part of the pfSense web GUI since version 2.0.

NOTE: You probably want to change the admin password. You can do this under System -> User Manager. Here you can change the admin password, add new users, and delete users, including the admin.

That’s it for the General Setup within the web GUI. In pfSense Setup: Part Three, I will cover how to configure the WAN and LAN interfaces using the web GUI. Part four will cover configuring optional interfaces.


External Links:

Another useful guide on installing and configuring pfSense (from the iceflatline blog)

Ad Links:


© 2013 David Zientara. All rights reserved. Privacy Policy