...

Thursday, July 29, 2010

Misc 48

If you wish you use routing protocols on a Linux , you would need to install a routing software suite known as Quagga. Quagga supports OSPF (ospfd), OSPFv3 (ospf6d), RIP (ripd), RIPng (ripngd) and BGP (bgpd). All these run on a core daemon known as zebra (required to add static routes).
As evident from the routing protocols it supports, Quagga supports both IPv4 and IPv6 routing. These Daemons need to be run together with Zebra, which is used for specifying the interfaces, static routes and so on. Zebra is also essential for communicating with the routing daemons.

Right after we install Quagga, we'll need to specify the daemons that we want to run. These daemons can be specified by modifying:
nano /etc/quagga/daemons

In this example, I'm going to run OSPF. To do this, simply edit the configuration to reflect:
zebra=yes
bgpd=no
ospfd=yes
ripd=no
ripngd=no
isisd=no


Now, if you read a little up, there is a warning that says that you'll need to have a configuration file even if it's empty. Luckily for us, we have sample configuration files available for us. To find them, we simply type:
dpkg -L quagga | grep zebra.conf
dpkg -L quagga | grep ospfd.conf


Once we've got the paths, we'll need to copy them into the /etc/quagga/ folder:
cp /usr/share/doc/quagga/examples/zebra.conf.sample ./zebra.conf
cp /usr/share/doc/quagga/examples/ospfd.conf.sample ./ospfd.conf


At this point, we'll simply make a loopback interface on the Zebra so that we can see routes appear at the router side. To do this, modify zebra.conf and add:
interface lo
ip address 10.10.10.1/24


Now, we'll need to modify ospfd.conf. On my side, Quagga is sitting on 8.8.8.2, the router is in 8.8.8.3. The router has a loopback of 9.9.9.1 and Quagga has a loopback of 10.10.10.1. We'll now configure ospfd.conf to reflect routes:
router ospf
network 8.8.8.0/24 area 0
network 10.10.10.0/24 area 0


Back on the router, here's the configuration we have:
in f0/0
ip add 8.8.8.3 255.255.255.0
in lo0
ip add 9.9.9.1 255.255.255.0
router ospf 1
network 8.8.8.3 0.0.0.0 area 0
network 9.9.9.1 0.0.0.0 area 0


Now we'll restart all the daemons through:
/etc/init.d/quagga restart

If it all goes well, "show ip ospf nei" should show up as:
Neighbor ID     Pri   State           Dead Time   Address         Interface
8.8.8.2         1     FULL/BDR        00:00:34    8.8.8.2         FastEthernet0/0


Now to check the routes on Linux, you can either use the kernel command:
route -n

Another method is to go directly into the daemon's interactive context which is similar to IOS in many ways. To do this, we'll need to telnet to the localhost. The ports we'll be using are:
2601 - zebra
2602 - ripd
2603 - ripng
2604 - ospfd
2605 - bgpd
2606 - ospf6d

If you're in zebra, you can simply type:
show ip route

If you're on ospfd, you can use:
show ip ospf routes

The passwords are those stored in zebra.conf and ospfd.conf. It is "zebra" by default. Now you can try pinging and it should all go well!

Misc 47

Now, if you've been following the previous articles, you would know that enrolling a certificate manually by copying and pasting requests is a chore. There is actually a simpler way to do this.
Introducing Microsoft's Network Device Enrollment Service, Microsoft's implementation of SCEP (Simple Certificate Enrollment Protocol) which they call MSCEP. This allows network devices, such as routers, to conveniently enroll for a certificate without needing to copy the entire certificate request over.

The NDES service can either be installed on a CA, or on a separate W2K8 machine. If you wish to get a certificate for SSL such as for WebVPN, then the Certificate Authority in this case must be a Standalone one. For some reason I was not able to enroll a Web Server certificate no matter what "usage" commands I used, the only certificate that the server sends during enrollment for an Enterprise CA is the IPSec Intermediate Offline certificate template, which is not usable as a SSL certificate.

Now, I'll assume that you know how to set up a Standalone CA. I have these roles installed, but you only need Certification Authority and the Network Device Enrollment Service:


During the installation, you can specify to use a user account to authorize the certificate. Before we can use that user account for this purpose, we'll need to add him/her to the IIS_IUSRS group. In this example, I'm going to add my Administrator account into that group. To do this, we'll open up MMC and add the Local Groups and Users snap-in:


Now you can add Administrator into IIS_IUSRS group:


Now you can complete the NDES installation. We'll now hop onto a Router to enroll the certificate. To do this, we'll first make sure that the device is server is reachable from your device, then configure a trustpoint like this:
crypto key gen rsa gen export label RSAKEYPAIR
crypto pki trust TRUSTPOINT
enroll url http://8.8.8.2/certsrv/mscep/mscep.dll
subject CN=8.8.8.3
rsakeypair RSAKEYPAIR


In this case, 8.8.8.2 is my CA/NDES and 8.8.8.3 is my router. Now we'll need to make sure that the router's clock is accurate (this is used for checking certificate validity):
conf t
clock time SGT +8
exit
clock set 11:03:00 July 29 2010


Now we'll add the CA certificate into the router:
crypto pki authenticate TRUSTPOINT

If it's all successful, you'll be asked to accept the certificate. Finally, we'll enroll the router's certificate through:
crypto pki enroll TRUSTPOINT

Now you'll get a message asking for a security code. This code can be obtained by visiting the mscep_admin page locally from the CA through:
http://localhost/certsrv/mscep_admin/



Now simply paste the code into your terminal twice and your certificate should enroll successfully! In some cases, you may need to manually issue the certificate. To do this, browse over to your Certification Authority console and down to Pending Certificates. Right-click on your certificate and click All Tasks - Issue:


You would have to wait for some time before the certificate reaches your router. When it does come in, this is the message you'll see:
Jul 29 03:17:49.271: %PKI-6-CERTRET: Certificate received from Certificate Authority

Tuesday, July 27, 2010

Misc 46

Now this would actually be a pretty quick one. We'll build on the knowledge gained in this article to set up the WRT54G router, then we'll install a client on Windows separately.
Now before we go any further, I'll need you to flash your router to the TomatoVPN firmware. This will add OpenVPN capabilities into your router allowing it to act as a VPN terminator. TomatoVPN can be obtained here.

Note that you should be responsible for your own router and I will not be held liable for any damage resulting from anything. Now I had to say that to give myself some immunity.

Once you've got connectivity back up, it's time to hop on to your router. Browse on over to VPN Tunneling - Server:


This is the page where we set the basic parameters. If you feel that these settings are familiar, in fact they are! Those are the same settings found in the server.conf file. I changed my subnet address to 192.168.2.0/24 but it may not work for you depending on the addressing scheme used at your remote location. Now notice that if you attempt to click on Start Now, it will not work. This is because we still need to set the CA certificate, Server keypair, and the DH parameters. Now this is all coming together isn't it?

Now browse on over to the second page:


Notice that I included to push the route to the client. This is so that the clients can access each other. Finally we find ourselves at the Keys page. Is this going to be a nightmare? At first, it may seem so. But when you look again, you'll realize that you already have all the components. Hop on over to your Linux router and open the ca.crt with Notepad. We now PASTE the exact contents over. Do the same for your server keypair and the DH parameters:


Now that you have everything in place, simply save, then click on Start Now and you are done with the server part! Now it's time to set up the Windows side of things. For this, I'm going to grab a copy of openvpn-2.1.1-install.exe from the official OpenVPN website.

When it prompts to install a TAP/TUN driver, let it do so. This is the interface that will support the tunnel later on. Once installation is done, it's time to set up everything. First, copy the ca.crt and your client keypair to:
C:\Program Files\OpenVPN\config\


If you're on a x64 system, you may have to go to:
C:\Program Files (x86)\OpenVPN\config\


Now, go back one folder and move into the sample-config folder. Make a copy of client.ovpn and paste it into the config folder. Double-click on it, and guess what? It's exactly the same as client.conf in Linux! Now, simply edit it the same way as you would in this article and save the file.

To start the VPN client, simply open OpenVPN GUI and look at your System Tray for the logo. Right-click on it and click on Connect! Test your ping connectivity and it should be fine and dandy!

Now, if you wish to automatically connect to the router every time you boot up, simply go to Start - Run - Services.msc and set OpenVPN service to start up automatically!

Misc 45

Now that we have a PKI set up, it's time to put it to good use. The most confusing thing about a Cisco router running HTTPS (such as one hosting WebVPN) is how it should obtain its certificate from a real CA. Now I'm going to show you the simplest way of obtaining a certificate (simplest in terms of technology, not necessary in terms of procedure).
First of we should have a CA set up in Linux, if not, you can refer to this article.

Now back on the router we want to run WebVPN on. What we want to do now is to create a trustpoint that we can enroll our certificates with. A trustpoint represents a CA, and the method we enroll our certificate is specified in there. But before we do that, we'll need to generate a keypair, which every RSA certificate needs:
crypto key gen rsa exportable label RSAKEYPAIR

Now that we have our RSA keypair, we can now create the trustpoint:
crypto pki trustpoint CA
rsakeypair RSAKEYPAIR


Now we'll specify our enrollment method, which is copying and pasting through the terminal. Now that's really low-tech. To do this, we'll specify:
enrollment terminal pem

Finally we'll specify the common name of the host. This common name needs to be the exact FQDN of the host. If the host does not have a domain name associated with it, you will need to specify the exact IP address it is going to use:
subject CN=1.1.1.2

Now you can actually specify a longer subject String with OU and all the extra stuff, but this will suffice for a very basic certificate. Now it's time to enroll the certificate:
crypto pki enroll CA

