Fortigate SCP backup

Here is a small guide to backup Fortigate config with SCP

Using the Web-based manager:
Go to System > Admin > Settings.
Make sure SCP is enabled

Go to System > Network > Interface.
Select the Edit icon for the interface you use for administrative access.
In the Administrative Access section, select the SSH check box.
Click OK.

Create a public-private key pair using a key generator tool compatible with your SCP client.
root@linux:~# ssh-keygen -t rsa -b 2048 -f /tmp/fw-001
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): ENTER
Enter same passphrase again: ENTER
Your identification has been saved in /tmp/fw-001.
Your public key has been saved in /tmp/fw-001.pub.

Save the private key to the location on your computer where your SSH private keys are stored.
root@linux:~# mv /tmp/fw-001.pub /etc/
root@linux:~# mv /tmp/fw-001 /etc/fw-001.sec

Connect to the fortigate using SSH.
root@linux:~# ssh admin@x.x.x.x

config system admin
edit admin
set ssh-public-key1 "[paste content from /etc/fw-001.pub]"
end

And you are done! :)

To trigger the copy, run the following command from bash.
root@linux:~# scp -i /etc/fw-001.sec admin@x.x.x.x:sys_config /backup/fw-001.fg.bin

Boot Image Recovery on Cisco ASA firewall

Here are the required steps to recover from a missing or corrupt boot image:

• Connect a console cable from the ASA to your computer and open up a serial connection using Putty
• Disable any software firewall on your computer
• Install TFTP server software on your computer – I used Solarwinds TFTP server
• Place the Cisco software image in the TFTP-Root folder (asa821-k8.bin) and start the TFTP service
• Assign a static IP address to your computer – I used 192.168.20.1 (an address outside of my existing subnet)
• Connect an Ethernet cable between your computer and port 0/0 on the ASA
• Power off the ASA then power it back on
• Press the escape key to boot into ROMMON mode
• Enter the following commands in the ASA (the first part of these commands must be in caps)
  rommon #1> ADDRESS=192.168.20.10
  rommon #2> SERVER=192.168.20.1
  rommon #3> GATEWAY=192.168.20.1
  rommon #4> IMAGE=asa821-k8.bin
  rommon #5> PORT=Ethernet0/0
• These commands assign an IP address of 192.168.20.10 to port 0/0 on the ASA and tell it to look at your TFTP server 192.168.20.1 and to select the ASA software image.
• Next, execute the command to transfer the image from the TFTP server to the ASA
  rommon #6> tftp

Before we look at some basic Frame Relay configurations, we need to go over a few important topics and terms. Figure as below shows two routers that connect to each other through a Frame Relay network.

Here are some terms you'll need to understand when working with Frame Relay:

Frame cloud

When connecting to a public frame network, you only know about your points of entry to the network; the interior of the network (the "cloud") is invisible to you. The network itself is often called a cloud, because you can't see what happens to your packets after they enter it.

Virtual circuit (VC)

A virtual circuit is a logical connection created by the frame provider from Point A to Point B across a frame cloud.

Data Link Connection Identifier (DLCI)

A DLCI is a value assigned by the frame provider to identify a virtual circuit. In other words, it's the Frame Relay equivalent of an address. DLCIs are unique only locally. That is, your router will have a unique DLCI for each virtual circuit it uses from one Frame Relay provider. However, as far as the Frame Relay provider is concerned, DLCIs are just numbers; the provider can reuse DLCIs throughout its network.

The router maps IP addresses to DLCIs so that it can communicate with a remote router by using the appropriate DLCI. There are two ways to map a DLCI to an IP address. First, you can allow the router to discover the DLCI by using inverse ARP, which is enabled by default. Second, you can explicitly map an IP address to a DLCI.

Local Management Interface (LMI)

The LMI is based on the type of Frame Relay switch you are connecting to. Your provider will give you this information. The LMI types are Cisco, Ansi, and q933a; Cisco is the default. Note that the routers at each end of the link may have different LMI settings, because they are connected to different types of switches.

Point-to-point

A point-to-point connection is a single virtual circuit that connects two points. In Figure 6-1, Router 1 connects to Router 2 with a frame network between them. On either side of the frame cloud is a router that knows that there is only one router at the other end. This kind of configuration is similar to connecting two routers directly over a serial line.

Multipoint

In a multipoint network, a single interface is connected to multiple virtual circuits with multiple DLCIs. Each virtual circuit is still point-to-point, but many logical point-to-point connections share the same physical interface. Subinterfaces should be used for each fully-meshed portion of the multipoint network. Remember that subinterfaces use the X.Y notation, where X is the interface and Y is the subinterface.

There are two types of multipoint networks: partially-meshed and fully-meshed. In a fully-meshed network, all the routers have direct connections to each other. In contrast, in a partially-meshed network, each router is connected to at least one other router, but may not have a direct connection to all the routers in the network. For example, you might have three routers, A, B, and C; Routers B and C are connected to Router A, but do not have a direct connection to each other.

Split horizon

Split horizon is a technique commonly used in routing protocols; it means that the router will not send information about a route out the same interface from which it learned the route. Split horizon is normally used to prevent routing loops. However, it can cause problems in a partially-meshed multipoint Frame Relay network. More than one router may be listening at the other end of any interface. Therefore, we don't want to suppress route announcements. For example, assume that we have three routers (i.e., three virtual circuits) connected to our multipoint interface. If a route comes to our interface from any of those points, we want to announce the route to the other two points. If split horizon is enabled, we can't send the route out our interface because that is where the route originated. However, split horizon should be enabled on a fully-meshed multipoint Frame Relay network.

