Objective:  I goal of this document is meant to outline a few steps that will allow you to troubleshoot the cause behind why users were unable to access the internet while behind a Fortigate 100A device.

Problem: I received a ticket today stating that users in one our computer labs were unable to access the internet.

After arriving onsite I discounted the device and plugged directly into the ISP link and confirmed that they were no issues with the ISP connection. Now is time to open a ticket with support and start the series of troubleshooting to figure out the root cause of the issue.

Step one: Information gathering

After opening the ticket I was told that the issue could have possibly been caused by a bad firmware image, or a corrupted configuration. I needed to log into the device to find out more information and the only way to do so was via the console port.

Connecting to the Fortigate 100A console port:

• Start your favorite terminal emulator program use the following settings:
• Baud rate: 9600
• Data bits: 8
• Parity: None
• Stop bit: 1
• Flow control: None
• Next, reboot the device and watch the screen for any error message.

After rebooting the first time I got the following message, “You must format the boot device”,  I then rebooted a second time and got the following message “The config file may contain errors, Please see details by the command ‘diagnose debug config-error-log read”.  This was somewhat good news because I would have had to RMA the device if the system RAM was corrupted.

At this point I know I had the following options:

• Backup the current configs
• Reset the device to it’s default state
• Reload a new configs

Backing up the device to USB via the console port:

• Plug a usb device into one of the ports on the back of the device
• Login to the device, if you are unable to use your admin login you can login with the maintainer account, this account is only valid for 30 sec after the device has been rebooted; so copy the username and password to a text file then cut/paste to the console. Username: maintainer Password: bcpb<input device serial number using uppercase letters>

• Issue the following command: execute backup configs usb filename<use any name here>
  FG100 # execute backup full-config usb fg100a-10-15-11
  Please wait…
  Copy onfigs fg100a-10-15-11 to USB disk …
  Copy onfigs file to USB disk OK.
  Setting timestamp

Before reloading a new configs its best to run a few diagnostic commands to try and understand what happened:

FG100 #  diag sys top –> Look at CPU load and any processor that running hot

FG100 # diag debug crashlog –> Look for clues as to what service crashed

          Ex Output:

89: 2011-11-14 16:06:42 <04434> application cmdbsvr

 290: 2011-11-14 16:06:42 <04434> *** signal 7 (Bus error) received ***

 291: 2011-11-14 16:06:42 <04434> Register dump:

298: 2011-11-14 16:06:42 <04434> Backtrace:

 299: 2011-11-14 16:06:42 <04434> [0x0893277b] => /bin/cmdbsvr 

 300: 2011-11-14 16:06:42 <04434> [0x08932a96] => /bin/cmdbsvr 

 301: 2011-11-14 16:06:42 <04434> [0x08910473] => /bin/cmdbsvr 

Reload new configs via console port:

• Rename your most recent backup configs file to fgt_system.conf, then place file on the root of your USB drive.
• Plug the USB into one of USB ports on the back of the unit and reboot the unit and you should see a similar output:

Reading boot image 1370111 bytes.
Initializing firewall…
System is started.
Get image from USB disk …Can not get image from USB disk.
Get config file from USB disk OK.
File check OK.

The system is going down NOW !!

 If you are not certain and you leave the drive in after the system reboots you will see the following message indication that the configs file on the disk is the same as the file on the system.

 Get config file from USB disk OK.
Checksum check synced! Don’t need restore config.

 Additional Troubleshooting:

After I restored the config file I was still unable to connect out to the internet, so I issued the following command to verify my IP address setting:

FG100A # get system interface  

After discovering that the IP address for my external interface WAN1 had a different subnet than the one I wrote down previously when I connected directly to my ISP modem with my PC. I decided to change the interface type to DHCP.

Configuring external interface for DHCP:

FG100A #  configs system interface –> To enter into Interface config mode

FG100A (interface) # edit wan1 –> Choose your external interface in our case it was wan1

FG100A (wan1) # unset ip –>  Removing current static IP entry