It will ask you if you want to display it on the terminal. Select YES and you should have something similar to this on your screen:
-----BEGIN CERTIFICATE REQUEST-----
MIIBOjCB5QIBADBfMRAwDgYDVQQDEwcxLjEuMS4yMUswEgYDVQQFEwtYWFhYWFhY
WFhYWDAUBgkqhkiG9w0BCQgTBzEuMS4xLjIwHwYJKoZIhvcNAQkCFhJSMi5zeXJh
eGl1cy5hdGguY3gwXDANBgkqhkiG9w0BAQEFAANLADBIAkEA8wJEMyVp/C84Y9br
jSA9DK0Bml8ya1xi6JNygxGPqsVC17AWVKHSAzFOUTnLj6E5OGsTq0Ud5mZ/ZkUf
V4E+QwIDAQABoCEwHwYJKoZIhvcNAQkOMRIwEDAOBgNVHQ8BAf8EBAMCBaAwDQYJ
KoZIhvcNAQEEBQADQQAe6gABr8oUtRftvxpYwHWEeCArCMhfWxO/XQDNzyFqP6xk
16bNLzJnF4021L9YS1eyrQnzUtAXj4qr8l/b1XwJ
-----END CERTIFICATE REQUEST-----


Now what you do with this information is that you need to copy the entire page from ----BEGIN CERTIFICATE REQUEST----- to -----END CERTIFICATE REQUEST----- and paste it into a file. What should you name the file? We'll, you've guessed it, you'll name it newreq.pem and place it into the /etc/ssl/ folder of your CA. Then we'll run the signature command with CA.pl. If you don't know what I'm talking about, you'll again need to refer to this article.

Now you should end up with a newcert.pem. Before we import the certificate, we'll need to import the certificate authority's root certificate. Why do we need to do that? This is because you don't have a button that says "Add Exception" in a Router, so you'll either have to have a CA certificate that you trust, or it's all not going to work at all.

Be sure that the system clock is set correctly! This is crucial as the certificates will be checked for both time and date to see if it's valid. To do this, we'll type:
conf t
clock timezone SGT +8
exit
clock set 19:11:00 July 27 2010


So we'll begin by invoking the command to allow importing of the root CA:
crypto pki authen CA

Next, we'll paste the contents of cacert.pem from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- into the prompt. In case you're wondering, cacert.pem is actually found in /etc/ssl/demoCA/.

Now it's finally time to import your certificate. We do it the same way as we import the CA certificate, except that we'll use the command:
crypto pki import CA certificate

Now that you have a certificate, we'll set up our WebVPN but this time with the trust point set to the trustpoint which you imported your certificate into. If you want to set up WebVPN, you can follow along this article.

In the future I'll go into topics like using automatic enrollment and so on, so stay tuned! Before I go into those, it's time to set up OpenVPN on a WRT54G and connect using a Windows host!

Misc 44

Today I'm going to talk about setting up a Certificate Authority in Linux. I'm going to skim on the in-depth theory and instead show more of the practical side of things. First of all, to be a certificate authority, you'll need to install OpenSSL in your system. To do this, we'll install this package on a Debian system:apt-get install openssl

Now that you have the OpenSSL packages, you are ready to generate certificates. To do this, we'll need to go through these steps:
1) Create Root Certificate
2) Create Certificate Request
3) Enroll/Sign Certificate

First of all, to be a Certificate Authority, you'll need something that represents you. This comes in the form of a Root Certificate. Think of certification as a hierarchy, and this Root Certificate sits on top of the certificate chain. A root certificate comes in a pair, with a public and private key. Certificates signed by the Root's key (Private Key) can be verified by decrypting it with the Root's public key (Public Key). The "signing" action actually means encryption with a private key. To create this keypair, we'll first browse over to the SSL directory, then invoke the CA.pl script:
cd /etc/ssl/
/usr/lib/ssl/misc/CA.pl -newca


When prompted, hit ENTER to create a new Root Certificate. The private key would be stored as /etc/ssl/demoCA/cacert.pem and the public key would be stored as /etc/ssl/demoCA/private/cakey.pem. At this point, your system is considered a Certificate Authority!

Now, to create certificates for others, we'll need to create a certificate request, then sign the request using the Root Certificate's private key and package it into X.509 format. This can be done in two steps. First we'll need to create the certificate request. This request generates a public and a private key:
/usr/lib/ssl/misc/CA.pl -newreq

Note that if you're creating a certificate for a Web Server, the Common Name should be either the Web Server's FQDN or IP Address (depending on how you access it). You should have a newreq.pem in the /etc/ssl/ folder. This newreq.pem actually contains your credentials signed with your private key and an attached public key. To view the information in your request, use:
openssl req -in newreq.pem -noout -text

Now, to make this certificate valid, you must turn it into a real X.509 certificate. To do this, we'll need to sign it with the CA's private key. This is the command for it:
/usr/lib/ssl/misc/CA.pl -signCA

Now you should have three files: newreq.pem, newcert.pem and newkey.pem. Your new X.509 formatted certificate signed by the CA is in newcert.pem, and the corresponding private key is in newkey.pem. You can safely delete newreq.pem. To view the X509 certificate, use:
openssl x509 -in newcert.pem -noout -text

You can now use this key in Web Servers or any application you like. To use the certificate generated here in APache2, simply follow along this article.

Now, if you attempt to access the site, you may get a message that says that the certificate is not valid. These are the two most common reasons for that message:
1) The security certificate presented by this website was issued for a different website's address.
2) The certificate is not trusted because the issuer certificate is unknown.

If your CN doesn't match the URL of the Web Server, you will need to regenerate a new certificate. The CN MUST match the IP or domain name of the server (e.g. If you're accessing it through 8.8.8.130, then the CN must be 8.8.8.130. If you are accessing it through syraxius.ath.cx, then the CN must be syraxius.ath.cx).

For the certificate to be trusted, you'll need to add it into the Trusted Root Certification Authorities store. To add the certificate to the store, simply download /etc/ssl/demoCA/cacert.pem into your computer, then rename it to .crt extension. Next, double-click on it and choose Install Certificate:


Next, you'll need to place it in the Trusted Root Certification Authorities container like this:


You should now be able to access your Web Server from Internet Explorer. For Firefox, you'll need to add the same certificate through Tools - Options - Advanced - Encryption - View Certificates - Authorities - Import:

Saturday, July 24, 2010

Misc 43

OpenVPN is an open-source VPN solution using the OpenSSL library. It supports site-to-site and remote-access connections in bridged (TAP) or routed (TUN) mode. Since it is TLS-based, it can traverse NAT very well.
Authentication is done through certificates, pre-shared keys as well as username and password. In this document, I'm going to describe the simple setting up of a certificate authority in Debian using scripts provided by OpenVPN.

Once we get on our Debian machine, we'll begin by first installing OpenVPN:
apt-get install openvpn

Now that we have OpenVPN in place, we'll have to copy some files. First, we'll browse to the folder where we'll store our files. In this article, I'll store them in the OpenVPN folder:
cd /etc/openvpn/
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ ./easy-rsa/
cp -r /usr/share/doc/openvpn/examples/sample-config-files/ ./


What we did above is to copy the easy-rsa scripts (used for generating the CA as well as keys used by the CA) and sample configuration files which we will need to modify to suit our scenario. Now let's browse into the easy-rsa folder to begin generating the keys:
cd easy-rsa

The first thing we want to do is to clean the configuration. Before we can do that, we'll need to load up some variables to let the scripts know where we are at (this needs to be done every time you restart your system before you can generate new certificates):
source ./var

Now, it's time to clean out the folders using the clean-all script:
./clean-all

Now that we're on ground zero, we'll begin by initializing the Certificate Authority:
./build-ca

After we've filled in the information (can be anything), we can begin building keys for our server or the clients. Let's begin by generating a server keypair:
./build-key-server server

You would now have a server certificate and key file in the ./keys folder. We'll deal with those keys later on in this article. Now let's create a client keypair:
./build-key client

Notice that every time you generate a key, there is a message that says "Data Base Updated". This database is actually the ./vars file. As you recall, you'll need to reload this database before you can enroll and sign certificates after you restart your computer.

Now you have a certificate for your server as well as the client. The final thing we need to do is to generate some Diffie-Hellman parameters (this is used by the server):
./build-dh

Now that we have all our files ready, let's take a look in the ./keys folder. You should have these files:
ca.crt
ca.key
client.crt
client.key
server.crt
server.key


These are the important files you need. Let's begin by doing configuration for the server file. Browse on to the sample-config-files folder:
cd /etc/openvpn/sample-config-files/

You'll notice a file called "server.conf.gz". Before we can modify this file, we'll need to unpack it. To do this, we'll need to type:
gunzip server.conf.gz

You should have a server.conf file now. We'll need to open it up:
nano server.conf

There are four things we need to modify: CA, Server Certificate, Server Key, and Diffie-Hellman Parameters. To do this, scroll down till you see these lines and modify as follows:
ca /etc/openvpn/easy-rsa/keys/ca.crt
server /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem


Instead of the absolute path, you can try using "../easy-rsa/keys/". Now you can start your server using:
openvpn server.conf

If it's all successful, you should see "Initialization Sequence Completed" at the bottom. To instead run the server as a daemon, use:
openvpn --daemon --config server.conf

I won't recommend running it as a daemon until you've verified it to be working. We can configure a client now. To do this, we'll be using the client.conf file found in the same folder. Make changes as shown (I'm pointing it to my server address at 192.168.1.2, you can connect to yourself to test your configuration):
remote 192.168.1.2
ca /etc/openvpn/easy-rsa/keys/ca.crt
server /etc/openvpn/easy-rsa/keys/client.crt
key /etc/openvpn/easy-rsa/keys/client.key


Now you can start the client using:
openvpn client.conf

You should again see "Initialization Sequence Completed" when you connect successfully.

Likewise, you can run OpenVPN client as a daemon using:
openvpn --daemon --config client.conf

When running as daemon, you can see your tunnel interfaces using:
ifconfig

For others to connect remotely, generate a client keypair for them and perform the same steps for client configuration at the remote end.