Configuring HSRP Protocol

I spent a little time this morning learning about the HSRP (Hot Standby Router Protocol) and how to configure it in a real world environment. This is something that I might think about implementing in our networking system actually. It works by creating redundancy between two routers in case one router loses internet connectivity, the other router can take over. The configuration was rather simple and easy to understand. You're basically creating a virtual IP (VIP) that your internal network will use rather than the routers actual Ethernet IP address. I have including a sample configuration below:

Router_A#sh run int fa0/0
Building configuration...

Current configuration : 166 bytes
!
interface FastEthernet0/0
ip address 192.168.100.2 255.255.255.0 (actual IP address)
duplex auto
speed auto
standby ip 192.168.100.1 (VIP address configured on Router B as well)

standby preempt (Tells the router to try and become primary when circuit is back up)

standby track Serial0/0 10 (decrements HSRP priority, router with highest is primary router)

General Cisco Security

There are several general configuration items that should be configured on all Cisco devices running standard IOS. Some layer2 only switches will ignore a few of the commands in this article that are layer3 specific.

The first place to start is with the service commands

service password-encryption

Explanation:

The router administrator will ensure passwords are not viewable when displaying the router configuration. Type 5 encryption must be used for the enable mode password.

no service udp-small-servers
no service tcp-small-servers

Explanation:

All IOS versions above 12.0 has small-servers disabled by default. However, it is good to make sure these services didn’t get enabled somewhere along the way. The commands above won’t show up in the configuration, since they are off by default. Cisco IOS provides these “small services” which include echo, chargen, and discard. These services are completely unnecessary to run on Cisco devices.

no service pad

Explanation:

Packet Assembler Disassembler (PAD) is an X.25 component that is seldom used. PAD acts like a multiplexer for the terminals. If enabled, it can render the device open to attacks.

service tcp-keepalives-in

Explanation:

Idle logged-in telnet sessions can be susceptible to unauthorized access and hijacking attacks. By default, routers do not continually test whether a previously connected TCP endpoint is still reachable. If one end of a TCP connection idles out or terminates abnormally, the opposite end of the connection may still believe the session is available. These “orphaned” sessions use up valuable router resources and can also be hijacked by an attacker. To mitigate this risk, routers must be configured to send periodic keep-alive messages to check that the remote end of a session is still connected. If the remote device fails to respond to the keep-alive message, the sending router will clear the connection and free resources allocated to the session.

no service finger

Explanation:

The IOS finger service supports the UNIX finger protocol, which is used for querying a host about the users that are logged on. This would give potential attackers a head start by providing valid usernames for the device.

no boot network
no service config

Explanation:

The routers can find their startup configuration either in their own NVRAM or load it over the network via TFTP or Remote Copy (rcp). Obviously, loading in from the network is taking a security risk. If the startup configuration was intercepted by an attacker, it could be used to either gain access to the router.

Next, let’s take a look at the various server services available in IOS.

no ip http-server
no ip ftp-server
no ip tftp-server

Explanation:

The services listed above are extremely insecure and serve very little useful purpose. An ftp-server or tftp-server might be used in environments where you have one device that has a software image on it that you want to distribute to other reachable devices. These other devices might not have connectivity to a centralized distribution server that would host images for software upgrades, therefore making it convenient to use a router in order to get the job done. If these services are used, it should only be in a temporary capacity and need to be disabled before logging out of the device.

no ip bootp server

Explanation:

Bootp is a user datagram protocol (UDP) that can be used by Cisco routers to access copies of Cisco IOS Software on another Cisco router running the Bootp service. In this scenario, one Cisco router acts as a Cisco IOS Software server that can download the software to other Cisco routers acting as Bootp clients. In reality, this service is rarely used and can allow an attacker to download a copy of a routers Cisco IOS Software.

no ip source-route

Explanation:

Source routing is a feature of IP, whereby, individual packets can specify routes. This feature is used in several different network attacks. The router should always control how traffic is routed as apposed to be told to trust a path that is provided from another source.

Mapping Hostnames to IP Addresses

IP Host Tables

The ip host command builds and maintains the router's host table. This command takes a hostname followed by one or more IP addresses. You can have up to eight IP addresses per hostname.

ip host pyramid 10.10.1.3

ip host sphinx 10.10.1.2 10.10.1.4 10.10.1.5

Deleting a host requires you to type the entire hostname and IP address over again!

no ip host pyramid 10.10.1.3

no ip host sphinx 10.10.1.2 10.10.14 10.10.1.5

 Enabling DNS

The Domain Name System (DNS) reduces the need for host entries—although, as I said before, you should have explicit host entries for any IP addresses that appear in your configuration. DNS is enabled by default; to enable it explicitly, use the command ip domain-lookup. To configure DNS, you must specify one or more name servers and the domain name to be used to complete unqualified names (typically, your own domain name). A typical configuration looks like this:

! Specify the DNS servers

ip name-server 10.10.9.1

ip name-server 10.10.9.2

!

! Set the name for unqualified hostnames

ip domain-name your-domain.com

To disable DNS lookups, use the no form of the command:

no ip domain-lookup

To re-enable DNS lookups, leave off the no keyword:

! Enable DNS lookups

ip domain-lookup

Use the show hosts command to view the cached hostnames and the DNS configuration:

Router>show hosts

Default domain is your-domain.com

Name/address lookup uses domain service

Name servers are 10.10.9.1 10.10.9.1



Host                     Flags      Age Type   Address(es)

