How do I... Configure firewall security on a SonicWALL device?

Takeaway: SonicWALL firewalls are a staple of network security in the small and medium business market. SonicWALL's proprietary SonicOS operating system powers its firewall devices, which means the mechanisms and procedures required to configure their security settings is similar for all of them. Here are the basic to configuring SonicWALL firewalls.

SonicWALL firewalls are a staple of the small and medium business market. Everyone from small nonprofit organizations to medium-size and enterprise class businesses depend upon SonicWALL devices to secure their network communications.

SonicWALL's proprietary SonicOS operating system powers its firewall devices. Most every SonicWALL device is now powered by the SonicOS Enhanced operating system. The main difference between the two operating systems is the Enhanced version enables the system's firmware to provide ISP failover services, zone management and WAN load balancing.

Factory Default Settings

 Default IP   : 192.168.168.168

 User Name : Admin

 Password    : Password

   You can access firewall through any explorer by typing http://192.168.168.168 in address bar.

The setup wizard

SonicWALL includes numerous wizards with its firewall devices. Available menus differ by model (for example, the WEP/WAP Encryption settings menu is available only on those models possessing wireless features).

The Setup Wizard is a time-saving tool that simplifies new router deployment. Or, if a network is being redesigned, a SonicWALL device can be reset to factory defaults and the Setup Wizard can be used to roll the device out anew.

To use the Setup Wizard, log in to a SonicWALL firewall and click the Wizards button. The Wizards (Figure A) button can be found on the main System | Status page.

Figure A

The SonicWALL System Status page provides a wealth of information regarding a firewall's configuration.

Here’s a walkthrough of the process using a SonicWALL PRO 1260.

After clicking the Wizards button, the SonicWALL Configuration Wizard presents four options (Figure B).

Figure B

The SonicWALL Configuration Wizard presents four options. Administrators can either choose to select the Setup Wizard (used to configure the SonicWALL device to secure network connections), the PortShield Interface Wizard (for segmenting networks), the Public Server Wizard (used to provide internal server access to the public) or the VPN Wizard (for configuring access to a virtual private network).

Specify whether you wish to select the Setup Wizard, PortShield Interface Wizard, Public Server Wizard or VPN Wizard. For this example, we’ll choose Setup Wizard and click Next. The Setup Wizard appears.

1. Step 1: The Change Password screen appears. Enter the default or old password, then enter a new password and confirm the new entry. When finished, click Next.
2. Step 2: The Change Time Zone menu appears. Specify the applicable time zone, and check the box if you want the firewall to automatically adjust for daylight saving time, and click Next.
3. Step 3: The WAN Network Mode screen appears. Select the radio button indicating the method used to connect to your ISP (Static IP, DHCP, PPPoE or PPTP). Then, click Next. For this example we’ll select Static IP. (Figure C)

Figure C

The WAN Network Mode menu enables specifying the most appropriate ISP connection method.

4. Step 4: The WAN Network Mode: NAT Enabled menu appears. Enter the SonicWALL WAN IP Address, WAN Subnet Mask, Gateway (Router) Address, DNS Server Address and a secondary DNS address, and click Next. (Figure D)

Figure D

Specify WAN settings using the WAN Network Mode screen.

5. Step 5: The LAN Settings menu appears. Supply an IP address for the SonicWALL’s LAN. Be sure to provide a subnet mask, and then click Next. (Figure E)

Figure E

Specify LAN settings using the SonicWALL’s LAN Network Settings screen.

6. Step 6: The LAN DHCP Settings screen appears. Check the Enable DHCP Server On LAN box if you wish for the SonicWALL device to provide DHCP services. If you check the box, you’ll also have to enter the valid LAN address range. When done, click Next. (Figure F)

Figure F

Specify DHCP settings using the DHCP Server menu.

7. Step 7: The SonicWALL Configuration Summary (Figure G). Review the information the wizard provides, and if all settings are correct, click Apply. If the configuration requires adjustment, click the Back button.

Figure G

Review the Confirmation Summary carefully before proceeding; clicking Apply triggers the settings reviewed on this menu.

A screen will appear indicating that the SonicWALL configuration is being saved, and you’ll be asked to wait. When the configuration is completed, you’ll see a Congratulations message stating the changes have been made and the Setup Wizard has completed.