Congratulations! You've set up a VPN service in Linux! In the next article, I'll show you how to set up OpenVPN in a Linksys router flashed with TomatoVPN, and how to connect to either a Linux or the Linksys router VPN server from the Windows version of OpenVPN.

Friday, July 23, 2010

CCNA Security 34

In a stateless hardware failover model, all existing connections maintained by the primary appliance are dropped. The stateful information is lost. During this downtime, most applications would encounter some form of downtime as the new Active ASA recreates the state table. To fix this, you'll need to enable ASA's stateful failover feature. During a stateful failover, all state tables are moved over to the new Active appliance.
To use stateful failover, you would need to configure a link for the link information, and another link for the state information. The two links configured here can be the same link if there is enough bandwidth!

There are two types of standby mode:
-Active/Standby - The primary device is actively serving connections, while the secondary device stays in a hot standby (passive) mode. When the Active device goes down, the Secondary standby appliance will assume the failover IP address.
Active/Active - There is still a single primary ASA device, but it's only available in Multiple Context Mode. One context from each ASA is the primary for each standby group.

For stateful failover to work, the platform type, platform upgrades and the platform version must match! There are also two failover mechanisms performed by an ASA:
-LAN-Based Failover - A link between the two devices is required to share link information. The messages sent has a PID of 105.
-Stateful Failover - A link between the two device is required to share the stateful information.

The two devices can be connected via a switch or a straight/crossover cable.

Devices configured for failover will constantly monitor the interfaces (up to 250) through link up/down tests, activity tests, ARP cache verifications, broadcast ping test, and so on.

I will now configure failover with the following topology. I'll begin with Active/Standby first:


The top network is 1.1.1.0/24 and the bottom network is 2.2.2.0/24. First of all, we'll configure the interface IP addresses for the failover on Primary:
in e0
nameif OUTSIDE
ip add 1.1.1.1 255.255.255.0 standby 1.1.1.2
no shut
in e1
nameif INSIDE
ip add 2.2.2.1 255.255.255.0 standby 2.2.2.2
no shut
in e2
no shut
exit
failover
failover lan unit primary
failover lan interface FAILOVER Ethernet2
failover lan enable
failover interface ip FAILOVER 3.3.3.1 255.255.255.0 standby 3.3.3.2


Then we configure Secondary ASA as follows:
in e2
no shut
exit
failover
failover lan unit secondary
failover lan interface FAILOVER Ethernet2
failover lan enable
failover interface ip FAILOVER 3.3.3.1 255.255.255.0 standby 3.3.3.2


Notice that I did not configure an IP address for the interfaces on the secondary unit. This is because once the secondary unit detects the primary, the configuration will be automatically passed over. The message you will see is:
ASAPrimary# Beginning configuration replication: Sending to mate.
ASASecondary# Beginning configuration replication from mate.
ASAPrimary# End Configuration Replication to mate
ASAPrimary# End configuration replication from mate.


Notice that even the hostnames went across! Right now on the Secondary unit, a "show int ip br" will look like this:
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0                  1.1.1.2         YES CONFIG up                    up
Ethernet1                  2.2.2.2         YES CONFIG up                    up
Ethernet2                  3.3.3.2         YES unset  up                    up
Ethernet3                  unassigned      YES unset  administratively down up
Ethernet4                  unassigned      YES unset  administratively down up


Pull the plug on ASAPrimary and check "show int ip br" again and this is what you'll end up with:
ASAPrimary# Switching to Active
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0                  1.1.1.1         YES CONFIG up                    up
Ethernet1                  2.2.2.1         YES CONFIG up                    up
Ethernet2                  3.3.3.2         YES unset  up                    up
Ethernet3                  unassigned      YES unset  administratively down up
Ethernet4                  unassigned      YES unset  administratively down up


Remember the stateful information that's supposed to go across? Well, this is how we'll configure in on the primary appliance:
failover link FAILOVER e2

Now set up a telnet session through, cause a failure, and watch as your telnet session survives!

Thursday, July 22, 2010

CCNA Security 33

When it comes to virtualization in an ASA, we have a phenomenon known as Security Contexts. The reason why we use Security Contexts is that it allows us to split a single ASA firewall into multiple virtual firewalls. This does not mean that every interface needs to belong to only one Security Context. An interface can be partitioned to support multiple Security Contexts. This is only true if you're using Routed mode. L2 firewalls require unique interfaces for each context.
When you enable multi-context mode, you automatically have an Administrator context. Users logged into the Administrator context can make changes to the system and can also have access to all other contexts.

Context information is stored in a database file in flash. The ASA has a base startup-configuration stored in flash, and each context has a separate configuration file which can reside in the flash or be downloaded during start-up from a remote system. The context configuration files have the extension of .cfg.

Now the question is that, as packets come into the ASA, how does the device actually know what context the packet belongs to? Now, this brings us into the topic of Packet Classification.

Each context has a separate IP address and a unique MAC address. Every packet that comes inbound to the ASA must be classified by something unique. This attribute can come in the form of a MAC address, Destination IP address, or almost any attribute that can be extracted from a packet. The most common attribute used in routed mode is the MAC address and is the Cisco recommended method. Here's how we visualize this:


Once the ASA is converted into multi-context mode, two files are saved in flash:
Admin.cfg
old_running.cfg


The Admin.cfg will be responsible for saving Admin context configuration, and old_running will be taken from the current running-config. The Administrator context does not have any traffic-passing interfaces. The Administrator context is mainly used to fetch configurations for other contexts, change system configurations and create new contexts. We can even turn regular contexts into the Administrator Context (you can only have one at one time).

To switch to multi-context mode, you need to type:
mode multiple

Now we'll create two new context using:
context ONE
allocate-interface e0 OUTSIDEONE
allocate-interface e1 INSIDEONE
config-url ONE.cfg
context TWO
allocate-interface e0 OUTSIDETWO
allocate-interface e1 INSIDETWO
config-url TWO.cfg


You can actually configure each context by going into them using:
changeto context ONE
conf t
in OUTSIDEONE
nameif OUTSIDE
sec 0
ip add 1.1.1.10 255.255.255.0
mac 0000.0000.1111
in INSIDEONE
nameif INSIDE
sec 100
ip add 2.2.2.10 255.255.255.0
mac 0000.0000.1112


Configuration for TWO would then be:
changeto context TWO
conf t
in OUTSIDETWO
nameif OUTSIDE
sec 0
ip add 1.1.1.11 255.255.255.0
mac 0000.0000.2221
in INSIDETWO
nameif INSIDE
sec 100
ip add 2.2.2.11 255.255.255.0
mac 0000.0000.2222


What I've done above is to allow a basic feel of the contexts system. This is not configured into a truly practical system. Its true application will be discussed in a different article in the future.

CCNA Security 32

Setting up a normal ASA solution requires proper design of the network infrastructure. It would be difficult if your normal ASA firewall solution is to be installed into a mature network infrastructure.
To easily add a firewall into an existing network without changing any of its infrastructure, we will need to implement something called TFM. TFM stands for Transparent Firewall Mode. By default, the router runs in Routed Mode, so each interface needs to be a different subnet. You can push ASA into a layer 2 configuration by starting TFM. In TFM mode, the ASA can be seen as a bridge.

The only IP address we will need to add is the management interface of the ASA. The downside of TFM is that it only supports 2 data interfaces. Traffic is now switched by MAC, and Ethertype traffic is permitted.

A management IP address is required and it must be on the same subnet. The two interfaces can only pass traffic. Both connected networks must be in the same subnet and there should be a proper default gateway configured.