Foxtrot                  (temp, OK)  18   IP    10.10.1.3

sphinx                   (temp, OK)  18   IP    10.10.1.2

Configure Switch VTY Ports

In this post I will configure all my VTY (Telnet ports) to have logging synchronous and a 30 minute exec timeout (max idle time). I give the ports a password of cisco, configure the switch to require a login on the VTY ports and display the motd banner. Finally I use a show command to check the running config.



switch1#conf t
switch1(config)#line vty 0 15
switch1(config-line)#logging synchronous
switch1(config-line)#exec-timeout 30 0
switch1(config-line)#password cisco
switch1(config-line)#login
switch1(config-line)#motd-banner
switch1(config-line)#end


switch1#sh run | begin line vty
line vty 0 4
exec-timeout 30 0
password 7 01100F175804
logging synchronous
login
line vty 5 15
exec-timeout 30 0
password 7 01100F175804
logging synchronous
login
!
end

Extended ACLs

Extended ACLs

In this post I will create an Extended ACL to block Telnet traffic from the 192.168.1.48/30 network reaching the R3 router. I'll be working with the network in the diagram below.



Unlike Standard ACL's which are placed as near to the destination as possible, Extended ACL's are placed as near to the source as possible, this is to reduce processing on the routers.


R1


R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip access-list extended 100
R1(config-ext-nacl)#deny 192.168.1.48 0.0.0.3 192.168.1.58 0.0.0.0 eq 23 log
R1(config-ext-nacl)#permit ip any any log
R1(config-ext-nacl)#exit


I have created an access-list to block all the 192.168.1.48/30 subnet from access R3 with Telnet.


R1(config-if)#ip access-group 100 in
R1(config-if)#end


I have applied the list to interface ethernet 0/0 on R1


R1#sh ip inter ethernet 0/0
Ethernet0/0 is up, line protocol is up
Internet address is 192.168.1.50/30
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.9
Outgoing access list is not set
Inbound access list is 100
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF Feature Fast switching turbo vector
IP multicast fast switching is enabled

I test that I can telnet to R3 from R1.


R1#telnet 192.168.1.58
Trying 192.168.1.58 ... Open
User Access Verification
Password:
Last login: Wed Mar 3 21:06:01 on ttys001


Now on R0 I attempt to telnet to R3


R0

R0#telnet 192.168.1.58
Trying 192.168.1.58 ...
% Destination unreachable; gateway or host down

R0#ping 192.168.1.58
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.58, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/16 ms


My telnet fails but ping works just fine. I check R1 to see the statement being hit.


R1

*Mar 1 00:10:52.315: %SEC-6-IPACCESSLOGP: list 100 denied tcp 192.168.1.49(22404) -> 192.168.1.58(23), 1 packet
R1#
*Mar 1 00:11:02.615: %SEC-6-IPACCESSLOGDP: list 100 permitted icmp 192.168.1.49 -> 192.168.1.58 (8/0), 1 packet
R1#

How-To create a basic configuration on a Fortinet Fortigate

is post will explain some useful command on a fortigate firewall. This post assume you have a Fortinet Fortigate device and want to use it to connect your local network (192.168.1.0/24) to internet and you have an internet connection. This post also assume that you have a router with a pubblic IP address 111.222.111.1 and you have a pubblic subnet 111.222.111.0/29. In this case I’ve used a point-to point device to detect the connection failure with IP address 111.222.111.123.
Obviously you must change your private (INTERNAL) IP address to adapt it to your network, and use your public subnet and not the one used here for the example (111.222.111.0/29).

config system global # Set the http admin port to 80/tcp set admin-port 80
# Set the https admin port to 443/tcp set admin-sport 443
# Set the ssh admin port to 22/tcp set admin-ssh-port 22
# Set the telnet admin port to 23/tcp set admin-telnet-port 23
# Set the hostname set hostname “FGT50B-MAGAZZINO”
# Set the ntp server to “time.ien.it” and enable it set ntpserver “time.ien.it” set ntpsync enable
# Set to 43200 seconds the tcp-halfclose timer set tcp-halfclose-timer 43200 end
# Set the telnet 23/tcp port timeout to 43200 seconds. # This is very useful if you have an AS400 (iSeries) to avoid session timeout. config system session-ttl set default 43200 config port edit 23 set timeout 43200 next end
# Set the IP address and administrative access options (ping https http) for INTERNAL interface. config system interface edit “internal” set ip 192.168.1.254 255.255.255.0 set allowaccess ping https http set type physical next
# Set the IP address and administrative access options (ping https) for WAN1 interface. # Set “gateway Detect” option enable and set the “Ping Server” destination.

# Set the interface speed to 10 Mb/s Half Duplex, this is useful for some connections like radio bridge. edit “wan1″ set ip 111.222.111.2 255.255.255.248 set allowaccess ping https set gwdetect enable set detectserver “111.222.111.123″ set type physical set speed 10half next end
# Set DNS Servers and DNS options config system dns set primary 192.168.1.3 set secondary 212.97.32.2 set domain ” set autosvr disable set dns-cache-limit 5000 set cache-notfound-responses disable end
# Set a firewall policy to enable traffic from INTERNAL TO WAN1 using NAT # Set a protection profile (a default one) called “scan” config firewall policy edit 1 set srcintf “internal” set dstintf “wan1″ set srcaddr “all” set dstaddr “all” set action accept set schedule “always” set service “ANY” set profile-status enable set profile “scan” set nat enable next end
# Set a default gateway on the WAN1 interface config router static edit 1 set device “wan1″ set gateway 111.222.111.2 end