FG100A (wan1) # set mode dhcp –> To change mode to DHCP from static

FG100A (wan1) # show –> To confirm that the change was made

config system interface
edit “wan1″
set vdom “root”
set mode dhcp
set allowaccess https ssh fgfm
set type physical
next
end

 FG100A (wan1) # end

 I was now able to access the internet!!

Discovering what happened:

Wrap-up:

Given that the logs were lost due the fact the FortiGate was reset and the unit is storing it’s logs in RAM, I can’t diagnose the exact cause. But we did see in the Crashlog “diag debug crashlog read”, which is written to flash that the cmdbsvr was crashing. We have identified a issue with cmdbsvr on the version of fortios on your fortigate.

Bug #’s : 117281, 144277
Summary : cmdbsvr crash in conserve mode may cause configuration loss

I updated the device to MR3 patch 2, since this version addressed the issue.
Reference Documentation:

http://emea.fortinet.net/fortinet/bht/index.php

http://bit.ly/uRSdYJ

http://docs.fortinet.com/fscan/fortiscan_cli_40.pdf

I needed a way to effectively troubleshoot a given traffic issue on our FortiGate 100A device and the out of the box configuration didn’t have this configured. This can be accomplish using the web GUI or via an SSH session, and since I already have SSH configure I went with this option for most of the configuration.

Step 1: Enable Logging

SSH to the device with your favorite client and issue the following commands:

FG100A # show firewall policy (this command will display the details for all policies)

edit 1
set srcintf “internal”
set dstintf “wan1″
set srcaddr “all”
set dstaddr “all”
set action accept
set schedule “always”
set service “ANY”
set logtraffic disable
set nat enable

next
end

Once you know which policy you would like to troubleshoot it’s now time to enable logging

FG100A # edit 1 (to edit policy id 1)

FG100A (1) # set logtraffic enable (to enable logging for this policy)

Once you are finish you can always review your changes on the GUI if you would to do so click on Firewall tab –> Policy –> select the policy in question and click edit on the top –> Then click the check box for “Log Violation Traffic”

Next, click on the “Log&Report” tab –>Log Setting –> and check off “Local Logging & Archiving”, “Memory” –> Minimum log level “Information” –> check off “Enable IPS Packet Archive”

Apply settings!

Step 2:  Diagnose Sniffer Packet

Launch another SSH session and issue the follow command just makes sure you put the filter expressions in quotes:

diag sniffer packet <interface> <’filter’> <verbose> <count>

Simple test do a continuous ping from your workstation to an IP on the internet and then issue the command below and keep the windows open:

diag sniff packet any ‘host <workstation ip> and icmp’ 4

Step 2:  Enabling debug mode

Lastly in a another SSH window enable debug mode, set the source IP address and watch as a series of useful information flows across the console to help you narrow down the problem at hand.

diag debug enable
diag debug flow show console enable
diag debug flow show function-name enable
diag debug flow filter proto 1 (protocol 1 is for icmp)
diag debug flow filter addr <workstation ip>
diag debug flow trace start 400 (400 is a random number it’ the number of traces)

To disable the debug when you are finish run the following command:
diag debug disable

References:

http://docs.fortinet.com/fgt/techdocs/fortigate-admin.pdf

http://docs.fortinet.com/fgt/techdocs/fortigate-cli.pdf

In most cases port base filtering  is an all or none approach. For example if you want to block  a user from accessing a certain website, blocking that user’s access to port 80/443 outbound will stop them from accessing all websites not just that one. If you would like to get more granular then you would need some sort of  web content filtering systems.

Good news is, if you are still using iptables you are now able to filter traffic destined to sites such as Facebook, Twitter, Gmail etc. You can accomplish this by using iptables to block a given hex string that will appear in the initial packet handshake. I first saw this technique being discussed in a full-disclouser posting and I figured it was worth trying out.

The tools of choice here is Ngrep (Network Grep) and IPTables .