If you use TFM, you cannot use DDNS, Routing Protocols (these protocols can traverse the ASA, it's just that the ASA cannot use a protocol), DHCP Relay, QoS, Multicast and VPN Termination. ASA only supports NAT in transparent mode. You however cannot use PAT.

To check the firewall mode, we can use this command in EXEC mode:
show firewall

To change the firewall mode, we'll use the command:
firewall transparent

This will actually WIPE OUT all your current configurations! Now, we'll begin by configuring the interface like we typically do:
in e0
nameif OUTSIDE
sec 0
in e1
nameif INSIDE
sec 100


Now we'll configure the management IP address. This is done at the global configuration prompt:
ip address 1.1.1.1 255.255.255.0

To add a default-gateway, we'll type:
route OUTSIDE 0 0 1.1.1.2

At this point we'll use a topology that looks like this to demonstrate the firewall operation:


The User has an IP of 1.1.1.3 and the Router has an IP of 1.1.1.2. By the time you typed the above commands, the User would be able to telnet into the router but not the other way round. This is very similar to normal ASA functionality except that it's done in L2.

ASA has a feature to perform ARP inspection. ARP inspection makes sure that there are no IP to ARP to source interface mismatch. To turn on ARP Inspection, we'll type:
arp-inspection INSIDE enable no-flood
arp-inspection OUTSIDE enable no-flood


Note that the ASA being transparent doesn't mean that it cannot look further than that. It can actually still filter packets as usual! We'll demonstrate this by allowing the Router to telnet back to the User. To do this, we'll type:
access-l PERMITTELNET ext permit tcp host 1.1.1.2 host 1.1.1.3 eq 23
access-g PERMITTELNET in int OUTSIDE


Similarly, you can configure an ACL for non-IP traffic by configuring an EtherType access list using:
access-list PERMITMPLSUNICAST permit mpls-unicast

CCNA Security 31

Cisco ASA SSL VPN is designed to allow quick access to clients. There are two types of SSL VPN, which are WebVPN and Anyconnect. WebVPN is known as a clientless SSL VPN, and is similar in operation to a web proxy. Anyconnect, on the other hand, requires a client and provides the features of a full fledged VPN over TLS. In this article, I'm going to go through both the clientless and the client version of SSL VPN.
WebVPN requires a supported browser (almost any SSL/TLS-supporting browsers), with nothing else to configure. WebVPN is typically best for accessing application servers. Like a web-proxy, it provides no direct connection to the actual resources.

Anyconnect VPN on the other hand, supports both WebVPN and Full-tunnel access. It is initiated via browser and supports a lot of access options. It offers varied application support and uses a WebVPN gateway.

Most people still prefer IPSec VPNs as it a more established technology and is excellent for company-owned systems. It is initiated using VPN Client Software and provides Full Tunnel Access.

To set up the WebVPN, we need to set up a WebVPN gateway. Before we can set up one, we'll need to create a trustpoint. In this article, I'll use a self-signed certificate. Before we can generate a self-signed certificate, we'll need to generate an RSA keypair, so we'll begin by typing:
crypto key gen rsa

Now that we have a keypair, we can enroll a self-signed trustpoint through:
crypto ca trust LOCAL
enroll self
crypto ca enroll LOCAL


We'll need to then enable the WebVPN gateway through:
webvpn
enable OUTSIDE


At this point, clientless WebVPN would be working. Of course, if you haven't done so, you'll need to create a local user account:
user cisco pass cisco

I'll begin setting up the Anyconnect. It is simpler to set up than an IPSec Remote Access solution.

First we'll have to enable SVC (SSL VPN Client):
webvpn
svc image disk0:/anyconnect-win-2.4.1012-k9.pkg
svc enable
tunnel-group-list enable


For SVC to work, your device must be loaded with an image. This image is available in disk0 by default so you would just have to specify it. The "tunnel-group-list enable" command is to enable the client to have a list of tunnel-groups to join upon connection to the ASA. The tunnel-group list looks like this:


We'll have to create a group-policy (This is optional as if no group-policy is applied to a tunnel-group, all protocols are enabled). We'll type:
group-policy ACPOLICY internal
group-policy ACPOLICY attributes
vpn-tunnel-protocol svc


Next, we'll simply create a pool, a tunnel-group and assign the group-policy to it (this is only applicable if you created a group policy above):
ip local pool ACPOOL 6.6.6.10-6.6.6.254 mask 255.255.255.0
tunnel-group ACGROUP type remote-access
tunnel-group ACGROUP general-attributes
address-pool ACPOOL
default-group-policy ACPOLICY
tunnel-group ACGROUP webvpn-attributes
group-alias AC enable
group-url https://1.1.1.1/AC enable


Now you can verify your configuration through:
show webvpn csd
show webvpn group-alias
show webvpn group-url


This is basically what you need to type to set up the ASA to allow Anyconnect connections! Do note that WebVPN is only supported on ASA firewalls! PIX does not support WebVPN even if they are using the same platform version!

CCNA Security 30

Why do we need Advanced Protocol Inspection? Some applications are able to dynamically negotiate source and destination ports, and some may even tunnel through known protocols by wrapping data through protocols like HTTP. We need to be able to inspect packets for signs of misuse. This is done through Advanced Protocol Inspection.
An example of a protocol which dynamically negotiates ports is FTP. Let's begin the introduction of Advanced Protocol Inspection with a scenario:


Now, let's begin by describing how FTP works in Active mode. In Active mode, the client first connects from a random port from the INSIDE interface of the ASA to the OUTSIDE interface towards port 21 of the FTP Server. Port 21 is the control port of the FTP server. At this point, the ASA would have statefully inspected the connection and permitted the return traffic.

For a file transfer to occur, the client must notify the server to send the file back. The file transfer is sent back from port 20 which is the data channel. This data is then seen by the firewall as a new connection inbound so it is denied. Active mode would not be very practical to be used without Advanced Protocol Inspection as the client-sided ports are always dynamic.

Advanced Protocol Inspection allows the ASA to inspect the control channel of the FTP for information about the data port. Once it has learnt about the data port, it will temporarily open that port for the duration of the FTP session.

Advanced Protocol Inspection can also inspect viruses and worms and effectively block them out of operation. We will now begin implementation of strict FTP inspection. To do this in ASDM, we'll need to go to Configure - Firewall - Service Policy Rules. When creating a service policy, we can turn on Protocol Inspection for FTP. Clicking Configure allows us to ensure strict adherence to FTP standards.

FTP is one of the services we can perform Advanced Protocol Inspection for. Other protocols like those used by instant messaging applications can also be inspected to ensure viruses don't spread.

There are various ways Advanced Protocol Inspection can hinder attackers. For example, ESMTP protocol inspection allows blockage of extended commands and force the command-set to the 7 RFC standard commands.

DNS Doctoring or DNS Rewriting allows the ASA to modify the packets exchanged between the DNS and the client. DNS Rewriting is designed to resolve problems where the client resides in the a private network with another server it is trying to access, while the DNS is actually outside in the public network. In this case, when the client tries to resolve the URL of the web server, it will get a public IP which may cause problems. What DNS rewriting does is that the ASA actually intercepts the reply from the DNS, rewrite the external IP to the correct internal IP, then forward it to the host. If the internal host tried to access the public address instead, the packet would be dropped by the ASA because it does not allow redirection of packets on the same interface.

To turn on DNS doctoring, we would need to tweak the NAT configuration of the ASA. To do this, let us first refer to an example static NAT entry used by the appliance:
static (DMZ,OUTSIDE) interface 2.2.2.2 netmask 255.255.255.255

To inform the ASA to intercept DNS replies relating to this static NAT, we'll need to add the DNS keyword like this:
static (DMZ,OUTSIDE) interface 2.2.2.2 netmask 255.255.255.255 dns

ASA can also detect and handle scanners like port scanners and sweepers. These tools are becoming harder and harder to detect, with the advent of stealth modes and other techniques. ASA supports three different types of threat detection:
1) Basic - Monitors the rate of dropped packets due to denial by access list, bad packet format, connection limit exceeded, DoS attacks, suspicious ICMP packets, and so on. To enable basic threat detection, we'll type:
threat-detection basic-threat

2) Scanning - Able to detect sweeps and scanners. This is different from an IPS detection as it does not match by signatures, but by a database of statistics gathered. When hosts are identified as attackers, they can be shun for a duration. By default, they are shun for 1 hour. To enable scanning threat detection, we'll use:
threat-detection scanning-threat shun duration 86400

3) Threat Statistics - Able to determine the host, protocol and port statistics. This is designed to collect extensive statistics. To enable, we can type:
threat-detection statistics

Default configuration are hidden from view. To view default configurations, we'll need to type:
show run all

To view threat-detection statistics, we can use the show command:
threat-detection statistics

By default, basic and statistics threat-detection is enabled. Scanning threat detection is not enabled by default.

CCNA Security 29

The Cisco Modular Policy Framework allows configuration of firewall, and a lot of other services like QoS, through a simple language. The Modular Policy Framework uses a subset of the commands found in MQC (Modular QoS CLI). The MPF consists of three components:1) Class-Maps - Classifies traffic by protocol, ACLs, etc.
2) Policy-Maps - Specifies action to take when class-map is matched (Pass, Drop, Inspect, IPS, Police, Shape, etc).
3) Service-Policy - Maps a policy-map to an interface and direction.

The order specified above is the order we create the components in the CLI. However, for the ASDM, we'll do it the other way round.

Classes are good because they can be reused over and over for policies. This makes things modular. For example, we can group all web traffic into a single class-map, then apply it to multiple policy-maps.

There are many ways a class-map can match traffic. These are ACLs, Default-Inspection-Traffic, DSCP, Flow, Ports, Precedence, RTP Ports, VPN Tunnel-Group.

In this example, I'm going to create a class-map to match INTERNET traffic. First, we'll create the object-group for the webservers:
!Create WEBSERVERS group
object-group network WEBSERVERS
network-object host 2.2.2.2
network-object host 2.2.2.3


Next, I'm going to group all related traffic types:
!Create WEBTRAFFIC group
object-group service WEBTRAFFIC tcp
port-object eq 80
port-object eq 443


We'll bring the groups together using an ACL:
!Create ACL
access-list AINTERNET extended permit tcp any object-group WEBSERVERS object-group WEBTRAFFIC


Then we'll apply the ACL to the class-map:
!Create Class-Map
class-map type CINTERNET
match access-list AINTERNET


Finally, we'll define the actions to take using the policy-map:
!Create Policy-Map
policy-map PINTERNET
class-map CINTERNET
ips


Finally we'll active the service-policy by associating it to the interface:
!Apply to interface using Service-Policy
service-policy IPSINTERNETOUTSIDE interface OUTSIDE


Note that the "ips" command is only available if your ASA supports IPS. You can use multiple class-maps in a single policy-map, but the action assigned to the first match will be applied. After implementing, you can

The way ASA processes the policies is in an order. This is:
1) TCP Processing
2) CSC/AIP-SSM
3) Application Inspection
4) IPS
5) QoS Input Policing
6) QoS Output Policing
7) QoS Priority Queuing

To configure all these from ASDM, we'll have to browse to Configuration - Firewall - Service Policy Rules.

CCNA Security 28

Before we begin, let's redefine what AAA is. AAA contains three components: Authentication, Authorization, and Accounting. Authentication is to check if the user is genuine, Authorization defines the things the user can perform, and Accounting is logging of the activity of the authenticated user.
Authentication is valid without Authorization, but Authorization is never valid without Authentication. AAA can be performed using either a LOCAL, RADIUS server or a TACACS+ server.

There are three types of authentication:
1) Console access - The ASA requires authentication before permitting console access
2) Cut-through proxy - The ASA is configured to require authentication before access is allowed through it.
3) Tunnel access - Before establishment of a full tunnel, the user has to authenticate.

We can authenticate and authorize through local databases. Through a cut-through proxy, you can configure the ASA to authenticate and authorize for both Telnet and FTP. Once a user is authenticated either for Telnet or FTP, he can use the other service without reauthenticating.

The cut-through proxy is defined with interesting traffic. This interesting traffic triggers the authentication process which communicates with the AAA server. If the AAA server is running ACS, it can upload authentication/authorization AAA lists into the appliance itself.

Before we can start, we'll configure some local accounts:
user cisco pass cisco

