Always Geeky | Firewalls

Category Archives Firewalls
Using hashdeep to confirm two directories match

Posted on February 10, 2020 11:56 am by scott Comment

First, use hashdeep to capture the hash of the first directory:

$ hashdeep -b -r /home/user/one/ > one-results.txt

Then do the same for the second directory:

$ hashdeep -b -r /home/user/one > two-results.txt

Now you need to compare the two resulting files. Their order is likely to be different, so you will need to sort them first.

$ sort one-results.txt > one-results-sorted.txt

$ sort two-results.txt > two-results-sorted.txt

$ diff one-results-sorted.txt two-results-sorted.txt

If the directories match, the only output of the diff command will be the headers showing the two files you are comparing. Like this:

10c10

\ ## $ hashdeep -b -r /home/user/one — \ ## $ hashdeep -b -r /home/user/two

You can use the -a command of hashdeep, but that will only if the directors are the same or not, it won’t show you what is different between them.

The -b flag is important – without this, hashdeep will store the full file path in the output files, which will never match between two directories. Using the -b flag ensure that only the filename is saves, not the full path, and this can be checked against different directories.

This entry was posted in Firewalls and tagged linux. Bookmark the permalink.
SSH to slave in HA Fortigate pair

Posted on June 1, 2015 12:07 pm by scott Comment

If you have a pair of HA Fortigates, sometimes you need to log into the slave device via SSH. Common examples including wanting to run a packet capture.

To do so, log into the primary device as usual, then run this command:

Fortigate1 # config global

Fortigate1 (global)# execute ha manage 0

Fortigate2 $

That’s it, you are now logged onto the slave Fortigate.

This entry was posted in Fortigate. Bookmark the permalink.
Fortigate VPN working except for ping

Posted on February 25, 2015 11:50 am by scott Comment

If you find a situation where a site to site IPsec VPN on a Fortigate is apparently up and passing traffic, except ping (ICMP) is not flowing over the VPN, here is a solution.

The cause can be if the VPN flaps momentarily, and an ICMP packet is received in the short space of time while the IPsec tunnel is down, the Fortigate will create a new session via the routed interface. Even when the tunnel is re-established, the incorrect session will persist via the physical interface, as opposed to via the correct tunnel interface.

To clear this erroneous session, run the following commands. Note that the first command (vd 2) is only required if you are using multiple Virtual Domains (VDOMS), and the number should correspond to the number of the impacted VDOM. If you don’t have VDOM’s in use, skip to the ‘proto’ command.
FORTIGATE (vdom) # diagnose system session filter vd 2
FORTIGATE (vdom) # diagnose system session filter proto 1 FORTIGATE (vdom) # diagnose system session filter session filter: vd: 2 sintf: any dintf: any proto: 1-1 proto-state: any source ip: any NAT'd source ip: any dest ip: any source port: any NAT'd source port: any dest port: any policy id: any expire: any duration: any FORTIGATE (vdom) # diagnose system session clear
FORTIGATE (vdom) #

Once you have cleared the session, you may need to restart the VPN tunnel. The next ICMP packet should bring up the session over the correct IPsec tunnel interface.

This entry was posted in Fortigate and tagged fortigate, fortinet, ICMP, IPsec, ping, VPN. Bookmark the permalink.
How to generate a pre shared key using APG

Posted on May 16, 2014 2:49 pm by scott Comment

A common requirement is to generate a random, unique and secure pre-shared key, typically for use in VPN’s. The Linux tool, APG (Automated Password Generator), is a great tool for this job, but you need to specify a few options to get the correct output.

If you just run ‘apg’, you get output that is designed to be read over the phone. This is not what we would consider secure. Here is my suggested command:
apg -a 1 -m 16 -n 1 -c /dev/random

What does each option do?
-a 1
This disables the ‘pronounceable’ password generation option, making password unpronounceable over the phone, and thus more random.

-m 16
This sets the length of the output to 16 characters. Feel free to substitute ’16’ with your own minimum requirement, just make sure that you make it larger than the default of 6.

-n 1
This produces only 1 password. If you need say 4 passwords, use -n 4. The default is 6.

-c /dev/random
By default, APG asks you to enter random data, which it will use as the seed for its PRNG. By using this option, we provide truly random data as the seed. Note that if your OS is low on entropy, using this option may take longer than usual.

If you want to avoid using symbols that might cause issues with input validation, try this command instead:
apg -a 1 -m 22 -n 1 -c /dev/random -M NCL
This will force the use of upper case, lower case and numbers, but no symbols. The number of characters has also been increased to 22, due to the lower entropy due the reduced character set.