SonicWALL Log In

Once the Setup Wizard is complete, log in to the firewall by entering the IP address you assigned to the SonicWALL device in Step 5 (on the LAN Settings menu). You’ll be greeted with a standard name and password dialog box. Enter the name and password you supplied for the firewall and click the Login button.

By default, the SonicWALL device displays the System | Status menu. To configure additional firewall settings, click the Firewall button from the menu appearing on the SonicWALL interface screen’s left edge.

The Firewall | Access Rules | All menu appears. The SonicWALL application displays important information about the firewall’s configuration within this screen. In addition to revealing zone and priority information, the Access Rules menu displays source and destination data, service type, action status, and user information (Figure H).

Figure H

Administrators can review SonicWALL’s Access Rules using three different views; here the All Rules view is displayed.

Traffic statistics for each access rule can be obtained simply by mousing-over the graph icon that appears toward the end of each access rule line. Access rule configurations can be tweaked by clicking the pencil and paper icon, or an access rule can be deleted by clicking its trash can icon.

Creating access rules

To create an access rule:

1. Log on to the SonicWALL firewall.
2. Click the Firewall button.
3. Click the Matrix or Drop-down Boxes View Style radio button. (See Figure I)
4. Click the appropriate From And To Zone (such as WAN to LAN).
5. Click the Add button that appears at the bottom of the menu.

Figure I

When creating an access rule, you must specify the appropriate criteria. SonicWALL’s firmware provides pre-populated drop-down boxes for configuring most settings.

6. Using the General tab, specify the action to be taken to traffic matching the access rule’s settings; Allow, Deny and Discard are the three options.
7. Select the appropriate service from the Service drop-down box. Do the same for the Source, Destination, Users Allowed and Schedule drop-down boxes.
8. Enter a comment that describes the access rule or its purpose.
9. Uncheck the Enable Logging checkbox if you don’t wish to log events related to the new access rule.
10. Configure any advanced options (such as a timeout for TCP connection inactivity or the number of connections permitted) using the Advanced tab.
11. Click OK.

Editing access rules

To edit an access rule:

1. Log on to the SonicWALL firewall.
2. Click the Firewall button.
3. Select Access Rules.
4. Click the pencil and paper icon for the access rule you wish to edit.
5. Use the resulting drop-down boxes to adjust the access rule as required (Figure J). Alternatively, you can click an access rule’s corresponding trash can icon to delete it.

Figure J

SonicWALL’s drop-down boxes make quick work when editing access rules.

6. Click OK to apply the edits (if you delete an access rule, the deletion occurs upon confirming the action). The SonicWALL firmware will write the changes and update the firewall’s configuration.

Editing service groups

SonicWALL devices, by default, include service objects and groups designed to simplify firewall administration. Using SonicWALL firewalls, service groups and objects are used to make common applications and services (such as PC Anywhere, ShoreTel, VNC and Yahoo Messenger) available to network users.

To review a firewall’s services settings:

1. Log on to the SonicWALL firewall.
2. Click the Firewall button.
3. Select Services.

Numerous service groups are provided by default (Figure K). To add additional groups or objects:

1. Log on to the SonicWALL firewall.
2. Click the Firewall button.
3. Select Services.
4. Click the Custom Services radio button.
5. Click Add Group to create a new Service Group or Add to create a new service (Figure L).

Figure K

SonicWALL’s firmware provides numerous pre-populated service groups to simplify firewall configuration.

Figure L

Administrators needing to create their own firewall services can do so by specifying the appropriate criteria.

6. If you click Add Group, numerous options are pre-populated in the left pane. You can choose to select one of those or enter your own name and click OK; to configure its settings, click its subsequent pencil and paper icon. To create a new service, click the Add button, provide a name, specify the appropriate protocol, enter the port range or sub type if required and click OK.

Easy packet captures straight from the Cisco ASA firewall

Whether you are troubleshooting a difficult problem or chasing some interesting traffic, sometimes you need to pull a packet capture. Of course, you could configure and deploy a sniffer, but that is not the only solution you have at your fingertips. You can pull the packet capture directly from the Cisco ASA firewall. The Cisco ASA makes this an easy process.

There are at least two ways to configure your ASA to capture packets. If you prefer the GUI interface of the ASDM, you can use the Packet Capture Wizard tool by selecting it from the wizard menu.

