LINICKX.com

Example Azure Web Application Firewall (WAF)

Nick Bettison — Sat, 05 Sep 2020 09:16:00 +0100

I quite enjoyed my recent foray into setting up an example Azure Firewall, so he's a sequel! 🙃

As before, the post will be screenshot heavy but not all screenshots, the plan is to deploy a vulnerable web application behind the WAF in blocking mode so we can see basic exploits being blocked.

Step 1 - Planning

Here's a basic picture of what we want to achieve...

For the Web Server, we're going to run Damn Vulnerable Web Application (DVWA) in an Azure Container Instance.

Everything will be deployed into a single resource group to make cleanup/delete easier at the end.

Naming Convention

Here's a gotcha for Naming Conventions, in my last post I used hyphens, but container instances not allow that, so I'll have to plan a new way.

I still want to follow the region followed by a primary identifier approach...

uksrgwaf → Resource Group
ukswaf1 → Azure Web Application Firewall
uksweb1 → 1st Web Server (Docker DVWA)
uksvnetwaf1 → WAF Network

Something like that should do the trick!

Networking

Two networks will be needed, one for the Security Gateway and one for the Docker Web App, we'll then peer them together.... if you want to by-pass the WAF and access the App directly, plan yourself a 3rd network for a Virtual Windows box.

uksvnetwaf1 → 172.16.1.0/24
uksvnetweb1 → 172.16.2.0/24

Step 2 - Create a Container Instance

The build takes a little while, so kick that off first.

We're going to pull an image vulnerables/web-dvwa from the public docker hub based on linux.

We want the networking type to be Private as we're protecting this behind the WAF; I'm going to create a new vNet to meet my planning above, you are welcome to accept the defaults if you like.

Make no changes to Advanced Settings, skip the tags and hit create.

Step 3 - Create Log Analytics workspace

If you don't have one already, you need somewhere to send the logs...

Step 4 - Create the WAF... well actually the Application Gateway.

So here's the thing, the WAF is part of the Azure Application Gateway product, which is actually a load balancer... so we're going to setup a basic load balancer and then enable the WAF functionaility. Of course we've only deployed "1x Web Server" (docker container instance) but you get the gist!

Change the Tier to WAF V2, set the firewall mode to Prevention, scroll down to networking and create a new vNet...

For the frontend, setup a new PublicIP

Next we need to setup a backend pool, for now select Add backend pool without targets we'll come back to that later!

On the configuration page, notice how the left & right sides are already completed, we just need to add some rules in the middle...

For the listener, setup a basic HTTP routing rule..

And then select Backend targets, assign our pool and add a new HTTP Setting; the HTTP settings will be 100% defaults, this is all load balancer stuff that won't apply to us as we have 1x Web Server.

Skip over tags and we can finally create.

Step 5 - Start joining the dots.

At this stage we have two islands, a docker container and a WAF, they're not connected. The first thing you want to do it peer the vNets.

Peering

Open one of the vNets, I've selected uksvnetwaf1, select peering on the left and add a peering. Give it a name like uksvnetwaf1-to-uksvnetweb1, select uksvnetweb1 from the dropdown list and give that a name like uksvnetweb1-to-uksvnetwaf1

Scroll down to the bottom, and allow external traffic in...

Update the Pool

Remember that step we skipped when creating the WAF (Application Gateway)... time to fix that.

Go into your container instance and grab the private IP

Now, go into your application gateway → backend pool and set the IP, mine is 172.16.2.4

Diagnostic Settings

Remember that Log Analytics workspace we created; within your application gateway add some diagnostics pointing the logs to the workspace.

Step 6 - Bootstrap DVWA

If all has gone well, in a new tab/window you can browse to your public IP http://a.b.c.d and you should get the DVWA log in screen.

The default credentials are admin & password, scroll to the bottom and click create / reset database , you'll be redirected to the login screen where you can log back in.

At this stage you might want to change the password (under the CSRF menu) so you can play in peace, but just remember this thing is designed to be hacked 🙃

Step 7 - Lets test!

To prove the functionality we're going to do a couple of basic tests, a command injection and an SQL Inject, we're also going to disable a WAF RULE to show how to switch stuff off.

How to disable a rule

The WAF comes with a bunch of rules enabled by default, if you're deploying this into production the developers are going to be very concerned about the WAF blocking legitimate requests. To demonstrate the steps, we're going to disable the rule that flags "IP in header"; by default you should browser a site by it's name, but in our test we don't have one so let's switch off that rule.

Go into your logs, and run this query to find WAF events...

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS" and OperationName == "ApplicationGatewayFirewall"

Scroll to the right you should see message Host header is a numeric IP address with the rule ID 920350