Step one: Capture the X.509 certificate

You will be doing this by using ngrep:

[infolookup@Test ~]# ngrep -d eth2 -q -x ‘Twitter’
interface: eth2 (10.100.0.0/255.255.255.128)
match: Twitter

You will then notice the following output in your terminal:

<snip>

T 199.59.148.11:443 -> 10.100.0.119:38414 [A]

1. 30 30 31 16 30 14 06 03    55 04 0a 14 0d 54 77 69    001.0…U….Twi
2. 74 74 65 72 2c 20 49 6e    63 2e 31 1c 30 1a 06 03    tter, Inc.1.0…
3. 55 04 0b 14 13 54 77 69    74 74 65 72 20 20 4f 70    U….Twitter  Op

</snip>

Step two: Creating your IPtable rule

You will be building your rule based on the hex string obtained above.

Prior to applying the rule I able to run the following command:

[infolookup@Test]$ curl –connect-timeout 60 https://www.twitter.com/
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>301 Moved Permanently</title>
</head><body><h1>Moved Permanently</h1>
<p>The document has moved <a href=”https://twitter.com/”>here</a>.</p>
</body></html>

IPtable rules to use:
http://pastebin.com/1HQD017A

sudo iptables -I INPUT -m string –algo bm –hex-string ‘|303031163014060355040a140d547769747465722c20496e632e311c301a060355040b141354776974|’ -j DROP

sudo iptables -I INPUT -m string –algo bm –hex-string ‘|303031163014060355040a140d547769747465722c20496e632e311c301a060355040b141354776974|’ -j LOG

The first rule will drop the connection to twitter and the second rule will log the entry. If you take a look at your /var/log/message you will see the following entry over and over:

Apr  7 00:05:11 Test kernel: [870656.036848] IN=eth2 OUT= MAC=00:50:56:b2:53:90:00:23:5e:a4:f2:bf:08:00 SRC=199.59.148.11 DST=10.100.0.119 LEN=1420 TOS=0×00 PREC=0×00 TTL=44 ID=58494 DF PROTO=TCP SPT=443 DPT=49542 WINDOW=23 RES=0×00 ACK URGP=0

Apr  7 00:05:19 Test kernel: [870664.675930] IN=eth2 OUT= MAC=00:50:56:b2:53:90:00:23:5e:a4:f2:bf:08:00 SRC=199.59.148.11 DST=10.100.0.119 LEN=1420 TOS=0×00 PREC=0×00 TTL=44 ID=58496 DF PROTO=TCP SPT=443 DPT=49542 WINDOW=23 RES=0×00 ACK URGP=0

If you try to access www.twitter.com you will get to the site, but when you try login the session will set there and just timeout.

[infolookup@Test]$ curl –connect-timeout 60 https://www.twitter.com/
curl: (35) SSL connect error

Note:

I was unable to use the following IPtable rule on a Ubuntu based system but it worked fine on my Fedora 14 test box. Also another thing to look out for is if you use too short of a hex string will will get an error the one I used was about 85 characters give or take.

Have fun filtering and post your comments about how you are currently using IPtables.

I needed a way to remotely access and manage an admin workstation at one of our  satellite locations with low bandwidth. We didn’t want to use the VPN function because the last time we tried this it was really slow when pulling over the user profile.

Configuring SSH Access:

You can configure this device via https, telnet, or SSH. Since I prefer SSH I will begin by showing you how to enable SSH.

• Log into your Fortigate appliance via the https://ipaddress then click on the “Dashboard” sub-menu on the left.

• Scroll down and click on “CLI Console” from there enter the following command to enable SSH access on your WAN/DMZ/Internal interface:

FG100A #config system interface
edit WAN1
set allowacess ssh https
end

Now you can fire up your favorite SSH client and connect!

Adding a virtual IP to enable port forwarding:

To forward TCP or UDP ports received by your FortiGate unit external interface to an internal server, you need to follow two steps.

=> Add a virtual IP
=>Add a firewall policy with a virtual IP