The local database can be used for CLI access authentication, privilege mode authentication, command authorization, network access authentication, and VPN authentication/authorization. However, the local database cannot be used for network access authorization as well as all forms of accounting.

We can configure users in the ASDM by browsing to Configuration - Local AAA - User Accounts. We can configure various things like which users are permitted, or how many retries are allowed for a single user account. If a user account gets locked out, we can unlock his account by going to Monitoring - Device Access - AAA Local Locked Out Users.

In this article, I'll discuss configuring the cut-through proxy to be used with an RADIUS server in the backend (the local database simply requires you to have an account and to designate the rule to use the LOCAL database). The topology looks like this:


How this cut-through proxy scheme works is that when the user connects to the Web Server, the user will be prompted with a dialogue box asking for credentials:


Once the user authenticates, the ACS (RADIUS or TACACS+ server) is queried. If authentication is successful, the User is said to "cut-through" the ASA to the Web Server. The credentials is automatically passed to the web server for authentication. There are four types of cut-through authentication:
-HTTP (80)
-HTTPS (443)
-Telnet (23)
-FTP (21)

This operation is very similar to Single Sign-On. The authentication ports supported by the cut-through proxy is fixed to the defaults listed above.

The configuration of the cut-through proxy can be split into three steps:
1) Create the RADIUS or TACACS+ server group for authentication.
aaa-server CTPRADIUS protocol RADIUS
2) Designate an authentication server and the PSK.
aaa-server CTPRADIUS (DMZ) host 2.2.2.2
key cisco

3) Enable cut-through proxy authentication by configuring a rule (a rule is defined using an access-list specifying the interesting traffic).
access-list CTPINTERESTING extended permit tcp any 2.2.2.0 255.255.255.0
aaa authentication match CTPINTERESTING OUTSIDE CTPGROUP


Of course, do note that ASA does not only support RADIUS and TACACS+, but it also supports NT, Kerberos, LDAP and other authentication methods. Once you are authenticated, you can see the authenticated users by typing:
show aaa local user

You can display customized prompts when the user authenticates through the cut-through proxy. We can configure the text for both successful and failed authentication attempts. To do this, we'll need to type:
auth-prompt prompt Please authenticate with the cut-through proxy!
auth-prompt accept Authentication accepted!
auth-prompt reject Authentication rejected!


The time the user is allowed to stay authenticated can either be absolute (e.g. 10 minutes) or based on inactivity (e.g. inactive for 10 minutes). From the ASDM, we can go to Configuration - Firewall - Advanced - Global Timeouts. To change these timers from the CLI, type:
timeout uauth 0:5:0 inactivity

Now it comes to authorization. There are two type of authorization methods:
1) Classic User - The AAA user is authorized based on the AAA server. This is TACACS+ only.
2) Per-User ACL - Each user (or group) is assigned a dynamic ACL when they connect. This is only supported by RADIUS.

To configure the downloadable ACLs from the ACS interface, we'll need to go to Interface Configurations - Advanced Options - Downloadable IP ACL Content. In the Window, we'll type access-list commands similar to IP Access-lists like this:
permit tcp any host 2.2.2.3 eq 80
permit tcp any host 2.2.2.3 eq 443


To designate which user gets which ACL, we'll go to User Setup and check Assign IP ACL. We can also designate group ACLs by going to the Groups section.

We can also configure to override ACLs per-user from the ASDM by going to Configuration - Firewall - Access Rules - Per User Override Setting. If the Per User Override settings is enabled, the downloaded access-list REPLACES the configured inbound interface ACL. If it is disabled, the ACL is MERGED with the configured interface ACL.

Tuesday, July 20, 2010

Misc 42

Now I'll touch up a little on our apache2 knowledge. Remember how we set up SSL over HTTP (HTTPS) in this article? Now, what if we decide that we want to force users accessing through HTTP into using SSL as well?
This short article would briefly describe a mod in apache2 known as mod_rewrite. mod_rewrite is an advanced, extremely comprehensive URI rewriting mod that works with REGEXP.

We'll now pick up where we ended in that article, where our server has both port 80 and port 443 access. Now, we'll want to first enable the rewriting mod, so we'll type:
a2enmod mod_rewrite

Next, we'll want to access the 000default file found in sites-enabled so that we can directly affect port 80 connections. We'll modify it so that we have:
<VirtualHost *:80>
RewriteEngine on
RewriteCond %{SERVER_PORT} 80
RewriteRule ^{.*}$ https://%{SERVER_NAME}/$1 [L,R]
</VirtualHost>


First of all, RewriteEngine tells the server to turn on the mod_rewrite engine at that point. Next, the RewriteCond specifies the condition in which rewriting would trigger. The condition here is that the SERVER_PORT variable, specified using the %{} symbols, be 80.

Now I'll move on to the RewriteRule. ^{.*}$ simply means starting with anything. How we read this is that ^ starting with, and $ stands for ending with. If you start and end with something, then you're doing an exact match. Here, we're matching for .* which is anything.

Once matched, the rewriting will substitute the SERVER_NAME into the URL. SERVER_NAME is substituted with whatever the host references the server with (either IP, or domain name). Finally, the [L,R] represent flags, with L meaning to stop at this rewrite, and R means to redirect.

Misc 41

I'll now sidetrack a little bit to Debian. More specifically, I'm going to go into setting up WLAN services in Debian using Windows drivers. Yes you heard me right, you can actually natively use Windows drivers in Debian as long as the architecture is the same (e.g. an i386 driver for an i386 installation of Debian).
This sounds like a miracle and it probably is. It is completely done through a software wrapper known as NDISwrapper. NDISwrapper dynamically links the driver through Windows kernel and NDIS APIs. Notice that I mentioned "natively" in the previous paragraph. This explicitly means that there is no emulation involved, and so implementation would be reliable and fast.

If we have module-assistant, Debian can help us set up the entire NDISwrapper module from scratch, including downloading of the source, compiling, and installing. In this example, I am going to use the Netgear WG111T wireless adapter. We'll need a few files. First, we need to download the driver and extract it to a folder. To download the driver, we'll use the wget command:
apt-get install wget
wget http://www.netgear.de/download/WG111T/WG111T_GRV1.2.zip


Now, we'll unzip using the unzip command:
apt-get install unzip
unzip WG111T*zip -d wg111t


Now, we'll install ndiswrapper. To do this, we'll need to first install module-assistant and wireless-tools:
aptitude install module-assistant wireless-tools

Now, we'll use the module-assistant's automatic install feature to completely install ndiswrapper from source:
m-a a-i ndiswrapper

Now, we would need to add ndiswrapper to load on start up:
echo ndiswrapper >> /etc/modules

Now we can begin installing the drivers. To do this, browse into the folder you just extracted:
cd wg111t/WG111T_GR\ V1.2/

Next, we'll install two .inf files required for the device to work. To know the files to use, we need to check the database of known working devices here:
ndiswrapper -i athfmwdl.inf
ndiswrapper -i netwg11t.inf
ndiswrapper -m


Now if you haven't started ndiswrapper, type:
modprobe ndiswrapper

Check your interfaces file to make sure that wlan0 exists. If it doesn't, manually add in a line like this:
iface wlan0 inet dhcp

Here is where we choose our SSID and authentication method. For this case, I'll use WEP. To do this, we'll need to use the iwconfig command:
iwconfig wlan0 essid Kelvin
iwconfig wlan0 key CF3E89B61E


Now turn on your interface using the ifup command like this:
ifup wlan0

Now, if you would like to use WPA-Personal instead, you would configure the network file as follows:
iface wlan0 inet dhcp
wpa-ssid Kelvin
wpa-psk CF3E89B61E


In the next article, I'll walk through setting up of EAP-TLS (WPA/2-Enterprise) by making use of the wpa_supplicant.conf file.

CCNA Security 27

An ASA has many inherited switching and routing capabilities similar to IOS switches and routers. The most widely employed switching feature in the ASA is its Dot1Q tagging capabilities. ASA can use sub-interfaces just as a router could, and the configuration is really similar.
Suppose that we want to partition our e0/1 interface into two sub-interfaces connected to two different companies through leased lines. The only trunking protocol supported by the ASA (all models) is the Dot1Q protocol. Sub-interfaces assume the state of the physical interface, so before we can use the sub-interface, we will need to enable the physical interface.

However, we would not want the physical interface to pass traffic. The way we do this is to completely omit the "nameif" command on the physical interface. We instead name the sub-interfaces only. Like any other interfaces, a sub-interface also has a security-level.

On the ASDM, the configuration of the sub-interfaces can be found at Configuration - Interfaces. Of course, for us, we'll do it on the CLI:
in e0/1
no shut
in e0/1.10
vlan 10
nameif COMPANYONE
sec 50
ip add 10.10.10.1
in e0/1.20
vlan 20
nameif COMPANYTWO
sec 50
ip add 20.20.20.1


The only difference between the ASA and the IOS, of course other than the "nameif" and "security-level" command, is that the "encap dot" command is changed to "vlan" since Dot1Q is the only protocol it supports.

Of course, at the other end, you should have a switch to help us dynamically the packets as it leaves to the other companies. I however will not go through configuration of the switch as you can review it here.

Like a router, the ASA will send unknown routes to the default-gateway. The default-gateway is where the ASA will send packets of unknown destination gateways. Static routes can also be set in the ASA. Static routes will be up until the interface is down.

ASA comes with a static route tracking feature so that we can cause another route to come online if a monitoring target goes down. A monitoring target is typically a pingable host.

To track a host, for example, 10.10.10.2, we'll create a monitoring process as follows:
sla monitor 1
type echo protocol ipIcmpEcho 10.10.10.2 interface COMPANYONE
numpackets 3
frequency 10


This will create a monitoring process that pings for 3 packets every 10 seconds. We would also need to configure a schedule to do the monitoring. We can type:
sla schedule 1 life forever start-time now

This creates a schedule that runs from now till forever for monitor process 1 defined above. We now create a track object to group the monitor and the schedule objects together:
track 1 rtr 1 reachability