FORTIGATE 60 FIREWALL CLI CONFIGURATION

Configure Interface
Fortiget-60 # config system interface
edit internal
set ip 192.168.2.1 255.255.255.0
set mode static
next
edit wan1
set ip 192.168.3.1 255.255.255.0
next
edit internal
set ip 192.168.100.1 255.255.255.0
set dhcp-server-mode none (Set DHCP Server Mode Off)
next
edit wan1
set ip 192.168.1.2 255.255.255.0
show system interface (Check interface configuration)
Configure DNS
Fortiget-60 # config system dns
set primary 165.21.83.88
set secondary 165.21.100.88
end
Configure Internal Allowaccess (ping, https)
Fortiget-60 # config system interface
edit internal
unset allowaccess
set allowaccess ping
set allowaccess https
end
Configure Wan1 Allowaccess (ping)
Fortiget-60 # config system interface
edit wan1
unset allowaccess
set allowaccess ping
end
Configure Static Route
Fortiget-60 # config router static
edit 1
set device wan1
set dst 0.0.0.0 0.0.0.0
set gateway 192.168.1.1
set distance 10
Change Admin Password
Fortiget-60 # config system admin
edit admin
set password
end
Firmware Upgrade
To upgrade the FortiGate firmware from the CLI:
1 Make sure that the TFTP server is running.
2 Copy the new firmware image file to the root directory of your TFTP server.
3 Log into the CLI as the admin administrative user.
Fortiget-60 # execute restore image

Netscreen - NSRP

HA Setups
There are 3 main types of HA setup, they are,

• Active / Passive - All traffic passes the active node. In the event of failure the backup firewall is activated, and traffic flow is resumed.
• Active / Active - Both Firewalls share the network load. In the event of failure all traffic is passed through the working node.
• Active / Active Full Mesh - This setup eliminates any single point of failure. Every link to each node, switch, and router is cabled twice to allow for complete redundancy.

HA Feature Sets

SOHO
This allows for you to configure a secondary untrust interface. Of which in the event of failure the secondary link will become active, in order to restore connectivity. You can use either the available serial port or ethernet port for your secondary link, allowing you to connect ADSL Modems or Routers.
By default you must manually initiate a failover from the CLI.
The various commands are below,

ns5gt-> exec failover force <- failover manual
ns5gt-> exec failover revert <- revert ack
ns5gt-> exec failover auto <- enable automatic failover

To allow the link to stabilize there is a default hold down timer of 30secs. If required you can modify this by using the command,

ns5gt-> set failover hold-down [number of seconds]

SOHO only monitors the link between the Netscreen and the modem or the router. So if there is a problem with the ISP service the Netscreen will not failover.
To allow you to configure this setup (dual untrust) you will need to be using a port mode of "dual-untrust" or "combined".
To confirm which mode you are running use the command `get system`. You can change the mode by using `exec port-mode dual-untrust` command, but be warned this will cause all the configuration to be erased.
NSRP-Lite
This allows for Active/Passive setup with configuration syncronisation. But does not provide Run-Time Oject syncronisation (discussed later) or an Active/Active setup.
NSRP
NSRP is the protocol that allows clustered Netscreens to communicate with each other and allows them to exchange state information. Which in turn allows them to make the required decisions to ensure traffic is still passed in the event of failure.
When NSRP is enabled a VSD (Virtual Security Device) is created, along with the configuration of the physical interfaces being applied to VSI`s Virtual Security Interfaces. Each VSD belongs to a VSD group. In each VSD group, one VSD is nominated as a master VSD. Each VSD will sit on each firewall. Only the master VSD (Active firewall) will pass the traffic. Along with this the IP addresses assigned to a VSI follow the master VSD. With regards to the management IP`s these stay static to each firewall.

NSRP States
At any one time each VSD can be in one of 6 states.

1. Master
2. Primary Backup
3. Backup
4. Initial
5. Ineligible
6. Inoperable

Initial - Occurs when a VSD is first created due to reboot or configuration change. While in this state the VSD learns other devices in the VSD group, syncs the state with other VSD`s, and elections for which VSD should be master.
Master or Backup - Each VSD then either goes into a master or backup state.
Primary backup - If the backup node finds there is no primary backup VSD it sets itself to the Primary Backup for the VSD group. When in this state the VSD can either be prompted to master due to the old VSD disappearing or goes into an inoperable state.
Inoperable - The VSD will go into this state if it detects a failure that stops it from passing traffic, when in this state the VSD isnt included in elections.
Ineligible - This is an administratively down state of a VSD, of which is done manually. `set nsrp vsd-group id [number] mode ineligable`.The Master VSD is determined,

• if there is no other VSD then the devices wins and becomes active
• if there are 2 VSDs the device with the lowest priority wins ( `set nsrp vsd-group id X priority N` )
• if both devices have same priority or its not set then the VSD with the lowest MAC address wins. 

A fail over can be caused by any of the following,

• Software crashes
• Hardware or power failure
• Link failure on monitored interfaces or zones
• Unavailability of one or more Tracked IP`s

Cluster Traffic
2 types of packets are exchanged over HA Links. These are control messages and data packets.

• Control messages : Consists of Heartbeats, Link probes, VSD stat information and session synchronizations.
• Data packets       : This is normal user traffic which is passed from one firewall to another. This happens in an Active/Active HA setup.

To check if both devices are in sync run the command,

ns5gt-> clear db
ns5gt-> exec nsrp sync global-config check-sum
ns5gt-> get db str