This example describes how to configure port forwarding to allow access to an internal Windows XP PC (IP 172.29.19.10) with the Dameware remote access utility on port of 5555 externally and 6129 internally.

Adding a virtual IP

First run the following command to see if any VIP are already configured on the firewall.

FG100A #  show firewall vip

Once you verify you don’t have any old rule to update you can simply add one of your own (Test-VIP) with the following command:

FG100A # config firewall vip
FG100A (vip) # edit Test-VIP
FG100A (Test-VIP) # set extip 192.168.10.10 => setting up the external IP
FG100A (Test-VIP) # set extintf wan2 => binding to an external interface
FG100A (Test-VIP) # set portforward enable => enable port forwarding
FG100A (Test-VIP) #  set mappedip 172.29.19.10 => mapping to an internal IP
FG100A (Test-VIP) # set extport 5555 => setting up external port
FG100A (Test-VIP) # set mappedport 6129 => mapping to internal destination port
FG100A (Test-VIP) # end

Now you can do a “show firewall vip “ to verify your virtual IP configuration:

Now all that’s left is to define a firewall policy that accepts DameWare traffic from the Internet on port 5555 and forwards it to the internal Windows PC.

To add a firewall policy with a virtual IP
You can do so following these steps:

1-  Set Source Interface to WAN1.
2-  Set Source Address to all.
3- Set Destination Interface to internal.
4- Set Destination Address to the name of the virtual IP.
Usually, the remainder of the options in this firewall policy does not need to be changed. For example, Service can remain ANY, because the virtual IP only forwards packets using port 5555.

FG100A # config firewall policy
FG100A # show => view all configured policy
FG100A  (policy) # edit 2 => to create new policy
FG100A (2) # set ? => notice some are require others  are optional.
FG100A (2) # set srcintf wan2 => set source interface name
FG100A (2) # set dstintf internal => set destination interface name
FG100A (2) # set srcaddr all
FG100A (2) # set dstaddr Test-VIP
FG100A (2) # set action accept
FG100A (2) # end
FG100A # show firewall policy => review changes and test

Reference

http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=12945&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=10078518&stateId=0%200%2010080217

I have to admit that I am a bit late to the party, but I see this as an opportunity to try out SET and learn a bit about the DLL hijacking issue at the same time.

Last Thursday, Acros, a Slovenian security firm, published an advisory that identified what they call a “binary planting” flaw in iTunes. Essentially, if you open a file type associated with iTunes from a remote network share, iTunes will also try to load one more DLLs from the share. Even if the file that the user opened is completely safe, a malicious DLL can be supplied that will lead to code execution.

HD Moore stated “While working on the Windows Shortcut exploit, he stumbled on this class of bugs and identified a couple dozen applications that seemed to be affected by this problem.  iTunes was one of these applications and the details in the Acros advisory made it clear that this was indeed the same flaw. He was planning to finish the advisories and start contacting vendors on August 20th (last Friday). The  Acros advisory on the 18th threw a wrench into this process.

Microsoft later release the following details  in an advisory:

Microsoft is aware that research has been published detailing a remote attack vector for a class of vulnerabilities that affects how applications load external libraries.

This issue is caused by specific insecure programming practices that allow so-called “binary planting” or “DLL preloading attacks”. These practices could allow an attacker to remotely execute arbitrary code in the context of the user running the vulnerable application when the user opens a file from an untrusted location.

This issue is caused by applications passing an insufficiently qualified path when loading an external library. Microsoft has issued guidance to developers in the MSDN article, Dynamic-Link Library Security, on how to correctly use the available application programming interfaces to prevent this class of vulnerability. Microsoft is also actively reaching out to third-party vendors through the Microsoft Vulnerability Research Program to inform them of the mitigations available in the operating system. Microsoft is also actively investigating which of its own applications may be affected.

In addition to this guidance, Microsoft is releasing a tool that allows system administrators to mitigate the risk of this new attack vector by altering the library loading behavior system-wide or for specific applications. This advisory describes the functionality of this tool and other actions that customers can take to help protect their systems.