Now we have the object which we can put to a static route. If the tracking fails, the route is removed. You would not need to wait for the interface to go down. Suppose that we have to entries for a server farm at the other end:
route COMPANYONE 15.15.15.0 255.255.255.0 10.10.10.2 1 track 1
route COMPANYONE 15.15.15.0 255.255.255.0 10.10.10.3 2


In this case, the route with the metric of 1 would be used first. If the 10.10.10.2 becomes unreachable, it would attempt to go through using 10.10.10.3.

Finally, we'll go through some routing protocols that the ASA supports. These includes all the standard OSPF, EIGRP and RIP. To enable a routing protocol, you enable them the same way as IOS routers from the global configuration screen:
router ospf 1
network 1.1.1.1 255.255.255.255 area 0
network 10.10.10.1 255.255.255.255 area 1
network 20.20.20.1 255.255.255.255 area 2


Note that the mask of the network is opposite from how we do it in an IOS router. We no longer make use of wildcard masks. There are a few other deviations in the commands, so make sure you use context-sensitive help (?) regularly.

CCNA Security 26

We're now going to look at some ways to use compact ACLs. We do this through object grouping in ASA. Suppose that in the DMZ, we have three servers. These servers are 20.20.20.1-3. Suppose that we have statically translated the servers like this:static (DMZ,OUTSIDE) 10.10.10.1 80 20.20.20.1 netmask 255.255.255.0
static (DMZ,OUTSIDE) 10.10.10.2 80 20.20.20.2 netmask 255.255.255.0
static (DMZ,OUTSIDE) 10.10.10.3 80 20.20.20.3 netmask 255.255.255.0


Now suppose that all the servers provide HTTP, HTTPS and FTP services. To permit all these protocols, we have a hell of an access-list to type:
access-list PERMITSERVICES permit tcp any host 20.20.20.1 eq http
access-list PERMITSERVICES permit tcp any host 20.20.20.1 eq https
access-list PERMITSERVICES permit tcp any host 20.20.20.1 eq ftp
access-list PERMITSERVICES permit tcp any host 20.20.20.2 eq http
access-list PERMITSERVICES permit tcp any host 20.20.20.2 eq https
access-list PERMITSERVICES permit tcp any host 20.20.20.2 eq ftp
access-list PERMITSERVICES permit tcp any host 20.20.20.3 eq http
access-list PERMITSERVICES permit tcp any host 20.20.20.3 eq https
access-list PERMITSERVICES permit tcp any host 20.20.20.3 eq ftp


Now imagine if we can group up all the servers into a single group. In this way, we can simply type:
access-list PERMITSERVICES permit tcp any object-group SERVERS eq http
access-list PERMITSERVICES permit tcp any object-group SERVERS eq https
access-list PERMITSERVICES permit tcp any object-group SERVERS eq ftp


Now we can even do it further by grouping up all the services! We can totally reduce everything into:
access-list PERMITSERVICES permit tcp any object-group SERVERS object-group SERVICES

Objects should be grouped into groups of similar servers or services. For example, web services like HTTP, HTTPS and FTP can be grouped into a single WEBSERVICES group. Business-critical protocols like SQL can be grouped into a single BUSINESSSERVICES group. ASA provides a flexible way of grouping things in which we can group by Protocols, Network, Services and ICMP Type (Echo, Echo-Reply, etc).

The steps to group things is:
1) Designate the type of object-group and name the group
2) Define the members of the object-group
3) Apply the object-group in an ACL

We'll first configure groups in the ASDM. To do this, we'll go to Configuration - Firewall - Objects - Network Objects/Groups.

Whenever you give an IP address to an interface, we have a Network Object referencing the subnet of the entire network that interface is connected to. A Network Object can be either a host or a subnet.

A network object is just another type of object, and a network group is an object-group of the type Network. An object-group comes with a type. The type can be ICMP-Type, Network, Protocol or Service. For example, if we wish to create a group for our three servers, we can simply create a network group like this:
object-group network SERVERS
network-object host 20.20.20.1
network-object host 20.20.20.2
network-object host 20.20.20.3
network-object net_addr 255.255.255.0


We can then group services like this:
object-group service SERVICES tcp
port-object eq http
port-object eq https
port-object eq ftp

CCNA Security 25

Recall that I mentioned that ASA does Content Filtering. ACLs contain ACEs. An ACE stands for a Access Control Entry. ACEs are also called access rules in the ASA. ACLs are always checked before a translation is performed, so make sure that we always use the global outside address when we create ACEs.
By default, traffic from a lower to a higher interface would be denied. In some cases we might want HTTP traffic to come in to a web server in the DMZ. To allow this, we have to first create a static translation from OUTSIDE to DMZ. From here, we will create an ACL that permits HTTP traffic from OUTSIDE to the outside global address.

Suppose that our OUTSIDE interface has an IP of 10.10.10.1 and we wish to perform SPAT for a web server in the DMZ with the IP of 20.20.20.150, we can first type:
static (DMZ,OUTSIDE) interface

Now we create an ACL and apply it to an access-group like this:
access-list PERMITHTTP extended permit tcp any host 10.10.10.1 eq 80
access-list PERMITHTTP extended permit tcp any host 10.10.10.1 eq 443
access-group PERMITHTTP in OUTSIDE


By default, there is no outbound ACL applied on any interface, so all traffic going out of an interface is permitted.

ASDM has a feature that allows you to visually analyze access-lists. The ASDM actually draws a topology diagram showing the direction and the action of the ACL. This can be enabled at the Configuration - Firewall - Access Rules by clicking on Diagram at the top panel.



By default, the ICMP inspection engine is disabled. Cisco recommends that the ICMP engine be enabled if you wish to permit ICMP traffic. ICMP can be allowed through either enabling the inspection engine from the inside interface, or applying an access-group to the outside interface permitting the ICMP protocol inbound.

The reason why we cannot ping outwards is not that ping is disabled by default, but ping INSPECTION is disabled. This does not mean that ping cannot go from a higher to lower security interface. In fact, the ping gets out freely! However, since it is not inspected, a return path is not put in the state table and therefore the return packet is blocked! (Or rather, the return traffic is not explicitly permitted).

This inspection engine is actually the same one used to statefully inspect everything else. To enable ICMP for the inspection engine, we would need to inspect ICMP through:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect icmp
service-policy global_policy global


Now we have enabled a 1-way stateful ping. Test to see that a host from a higher security level interface can ping one from a lower security interface, but not the other way round.

When traffic is denied by an access-rule, you can enable logging to a syslog server. Suppose we have a logging server inside at 4.4.4.150. To do this, we'll enable logging through:
logging enable
logging host INSIDE 4.4.4.150
logging trap informational


Next, we'll define an access-list that denies ICMP, for example. We will then specify to log the entry. To do this, we'll type:
access-list alert-interval 5
access-list DENYICMP extended deny icmp any any log interval 5
access-group DENYICMP in interface OUTSIDE


This will set it to log informational traps to 4.4.4.150. The access-list denies will be grouped into traffic flows and will log every 5 seconds if there is a continuous flow. There will only be one log per flow, so you may have to ping from different devices to check the behavior.

Note that similar settings can be applied on IOS routers.

As previously mentioned, the ASA can do Content Filtering. From the ASDM, we can configure it at Configuration - Firewall - Filter Rules. We can add Java, ActiveX, HTTP, HTTPS and FTP rules. We can filter the source and destination IP of the filter, and the service used (HTTP, for example).

As an example, we want to filter Java and ActiveX over HTTP from anywhere. To do this, we'll type:
filter java 80 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
filter activex 80 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0


In Content Filtering, can also do URL filtering at Configuration - Firewall - URL Filtering Servers. There are two types of filtering server types: Websense and Secure Computing SmartFilter. A URL filtering server must be added somewhere before it will work. Once we have a URL filtering server set up, which in this case is Websense at 2.2.2.150, we'll type:
filter http http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
url-server (DMZ) vendor websense host 2.2.2.150


A demo version of Websense can be obtained here.

Monday, July 19, 2010

CCNA Security 24

In UDP, the state of the connection is more difficult to track. This is because unlike TCP, UDP doesn't have handshakes, sequencing and acknowledgments. Due to this, UDP is known to be connectionless. Therefore, the state of the UDP session is more difficult to maintain.
ASA is able to derive the status of a session by observing the TCP bits found in the flow. For example, when an INSIDE host first initiates a SYN outwards, the OUTSIDE interface listens for a SYN-ACK.

Now we'll go through the full process of the creation of an connection object. The first SYN packet coming in from the INSIDE host would create a connection slot. This connection slot is not complete, so it is marked as EMBRYONIC.

The ASA then modifies the TCP header parameters before forwarding it to the OUTSIDE host. These modifications include randomizing the SEQuence number and adding the delta (the amount of change from the original SEQuence number).

The appliance then waits to hear a SYN-ACK from the OUTSIDE host and it is matched to the EMBRYONIC connection slot. If it matches, it would compute the SEQuence numbers before forwarding it to the INSIDE host.

At this point, the ASA would listen for an ACK from the INSIDE host and would once again compute a new SEQuence number before forwarding it to the OUTSIDE host. At this point, the connection slot would become an ACTIVE,ESTABLISHED or CONNECTED connection object.

Tracking UDP services come in the form of timeouts. A return path is opened once an INSIDE host sends something out, and would remain open until it is idle for a specified time.

Now I'll go into NAT. NAT stands for Network Address Translation from our studies and it provides a generic form of security and is also a solution for the lacking address space. Suppose that we have this topology:



Before any host in the INSIDE or the DMZ network can successfully transmit out to the internet, you would need to translate it to the OUTSIDE interface address (PAT) or any publicly routable address (NAT). RFC1918 addresses are explicitly denied by ISPs.

To enforce that packets traversing from an higher security to lower security interface match a NAT rule, we'll need to type:
nat-control