Now go into Web Application Firewall → Rules and enable advanced configuration, search for 920350 and untick the box... then click save.

Job done, that should clean out your logs a bit for the next test.

Blocking Command Injection

We're going nice and simple, from your DVWA tab, select Command Injection and type in 127.0.0.1;cat /etc/password and click submit.

You should get a forbidden page, notice how it says Microsoft-Azure-Application-Gateway/v2 ... the WAF blocked the attack. At this point be a little patient, it can take a while for logs to show up in the azure portal, but this time run:

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS" and ruleId_s == "932100"

You can see the command matched a rule that caused the block.

Blocking SQL Injection

For the 2nd test, browse to SQL injection and type in %' or '0'='0 and click submit.

Once again, you should see the blank Azure 403 forbidden page!

Run this log search:

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS" and OperationName == "ApplicationGatewayFirewall" and Message contains "SQL"

You can see the SQL Injection was detected!

/End

That was another long post but we got there in the end, there's a lot to unpack there from setting up a docker container to disabling a WAF rule. As a reader there's a couple of area's you can follow up with, if you're not familiar with the basic exploits, set the WAF to detection mode to view DVWA get compromised, you will also want to spend some time looking at the logs and preparing better searches as my examples are very specific to this post.

Example Hub & Spoke Azure Firewall

Nick Bettison — Wed, 19 Aug 2020 11:49:00 +0100

It's been a while since I've done a Technical How-to, recently I wanted to get my head around Azure's firewall appliance, here's an example setup and in true MicroSoft style it comes complete with Point-n-Click screenshots! I'm assuming you at least know how to navigate Azure so post doesn't contain all the possible screenshots, for example I will skip screenshots for creating tags, but that all being said, it's still going to be a long one, hold on tight!

Step1 - Planning

Whilst reading the doc's and getting to grips with the Azure Portal it became clear to me, you really need to plan before clicking, it's sooo easy to get stuff running that I'm confident that most orgs will have objects with generic names like "monitoring server" and then forget details like, which region is the server hosted!

This picture is basically what I want to achieve, 2 servers separated by a firewall appliance for access to the Internet and each other; spoke 1 and 2 are isolated zones.

Naming Convention

To get started I planned a basic naming standard using region followed by a primary identifier and then a description...

UKS-FW-vNET → UK (South) Firewall Virtual Network
or
UKS-Route-Spoke1-to-Hub → UK (South) Routing table, Spoke 1 static routes to Hub
or
UKS-Spoke1-VM1 → UK (South), Spoke 1, Virtual Machine

I'm sure it could be better or more rigid but it should be enough for me to know what's what. In the GUI you can group by type & region so you don't really need these in your naming convention, but it's useful to know priority, in my examples the type "Route" is more important that if it's for Spoke1 or Spoke2 ... but for the VM, the location is more important... it's just a lab, do whatever you want 😉

Resource Group(s)

For this example, I'm creating a single resource group and putting it all there; in the real world we would expect to see different networks & VM's in different groups; I'm calling mine FW-Test plan what you need.

Networking (IP Addressing)

Before defining the IP structure, think about DNS, by default all networks/devices use Microsoft's DNS but now-a-days we expect our DNS provider to add some security filtering & protection, so I'll be using Cisco's Umbrella (OpenDNS): 208.67.222.222 & 208.67.220.220

Each Virtual Network is like a zone, it lives in a region and it can be calved up into smaller subnets when needed. I'll be working in /23 chunks, with the first /24 as the "main" subnet leaving the 2nd /24 to be used for other stuff, I'm also going to use the 172.16 RFC1918 space instead of the 10.x generated by Azure to really help show how networking hangs together in this example.

UKS-FW-vNET1 → 172.16.0.0/24
UKS-vNET-Spoke1 → 172.16.2.0/23
UKS-Spoke1-Subnet1 → 172.16.2.0/24
UKS-vNET-Spoke2 → 172.16.4.0/23
UKS-Spoke2-Subnet1 → 172.16.4.0/24

Create UKS-vNET-Spoke1 & UKS-vNET-Spoke2

Create the networks spoke networks first but not the firewall vNET, we'll do that after with the FW Appliance; There's nothing special about the Spokes at this stage, here is Spoke 1

Repeat for Spoke2.

After both vNets are built, if you want to use Custom DNS make that change...

Step 2 - Create the Firewall

The firewall build takes a little time, let's kick that off!

Under the firewall settings, we're going to now define the vNET... notice how the subnet has a special (reserved) name; we also need to create and assign a public IP.

Whilst you're waiting for the deployment...

Setup Logging

By default you don't get firewall logs, we need to switch that on. Before you start you need a Log Analytics workspace, go and create that.