Mitigating Factors:

• This issue only affects applications that do not load external libraries securely. Microsoft has previously published guidelines for developers in the MSDN article, Dynamic-Link Library Security, that recommend alternate methods to load libraries that are safe against these attacks.
• For an attack to be successful, a user must visit an untrusted remote file system location or WebDAV share and open a document from this location that is then loaded by a vulnerable application.

• The file sharing protocol SMB is often disabled on the perimeter firewall. This limits the possible attack vectors for this vulnerability.

Demo Time with SET… Thanks to Dave for his wonderful video that he posted this afternoon, I can now use this as my base for this demo.

What is SET?

The Social-Engineer Toolkit (SET) was designed by David Kennedy (ReL1K) and incorporates many useful Social-Engineering attacks all in one simplistic interface. The main purpose of SET is to automate and improve on many of the social-engineering attacks out there. As pentesters, social-engineering is often a practice that not many people perform. You can download the Social-Engineering Toolkit through subversion by simply typing this in Back|Track 4 or any other Linux OS.

svn co http://svn.thepentest.com/social_engineering_toolkit/ SET/

However BT4 now comes with SET located under /pentest/exploits/set, from here you can simply launch SET with a ./set and get your latest updates by selecting option 8.

SET can do tons of cool stuff and I have included a few links at the end of this post that explains them in details, and I have a few post to come that will also go into some more details. However for todays demo I will only be using a few of those features.

Launch and update SET

If you are using BackTrack4 you can find SET located under /pentest/exploits/set, you can launch it with ./set and as stated above select option 8 to get the latest and greatest updates.

Choose your path to pwnage

I selected Option 2 or “Web Attack  Vectors” which is a unique way of utilizing multiple web-based attacks in order to compromise the intended victim.

Select option 2 once more “The Metasploit Browser Exploit Method” this method will utilize select Metasploit browser exploits through an iframe and deliver a Metasploit payload.

And yet again select option 2, “Site Cloner” this method will completely clone a website of your choosing and allow you to utilize the attack vectors within the same web application you were attempting to clone.

Choosing your browser Exploit:

At this point you have several options to choose from, today we will be picking option 1 “Microsoft Windows WebDAV Application DLL Hijacker”.

Choosing your Payload:

Once more you are giving several options, I choose option 2 “Windows Reverse_TCP Meterpreter“, this payload  will spawn a meterpreter shell on the victim and send it back to the attacker.

Once you are done, you have to choose your vulnerable extension types if you are not certain select enter to choose the defaults, or find a semi-complete list over at exploitdb . At this point the malicious iframes are infected into the cloned website and awaits your victim.

SET Mass E-Mailer Option :

There are two options on the mass e-mailer,we are choosing option1 this option will allow you to send an email to one individual person. Once you are done you have to choose who you would like to send the phishing email too, and who is your sender lastly figure if you would like to use Gmail, your own mail server or some open relay server.

Next think of something clever as a email subject and body. A good example would be to clone a local web-based system from your attacker network and send an email saying “we are doing some updates kindly click to verify you can access this test link. After you are finish click Ctrl + C and hit enter to complete this step. You will then receive a message stating that SET has already sent the email. Now is just a matter of waiting on your victim to click the email and check out the vulnerable files via the network share.

Exploit in action..

Once your victim clicks on the link, the  will be presented with the cloned site at first then the exploit will begin doing its thing in the background. Shortly after the user will be presented with a network share with the vulnerable files. After opening up the file  it  its Game Over.

Since the initial reporting of this issue, many researchers have came out with several ways of doing this so far some of my favorites are:

• Using msfconsole courtesy of the guys HDM in this post.
• Using msfpayload courtesy of Matt over at http://www.attackvector.org/alternative-dll-hijacking-method/
• Yet again Matt demoing using msfpayload + autorun usb stick  http://www.attackvector.org/autorun-dll-hijacker-usb-stick/