NSRP Track IP
Interface Track IP and VPN monitoring are not included with NSRP. NSRP Tracking allows you to fail across your cluster in the event of IP`s becoming unreachable. Such as a router IP. This allows for failovers in the event of a Netscreen interface or switch port failing.
If in the event of failure you required your traffic to take an alternative route, a configuration option would be to,

1. Disable the default VSD group
2. Create a new VSD group but leave out your interfaces that you require as being local.
3. Set Track IP to poll an IP address (such as your Router)

In the event of failover this would prevent the failed interface from moving to the other VSD.
RTO Mirroring
Real-Time Object mirroring allows dynamic based information to be synchronized between the cluster nodes, such as DHCP leases, VPN sessions etc.
To enable RTO use the following commands,

ns5gt-> set nsrp cluster id1
ns5gt-> set nsrp rto-mirror sync

With some insecure protocols you may wish to disable sessions created by a certain policy from being mirrored when dealing with DoS attacks. To change this,

1. Go into the policy
2. Select "Advanced"
3. Deselect "HA Session Backup" and click return.
4. Click OK

Split Brain
Split Brain is a situation where the HA link fails and in turn both devices believe the other device has failed and then promotes itself to master.
There are 3 methods in which you can prevent this situation from arising,

1. Dual HA links.
2. Connect the Ha links directly using cross over cables.
3. Add a secondary path for the HA link. This will use an existing traffic interfaces and is enabled via the commands.

ns5gt-> adding a secondary path
ns5gt-> set nsrp secondary-path eth1

"No Brain" Situation
In this situation both switches/switch ports fail. Both firewalls may be plugged into the same switch or different switches which may fail due to power failure etc. This causes both firewalls to place themselves into an inoperable state and then backup. Causing both firewalls to be in a backup state.
To ensure that one device is always master you can use the command,

ns5gt-> set nsrp vsd-group master-always-exists

The main issue with this occurs in a situation where both switches/switch ports fail for one network (i.e trust) and then a switch/switch port fails on the active node. In this case the cluster will not fail across to the secondary node even though it is the best candiate for master.

DNS / nslookup - How to find the root servers

DNS servers are based on a recursive look up as you can see below.
Below you can see XP forwarding the request to its DNS server. The DNS Server then recursively resolves the DNS request. Once it has the answer to the Clients request, it forwards the answer back to the client.

A great tool for DNS troubleshooting is nslookup.

How do I find the root servers ?

C:\Documents and Settings\admin>nslookup
Default Server:  dns.service.isp.net
Address:  194.168.1.100

> set type=ns
> .
Server:  cache2.service.virginmedia.net
Address:  194.168.8.100

Non-authoritative answer:
(root)  nameserver = M.ROOT-SERVERS.NET
(root)  nameserver = A.ROOT-SERVERS.NET
(root)  nameserver = B.ROOT-SERVERS.NET
(root)  nameserver = C.ROOT-SERVERS.NET
(root)  nameserver = D.ROOT-SERVERS.NET
(root)  nameserver = E.ROOT-SERVERS.NET
(root)  nameserver = F.ROOT-SERVERS.NET
(root)  nameserver = G.ROOT-SERVERS.NET
(root)  nameserver = H.ROOT-SERVERS.NET
(root)  nameserver = I.ROOT-SERVERS.NET
(root)  nameserver = J.ROOT-SERVERS.NET
(root)  nameserver = K.ROOT-SERVERS.NET
(root)  nameserver = L.ROOT-SERVERS.NET

How do I find the TLD servers ?

> com
Server:  cache.service.isp.net
Address:  194.168.1.100

Non-authoritative answer:
com     nameserver = g.gtld-servers.net
com     nameserver = d.gtld-servers.net
com     nameserver = j.gtld-servers.net
com     nameserver = h.gtld-servers.net
com     nameserver = c.gtld-servers.net
com     nameserver = i.gtld-servers.net
com     nameserver = m.gtld-servers.net
com     nameserver = k.gtld-servers.net
com     nameserver = b.gtld-servers.net
com     nameserver = l.gtld-servers.net
com     nameserver = a.gtld-servers.net
com     nameserver = e.gtld-servers.net
com     nameserver = f.gtld-servers.net

How do I find zone information ?

> set type=soa
> bbc.com
Server:  cache.service.isp.net
Address:  194.168.1.100

Non-authoritative answer:
bbc.com
primary name server = ns0a.rbsov.bbc.co.uk
responsible mail addr = bofh.bbc.co.uk
serial  = 1225383591
refresh = 86400 (1 day)
retry   = 86400 (1 day)
expire  = 86400 (1 day)
default TTL = 0 (0 secs)

Client and Server side NAT relates to when we perform destination NAT`ing.
The "Translate destination on Server side" option is an legacy option which was included due to pre NG versions of checkpoint using Server-Side NAT.

• Client Side NAT - The destination address is NAT`d by the inbound Kernel
• Server Side NAT - The destination address is NAT`d by the outbound Kernel