Create Log Analytics workspace

This is how you access or visualise the FW logs, if you're using the eval/free subscription like my screenshots you'll need to select pay-as-you-go pricing, I've not been charged anything 😬

Setup Diagnostics

Back on the Firewall, if it's done, setup logging, it's under Diagnostics Settings....

Add a new Diagnostics Setting.

Tick all the lefthand boxes, we want all them logs! On the right, setup Log Analytics to the workspace you created. At this point, don't expect to see anything under the FW logs section, not only do we not have any traffic yet but it can take ~10mins before any hits appear in the logs.

Create some Rules

We're ready at this point to create some rules, we're only going to work with Add network rule collection rules.

This is where we start and are aiming for, so click add network rule collection and fill in these details...

Name: Basic-Networking
Priority: 100
Action: Allow
Rule 1:
- Name: DNS
- Protocol: TCP & UDP
- Source Type: IP Address
- Source: 172.16.0.0/12
- Destination Type: IP Address
- Destination Address: 208.67.222.222, 208.67.220.220
- Destination Ports:
Rule 2:
- Name: NTP
- Protocol: UDP
- Source Type: IP Address
- Source: 172.16.0.0/12
- Destination Type: IP Address
- Destination Address: *
- Destination Ports: 123

We want a nice and simple policy to test basic functionality; repeat the process for the following rules...

Name: HTTP-HTTPS
Priority: 1000
Action: Allow
Rule 1:
- Name: HTTP
- Protocol: TCP
- Source Type: IP Address
- Source: 172.16.0.0/12
- Destination Type: IP Address
- Destination Address: *
- Destination Ports: 80
Rule 2:
- Name: HTTPS
- Protocol: TCP
- Source Type: IP Address
- Source: 172.16.0.0/12
- Destination Type: IP Address
- Destination Address: *
- Destination Ports: 443

and

Name: Default-Deny
Priority: 65000
Action: Deny
Rule 1:
- Name: Deny
- Protocol: Any
- Source Type: IP Address
- Source: *
- Destination Type: IP Address
- Destination Address: *
- Destination Ports: *

You should end up with something like this:

Azure & ICMP

Ok, a bit of an Azure quirk here! There's a few google hits of people complaining that you cannot "ping out" from Azure to the Internet, but if you want to be able to ping between spokes you can do that... weirdly tho, restricting the rule by IP/Subnet doesn't work, you have to setup an "any" rule 😒

If you want one, create a rule using these settings...

Name: ICMP
Priority: 101
Action: Allow
Rule 1:
- Name: ICMP
- Protocol: Any
- Source Type: IP Address
- Source: *
- Destination Type: IP Address
- Destination Address: *
- Destination Ports: *

Step 3 Peering

Now we're onto some good stuff! You have 3x Virtual networks, and they're isolated from each other, our target is to route these via our firewall, we do this by setting up peering. We need two peering configs:

Peering on UKS-FW-vNET1 to UKS-vNET-Spoke1
Peering on UKS-FW-vNET1 to UKS-vNET-Spoke2