I have tested several of these and noticed that MSE AV was effective in identifying the msfpayload file, however using the standard method I successful exploited both windows XP and Windows 7.

Reference links:

http://www.exploit-db.com/exploits/14726/

http://blog.metasploit.com/2010/08/exploiting-dll-hijacking-flaws.html

http://blog.rapid7.com/?p=5325

http://www.securityfocus.com/archive/1/513190

http://www.microsoft.com/technet/security/advisory/2269637.mspx

http://www.vimeo.com/14403642

http://www.secmaniac.com/

http://www.offensive-security.com/offsec/microsoft-dll-hijacking-exploit-in-action/

http://www.offensive-security.com/metasploit-unleashed/Social-Engineering-Toolkit

I received notification of the following vulnerabilities outlined below via the full disclosure mail list but you can find a direct link to it here –> Link. I figured it was worth mentioning again since most organization depend on their Firewall as the primary means of protection against the many threats on the  internet.

The Cisco ASA 5500 Series Adaptive Security Appliance is a modular platform that provides security and VPN services. It offers firewall, intrusion prevention system (IPS), anti-X, and VPN services.

Cisco ASA 5500 Series Adaptive Security Appliances are affected by the following vulnerabilities:

SunRPC Inspection Denial of Service Vulnerabilities ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Sun RPC inspection engine enables or disables application inspection for the Sun RPC protocol. Sun RPC is used by Network File System (NFS) and Network Information Service (NIS). Sun RPC services can run on any port. When a client attempts to access a Sun RPC service on a server, it must learn the port that service is running on. The client does this by querying the port mapper process, usually rpcbind, on the well-known port of 111. Three DoS vulnerabilities affect the SunRPC inspection feature of Cisco ASA 5500 Series Adaptive Security Appliances, in which an unauthenticated attacker may cause the affected device to reload.

Note:  Only transit traffic can trigger these vulnerabilities; traffic that is destined to the appliance will not trigger the vulnerabilities. These vulnerabilities can be triggered by using UDP packets, not TCP.

These vulnerabilities are documented in Cisco bug IDs CSCtc77567, CSCtc79922, and CSCtc85753; and have been assigned Common Vulnerabilities and Exposures (CVE) IDs CVE-2010-1578, CVE-2010-1579, and CVE-2010-1580, respectively.

Transport Layer Security (TLS) Denial of Service Vulnerabilities ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TLS and its predecessor, SSL, are cryptographic protocols that provide security for communications over IP data networks such as the Internet.

Three vulnerabilities exist on the Cisco ASA security appliances that can be triggered by a series of crafted TLS packets. An unauthenticated attacker may cause the affected device to reload. A Cisco ASA device configured for SSL VPN, TLS Proxy for Encrypted Voice Inspection, or configured to accept ASDM management connections is vulnerable.

These vulnerabilities are documented in Cisco bug IDs CSCtd32627, CSCtf37506, and CSCtf55259; and have been assigned Common Vulnerabilities and Exposures (CVE) IDs CVE-2010-1581, CVE-2010-2814, and CVE-2010-2815, respectively.

Session Initiation Protocol (SIP) Inspection Denial of Service Vulnerability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SIP, as defined by the Internet Engineering Task Force (IETF), enables call handling sessions, particularly two-party audio conferences, or “calls.” SIP works with SDP for call signalling. SDP specifies the ports for the media stream. Using SIP, the Cisco ASA can support any SIP VoIP gateways and VoIP proxy servers. To support SIP calls through the Cisco ASA, signaling messages for the media connection addresses, media ports, and embryonic connections for the media must be inspected, because while the signaling is sent over a well-known destination port (UDP/TCP 5060), the media streams are dynamically allocated. Also, SIP embeds IP addresses in the user-data portion of the IP packet. SIP inspection applies NAT for these embedded IP addresses.