Note !! Source NAT always happens on the Outbound Kernel.
Note !! Rule > NAT - The kernels will  always process the rules before the NAT.
So why does this matter ?
Well when we use client side NAT the IP address is NAT`d before it hits the routing table. So we can route the packet based on the real IP. 
But when we use Server side NAT the IP is NAT`d after passing the routing table so there has to be a route for NAT`d (fake) IP in the routing table so that the operating system can pass the packet to the correct interface.
To explain things a little easier have a look at the diagram below,

So we want to access the server (10.8.8.1). If we use Client Side NAT the inbound kernel will NAT the destination IP (192.168.8.1) to the real IP (10.8.8.1) and then pass the packet to the (OS) routing table. Which as you can see will have the routing entry for this subnet and pass it out (via the outbound kernel) to the interface (eth0).
But if we use Server Side NAT the packet would not get NAT`d by the inbound kernel. It would get to the (OS) routing table with a destination of 192.168.8.1. Which, there is no entry for. We would need to add an entry to the routing table.  Once added the operating system would know where to route this packet, the packet would pass through the outbound kernel which would NAT the destination IP to 10.8.8.1.
Note: Client AND Server side NAT are options ONLY for destination NAT.

DMVPN Tutorial

Introduction

DMVPN (Dynamic Multipoint Virtual Private Network) is a feature within the Cisco IOS based router family which provides the ability to dynamically build IPSEC tunneling between peers based on an evolved iteration of hub and spoke tunneling. DMVPN uses a combination of the following technologies :

1. Multipoint GRE (mGRE)
2. Next-Hop Resolution Protocol (NHRP)
3. Dynamic Routing Protocol (EIGRP, RIP, OSPF, BGP)
4. Dynamic IPsec encryption

DMVPN alleviates the need for multiple IPSEC configurations. This:

1. reduces administration and management overhead
2. allows for efficient scalability

Example

In the following example we will configure DMVPN between the Hub router and each of its spokes (router 2, 3 and 4). The steps will be broken broken down into the following sections:

• Physical Connectivity
• DMVPN Configuration
• IPSEC
• Dynamic Routing

PHYSICAL CONNECTIVITY

Below shows the physical topology along with the configuration for each of the routers.

HUB

interface f0/0
  ip address 192.168.1.100 255.255.255.0
  duplex full
  speed 100
  no shut

ip route 192.168.2.0 255.255.255.0 192.168.1.1
ip route 192.168.3.0 255.255.255.0 192.168.1.1
ip route 192.168.4.0 255.255.255.0 192.168.1.1

ROUTER 1

interface f2/0
    ip address 192.168.1.1 255.255.255.0
    duplex full
    speed 100
    no shut

interface f0/0
    ip address 192.168.2.1 255.255.255.0
    duplex full
    speed 100
    no shut

interface f1/0
    ip address 192.168.3.1 255.255.255.0
    duplex full
    speed 100
    no shut

interface f0/1
    ip address 192.168.4.1 255.255.255.0
    duplex full
    speed 100
    no shut

ROUTER 2

interface f0/0
    ip address 192.168.2.2 255.255.255.0
    duplex full
    speed 100
    no shut

interface loopback 0
    ip address 172.16.2.1 255.255.255.0
    no shut

ip route 192.168.1.100 255.255.255.255 192.168.2.1

ROUTER 3

interface f0/0
    ip address 192.168.3.3 255.255.255.0
    duplex full
    speed 100
    no shut

interface loopback 0
    ip address 172.16.3.1 255.255.255.0
    no shut

ip route 192.168.1.100 255.255.255.255 192.168.3.1

ROUTER 4

interface f0/0
ip address 192.168.4.4 255.255.255.0
duplex full
speed 100
no shut

interface loopback 0
    ip address 172.16.4.1 255.255.255.0
    no shut

ip route 192.168.1.100 255.255.255.255 192.168.4.1

DMVPN CONFIGURATION

Once we have physical connectivity we can add the DMVPN configuration. The diagram below shows you the logical topology of our DMVPN network.
Note : Each tunnel is represented via the grey dotted lines.

HUB

interface Tunnel0
 ip address 10.1.1.1 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 tunnel source 192.168.1.100
 tunnel mode gre multipoint
 ip mtu 1416

ROUTER 2

interface Tunnel0
 ip address 10.1.1.2 255.255.255.0
 ip nhrp map 10.1.1.1 192.168.1.100
 ip nhrp map multicast 192.168.1.100
 ip nhrp network-id 1
 ip nhrp nhs 10.1.1.1
 tunnel source 192.168.2.2
 tunnel mode gre multipoint
 ip mtu 1416

ROUTER 3

interface Tunnel0
 ip address 10.1.1.3 255.255.255.0
 ip nhrp map 10.1.1.1 192.168.1.100
 ip nhrp map multicast 192.168.1.100
 ip nhrp network-id 1
 ip nhrp nhs 10.1.1.1
 tunnel source 192.168.3.3
 tunnel mode gre multipoint
 ip mtu 1416

ROUTER 4

interface Tunnel0
 ip address 10.1.1.4 255.255.255.0
 ip nhrp map 10.1.1.1 192.168.1.100
 ip nhrp map multicast 192.168.1.100
 ip nhrp network-id 1
 ip nhrp nhs 10.1.1.1
 tunnel source 192.168.4.4
 tunnel mode gre multipoint
 ip mtu 1416

IPSEC

Next we will need to add IPSEC, this will ensure that traffic is not sent in clear text. This configuration should be added to each router apart from router 1.

crypto isakmp policy 10
hash md5
encryption 3des
authentication pre-share

crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
crypto ipsec transform MINE esp-3des

crypto ipsec profile DMVPN
set transform-set MINE

interface tunnel0
tunnel protection ipsec  profile DMVPN

DYNAMIC ROUTING

To enable dynamic routing using EIGRP add the following configuration onto each of your routers excluding router 1.