However, I’ve found that if you don’t mind getting your hands dirty, so to speak, the CLI interface is the way to go. You can identify the traffic you are looking for with an ACL and then set your interface to capture based on the ACL results. Here’s an example of how easy it is to do this.

In this example, I want to capture all IP packets between a host at 192.168.80.51 and the test ASA at 192.168.81.52.

The first step is to set a quick ACL:

access-list testcap extended permit ip host 192.168.80.51 host 192.168.81.52

Then, we set up the capture using the capture command. We’ll reference our ACL (testcap) as our “interesting” traffic, and we’ll specify which interface we want to look at:

myasa# capture testcap interface inside

Admittedly, this is probably the command in its simplest form. There are many options you can configure as part of this command, including setting buffer sizes, setting a circular-buffer that overwrites itself when full, and selecting webvpn or isakmp traffic. The point is, with two quick commands, we’ve got a packet capture going! It just doesn’t get much easier than that.

A quick show capture command verifies my capture is running.

myasa# sh capture

capture testcap type raw-data interface INSIDE [Capturing - 4314 bytes]

To stop the capture, use the no form of this command.

myasa # no capture testcap

Now let’s look at the results. Here again, we have choices. We can look at the traffic via a browser directly from the ASA by opening an http link (Figure A) like the following:

https://192.168.81.52/admin/capture/testcap

Figure A

Click to enlarge.

While we see the traffic and much of the information, we cannot see all the detail of a regular packet capture. However, we can save this info as a libpcap file with the following command, and then open this file with Wireshark or such.

https://192.168.81.52/capture/testcap/pcap

Figure B shows this file when opened with Wireshark.

Figure B

Click to enlarge.

The command line also provides options for looking at your data.

myasa# show capture testcap ?

  access-list    Display packets matching access list

  count          Display  of packets in capture

  decode         Display decode information for each packet

  detail         Display more information for each packet

  dump           Display hex dump for each packet

  packet-number  Display packet  in capture

  trace          Display extended trace information for each packet

  |              Output modifiers

Let’s look at the first nine packets.

myasa# show capture testcap count 9

4532 packets captured

   1: 13:46:31.052746 192.168.81.52.22 > 192.168.80.51.2057: P 1290581619:1290581687(68) ack 941116409 win 8192

   2: 13:46:31.052884 192.168.80.51.2057 > 192.168.81.52.22: . ack 1290581687 win 65207

   3: 13:46:38.374583 arp who-has 192.168.80.219 tell 192.168.82.51

   4: 13:46:38.521655 arp who-has 192.168.80.204 tell 192.168.82.51

   5: 13:46:39.803120 192.168.81.52.443 > 192.168.80.51.3968: P 787673978:787675438(1460) ack 3043311886 win 8192

   6: 13:46:39.803150 192.168.81.52.443 > 192.168.80.51.3968: P 787675438:787675589(151) ack 3043311886 win 8192

   7: 13:46:39.803257 192.168.81.52.443 > 192.168.80.51.3968: P 787675589:787677049(1460) ack 3043311886 win 8192

   8: 13:46:39.803272 192.168.81.52.443 > 192.168.80.51.3968: P 787677049:787677200(151) ack 3043311886 win 8192

   9: 13:46:39.803287 192.168.81.52.443 > 192.168.80.51.3968: P 787677200:787677883(683) ack 3043311886 win 8192

9 packets shown

We can also look at an entire packet from the CLI.

myasa# show capture testcap detail packet-number 5 dump

4532 packets captured

   5: 13:46:39.803120 0022.5597.25b9 0014.3815.89fb 0x0800 1514: 192.168.81.52.443 > 192.168.80.51.3968: P [tcp sum ok] 787673978:787675438(1460) ack 30                   43311886 win 8192 (ttl 255, id 54032)

0x0000   4500 05dc d310 0000 ff06 c052 c0a8 5134        E..........R..Q4

0x0010   c0a8 5033 01bb 0f80 2ef2 f37a b565 410e        ..P3.......z.eA.

0x0020   5018 2000 5488 0000 1703 0106 4654 db31        P. .T.......FT.1