A DoS vulnerability affects the SIP inspection feature of Cisco ASA 5500 Series Adaptive Security Appliances. SIP inspection is enabled by default. During successful exploitation, an unauthenticated attacker may cause the affected device to reload.

Note:  Only transit traffic can trigger these vulnerabilities; traffic that is destined to the appliance will not trigger the vulnerabilities.

This vulnerability is documented in Cisco bug ID CSCtd32106 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-2816.

Crafted Internet Key Exchange (IKE) Message Denial of Service Vulnerability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

IPsec is an IP security feature that provides robust authentication and encryption of IP packets. IKE is a key management protocol standard that is used in conjunction with the IPsec standard. A DoS vulnerability exists in the IKE implementation of the Cisco ASA.

During successful exploitation, an unauthenticated attacker may cause an affected device to reload.

Note:  Only traffic that is destined to the appliance may trigger this vulnerability when the affected device is configured for IPsec remote access or site-to-site VPNs.

This vulnerability is documented in Cisco bug ID CSCte46507 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-2817.

As a side note I would like to add that unless you are already running on version 8.3 you should disable the vulnerable services and take a moment to read the release note for version 8.3.

The are some syntax changes you have to adjust too, as well as do a full rule set conversion. Below is an example of an old rule and its recommended migrated counterpart. Some of the migrated rules and not all new since the were supported in older IOS version, however its now mandatory to do them the proper/recommended way instead of the older way.

Old Configuration

static (inside,outside) tcp 172.23.57.170 5080 10.50.50.50 80

access-list 1 extended permit tcp any host 172.23.57.170 eq 5080

access-list 1 extended permit udp any host 172.23.57.170 eq 5080

access-list 1 extended permit tcp any host 172.23.57.170 eq 10000

access-list 1 extended permit tcp any host 10.2.3.4 eq 5080

access-group 1 in interface outside

Migrated Configuration

static (inside,outside) tcp 172.23.57.170 5080 10.50.50.50 access-list 1 extended permit tcp any host 10.50.50.50 eq 80

access-list 1 extended permit udp any host 172.23.57.170 eq 5080

access-list 1 extended permit tcp any host 172.23.57.170 eq 10000

access-list 1 extended permit tcp any host 10.2.3.4 eq 5080

access-group 1 in interface outside

As a Network Admin you would soon realize after a few months of adding various  ACL rules there comes a time when you need to go back and consolidate those rules before it gets out of hand.

Now that most cloud providers are moving away from the traditional (80, 443) TCP ports and moving towards your none standard (8800, 3995) ports, your job as a Network admin requires you to now plan a bit more.

Normally if I got a call that a users is unable to access a certain web, I would first verify if its a “URL filtering issue” or a “Firewall” access issue. If I determined that its the latter, I would then write a typical ACL and grant the user access after the requested service has been test.

For instance if you receive a call about not being able to access a website X on port 5454, you can write a basic ACL rule:

access-list external_access extended permit tcp 192.168.10.5 255.255.255.0 69.196.224.24 255.255.255.0 eq 5454

Now the above rule would work just fine, but think about it if you recieve about 10-15 of those request a day, your firewall will be a mess after a while. The way to take care of this is by using Using Network Objects and Groups in a Rule.

Network objects let you predefine host and network IP addresses so that you can streamline subsequent configuration. When you configure the security policy, such as an access rule or a AAA rule, you can choose these predefined addresses instead of typing them in manually. Moreover, if you change the definition of an object, the change is inherited automatically by any rules using the object.

Below is how you would accomplish this if you reieved say three request  for web related access all on different ports:

======================================
Creating Object group and adding ports Cisco ASA Firewall
======================================

config t
object-group service External_Acess tcp
description Access to external websites
port-object eq 7778
port-object eq 5454
port-object eq 3322

object-group network External_Access_Users
description Access to external websites
network-object host 192.168.10.5
network-object host 192.168.10.7
network-object host 192.168.10.9