This entry was posted in Firewalls, Linux and tagged apg, linux, prng, psk. Bookmark the permalink.
ERROR: Cannot remove connected route

Posted on December 4, 2013 10:43 am by scott Comment

firewall-asa(config)# no route INSIDE 192.168.0.0 255.255.255.0 172.16.0.254 ERROR: Cannot remove connected route firewall-asa(config)#

The above error is caused when you try to route a directly connected interface to another subnet. In order to remove this route, you need to shutown the interface, then remove the route.

For example, if you have 172.16.0.0/24 assigned to your INSIDE interface, and 192.168.0.0/24 routed to an IP within 172.16.0.0, and you want to move 192.168.0.0/24 to a dedicated segment on the FW (say DMZ), you will run into this problem. You need to shutdown the INSIDE segment in order to remove the route.

firewall-asa(config)# interface Ethernet0/1 firewall-asa(config-subif)# shut firewall-asa(config-subif)# exit firewall-asa(config)# firewall-asa(config)# no route INSIDE 192.168.0.0 255.255.255.0 172.16.0.254 firewall-asa(config)# firewall-asa(config)# interface Ethernet0/1.100 firewall-asa(config-subif)# no shut

Problem solved.

This entry was posted in Cisco ASA and tagged ASA 8.0, cisco asa, firewall, routing, static route. Bookmark the permalink.
Show sysopt configuration on ASA

Posted on June 27, 2013 10:09 pm by scott Comment

The normal commands to show configuration items don’t work as expected for sysopt.

asa/pri/act# sh run sysopt asa/pri/act#
asa/pri/act# sh run | include sysopt asa/pri/act#
asa/pri/act# more system:running-config | include sysopt asa/pri/act#

You need to use the “show run all sysopt” command.

asa/pri/act# show run all sysopt no sysopt connection timewait sysopt connection tcpmss 1380 sysopt connection tcpmss minimum 0 no sysopt nodnsalias inbound no sysopt nodnsalias outbound no sysopt radius ignore-secret sysopt connection permit-vpn no sysopt connection reclassify-vpn no sysopt connection preserve-vpn-flows asa/pri/act#

This entry was posted in Cisco ASA, Firewalls and tagged sysopt. Bookmark the permalink.

ERROR: ACE contains port, protocol, or deny. Removing NAT configuration

Posted on March 7, 2013 10:22 pm by scott Comment

Never specific anything other than IP (such as TCP or UDP), when creating an ACL on the ASA for an ACL used within a NAT statement. If you do, you may get this error:

ERROR: ACE contains port, protocol, or deny. Removing NAT configuration

The above means that all of your NAT config has now been removed. Depending on your config, this can break a lot of traffic.

Here is an example:

ciscoasa/pri/act# show run nat

nat (outside) 0 access-list nat-exempt
nat (dmz) 0 access-list nat-exempt
nat (inside) 0 access-list nat-exempt

ciscoasa/pri/act#
ciscoasa/pri/act# sh run access-list nat-exempt

access-list nat-exempt extended permit ip 10.101.0.0 255.255.255.0 10.120.0.0 255.255.255.0

ciscoasa/pri/act# configure terminal
ciscoasa/pri/act(config)# access-list nat-exempt extended permit tcp 10.96.0.0
255.255.255.0 172.19.19.0 255.255.255.0 eq 80

ERROR: ACE contains port, protocol, or deny. Removing NAT configuration
nat (outside) 0 access-list nat-exempt
ERROR: ACE contains port, protocol, or deny. Removing NAT configuration
nat (dmz) 0 access-list nat-exempt
ERROR: ACE contains port, protocol, or deny. Removing NAT configuration
nat (inside) 0 access-list nat-exempt

ciscoasa/pri/act(config)# exit
ciscoasa/pri/act# 
ciscoasa/pri/act# show run nat
ciscoasa/pri/act#

Notice that the NAT rules were removed completely when we added the incorrect ACE. We need to replace them manually:

ciscoasa/pri/act(config)# no access-list nat-exempt extended permit tcp 10.96.0.0
255.255.255.0 172.19.19.0 255.255.255.0 eq 80

ciscoasa/pri/act(config)# nat (outside) 0 access-list nat-exempt
ciscoasa/pri/act(config)# nat (dmz) 0 access-list nat-exempt
ciscoasa/pri/act(config)# nat (inside) 0 access-list nat-exempt

This entry was posted in Cisco ASA and tagged ASA 8.0, nat, nat exemption, nat-control. Bookmark the permalink.