0x0030   b3d4 0a5b 3295 f719 d82a 8767 6b8b dae1        ...[2....*.gk...

0x0040   0a54 0ea8 c8c4 1c61 c45c e321 452e 6ab6        .T.....a.\.!E.j.

0x0050   ba80 4e94 3801 d973 b4fe 97d4 8b2f 9e77        ..N.8..s...../.w

*Only a partial result is displayed.

So save your hardware or laptop sniffers for other parts of your network. Use your ASA to gather those snippets of network traffic that you need. But remember: in general, be kind to your ASA. When possible, create specific ACLs to refine the traffic you want to capture. Monitor your ASA while capturing packets and adjust the buffers if you need to. And, as always, refer to www.cisco.com for more detailed information.

Eight easy steps to Cisco ASA remote access setup

Need to set up remote access for users quickly? Configuring remote access for your users can be a confusing process. But it doesn’t have to be! Here is a guide that will make it simple.

——————————————————————————-

There are eight basic steps in setting up remote access for users with the Cisco ASA.

• Step 1. Configure an Identity Certificate
• Step 2. Upload the SSL VPN Client Image to the ASA
• Step 3. Enable AnyConnect VPN Access
• Step 4. Create a Group Policy
• Step 5. Configure Access List Bypass
• Step 6. Create a Connection Profile and Tunnel Group
• Step 7. Configure NAT Exemption
• Step 8. Configure User Accounts

So let’s get started!

Step 1. Configure an Identity Certificate

Here I am creating a general purpose, self-signed, identity certificate named sslvpnkeyand applying that certificate to the “outside” interface. You can purchase a certificate through a vendor such as Verisign, if you choose.

corpasa(config)#crypto key generate rsa label sslvpnkey

corpasa(config)#crypto ca trustpoint localtrust

corpasa(config-ca-trustpoint)#enrollment self

corpasa(config-ca-trustpoint)#fqdn sslvpn. mycompany.com

corpasa(config-ca-trustpoint)#subject-name CN=sslvpn.mycompany.com

corpasa(config-ca-trustpoint)#keypair sslvpnkey

corpasa(config-ca-trustpoint)#crypto ca enroll localtrust noconfirm

corpasa(config)# ssl trust-point localtrust outside

Step 2. Upload the SSL VPN Client Image to the ASA

You can obtain the client image at Cisco.com. As you choose which image to download to your tftp server, remember that you will need a separate image for each OS that your users have. After you select and download your client software, you can tftp it to your ASA.

corpasa(config)#copy tftp://192.168.81.50/anyconnect-win-2.0.0343-k9.pkg flash

After the file has been uploaded to the ASA, configure this file to be used for webvpn sessions. Note that if you have more than one client, configure the most commonly used client to have the highest priority. In this case, we’re using only one client and giving it a priority of 1.

corpasa(config)#webvpn

corpasa(config-webvpn)#svc image disk0:/anyconnect-win-2.3.0254-k9.pkg 1

Step 3. Enable AnyConnect VPN Access

corpasa(config)#webvpn

corpasa(config-webvpn)#enable outside

corpasa(config-webvpn)#svc enable

Step 4. Create a Group Policy

Group Policies are used to specify the parameters that are applied to clients when they connect. In this case, we’ll create a group policy named SSLClient. The remote access clients will need to be assigned an IP address during login, so we’ll also set up a DHCP pool for them, but you could also use a DHCP server if you have one.

corpasa(config)#ip local pool SSLClientPool 192.168.100.1-192.168.100.50 mask 255.255.255.0

corpasa(config)#group-policy SSLCLient internal

corpasa(config)#group-policy SSLCLient attributes

corpasa(config-group-policy)#dns-server value 192.168.200.5

corpasa(config-group-policy)#vpn-tunnel-protocol svc

corpasa(config-group-policy)#default-domain value mysite.com

corpasa(config-group-policy)#address-pools value SSLClientPool

Step 5. Configure Access List ByPass

By using the sysopt connect command we tell the ASA to allow the SSL/IPsec clients to bypass the interface access lists.

corpasa(config)#sysopt connection permit-vpn

Step 6. Create a Connection Profile and Tunnel Group

As remote access clients connect to the ASA, they connect to a connection profile, which is also known as a tunnel group. We’ll use this tunnel group to define the specific connection parameters we want them to use. In our case, we’re configuring these remote access clients to use the Cisco AnyConnect SSL client, but you can also configure the tunnel groups to use IPsec, L2L, etc.

First, let’s create the tunnel group SSL Client:

corpasa(config)#tunnel-group SSLClient type remote-access

Next, we’ll assign the specific attributes:

corpasa(config)#tunnel-group SSLClient general-attributes

corpasa(config-tunnel-general)#default-group-policy SSLCLient

corpasa(config-tunnel-general)#tunnel-group SSLClient webvpn-attributes

corpasa(config-tunnel-webvpn)#group-alias MY_RA enable

corpasa(config-tunnel-webvpn)#webvpn

corpasa(config-webvpn)#tunnel-group-list enable

Note that the alias MY_RA is the group that your users will see when they are prompted for login authentication.

Step 7. Configure NAT Exemption

Now we need to tell the ASA not to NAT the traffic between the remote access clients and the internal network they will be accessing. First we’ll create an access list that defines the traffic, and then we’ll apply this list to the nat statement for our interface.

corpasa(config)#access-list no_nat extended permit

ip 192.168.200.0 255.255.255.0 192.168.100.0 255.255.255.0

corpasa(config)#nat (inside) 0 access-list no_nat

Step 8. Configure User Accounts

Now we’re ready for some user accounts. Here we’ll create a user and assign this user to our remote access vpn.

corpasa(config)#username hyde password l3tm3in

corpasa(config)#username hyde attributes

corpasa(config-username)#service-type remote-access

Finishing up

Don’t forget to save your configuration to memory.

corpasa#write memory

Verify your configuration by establishing a remote access session and use the following show command to view session details.

corpasa #show vpn-sessiondb svc

This guide should help you to get your remote access users up and running in no time. If you run into any difficulties, use the debug webvpn commands to diagnose the problem.

Good luck and have fun out there!

Use sequence numbers for easy Access Control List modifications

In the “old days,” you could add an entry only to the bottom of an ACL. There was no way to specify the position of a line entry within an access list. If you wanted to insert an entry in the middle of an existing list, you had to copy the ACL to a notepad, make your change, remove the existing ACL, and enter your revisions as a new list, basically rebuilding and recompiling the entire ACL.

Cisco changed all that with the introduction of sequence numbers. This IOS feature was originally introduced with 12.2(14)S. With the use of sequence numbers, you can add entries where you want them, delete entries as needed, and reorder your lists. This feature makes managing your ACLs much easier.

Many of you are already familiar with ACL sequence number editing. For those of you who have not tried it yet, check out this example.

Let’s walk through just how easy this process has become. In this example, we’ll look at an existing ACL, add a line, resequence the list, and then delete a line. We’ll do all this while the ACL is actively applied to an interface. For this example, I’m using a simple extended ACL, but these concepts can be applied to other ACLs as well.

Here is the pertinent part of a show run command:

interface Ethernet0/0

  ip access-group MYTESTACL in

ip access-list extended MYTESTACL

 permit ip 10.10.10.0 0.0.0.255 any

 permit icmp 10.10.10.0 0.0.0.255 any

 deny   ip 10.10.20.0 0.0.0.255 any

 permit tcp 10.10.30.0 0.0.0.255 host 192.168.87.65 eq www

As you can see, the sequence numbers are not displayed in the router running configuration. However, a show access-list command reveals the line entry sequence number information.

router#sh access-list

Extended IP access list MYTESTACL

    10 permit ip 10.10.10.0 0.0.0.255 any

    20 permit icmp 10.10.10.0 0.0.0.255 any

    30 deny ip 10.10.20.0 0.0.0.255 any

    40 permit tcp 10.10.30.0 0.0.0.255 host 192.168.87.65 eq www

Now that we have this info, we can insert a new line where we need it, without disturbing the existing ACL. In this case, we’ll insert a new permit statement at sequence number 25. Note the first item in the statement is the new sequence number.

router#conf t

router(config)#ip  access-list extended MYTESTACL

router(config-ext-nacl)#25 permit tcp host 10.10.20.5 host 192.168.87.65 eq www

Here is the resulting change:

router#sh access-list MYTESTACL

Extended IP access list MYTESTACL

    10 permit ip 10.10.10.0 0.0.0.255 any

    20 permit icmp 10.10.10.0 0.0.0.255 any

    25 permit tcp host 10.10.20.5 host 192.168.87.65 eq www      (**note new line)

    30 deny ip 10.10.20.0 0.0.0.255 any

    40 permit tcp 10.10.30.0 0.0.0.255 host 192.168.87.65 eq www

Now let’s resequence this ACL with the following statement. The variables after the ACL name are the starting sequence number I want to use and the increment value I want to use.

router(config)#ip access-list resequence MYTESTACL 100 20

Here is the resulting show access-list command:

router#sh access-lists MYTESTACL

Extended IP access list MYTESTACL

    100 permit ip 10.10.10.0 0.0.0.255 any

    120 permit icmp 10.10.10.0 0.0.0.255 any

    140 permit tcp host 10.10.20.5 host 192.168.87.65 eq www

    160 deny ip 10.10.20.0 0.0.0.255 any

    180 permit tcp 10.10.30.0 0.0.0.255 host 192.168.87.65 eq www

And finally, we’ll delete a line without deleting the entire ACL.

router#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

router(config)#ip access-list extended MYTESTACL

router(config-ext-nacl)#no 120 permit icmp 10.10.10.0 0.0.0.255 any

  (**note the sequence number)

router#sh access-list MYTESTACL

Extended IP access list MYTESTACL

    100 permit ip 10.10.10.0 0.0.0.255 any

    140 permit tcp host 10.10.20.5 host 192.168.87.65 eq www

    160 deny ip 10.10.20.0 0.0.0.255 any

    180 permit tcp 10.10.30.0 0.0.0.255 host 192.168.87.65 eq www

Note that you don’t have to resequence your list every time you make a change.

10 Questions To Ask During An Information Security Interview

I’m getting ready to help screen some candidates for an information security consultant position, and I decided to jot down a few questions to ask. These won’t be the only questions being asked, of course, but just a few that came to mind. Anyway, I thought they were worth sharing.

The key here for me is not so much getting the perfect technical answer, but more so not getting a lame one. In other words, we’re looking to filter out those who don’t have the right skills and/or mindset rather than guarantee a good fit. I’ll highlight the things I’m looking for with each question.

1. Where do you get your security news from?Here I’m looking to see how in tune they are with the security community. Answers I’m looking for include RSS feeds for solid sites like rootsecure, secguru, astalavista, whitedust, internet storm center, etc. The exact sources don’t really matter. What does matter is that he doesn’t respond with, “I go to the CNET website.” (and nothing else). It’s these types of answers that will tell you he’s likely not on top of things.
2. If you had to both encrypt and compress data during transmission, which would you do first, and why? If they don’t know the answer immediately it’s ok. The key is how they react. Do they panic, or do they enjoy the challenge and think through it? I was asked this question during an interview at Cisco. I told the interviewer that I didn’t know the answer but that I needed just a few seconds to figure it out. I thought out loud and within 10 seconds gave him my answer: “Compress then encrypt. If you encrypt first you’ll have nothing but random data to work with, which will destroy any potential benefit from compression.”
3. What kind of computers do you run at home? Good answers here are anything that shows you he’s a computer/technology/security enthusiast and not just someone looking for a paycheck. So if he’s got multiple systems running multiple operating systems you’re probably in good shape. What you don’t want to hear is, “I like to leave my computers at work.” I’ve yet to meet a serious security guy who doesn’t have a considerable home network.
4. What port does ping work over? A trick question, to be sure, but an important one. If he starts throwing out port numbers you may want to immediately move to the next candidate. Hint: ICMP is a layer 3 protocol (it doesn’t work over a port) A good variation of this question is to ask whether ping uses TCP or UDP.
5. How exactly does traceroute/tracert work? This is a fairly technical question but it’s an important concept to understand. It’s not natively a “security” question really, but it shows you whether or not they like to understand how things work, which is crucial for an infosec professional. If they get it right you can lighten up and offer extra credit for the difference between Linux and Windows versions.The key point people usually miss is that each packet that’s sent out doesn’t go to a different place.Many people think that it first sends a packet to the first hop, gets a time. Then it sends a packet to the second hop, gets a time, and keeps going until it gets done. That’s incorrect. It actually keeps sending packets to the final destination; the only change is the TTL that’s used. The extra credit is the fact that Windows uses ICMP by default while Linux uses UDP.
6. Describe the last program or script that you wrote. What problem did it solve? This is a trick as well. All we want to see is if the color drains from the guy’s face. If he panics then we not only know he’s not a programmer (not necessarily bad), but that he’s afraid of programming (bad). I know it’s controversial, but I think that any high-level security guy needs some programming skills. They don’t need to be a God at it, but they need to understand the concepts and at least be able to muddle through some scripting when required.
7. What are Linux’s strengths and weaknesses vs. Windows?Look for biases. Does he absolutely hate Windows and refuse to work with it? This is a sign of an immature hobbyist who will cause you problems in the future. Is he a Windows fanboy who hates Linux with a passion? If so just thank him for his time and show him out. Linux is everywhere in the security world.
8. What’s the difference between a risk and a vulnerability?As weak as the CISSP is as a security certification it does teach some good concepts. Knowing basics like risk, vulnerability, threat, exposure, etc. (and being able to differentiate them) is important for a security professional.
9. What’s the goal of information security within an organization? This is a big one. What I look for is one of two approaches; the first is the über-lockdown approach, i.e. “To control access to information as much as possible, sir!” While admirable, this again shows a bit of immaturity. Not really in a bad way, just not quite what I’m looking for.A much better answer in my view is something along the lines of, “To help the organization succeed.”This type of response shows that the individual understands that business is there to make money, and that we are there to help them do that. It is this sort of perspective that I think represents the highest level of security understanding — a realization that security is there for the company and not the other way around.
10. Are open-source projects more or less secure than proprietary ones? The answer to this question is often very telling about a given candidate. It shows 1) whether or not they know what they’re talking about in terms of development, and 2) it really illustrates the maturity of the individual (a common theme among my questions).My main goal here is to get them to show me pros and cons for each. If I just get the “many eyes” regurgitation then I’ll know he’s read Slashdot and not much else. And if I just get the “people in China can put anything in the kernel” routine then I’ll know he’s not so good at looking at the complete picture.

    The ideal answer involves the size of the project, how many developers are working on it (and what their backgrounds are), and most importantly — quality control. In short, there’s no way to tell the quality of a project simply by knowing that it’s either open-source or proprietary. There are many examples of horribly insecure applications that came from both camps.