(Thanks Eddie for the correction: Lastly, "nat-control" does not _enable_ NAT, it restricts un-natted traffic from passing through two interfaces. (even if an ACL allows the traffic). This was standard/always "enabled" in PIX and 6.x code, but ASA 7.x code gives you the option to enforce "nat-control".)

All packets traversing the ASA must have a translation rule before they are allowed go to anywhere. NAT is then configured using two commands. The first command is to specify what devices should be NATted. This is typically put inside an inner interface:
nat (INSIDE) 1 0 0

Next, the global command is used to specify the global pool which should be used when a NATted packet exits the interface. This is typically entered at the outside interface:
global (OUTSIDE) 1 interface

The "1" specified in the commands stand for the NAT identifier. The NAT identifier allows the packet to choose the correct global pool. At this point, the INSIDE host would be able to properly communicate with anything OUTSIDE, but any connection relating to DMZ would not work.

The simplest thing we can do now is to allow the DMZ host to communicate with OUTSIDE hosts. We'll simply use the same settings as the INSIDE interface:
nat (DMZ) 1 0 0

We'll now want to allow INSIDE to DMZ, so we'll use:
global (DMZ) 1 interface

Notice that I've been using 0 0 right after the NAT identifier. This 0 0 stands for 0 address and 0 mask. This simply means any traffic originating from that interface would be NATted.

If we would not want a packet to be NATted, we can use identity NAT. Identity NAT actually creates a transparent mapping that allows replies directly back to the originating IP. Since all traffic now needs a NAT rule, what this does is that it actually creates a return entry for the originating IP of the identity NATted device. We can create an identity NAT for, an example, a host 10.10.10.150, we use:
nat (INSIDE) 0 10.10.10.150 255.255.255.255

If we have a range of addresses to use for the outside interface instead of just the interface IP itself, we can use DNAT through:
global (OUTSIDE) 0 152.226.152.10-152.226.152.254 netmask 255.255.255.0

DNAT only translates from INSIDE to OUTSIDE. Now, how about if someone wants to communicate with a DMZ device. For example, if we have a web server at 20.20.20.150, we would want to allow an outside translation by turning on static NAT. This type of NAT is also known as SPAT (or Port Forwarding). To do this, we'll type:
static (DMZ,OUTSIDE) interface 80 20.20.20.150 80
static (DMZ,OUTSIDE) interface 443 20.20.20.150 443


Now anyone accessing 152.226.152.1 would be redirected to 20.20.20.150.

You can also translate entire networks. For example, if we want to translate the entire DMZ network to the OUTSIDE network, we'll use:
static (DMZ,OUTSIDE) 152.226.152.0 20.20.20.0 netmask 255.255.255.0

We can actually set connection limits for our NATs. This is to protect the firewall from DoS attacks. The connection limits we can change are:
-TCP Embryonic
-TCP Max
-UDP Max

To modify this, we'll append to the back of the NAT command as follows:
nat (inside) 1 0 0 tcp 0 25 udp 0

What this does is that after 25 embryonic connections from inside, the ASA will activate the TCP SYN Cookies feature. What this does is that it would instead proxy the request, complete the connection, and attempt to open a connection to the inside host before bridging both.

This is typically done to static NAT so that an inside host would not receive the barrage of SYN packets, but would instead get only 1 SYN from the ASA once the connection is complete.

CCNA Security 23

From the ASDM, we can configure the interfaces by going to Configure - Interfaces. From there, we can rename interfaces, set the security-level, change the MTU and IP address and allow same-security-level interfaces to pass traffic. From here, we can also allow interfaces to use DHCP. You can also select to receive default-gateway information and to renew.
To check the DHCP leases and bindings, we can go to the Monitoring tab. In Monitoring - Interfaces, we can find the DHCP section. If you would like to run a DHCP server, we can go to Configuration - Properties - DHCP Services. You would notice that DHCP is enabled on management interfaces by default. Apart from the DHCP server, you can also configure a DHCP Relay there.

For the 5500 series ASA, you would have an interface dedicated to management traffic known as Management 0/0. You can actually turn the management-only mode off so you can use it as an extra port. To do this, we'll go into the management interface through:
in management 0/0
no management-only


Like IOS routers, you the ASA only knows connected routes by default. To allow it to route further, you'll need to create either a static route or use a routing protocol. You can also configure a default-route on an ASA. Before we do any of that, let's go through some of the show commands.

The first and most common show command we use is:
show run

This will show all configurations currently in place. This is the most basic way we troubleshoot as we know from our IOS routers. To check on our interfaces, we use the command:
show interfaces

If you are only looking for IP address and the interface's state, we can hide all the details using:
show int ip br

Alternatively, if we want to see the interface names as well as the IP addresses on them, use:
show ip add

To view the routing table, we can use:
show route

To view the memory available, use:
show mem

To view the CPU usage, use:
show cpu usage

Now while we're at the basic services, we'll configure NTP. Before we configure anything, we'll need to set the timezone:
clock timezone SGT +08

Next, we'll add the NTP server using:
ntp server 192.168.1.10

NTP is configured on the ASDM at Configuration - Device Administration - Administration - NTP.

We can use authentication with NTP. NTP requires a key ID which needs to be the same between the client and the server. Instead of the server actually authenticating the client, the NTP client actually does the authentication. To add the key, use:
ntp authentication-key 1 md5 cisco
ntp trusted-key 1 key 1 source INSIDE prefer
ntp authenticate


In the ASDM, you can enable logging at Configuration - Properties - Logging - Logging Setup. You can split the logging to different devices according to severity using event lists. You can even log by email from Configuration - Properties - Logging - Email Setup.

If the logging is too fast, causing the syslog devices be flooded, we can configure rate limiting through Configuration - Properties - Logging - Rate Limit.

Syslog comes with facility codes. These facility codes does not affect the severity level in any way. Instead, facility code is an identifier in the syslog message which allows the syslog server to sort messages. For example, we can configure all routers to use local0 and all switches to use local1, then sort all router messages into its own log file and do the same for the switches.

CCNA Security 22

Now I'm going to revisit ASA basics. When we first turn on the ASA, we'll be in User mode. The User mode, like in IOS, offers a very limited command set. To get into Privileged mode, use:enable

The default password is blank. We can either hit Return on press Backspace. By default, a device would have the Base license. With Base License, you won't have things like Security Contexts. However, you can use 4 interfaces, 10 VLANs, 50 RA hosts, unlimited INSIDE hosts, and all VPN encryption types.

From privileged mode, we can move into the global configuration mode like in an IOS router. To do this, we'll use:
configure terminal

We should now change our enable password:
enable secret cisco

The recommended secure password should contain uppercase and lowercase letters, numbers and symbols. It should also be 8 characters or more.

From here, we can configure interfaces. For the ASA, a Fast Ethernet interface is referred to as simply Ethernet. To go into an interface, use:
interface ethernet0/0

You can turn an interface into a management-only interface using:
management-only

This command prevents all traffic THROUGH it (aka it blocks packet mode traffic).

ASA has a help system which can be invoked by typing:
help management-only

The help system also shows commands related to the one you typed.

To save a configuration, you can use:
copy run start

Alternatively, you can use:
wr

You can view the list of commands you typed previously using:
show history

You can clear out your running-configuration using:
clear configure all

You can also go to factory-defaults using:
conf factory-default

To clear the startup-configuration, use:
write erase

You can then reboot the ASA using:
reload

During the reboot process, you may encounter a delay to allow the Administrator to enter the ROMMON mode. Like an IOS router, the ASA also has a ROMMON mode. To do this, we'll need to hit CTRL+R during bootup.

The ASA has a filesystem which you can explore through:
dir

The ASA firmware and the ASDM image is both stored in the flash as .bin files. You can store more than 1 image of each type. You can designate which to boot from using:
boot system flash:asa802-k9.bin

The Adaptive Security Algorithm does a few things. The most obvious one is that it provides stateful control. This is the actual service that the stateful functionality. The ASA allows one-way outbound connections using minimum configuration changes. The ASA also watches all ingress packets. These packets are all watched for state and sequence numbers (which it can also randomize). It allows the appliance to be a more defined security boundary.

Understanding security-levels is extremely important on an ASA/PIX because it is one of the first things we need to configure. It allows to specify how trusted/protected an interface is with relation to another interface. The security-level is a number between 0 to 100. The INSIDE interface is typically 100 while the OUTSIDE interface has a default of 0. The DMZ is typically put to 50.

Traffic that originates from a less secure interface to a higher security interface is denied by default. Traffic from OUTSIDE to INSIDE, or DMZ to INSIDE, or OUTSIDE to DMZ, are such traffic. This is dropped unless specifically permitted by an access-list.

Traffic that originates from two interfaces with the same security-level are also denied by default. We can prevent this behavior using:
same-security-traffic permit

On the other hand, a host from a higher security level can statefully traverse to a lower security interface. Such would be true for INSIDE to OUTSIDE, INSIDE to DMZ, or DMZ to OUTSIDE.

The interfaces are named from interface context using:
nameif INSIDE

To set the security-level, we use:
security-level 100

There are many ways to configure an ASA. One of the ways is to use the ASDM web interface. To do this, we'll need to find a way to connect the computer to the ASA (through a switch or an interface). By default, we can obtain an IP by plugging directly to the management interface because DHCP is turned on for all management interfaces.

Once should make sure that the basics are set up, such as Time, Interface Names, Host Name, and the Auth Hosts. Auth Hosts is a list of the authorized hosts allowed to configure through the web interface. All these configurations are done using:
en
conf t

!Time
clock time zone SGT +08
exit
clock set 11:13:00 19 July 2010
conf t

!Host Name
host ASA
domain-name syraxius.local

!Interface Names
in e0/0
nameif MANAGEMENT
sec 99
ip address 192.168.1.1 255.255.255.0
management-only
in e0/1
nameif INSIDE
sec 100
ip address 1.1.1.1 255.255.255.0
exit

!Auth List
http 192.168.1.150 255.255.255.255 MANAGEMENT
http server enable