In new versions of the GUI (you'll not some differences between what you see and the official documentation) this will create Peering back the other way, I guess this had to be done manually before!

Navigate to the vNET: UKS-FW-vNET1 and click Add Peering

Take note of the bottom Enabled if that's not on, then Spoke 2 won't be able to speak to Spoke 1. If your vNET has an onward connect to a VPN gateway then you'll need to tick the bottom box.

Repeat for Spoke2.

Step 4 Create Some Routes

We need 2x routes, I reckon we could probably get away with bundling it together as one, but this feels cleaner and I know it works! 😝

The plan is to setup a default route for UKS-Spoke1-Subnet1/2 to the Firewall, we don't need static routes back the other way, that's sorted by the peering, these static routes give us Internet access and Spoke-to-Spoke connectivity.

Create a new Route Table: UKS-Route-Spoke1-to-Hub

For the next step, you need to pop back to the firewall and grab the private IP... in my example it's 172.16.0.4.

No go to the Route Table and add a default route, the gateway IP is going to the the private IP you just copied from the FW.

Then under Subnets, associate the Spoke1 Subnet.

All that done, now Repeat for UKS-Route-Spoke2-to-Hub!

Step 5 Add some machines

Foundations laid, we have something to stand a computer on lets build a couple of test machines. We'll use a windows server as a GUI client and a linux box as a server.

Windows - Spoke 1

Build a basic Windows 2019 Server...

Default Disk Settings is fine, but Networking settings are important, assign the server to Spoke1, Subnet1 and disable public IPS ...

Default settings for Management and advanced also fine.

Linux - Spoke 2

Build a Linux Server, pick whatever distro makes you happy; you can build a 2nd windows box if you like, but you'll have to install IIS afterwards for some sensible testing.

We're basically repeating the steps from above, the networking tab is the detail to pay attention to...

Step 6 - Bastions, get access to the machines.

As those servers build/deploy you'll be thinking, how am I going to access them?! Well, remember we left some space in the Subnets/vNETs, we'll use Microsoft's Bastion solution.

Go to your VM, scroll to the bottom and select Bastion, you'll notice there's a red error!

Click on Manage Subnet Configuration ... you need to create a subnet called AzureBastionSubnet ← That's a special/reserved name. Bastion's only need a small /27 subnet.

Once the subnet has been created you can then click the create button with no errors. Repeat for Spoke 2.

Test

Finally! After all that setup, we're ready to log into a server. Connect to your linux box first (Using the Bastion Option), install apache & start it.

Now connect to your Windows box:

open Internet Explorer you should be able to browse the web. Disable Enhanced Security if you want/need to! (Note: That's why I'm using Umbrella as a compensating control)
Now connect to your linux box, that should work to
Open a Command Prompt, if you created an ICMP rule, ping should work. If you are pining from the linux box, remember windows servers come with host based firewalls, you'll need a rule there to allow ICMP as well.
Finally, download putty and try to SSH to your linux box, that should fail!

(No Screenshots here, I'm sure you can figure that out 😅)

Check the firewall logs!

If all your tests went as designed, you'll need to filter the firewall logs to see them as any Internet traffic will be filling up the logs.

END

I hope this is useful to someone, it took me a little while and some twitter frustration to get there, but I'm pleased with the result! If I can find the time, I'd like to re-create this in powershell and automate all the things!

References:

https://docs.microsoft.com/en-us/azure/firewall/overview
https://docs.microsoft.com/en-us/azure/firewall-manager/secure-hybrid-network
https://docs.microsoft.com/en-us/azure/firewall/logs-and-metrics

Is your firewall Team from Venus?

Nick Bettison — Sun, 02 Feb 2020 20:26:00 +0000

Something a little different for my site; this post is a soft-skill article. In job listing, or development plans its really common for Technical roles to include a soft skills component and I had kinda assumed it was filler content, how hard is it to talk to people?! A couple of years ago I moved from Consultancy into an Internal Operational role, and now, ok I get it, it's that old saying Men from Mars, Women from Venus but with like 7 Layers of OSI complication!

I have something like 15years experience working with firewalls in large enterprise, it's a tricky topic, if you cannot communicate your requirements to the firewall team the chances are you application/solutions/service just isn't going to work, after all as Scott Adams has portrayed in Dilbert, everyone blames the firewall.

Firewalls are everywhere, and even though the security industry likes to argue that they are becoming less and less effective I'm confident they're not going away any time soon, so here are my tips:

1. Do not forward (copy/paste) vendor documentation

If I had a £$ for every time I get forwarded this Microsoft document I'd be a millionaire, forwarding the documentation verbatim is the quickest way to get yourself at the bottom of someones's todo list or land you in the SLA trap where the minimum gets done on your ticket to keep the timer green.

Communication requires consideration, throwing a document you haven't read at another team is showing you don't value their time/effort

Remember:

Everyone is busy! The simplest and most complete requests will be implemented quickest, all operations teams have this issue, it is not unique to firewalls.
The firewall team do not know anything about your application/solution/service, but are accountable for the security; help them to help you, reduce friction by having information up front.
You are making the request for Your Application, You should take the time to read and understand the documentation so that you can present the firewall change accurately and make it is simple as possible.

2. Presentation is everything

Always format your communication for your audience, powerpoint for Execs, spreadsheets for finance, for firewalls it's tables.

Large organisation will/probably/maybe have a template to follow for change requests, don't deviate from that, seriously if your firewall team has a template use it! Arguing yours is better is futile, firewalls form part of a compliance chain, auditors tick boxes your rockstar form won't tick the box; if you think you can improve the process or add value, speak to the Security Officer.

Formal documentation such as High Level (HLD) or Low Level Designs (LLD) might be a bit more fluid, here are some hints to make it easy to read and understood.

Arrows like -> should not be used in formal documentation, unless in a flow diagram, don't do it, from my experience I know it leads to mistakes. Something like 10.1.1.1 -> 192.168.1.1 on port 22 is fine for an email or instant message but for documentation use a table (or spreadsheet):

Source Name | Source IP    | Destination Name | Destination IP | Service Name | Protocol | Port | Comment
------------|--------------|------------------|----------------|--------------|----------|------|---------
VLAN11      | 10.10.0.0/24 | WebServer01      | 192.168.168.1  | HTTPS        | TCP      | 443  | Intranet
AdminPC     | 10.1.0.1     | WebServer01      | 192.168.168.1  | SSH          | TCP      | 22   | Admin Access

Use the above table format, give IP addresses names (use the FQDN if possible), the FW team will instantly recognise what needs to be done; a table like this is both simple to read and complete and will put you top of anyone's todo list.

If you have a large design document, I recommend the firewall table (communications matrix) being a summary/appendix of all the required flows as picking rules from disparate sections will only lead to tears.

3. Direction, know which way to go

On a firewall direction is really, really important. Your communication needs to demonstrate you know which way traffic is going and what your expectations are of the firewall.

Firewalls process traffic as it arrives, from a source IP to a destination IP. Your request needs to show which IP addresses are the client (source) and which IP address are the server (destination)... DO NOT bung in both directions to be "safe" when you don't need it, it just shows that you don't know what you are requesting, it's a common red flag for rule approvers/implementer.

For example, A laptop accessing a web site on HTTPS, needs TCP/443 to the server (web site) only. You do not need TCP/443 from the server (web site) to the client (laptop). Take time when digesting the vendor documentation to understand the direction of traffic flow.

Modern Firewall are smart when it comes to TCP and common applications; unless your traffic is media (voice/video) you typically don't need to worry about the random high port source, focus your effort on the destination port, get the direction right and your app will work.

(Media traffic is the devil, ask the firewall team for their recommendations prior to submitting your request)

4. Choose Secure

Most vendor documentation includes protocol choices, HTTP vs HTTPS for example. As the Firewall Team are responsible/accountable for security, you'll make friends with the security teams if you pick the secure protocol, forming strong relationships with other teams is a valuable skill.

If you are unclear, secure in this instance is encrypted. So:

HTTPS (not HTTP)
SSH (not Telnet)
FTPs (FTP with SSL is better than plain old FTP)
LDAPS (LDAP with SSL is better than plain old LDAP)
etc, etc.. if in doubt pick "s" ;-)

Thanks to the dangers of Privacy/GDPR most organisations are moving to a Secure by Design motto, the firewall team are tasked to help enforce that.

5. Firewalls are everywhere

In a large enterprise there is going to be more than one firewall. Some organisations will add a column to their request tables to record which flow (rule) belongs to which firewall others will want a table per firewall.

If your environment is large/complicated, typically you'll find different firewalls for management, production traffic or testing. Keep the communication flowing with the firewall team to find out what you need to know/do before submitting a 100 rules, it'll save you all time!

Some firewall language

To finish, here is some further firewall language to help you on your way:

Security Policy - A document that tells the firewall guy what he can and cannot allow through the firewall
Firewall Policy - The complete set of rules implemented on a single firewall
Firewall Rule - A line in the FW policy that contains, source, destination, service. The exact content of the line may vary by vendor.
Flow - Firewall Flow / Network Flow / Traffic flow. All used interchangeably, it means the path taken from the source to the destination, a flow might touch one or many firewalls
Communications Matrix - All of the rules required for an application or service that need to be implemented into an existing firewall policy

/End

Hopefully this is of help to someone, comments via twitter are welcomed; would you like to see more of this kind of thing?

Multi-Context HTTPS backups of Cisco ASA Script

Nick Bettison — Tue, 28 Jul 2015 16:04:00 +0100

If you look in the Cisco forums for scripts to backup ASAs you'll find various SSH / Expect , complicated examples... not sure why since in 2006 I showed it can be done with a single wget command ;-)

Recently I needed something that would support Multi-Context firewalls, so I pimped my one line command into the below shell script.

Copy/paste into a new file as backup_cisco_asa.sh then chmod 700 the file as necessary.

Run the file with no options ./backup_cisco_asa.sh and it'll ask you for IP address, username and password to make the connection.

For this to work the ASA needs appropriate HTTP statements (i.e. allow ASDM access from where you are running the script)

The file supports in-line backup of a single device such as ./backup_cisco_asa.sh 10.10.10.10

Multi-context support is via an environment variable or a config file ~/.asa_config. You must set an array containing entries for each context you want to backup. e.g.

ASA_CONTEXTS=( 
 "172.31.9.10:system"
 "172.31.9.10:admin"
 "172.31.9.10:Edge"
 "172.31.2.254:system"
 "172.31.2.254:admin"
 "172.31.2.254:Core" )

If you're feeling insecure you can also save your username/password variables into the ~/.asa_config as ASA_UID and ASA_PW respectively (or as environment variables)

Given that the script is a bash shell script I assume that SCP isn't required (because you are probably already on your linux SSH/SCP server running the script) but to keep the router team happy you might need to copy the files up via TFTP, this can be set with the ASA_TFTP_IP variable in ~/.asa_config.

By default the backup files will be saved to ./ (i.e. where ever you run the script from) and you can change that with the ASA_FILEPATH variable.

backup_cisco_asa.sh

#!/bin/bash

# Nick Bettison - LINICKX.com - 2015 - v1
# Bash Shell Scipt for backing up Cisco ASA's via HTTPS (i.e. ASDM)
# 
# Read the file comments, you can setup a config file ~/.asa_config to store variables.
# ASA_UID & ASA_PW for credentials (if you're feeling insecure)
# ASA_CONTEXTS for multi-context support
# and ASA_TFTP_IP for copying the files via TFTP (for insecure router boys)
#
# Tested on.
# Cisco Adaptive Security Appliance Software Version 9.2(3)4 <context>
# Device Manager Version 7.4(2)

# Timestamp for file names
TIMESTAMP=`date "+%Y%m%d-%H%M%S"`

# Allow single ASA IP address to be passed from CLI
# e.g ./backup_cisco_asa.sh 10.10.10.10
if [ -n "$1" ]
    then
    ASA_IP="$1"
fi

# Check for Curl
type curl >/dev/null 2>&1 || { echo >&2 "I require curl but it's not installed.  Aborting."; exit 1; }

# Read Variables from a config file (if it exits)
# The config file can be used for storing multi-context configurations... and for the insecure username/password ;-)
if [ -e ~/.asa_config ]
then
  . ~/.asa_config
fi

# Default File Path
if [ -z "$ASA_FILEPATH" ]
    then
    ASA_FILEPATH="./"
fi

# Check for UID/PW Variables - Ask if not found
if [ -z "$ASA_UID" ]
        then
        read -p "ASA Username:" ASA_UID
fi
if [ -z "$ASA_PW" ]
        then
        read -s -p "ASA Password:" ASA_PW
        echo
fi

# Check to see if single or multi-context mode.
if [ -z "$ASA_CONTEXTS" ]
        then
        if [ -z "$ASA_IP" ]
                then
                read -p "ASA IP Address:" ASA_IP
        fi

        ASA_tFILE="$ASA_FILEPATH.$TIMESTAMP.asaconfig.txt"

        # Download the "show run" via the unofficial CLI.
        curl -s -k -o $ASA_tFILE -u $ASA_UID:$ASA_PW "https://$ASA_IP/admin/exec/show%20running-config%20asdm/show%20running-config"

        if [ -e $ASA_tFILE ]
            then
            # Look for hostname in config file
            ASA_HOSTNAME=`grep ^hostname $ASA_tFILE | awk '{print $2}'`
            # rename the temp file to something sensible.
            mv $ASA_tFILE "$ASA_FILEPATH$TIMESTAMP.$ASA_HOSTNAME.txt"
            # Setup an array for TFTP later.
            ASA_FILES=("${ASA_FILES[@]}" "$ASA_FILEPATH$TIMESTAMP.$ASA_HOSTNAME.txt")
            # Done.
            echo "DONE: $ASA_FILEPATH$TIMESTAMP.$ASA_HOSTNAME.txt"
        else
            echo "FAILED: $ASA_IP"
            exit 1
        fi
else
    # Example ASA_CONTEXTS array:
    # 172.31.9.10 is the admin context IP, admin & Edge are the names of the two contexts to backup.
    # 172.31.2.254 is the admin context IP, admin & Core are the names of the two contexts to backup.
    # "system is obviously the system context"
    # ASA_CONTEXTS=( 
    #     "172.31.9.10:system"
    #     "172.31.9.10:admin"
    #     "172.31.9.10:Edge"
    #     "172.31.2.254:system"
    #     "172.31.2.254:admin"
    #     "172.31.2.254:Core" )

    # Loop through the array
    for firewall in ${ASA_CONTEXTS[@]} ; do
         ASA_IP=${firewall%%:*}
         ASA_CONTEXT=${firewall##*:}

         # Feedback on progress
         printf "Connecting to %s for %s \n" $ASA_IP $ASA_CONTEXT
         # Filename
         ASA_FILE="$ASA_FILEPATH$TIMESTAMP.$ASA_IP.$ASA_CONTEXT.txt"

         # Download the CONTEXT "show run" via the unofficial API.
         curl -s -k -o $ASA_FILE -u $ASA_UID:$ASA_PW "https://$ASA_IP/admin/exec/changeto%20context%20$ASA_CONTEXT/show%20running-config/show%20running-config%20asdm"

         if [ -e $ASA_FILE ]
             then
             # Setup an array for TFTP later.
             ASA_FILES=("${ASA_FILES[@]}" "$ASA_FILE")
             # Done!
             echo "DONE: $ASA_FILE"
         else
             echo "FAILED: $ASA_IP"
         fi
     done
fi

# Optional Backup to insecure tftp - you know, to keep the router boys happy!
if [ -n "$ASA_TFTP_IP" ]
    then
    # Check for TFTP binary
    type tftp >/dev/null 2>&1 || { echo >&2 "tftp client not installed.  Aborting."; exit 1; }
    type wc >/dev/null 2>&1 || { echo >&2 "wc not installed (needed for counting stuff).  Aborting."; exit 1; }
    type awk >/dev/null 2>&1 || { echo >&2 "awk not installed.... seriously?!?!  Aborting."; exit 1; }

    # Loop through array
    for file in ${ASA_FILES[@]} ; do
        LOCAL_FILE=$file
        # backup separator
        OIFS=$IFS
        # Change separator to /
        IFS='/'
        # Split the filename from the path
        AWK_POSITION=`echo $file | wc -w`
        REMOTE_FILE=`echo $file | awk -v w=$AWK_POSITION '{print $w}'`
        # restore separator
        IFS=$OIFS
        # TFTP the file.
        tftp -v $ASA_TFTP_IP -c put $LOCAL_FILE $REMOTE_FILE
    done
fi

Cisco ASA SYSLOG config for Tufin SecureTrack

nick — Mon, 02 Jun 2014 17:27:00 +0100

I'm sure there's a very good reason that the Tufin Secure Track User Guide (R14-1) has 8 pages of screenshots instead of including these 10 lines of config; I just don't yet know what the reason is :)

logging enable
logging timestamp
logging facility 23
logging message 111008 level  notifications
logging device-id  hostname 
logging list securetrack message 111008
logging list securetrack message 106100
logging list securetrack message 106023
logging trap securetrack
logging host inside 1.2.3.4

Replace 1.2.3.4 with the IP address of your ST server.

CheckPoint: "Encryption Failure: according to the policy the packet should not have been decrypted."

nick — Mon, 19 Nov 2012 15:59:00 +0000

The checkpoint sk article isn't that helpful... what it should say is... If you have your encryption domain set as "defined by topology", then check your topology!

password-less ssh login to JunOS

nick — Tue, 17 Jan 2012 13:35:00 +0000

Juniper (JunOS) SRX's support ssh public key authentication.

nick> show configuration system login | display set 
set system login user nick uid 2001
set system login user nick class super-user
set system login user nick authentication ssh-rsa "PASTE_KEY"
nick>

No-one likes to type passwords!

Cisco ASA Firewalls and IP Ranges in ACLS

nick — Fri, 29 Jul 2011 15:05:00 +0100

I've google'd and I cannot find a way of creating a firewall range style object in an ASA, you know the kind of thing whereby you want to allow IP addresses 192.168.1.10 thru 192.168.1.20 in an ACL.

In my frustration I have given up and created a shell script which converts a CSV into an ASA output, simply create a two column CSV with Col A containing your starting IP and Col B containing you end IP.

The script is a recursive loop so should support large outputs such as 10.1.2.10 to 10.2.1.20 howvere I'm not actually sure you'd want that in your firewall config but I wrote the computability for the fun it!

Have fun, click "more" below if you can't see the script!

#!/bin.bash

# Commas separated VAR....
IFS=","
while read name firstip lastip
# Loop around CSV
do

# Split up our first ip into it's octects
firstipfirstoctect=$(echo $firstip | awk -F "." '{print $1}')
firstipsecondoctect=$(echo $firstip | awk -F "." '{print $2}')
firstipthirdoctect=$(echo $firstip | awk -F "." '{print $3}')
firstipforthoctect=$(echo $firstip | awk -F "." '{print $4}')

# Split up our last IP into it's ocects
lastipfirstoctect=$(echo $lastip | awk -F "." '{print $1}')
lastipsecondoctect=$(echo $lastip | awk -F "." '{print $2}')
lastipthirdoctect=$(echo $lastip | awk -F "." '{print $3}')
lastipforthoctect=$(echo $lastip | awk -F "." '{print $4}')

    # Re-set BASH
    unset IFS

    # Echo out the object GROUP name
    echo "object-group network $name"

    # Loop through 1st Octect
    for a in `seq $firstipfirstoctect $lastipfirstoctect`;
    do
        # test to see if we need to print the whole range
        if [ $firstipfirstoctect -lt $lastipfirstoctect ]
        then
            firstipsecondoctectCOUNTER="0"
            lastipsecondoctectCOUNTER="255"
        fi

        # first IP might not be 1
        if [ $a -eq $firstipfirstoctect ]
        then
            firstipsecondoctectCOUNTER=$firstipsecondoctect
        fi

        # last IP might not be 255
        if [ $a -eq $lastipfirstoctect ]
        then
            lastipsecondoctectCOUNTER=$lastipsecondoctect
        fi

            # Loop through 2nd Octect
            for b in `seq $firstipsecondoctect $lastipsecondoctect`;
            do

                # Same tests as before except, next octect.
                if [ $firstipsecondoctect -lt $lastipsecondoctect ]
                then
                    firstipthirdoctectCOUNTER="0"
                    lastipthirdoctectCOUNTER="255"
                fi

                if [ $b -eq $firstipsecondoctect ]
                then
                    firstipthirdoctectCOUNTER=$firstipthirdoctect
                fi

                if [ $b -eq $lastipsecondoctect ]
                then
                    lastipthirdoctectCOUNTER=$lastipthirdoctect
                fi

                    # Loop through 3rd Octect
                    for c in `seq $firstipthirdoctectCOUNTER $lastipthirdoctectCOUNTER`;
                    do

                        # copy / paste / tweak
                        if [ $firstipthirdoctect -lt $lastipthirdoctect ]
                        then
                            firstipforthoctectCOUNTER="0"
                            lastipforthoctectCOUNTER="255"
                        fi

                        if [ $c -eq $firstipthirdoctect ]
                        then
                            firstipforthoctectCOUNTER=$firstipforthoctect
                        fi

                        if [ $c -eq $lastipthirdoctect ]
                        then
                            lastipforthoctectCOUNTER=$lastipforthoctect
                        fi

                            # final octect... echo result.
                            for d in `seq $firstipforthoctectCOUNTER $lastipforthoctectCOUNTER`;
                            do
                                echo " network-object $a.$b.$c.$d  255.255.255.255"
                            done

                    done
            done
    done

done<./FirewallRanges.csv

Cisco ASA - First steps to a Check Point Style Policy

nick — Wed, 01 Dec 2010 10:14:00 +0000

I've just spotted this in the Cisco ASA 8.3 release notes...

You can now configure access rules that are applied globally, as well as access rules that are applied to an interface. If the configuration specifies both a global access policy and interface-specific access policies, the interface-specific policies are evaluated before the global policy.

The following command was modified: access-group global

For users/companies which have migrated from Check Point to Cisco (usually to save on licensing fees), getting their head around a new interface level policy rather than a system (global) level is usually a bit of a challenge.

I'm looking forward to seeing if this really helps with policy migrations!

Thoughts on Firewalling

nick — Tue, 08 Jun 2010 07:16:00 +0100

Firewalls will always be a key ingredient to network security, but not all firewalls are equal. Recently I've been forced into documenting how I decide & think about firewall rules...

Strict Firewalling
IMO Strict Firewalling is the traditional way to implement your traffic policies (ACLS), each rule should be as tight as possible... the idea of "any" should not be used at all and ranges should be kept at a minimum; hosts better than subnets, source and destination IPs restricted, specific TCP ports (not ranges) used.

Service Led Firewalling
A term I think I made up, Service Led Fierwalling is where you relax the ACL/policy at the source... to host a DNS Zone you need to allow "anyone" to perform lookups so Strict Firewalling cannot be applied here but you do know the destination and the service so both of these should be defined/restricted as appropriate... you see what I mean here the policy is defined by the "service" provided.

Open Firewalling
Possibly a contradiction in terms but bare with me; there are some instances whereby implementing a firewall provides little benefit, one example I've seen was a customer's security officer wanted an internal firewall (i.e. no internet connection) in front of their Microsoft file server, in order for AD & MS clients to work properly all the MS ports had to be opened... so server guys continuously complained, what exactly is the firewall doing? What is Open Firewalling? It's the process of implementing a black list followed by a white list, rather than the traditional permit then drop processing that a firewall does; I'd create a rule that Drops Prohibited applications (such as P2P or unencrypted protocols) and then create a policy permitting all ports from legitimate IP ranges.

When would I use these?
Your firewall should be broken into zones, each zone meets both security policy and business requirements, you should then apply a firewalling technique to each zone. For example it's not uncommon to have a back-end database which should only ever be accessed by the front end application, therefore it could be in a zone protected by Strict Firewalling; public services such as websites/email servers require flexibility on their source thus require service led firewalling. Occasionally your business or application requirements suggest that firewalling impedes things, using open firewalling to "clean" traffic compromises "security people wanting firewalls" and any historical business/application issues... the firewall is there perhaps protecting against syn-flood attacks & as previously suggested blocking prohibited apps yet the business doesn't see any traditional firewall headaches.

I don't agree you fool!
That's your choice, there's no correct answer to security, the business you work in and the security policy mandated from senior management direct what you do, these are just my approaches :-)