=======================================
Creating ACL and applying object group
========================================
access-list acl_inside remark ***** External  Websites Access *****
access-list acl_inside extended permit tcp object-group External_Access_Users any object-group External_Acess

Now the next time you receive a request for external website access on a none standard port you simply add the port to the service group, and the Host IP to the network access group and you are set. Now that’s much more easy on the eyes to look at!

If you have another way of achieving the same outcome don’t hesitate to leave a comment, in the end its all about learning.

I have been a faithful Smoothwall user for many years.After the first time I got hacked I started to look into firewalls and was pointed to smoothwall by my co-blogger Dre Day.

Now years later I have decided to leave Smoothwall in 2009 and start the year a fresh with pfSense. Why you might ask, I will attempt to answer this question but putting the facts in front of you and hopefully you can see why.

I have take information from both projects website and narrowed it down to a few features of interest to me.

Firewalling:

* Supports LAN, DMZ, and Wireless networks, plus Extrnal.
*External connectivity via: Static Ethernet, DHCP Ethernet, PPPoE,PPPoA using various USB and PCI DSL modems.
* Portforwards, DMZpin-holes
* Outbound filtering
* Timed access
* Simple touse Quality-of-Service (QoS)
* Traffic stats, including perinterface and per IP totals for weeks and months
* IDS viaautomatically updated Snort rules
* UPnP support
* List of badIP addresses to block

Proxies:

* Web proxy for accelerated browsing
* POP3 email proxy withAnti-Virus
* IM proxy with realtime log viewing

Maintenance:

• Backup config
  * Easy single-click application of all pending updates
  * Shutdown and Reboot from UI

pfSense features of interest to me

Firewall

• Filtering by source and destination IP, IP protocol, source and destination port for TCP and UDP traffic
• Able to limit simultaneous connections on a per-rule basis
• pfSense utilizes p0f, an advanced passive OS/network fingerprinting utility to allow you to filter by the Operating System initiating the connection. Want to allow FreeBSD and Linux machines to the Internet, but block Windows machines? pfSense can do so (amongst many other possibilities) by passively detecting the Operating System in use.
• Option to log or not log traffic matching each rule.
• Highly flexible policy routing possible by selecting gateway on a per-rule basis (for load balancing, failover, multiple WAN, etc.)
• Aliases allow grouping and naming of IPs, networks and ports. This helps keep your firewall ruleset clean and easy to understand, especially in environments with multiple public IPs and numerous servers.
• Transparent layer 2 firewalling capable – can bridge interfaces and filter traffic between them, even allowing for an IP-less firewall (though you probably want an IP for management purposes).
• Packet normalization – Description from the pf scrub documentation – “‘Scrubbing’ is the normalization of packets so there are no ambiguities in interpretation by the ultimate destination of the packet. The scrub directive also reassembles fragmented packets, protecting some operating systems from some forms of attack, and drops TCP packets that have invalid flag combinations.”
  • Enabled in pfSense by default
  • Can disable if necessary. This option causes problems for some NFS implementations, but is safe and should be left enabled on most installations.
• Disable filter – you can turn off the firewall filter entirely if you wish to turn pfSense into a pure router.
• VPN
• IPSec
• Reporting and Monitoring RRD Graphs
• Dynamic DNS support
• Network Address Translation (NAT)
• Real Time Information
• State Table

Redundancy

CARPfrom OpenBSD allows for hardware failover. Two or more firewalls canbe configured as a failover group. If one interface fails on theprimary or the primary goes offline entirely, the secondary becomesactive. pfSense also includes configuration synchronizationcapabilities, so you make your configuration changes on the primaryand they automatically synchronize to the secondary firewall

Captive Portal

Captive portal allows you to force authentication, or redirectionto a click through page for network access. This is commonly used onhot spot networks, but is also widely used in corporate networks foran additional layer of security on wireless or Internet access. Formore information on captive portal technology in general, see theWikipediaarticle on the topic. The following is a list of features in thepfSense Captive Portal.
 
In the end pfSense was the best fit for what I was looking for in a Firewall.