The goal of these questions is to get a feel for how the person thinks and approaches problems — not so much how strong they are technically (that’s a different set of questions). Experience shows that it’s better to have open-minded and adaptive problem solvers who can find information as needed rather than know-it-alls who live in a small mental box.:

OSPF LSA Types

I was working through Narbik's OSPF labs and ran across a few notes that I took in the class. I believe way too many network engineers get stuck when it comes to LSA types and Narbik did a great job teaching us the concepts. Here is a nice visio I did to capture the concepts! Let me know how these help you out. Let me first try to explain the different LSA types and then you can take a look at the diagram for better understanding.

• LSA 1 (Router LSA)

Generated by all routers in an area to describe their directly attached links (Intra-area routes). These do not leave the area.

• LSA 2 (Network LSA)

Generated by the DR of a broadcast or Nonbroadcast segment to describe the neighbors connected to the segment. These do not leave the area.

• LSA 3 (Summary LSA)

Generated by the ABR to describe a route to neighbors outside the area. (Inter-area routes)

• LSA 4 (Summary LSA)

Generated by the ABR to describe a route to an ASBR to neighbors outside the area.

• LSA 5 (External LSA)

Generated by ASBR to describe routes redistributed into the area. These routes appear as E1 or E2 in the routing table. E2 (default) uses a static cost throughout the OSPF domain as it only takes the cost into account that is reported at redistribution. E1 uses a cumulative cost of the cost reported into the OSPF domain at redistribution plus the local cost to the ASBR.

• LSA 6 (Multicast LSA)

Not supported on Cisco routers.

• LSA 7 (NSSA External LSA)

Generated by an ASBR inside a NSSA to describe routes redistributed into the NSSA. LSA 7 is translated into LSA 5 as it leaves the NSSA. These routes appear as N1 or N2 in the ip routing table inside the NSSA. Much like LSA 5, N2 is a static cost while N1 is a cumulative cost that includes the cost upto the ASBR.