SRX VPN Phase-1 negotiation failed with error Timeout

Posted on December 15, 2012 11:46 pm by scott Comment

If your phase 1 negotiation is timing out from your SRX, it may be due to lack of IKE setting on the host-inbound-traffic setting.

Here is a typical error:
Jan 01 12:00:00 Phase-1 negotiation failed with error Timeout for p1_local=ipv4( udp:500,[0..3]=192.0.2.1) p1_remote=ipv4(udp:500,[0..3]=198.51.100.1)

A broken config will look like this – notice the lack of IKE.

root@srx> show configuration security
security {
        security-zone untrust {
            address-book {
                address 10.0.0.0/24 10.0.0.0/24;
                address 10.0.1.0/24 10.0.1.0/24;
            }
            host-inbound-traffic {
                system-services {
                    ping;
                    ssh;
                }
            }
            interfaces {
                fe-0/0/2.0;
                st0.0;
            }
        }
    }

Note the lack of IKE on host-inbound-traffic. Here is how you fix it.

root@srx# set security security-zone untrust host-inbound-traffic system-services ike

Here is the update config

root@srx> show configuration security
security {
        security-zone untrust {
            address-book {
                address 10.0.0.0/24 10.0.0.0/24;
                address 10.0.1.0/24 10.0.1.0/24;
            }
            host-inbound-traffic {
                system-services {
                    ping;
                    ssh;
                    ike;
                }
            }
            interfaces {
                fe-0/0/2.0;
                st0.0;
            }
        }
    }

This entry was posted in Juniper SRX and tagged junos ike vpn phase-1. Bookmark the permalink.

SRX cluster SSH/HTTPS access to secondary fails

Posted on October 21, 2012 12:51 pm by scott Comment
A Juniper SRX cluster configuration does not allow access to the secondary device, even by out-of-band management, but default. This is expected behaviour, as the non-primary device in a cluster will not start the router process. So, unless your out-of-band management gives you access from the same layer 2 network, the secondary SRX will not respond to SSH/HTTPS

To resolve this, you need set a backup-router. A backup-router is a static route which is active before the routing engine starts. Typically, this is useful while the SRX is booting, as it allows BOOTSTRAP or PXE based boots, but presents a problem in cluster.

root@srx-secondary> show route error: the routing subsystem is not running

Fix this problem, with the following command:
set groups node1 system backup-router 172.29.0.1 destination 0.0.0.0/0
This will appear in the groups configuration as such:
```
node0 {
    system {
        host-name srx-primary;
    }
    interfaces {
        fxp0 {
            unit 0 {
                family inet {
                    address 172.29.0.100/24;
                }
            }
        }
    }
}

node1 {
    system {
        host-name srx-secondary;
        backup-router 172.29.0.1 destination 0.0.0.0/0;
    }
    interfaces {
        fxp0 {
            unit 0 {
                family inet {
                    address 172.29.0.101/24
                }
            }
        }
    }
}
```
You will now have SSH/HTTPS access to your secondary device. It is a good idea to also add a backup-router to the primary device, in case the router daemon on the primary crashes or fails.
This entry was posted in Juniper SRX and tagged backup-router, HTTPS, out of band, routing daemon, SSH. Bookmark the permalink.
Example IP addresses and domains for documentation

Posted on October 14, 2012 2:52 pm by scott Comment

Don’t be tempted to use any random IP address or domain for documentation or testing purposes. It is quite easy to forgot to remove such an IP or domain from a config or diagram, which can cause outages and other unintended consequences.

RFC 5737 details IPv4 address blocked which have been specifically set aside for use in documentation. These IP blocks are:
192.0.2.0/24
198.51.100.0/24
203.0.113.0/24

Of course, there is nothing stopping your from using private IP blocks for us in documentation, but you do run the risk of conflicts arising, as well as not recognizing that an IP is for documentation purposes, and not an actual IP address. The above IP blocks should be added to bogan filters, therefore hopefully preventing any production issues.

IPv6 documentation IP’s are covered in RFC 3849, being:
2001:DB8::/32

Domain names for documentation purposes are also covered, by RFC 2606. There are 3 options if you need to use a real TLD, being:
example.com
example.org
example.net.

IANA has also reserved a number of TLD specifically for documentation purposes, so any domain using a TLD of .test, .example, .invalid or .localhost is permitted.

This entry was posted in Firewalls and tagged bogan filter, documentation, domain, IPv6, RFC5737, TLD. Bookmark the permalink.
← Older posts