On a side note, if you don't have a system with a serial port, we can get a USB-to-Serial converter.

When we're done, we can connect to the ASA through the web browser by putting in the ASA's management interface IP (assuming that we've connected the computer through a crossover to the management interface).

We can manage ASDM as a Windows application or a Java application. If you run it as a Windows application, you will not have to double-authenticate. The launcher also works well if your version of Java is not completely compatible with the Java version.

The ASDM is very similar to the SDM and the IDM we covered in previous articles. ASDM is more similar to SDM, in which you have a Home tab, but the Configuration and Monitoring tabs that we're interested in is common across all the management GUIs.

We'll talk more about configuration in the next article. This about commands more specific to the ASA itself.

CCNA Security 21

To attain CCSP, you would require SNRS, SNAF, IPS, SNAA exams. From here on, I'll cover materials found in SNAF and SNAA. SNAF covers the fundamentals of ASA, and SNAA covers the advanced aspect of ASA.
The ASA is designed as a single box solution to provide a baseline security for a network. ASA is a type of firewall, so it makes good sense to first define what a firewall is.

The original definition of a firewall is to stop the spread of fire. It is to isolate one compartment from another. This definition can be brought over to our hardware or software solution, describing how it can stop the spread of threats and to isolate different subnets. A firewall need not be a single device. A group of devices can also make up a firewall.

One of the most common designs of a firewall is the screened subnet. The screened subnet involves an Outside, Inside and a DMZ. The DMZ is then known as the screened subnet, where content from within is meant for public access. It is screened in the sense that it is not completely free. This is what a screened subnet looks like:



Typically there is a router in between the ISP and the ASA, but it is possible that the ASA connect directly to the ISP.

For firewalls, there are three types. The most basic is the packet filtering firewall where we statically define the sockets of the packet we want to permit or reject. Typically this is implemented through access-lists. This is easily cracked by hackers who know how to craft packets either through spoofing or fragmentation. This is also difficult to manage.

An ALG (Application Layer Gateway), or otherwise known as Proxy Server, works on layer 5 to 7. It serves as an interface between the client and the outside untrusted network. Examples are web proxy and HTTP proxies. A proxy server can authenticate and authorize. It is typically used for content security (e.g. restricting the user from visiting certain sites). For a proxy server, we have to ensure the security integrity of the server itself. This differs according to what operating systems you use. The disadvantage is that it is a single point of failure, and it is difficult to add new services as they are typically developed for specific purposes (e.g. HTTP traffic).

In the best of both worlds, we have the stateful packet filtering. A stateful packet filter combines the best of both worlds, using state tables and TCP proxy technologies. This is the default used by ASA and is the Cisco-recommended firewall type. When an inside host initiates a connection out, a new entry is added to the state table. Traffic from the outside host is only allowed back only if it has an active entry in the state table.

How the state table works is that it records the state of all connections. Aside from static sockets, the stateful firewall checks for the state of connections (sequence numbers, connection state, etc.). Each entry in the stateful table is known as a connection object. Cisco uses the Fast Path algorithm which allows much higher performance compared to proxy server and other firewall types.

When an ASA receives an ingress packet, it would ask a few questions. The first question it asks is: Is it a new connection? If it's a new connection, the packet will be matched across ACLs and XLATE tables. If the packet is permitted, a new connection object is established. The packet will be sent to the Fast Path. On the other hand, if the packet has a matching established connection object, it is immediately put to the Fast Path.

ASA stands for both Adaptive Security Appliance and Adaptive Security Algorithm. That is the algorithm used in PIX and ASA devices. ASA supports the following features:
-Stateful packet inspection
-User-based authentication (Cut-through proxy)
-Modular policy framework
-IPSec VPN and SSL VPN (WebVPN)
-IPS
-Content Security
-Security Contexts
-Transparent Firewalls (L2)
-Web-based Management

A cut-through proxy is also known as user-based authentication. This is done through a web-page, telnet or FTP connection. The authentication leverages on AAA.

MPF, or otherwise Modular Policy Framework, leverages on the MQC style policies. This gives us granular control over flows and allows modular use of existing policies for more efficient use of memory.

In MPF, we group traffic into flows using Class-Maps. In class-maps, we have multiple match statements to match access-lists, protocols, and so on.

Next, we use Policy-Maps to define what we want to do with the traffic flows. In policy-maps, we specify class-maps and the action to apply to the flows, such as Inspect, IPS, Police, Priority, etc.

Notice that I mentioned Police and Priority. These are QoS terms, and yes, you can implement QoS and access-control through the same mechanism.

The Service-Policy is then used to apply the policy-maps to either on a per-interface basis or globally.

IPS is implemented through SSM. SSM stands for Security Service Module and AIP (Advanced Inspection and Prevention) and CSC (Content Security and Control Security) modules are available.

The ASA can also be run in transparent mode, where it acts as a L2 bridge.

Saturday, July 17, 2010

CCNA Security 20

On the IOS, we have the Security Device Manager. For sensors, we have the IDM. IDM Stands for the IPS Device Manager. The IDM is similar to SDM in terms of look and feel.
IDM can be accessed with TLS/SSL/HTTPS. HTTPS is not a protocol itself, it is simply HTTP over SSL/TLS. SSL came out first and is designed for only HTTP, but TLS is a replacement which can be used for HTTP as well as just about any communication methods.

The IDM uses RDEP to configure the sensor. It stands for Remote Data Exchange Protocol. SDEE is a notification method used by the sensor to send event information to management software. SDEE stands for Security Device Event Exchange. XML is a universal way to represent information with tags. Configuration are in XML over SDEE. IDCONF is the DTD applied to XML.

To access the IDM, we simply visit the sensor's IP through the browser using HTTPS. Like the SDM, you have the Configuration and Monitoring tabs. You can manage networking, SSH, certificates, etc. through the Configuration tab. You can even reboot or shutdown the sensor.



In the Monitoring tab, you can see the denied attackers, blocks, logging, events and system information. In the event screen, we can view more detailed information about the event by double-clicking it.

Friday, July 16, 2010

CCNA Security 19

I will now go into configuration of a typical IDS/IPS appliance. The CLI is a requirement for the initial configuration of an IDS/IPS, but you can configure the other options through a web GUI.
Cisco allows a few ways to configure the IDS/IPS. The console port is the fastest way to access the device. Telnet is disabled by default, and Cisco recommends jumping straight to SSH.

The default login for the IPS sensor is "cisco" with the password of "cisco". The setup wizard on the IPS sensor is not as bad as the intial configuration wizard found in IOS. The setup wizard actually does a lot of necessary configuration for us so let's begin by invoking it through:
setup

The setup wizard walks us through setting up of: Host Name, Interface IP (and Default Gateway), Telnet, HTTPS, Management Access List, System Clock and Virtual Sensor. At the end of the wizard, a preview of the commands will be displayed on the screen like in an IOS device.

To reload the sensor, instead of "reload", we use:
reset

The reset will take a while to start (up to 90 seconds). You will be logged out upon reset but the sensor will reset once it's fully shut down. An IPS is actually running on Red Hat Linux 7.3, so you would actually see the GRUB boot loader during reboot. The IOS-like interface is actually an application known as MainApp.

There are four major modes in the sensor firmware. These are:
-Privileged EXEC Mode - The same as the privileged mode on a router. There is no such thing as a user mode on a sensor.
-Global Configuration Mode - From here, we can access the other two modes: Service Mode, and Multi-Instance Service Mode.
-Service Mode - Allows configuration of various services like network configurations of the sensor itself.
-Multi-Instance Service Mode - Can be used to modify the signature definitions and the actions to take.

There are many services available for configuration in the Service Mode. To configure the host, we can go under the host service prompt through:
service host

From here, we can then modify the network settings of the host. Under host services, we can modify access-list, the IP address, the host name, login banner and so on:
network-settings

We can also go under the interface service mode to change settings like the bypass-mode (discussed in the previous article), inline-interfaces and so on:
service interface

It may not be as intuitive as it is on a router. For example, a new user would typically go into interface service mode to configure an IP address, but it's actually in host.

The Multi-Instance Service Mode can be accessed from either:
service signature-definition sig0
service event-action-rules rules0


We'll begin with sig0. This is where we modify the signatures. Signatures tell the sensor what kind of traffic to match. An example is to modify the H225 : SETUP fixed signature 1. To do this, we'll type:
signatures 12505 3

This references signature 12505, sub-signature 3. A good list can be found here.

At this prompt, we can change the priority levels and other configurations. To see information about the signature, we can type:
show settings

From here, we can modify settings specific to the h225 engine through:
engine service h225

By now you would be in 4 sub-prompts. However, lets not get too carried away with this introductory article. We'll begin with the simple things, like setting up banners:
banner login
Do not log in!*CTRL+V Enter*
All activities are logged!


CTRL+V allows entering of a control character, and the enter button would cause a carriage return. The Enter button itself would end the banner entry.

To save the configuration of the sensor, we'll use:
copy current-config backup-config

In the sensor, the current-config is the running-config, and the backup-config is the startup-config. We cannot use "wr" so we must get used to "copy run back".

Commands like "more" also works in the sensor. To see the backup-config, we use:
more backup-config

We can also use:
show configuration | include service

To add hosts into the management access-list, we can go through:
service host
network-settings
access-list 1.1.1.1/32


This would allow the 1.1.1.1 host to manage the router. When you exit the service prompt, you will be prompted to save the configuration. This is because changes in service mode doesn't take effect immediately. This gives us more freedom to fiddle around with the settings.

We can actually REPLACE the running-configuration through:
copy /erase backup current

This erases the current-configuration before replacing it with the backup-configuration. On an IOS router, you can only MERGE the configurations.

Finally, we'll check out the events in the sensor. To do this, we'll use:
show events 21:00 July 16

This would actually show events beginning from 9PM on 16 July. The event log stores things like interface status and IPS alerts. You can also clear the event log using:
clear events
<