interface tunnel0
    ip hold-time eigrp 1 35
    no ip next-hop-self eigrp 1
    no ip split-horizon eigrp 1

 router eigrp 1
     network 192.168.0.0
     network 172.16.0.0
     network 10.0.0.0
     no auto-summary

TESTING / DIAGNOSTICS

NHRP TUNNELS

HUB#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer Tunnel0, Type:Hub, NHRP Peers:2,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1     192.168.2.2        10.1.1.2    UP    never D
     1     192.168.3.3        10.1.1.3    UP    never D
     1     192.168.4.4        10.1.1.4    UP    never D

DYNAMIC TUNNELS

To test for dynamic tunnels between spokes run the following command:

R3#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 372/506/660 ms R3#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Spoke, NHRP Peers:2,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1   192.168.1.100        10.1.1.1    UP 00:15:48 S
     1     192.168.2.2        10.1.1.2    UP    never DX

EIGRP

HUB#sh ip route
! Gateway of last resort is not set
     172.16.0.0/24 is subnetted, 2 subnets
D    172.16.2.0 [90/297372416] via 10.1.1.2, 00:02:02, Tunnel0
D    172.16.3.0 [90/297372416] via 10.1.1.3, 00:00:42, Tunnel0     
D    172.16.4.0 [90/297372416] via 10.1.1.4, 00:00:42, Tunnel0 S    192.168.4.0/24 [1/0] via 192.168.1.1
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Tunnel0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
S    192.168.2.0/24 [1/0] via 192.168.1.1
S    192.168.3.0/24 [1/0] via 192.168.1.1

Start Server Manager via the Start Menu | Administrative Tools. Click on Roles (left navigation pane). Select Add Role in the Roles Summary pane to the right. Select the File Services role. Click Next. Select the Windows Search role service.

Link State Tracking

Link State Tracking is a feature (within Cisco Switches) that binds the link state of multiple interfaces. This provides the ability to "down" interfaces based upon the link state of upstream interfaces.
The diagram below shows a simple of example of an scenario where link state tracking would be required. As you can see from the diagram if interface e0/0 was to go down (on either switch) unless the corresponding e0/1 link state was also changed to down, the server would continue to send traffic via the switch that has the downed upstream link.

Commands

The command structure consists of 3 steps:

1. define a link state group
2. define upstream interfaces to the link state group
3. define downstream interfaces to the link state group

Define Link State Group

Switch(config)# link state track 1

Define Upstream

Switch(config)# interface range gigabitethernet 0/1
Switch(config-if)# link state group 1 upstream

Define Downstream

Switch(config-if)# interface range gigabitethernet 0/2-10
Switch(config-if)# link state group 1 downstream

Show Commands

show link state group 1
show link state group detail

IGMP

To Allow multicast traffic from 224.0.1.50 on the outside and traffic to go through the PIX to outside interface.

(config)#Access-list 109 permit udp any host 224.0.1.50

(config)#Interface Ethernet0

(config-if)#Igmp access-group 109

(config)#Interface ethernet1

(config-if)#Igmp forward interface outside

(config-if)#Igmp join-group 224.0.1.50

Multicast IP range

224.0.0.0 239.255.255.255

224.0.0.1 multicast broadcast

Protocol Independent Multicast Sparse Mode

Saves flooding the networks with multicast packets. Using a R Point.

Below Enables multicast routing.

Sets the address of the RP
Sets the priority of PIX interface to 5 (default 1)

(config)#multicast-routing

(config)#pim rp-address 172.16.10.1

(config)#interface ethernet1

(config-if)pim dr-priority 5

General show commands for multicast forwarding information database

Show mfib
Show mrib
Debug igmp
Debug mfib
Debug mrib

Cisco PIX - Routing

Static
To send all traffic to 192.168.0.1 out the outside interface.
To send any traffic in 10.0.1.0/24 to 10.0.0.1 out the inside interface

(config)#Route outside 0 0 192.168.0.1
(config)#Route inside 10.0.1.0 255.255.255.0 10.0.0.1

RIP
Allow RIP updates to be received on the outside interface with a key of cisco and id of 2.
Pass RIP updates out the inside interface

(config)#rip outside passive version 2 authentication md5 cisco 2
(config)#rip inside default

Allow RIP v2 passive on the the outside and dmz interface and Allow RIP v1 passive on the inside

(config)#rip outside passive version 2 authentication md5 cisco 2
(config)#rip inside passive
(config)#rip dmz passive version 2

OSPF

To configure OSPF with the standard 3 interfaces (inside,outside,DMZ)

(config)#router ospf 1
(config-router)#network 1.1.1.0 255.255.255.0 area 0
(config-router)network 172.16.0.0 255.255.0.0 area 172.16.0.0
(config-router)network 10.0.0.0 255.255.255.0 area 10.0.0.0

To filter LSA3 advertisments out from area 0 so that the internal network is denied but the DMZ is allowed.
(config-router)area 0 filter-list prefix testlist
(config)#prefix-list testlist deny 10.0.0.0/16
(config)#perfix-list testlist permit 172.16.0.0/16

PIX - Active-Active Configuration

To enable active-active 2 security contexts on both PIXs will need to be created. One context being active and one stand by.

Create a stateful link

hostname(config)#failover link if_name phy_if

hostname(config)#failover interface ip if_name ip_addr mask standby ip_addr

hostname(config)#interface phy_if

hostname(config-if)#no shutdown

Create Groups

hostname(config)#failover group 1

hostname(config-fover-group)#primary

hostname(config-fover-group)#exit

hostname(config)#failover group 2

hostname(config-fover-group)#secondary

hostname(config-fover-group)#exit

The admin context is always a member of failover group 1

hostname(config)#context context_name

hostname(config-context)#join-failover-group {1 | 2}

hostname(config-context)#exit

Enable on Primary device first

hostname(config)#failover

PIX - BGP Advanced Protocol Inspection

Summary

When passing BGP traffic through a PIX you will need to configure the PIX to disable random sequence numbers to prevent MD5 Digest mismatches on either router.

Please Note : Below presumes you all ready have a policy map defined with the name of global_policy and this has already been assigned to your device using the service-policy command.

Commands

access-list BGP-MD5-ACL permit tcp host [BGP ROUTER IP] host [BGP ROUTER IP] eq bgp

tcp-map BGP-MD5

tcp-options range 19 19 allow

class-map BGP-MD5-CLASSMAP

match access-list BGP-MD5-ACL

policy-map global_policy

class BGP-MD5-CLASSMAP

set connection random-sequence-number disable

set connection advanced-options BGP-MD5

PIX / ASA - Display Encrypted Pre-Shared Keys.

To allow you to view your preshared keys on your PIX ASA use the command `more system:running-config`.

You can also view the preshared password with some versions of ASDM. Below shows the example of the command.

pixfirewall# show run

!

tunnel-group mytunnel type ipsec-ra

pre-shared-key *

telnet timeout 5

Your preshared key .....

pixfirewall# more system:running-config

!

tunnel-group mytunnel type ipsec-ra

pre-shared-key MYPRESHAREDKEY

telnet timeout 5

How do I configure shared licensing on an ASA

A shared license lets you purchase a large number of SSL VPN sessions and share the sessions as needed amongst a group of security appliances by configuring one of the security appliances as a shared licensing server, and the rest as shared licensing participants.
Further information on shared licensing can be found here

Below shows the steps on how to configure a Shared License server.

1. Install Cisco license key, run the commands:

1.activation-key key

2.reload

2. Configure license server :

1.license-server enable interface (Inside interface)           

2.license-server secret   ‘your-password’

3.license-server port port  50554

4.license-server refresh-interval 100

5.wr mem

3.  Configure shared license ASA’s.

1.license-server address  X.X.X.X  secret [password] port 50554

2.wr mem

4.  Confirming shared license  - show shared license

01.hostname >  show shared license

02.Primary License Server : 10.3.32.20

03.Version              : 1

04.Status               : Inactive

05. 

06.Shared license utilization:

07.SSLVPN:

08.Total for network :     5000

09.Available         :     5000

10.Utilized          :        0

11.This device:

12.Platform limit    :      250

13.Current usage     :        0

14.High usage        :        0

15.Messages Tx/Rx/Error:

16.Registration    : 0 / 0 / 0

17.Get             : 0 / 0 / 0

18.Release         : 0 / 0 / 0

19.Transfer        : 0 / 0 / 0

ASA 8.3 - How to configure NAT

As you will have heard (and if not you will do soon) the new ASA 8.3 brings massive changes. The main change is the way in which the ASA handles NAT. Rather the configuring NAT at purley the interface level NAT is now configured within network objects.
That way in which is now configured is :

1. Create a network object.
2. Within this object define the Real IP/Network to be translated.
3. Also within this object you can use the the nat commands to specifiy whether the translation will be dynamic or static.

Examples

Configuring Dynamic NAT
The following example configures dynamic NAT that hides 192.168.2.0 network behind a range of outside addresses 2.2.2.1-2.2.2.10:

1.hostname(config)# object network my-range-obj

2.hostname(config-network-object)# range 2.2.2.1 2.2.2.10

3.hostname(config)# object network my-inside-net

4.hostname(config-network-object)# subnet 192.168.2.0 255.255.255.0

5.hostname(config-network-object)# nat (inside,outside) dynamic my-range-obj

Dynamic PAT (Hide NAT)
The following example configures dynamic PAT that hides the 192.168.2.0 network behind address 2.2.2.2:

1.hostname(config)# object network my-inside-net

2.hostname(config-network-object)# subnet 192.168.2.0 255.255.255.0

3.hostname(config-network-object)# nat (inside,outside) dynamic 2.2.2.2

The following example configures dynamic PAT that hides the 192.168.2.0 network behind the outside interface address:

1.hostname(config)# object network my-inside-net

2.hostname(config-network-object)# subnet 192.168.2.0 255.255.255.0

3.hostname(config-network-object)# nat (inside,outside) dynamic interface

Configuring Static NAT or Static NAT with Port Translation
The following example configures static NAT for the real host 1.1.1.1 on the inside to 2.2.2.2 on the outside with DNS rewrite enabled.

1.hostname(config)# object network my-host-obj1

2.hostname(config-network-object)# host 1.1.1.1

3.hostname(config-network-object)# nat (inside,outside) static 2.2.2.2 dns

The following example configures static NAT for the real host 1.1.1.1 on the inside to 2.2.2.2 on the outside using a mapped object.

1.hostname(config)# object network my-mapped-obj

2.hostname(config-network-object)# host 2.2.2.2

3.hostname(config-network-object)# object network my-host-obj1

4.hostname(config-network-object)# host 1.1.1.1

5.hostname(config-network-object)# nat (inside,outside) static my-mapped-obj

The following example configures static NAT with port translation for 1.1.1.1 at TCP port 21 to the outside interface at port 2121.

1.hostname(config)# object network my-ftp-server

2.hostname(config-network-object)# host 1.1.1.1

3.hostname(config-network-object)# nat (inside,outside) static interface service tcp 21 2121