• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

Firewall

Router versus Firewall: What are the differences?

06/22/2020 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email
router versus firewall

There seems to be some confusion about the differences between the router and firewall. One of the contributing factors to this is that device manufacturers tend to combine the functionalities into one device. Traditionally, these devices are specialized hardware that does a specific job well.

Both of these devices have advantages and disadvantages over the other, unique features, and different purposes. In this article, we will define what they are, identify their primary use in your network, and explain why you may need both.

What is a router?

A router is a device that quickly forwards data from one network to another. For example, for your devices to communicate to the Internet, you need a networking device to transmit the traffic from your home to the Internet Service Provider (ISP). Typically, this device is a router that either you purchased or provided by your ISP.

The type of router found in most homes and some small businesses is called a wireless router. The wireless router combines the functionalities of multiple devices: wireless access point, switch, and a router.

Furthermore, a lot of routers in the market provide some level of network security by including features like Network Address Port Translation (NAPT), Stateful Packet Inspection (SPI), etc.

What does a router do?

The principal function of a router is to route network traffic between networks. The job of a router is similar to the role of the United States Postal Service (USPS). The router tries its best to forward the data between the sender and the receiver in different networks.

Since the majority of routers in a lot of small businesses are wireless routers, they also allow the connection of wired and wireless devices such as computers, printers, mobile devices, etc.

What is a firewall?

A network-based firewall is a device that provides security by monitoring incoming and outgoing traffic and makes a decision whether to allow or deny specific traffic based on the rule sets.

For many years, the firewall has been an integral part of any successful security program. It serves as the first line of defense in network security.

Today’s modern operating systems, such as Windows and macOS, include a software firewall that provides added network protection. A software host-based firewall functions similarly to a traditional network-based firewall.

Nowadays, firewall manufacturers add extra features like anti-malware, Intrusion Prevention System (IPS), application awareness, URL filtering, etc. referred to as a next-generation firewall (NGFW). An NGFW offers far improved security than a router or a traditional firewall.

What does a firewall do?

The principal function of a firewall is to provide network protection by blocking unwanted traffic. A job of a firewall is similar to the role of the Transportation Security Administration (TSA). The firewall inspects network traffic to make sure everything looks good before it is allowed to pass through.

Some firewalls designed for small businesses or branch offices also combine functionalities of wireless routers, allowing both wired and wireless network connectivity.

Which one should you buy?

Unfortunately, the answer to this question is it depends. Determining the right device for your business requires an understanding of the goals and requirements.

For a small coffee shop, a wireless router from your favorite retailer may be sufficient. For some small and medium-sized businesses (SMB), they may opt to purchase NGFW for better security.

In some scenarios, you might need to purchase both a router and a firewall. For example, if a branch office has the following requirements: WAN connectivity options (both wired and wireless), VoIP, switching, NGFW, and computing. Then, buying a router that can do the majority of these requirements and a separate NGFW could be a suitable solution.

There are some instances where you don’t want to, by default, restrict network traffic. For example, in higher education space, the researchers may expect no restrictions and a fast network to transfer data between each other.

Summary

Both devices can provide a level of network security. However, NGFW gives a higher level of protection compared to a router with some firewalling features.

Choosing between a router and a firewall will vary from one company to another. The key to determining the proper device is by gathering the requirements, goals, and business and technical constraints.

If security is paramount to your company, then purchasing a next-generation firewall with a subscription to the advanced features is the right way to go.

Still unsure on what to get?

Let us answer your questions by contacting us. We’ll help you with hardware selection, design, configuration, and implementation.

LET’S TALK

NetworkJutsu provides networking and network security consulting services for startups, a more established small and medium-sized business (SMB), or large business throughout the San Francisco Bay Area.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Securing Cisco ASA SSH server

07/15/2018 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Last year, I wrote a post about securing the Cisco IOS SSH server. It also makes sense to create one for Cisco ASA especially when my old post about enabling SSH on Cisco ASA was back in 2012. That blog post didn’t include the advanced configurations that will improve the security of the Cisco ASA SSH server. With this post, I’d like to share the minimum advanced SSH configurations that network engineers should consider adding to their ASA template.

Enabling Cisco ASA SSH server

Before we can connect to our Cisco ASA via SSH, we need to have a checklist of things we need to configure.

  1. While it’s a good idea to have enable password configured, it is optional for SSH.
  2. You must have at least one user account locally.
  3. Configure ASA’s authentication method. The authentication method can be local, RADIUS, or TACACS+.
  4. Generate RSA key pair.
  5. Configure ACL to allow a specific IP address or range(s).

Setting enable password

My old post covered how to set enable password. It’s the same command on how to set the enable password, but in the newer ASA software, it uses PBKDF2 to encrypt the password compared to the MD5-based hash in older ASA software.

ASA5506(config)# enable password strongpasswordhere
ASA5506(config)# sh run | i enable password
enable password $sha512$5000$XEBAb1W7gNRdaxFbPHiF6A==$NlSiKyjZpreT3hbRL9gBsg== pbkdf2

Generating RSA keys

As covered in my old post, to enable SSH on the ASA, we’ll need to generate RSA key pair first. Current NIST recommendation is to use 2048-bit or above. In this post, I am going to use 4096-bit key pair.

ASA5506(config)# crypto key generate rsa modulus 4096

SSH Version

Configuring the Cisco ASA SSH server to accept only version 2 is best practice. The reason for this is because SSHv1 has vulnerabilities. That said, make sure to add this to your ASA template.

ASA5506# show ssh 
Idle Timeout: 10 minutes Versions allowed: 1 and 2 
<-- Output omitted --> 
ASA5506# config t 
ASA5506(config)# ssh version 2 
ASA5506(config)# show ssh 
Idle Timeout: 10 minutes Version allowed: 2 
<-- Output omitted -->

SSH Encryption Algorithms

By default, it seems that the ASA’s encryption algorithm is configured to use the medium settings. Unfortunately, I cannot seem to verify it using the show run all command. However, the combination of show ssh and show ssh ciphers does the trick.

ASA5506# show ssh
Idle Timeout: 10 minutes
Versions allowed: 2
Cipher encryption algorithms enabled:	 aes128-cbc   aes192-cbc   aes256-cbc   aes128-ctr   aes192-ctr   aes256-ctr
<-- Output omitted -->
ASA5506# show ssh ciphers
Available SSH Encryption and Integrity Algorithms
Encryption Algorithms:
	all:	 3des-cbc     aes128-cbc   aes192-cbc   aes256-cbc   aes128-ctr   aes192-ctr   aes256-ctr
	low:	 3des-cbc     aes128-cbc   aes192-cbc   aes256-cbc   aes128-ctr   aes192-ctr   aes256-ctr
	medium:	 aes128-cbc   aes192-cbc   aes256-cbc   aes128-ctr   aes192-ctr   aes256-ctr
	fips:	 aes128-cbc   aes256-cbc
	high:	 aes256-cbc   aes256-ctr
<-- Output omitted -->

The client and server negotiate the encryption algorithm. That said, it is possible that the client would pick a weaker cipher. To avoid that, we’re going to specify the use of a safer cipher. According to this thread, the use of EAX or GCM is preferable when available. If not, the use CTR over CBC mode. By specifying the encryption algorithm, we’re telling ASA to only offer the AES-256-CTR mode to any clients that try to connect to it.

Here’s the verbose output of my SSH to a Cisco ASA using the default SSH cipher encryption.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->
debug2: ciphers ctos: aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
debug2: ciphers stoc: aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
<-- Output omitted -->

Let’s configure the ASA to only use AES256 CTR mode.

A5506(config)# ssh cipher encryption custom aes256-ctr ASA5506(config)# show ssh Idle Timeout: 10 minutes Version allowed: 2 Cipher encryption algorithms enabled:  aes256-ctr Cipher integrity  algorithms enabled:  hmac-sha1    hmac-sha1-96

Here’s the verbose output of my SSH connection to a Cisco ASA device using the SSH cipher encryption configuration mentioned above.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->
debug2: ciphers ctos: aes256-ctr
debug2: ciphers stoc: aes256-ctr
<-- Output omitted -->

SSH Integrity Algorithm

By default, it seems that the ASA’s integrity algorithm is configured to use the medium settings. Unfortunately, I cannot seem to verify it using the show run all command. However, the combination of show ssh and show ssh ciphers does the trick.

ASA5506# show ssh
Idle Timeout: 10 minutes
Version allowed: 2
Cipher encryption algorithms enabled:	 aes256-ctr
Cipher integrity  algorithms enabled:	 hmac-sha1    hmac-sha1-96
<-- Output omitted -->
ASA5506# show ssh ciphers
Available SSH Encryption and Integrity Algorithms
<-- Output omitted -->
Integrity Algorithms:
	all:	 hmac-sha1    hmac-sha1-96 hmac-md5     hmac-md5-96
	low:	 hmac-sha1    hmac-sha1-96 hmac-md5     hmac-md5-96
	medium:	 hmac-sha1    hmac-sha1-96
	fips:	 hmac-sha1
	high:	 hmac-sha1

The default setting for the ASA SSH integrity algorithm is medium. Which means, it will accept both HMAC-SHA1 and HMAC-SHA1-96. The difference between the two algorithms is the digest length. The HMAC-SHA1-96 is a truncated message digest. From my limited understanding, the HMAC-SHA1-96 is the weakened version of HMAC-SHA1 due to the shortened message digest.

Here’s the verbose output of my SSH to a Cisco ASA using the default SSH integrity algorithm.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->
debug2: MACs ctos: hmac-sha1,hmac-sha1-96
debug2: MACs stoc: hmac-sha1,hmac-sha1-96
<-- Output omitted -->

Let’s configure the ASA to only use HMAC-SHA1.

ASA5506(config)# ssh cipher integrity custom aes256-ctr
ASA5506(config)# show ssh
Idle Timeout: 10 minutes
Version allowed: 2
Cipher encryption algorithms enabled:	 aes256-ctr
Cipher integrity  algorithms enabled:	 hmac-sha1

Here’s the verbose output of my SSH connection to a Cisco ASA device using the SSH integrity algorithm configuration mentioned above.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->
debug2: MACs ctos: hmac-sha1,hmac-sha1-96
debug2: MACs stoc: hmac-sha1,hmac-sha1-96
<-- Output omitted -->

SSH Key Exchange

The ASA support two Diffie-Hellman key exchange methods and these are DH Group 1 (768-bit) and DH Group 14 (2048-bit). By default, the ASA is set to use Diffie-Hellman Group 1. Unfortunately, this is below what NIST recommends to use in this day and age.

Here’s a Cisco ASA with default SSH key exchange configuration. I issued the no ssh key-exchange to be sure.

ASA5506(config)# no ssh key-exchange
ASA5506(config)# sh run all | i ssh key-exchange
ssh key-exchange group dh-group1-sha1

Here’s the verbose output of my SSH connection to a Cisco ASA using the default SSH key exchange.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->
debug1: kex: algorithm: diffie-hellman-group1-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha1 compression: none
<-- Output omitted -->

Let’s configure the ASA to use DH Group 14.

ASA5506(config)# ssh key-exchange group dh-group14-sha1

Here’s the verbose output of my SSH connection to the Cisco ASA after changing the key exchange method.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->
debug1: kex: algorithm: diffie-hellman-group14-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha1 compression: none
<-- Output omitted -->

SSH ACL

Restricting remote management to a certain IP address is a best practice. It is also required to add the ACL, or we won’t be able to access the Cisco ASA via SSH. That said, I included the command here.

ssh 192.168.1.0 255.255.255.0 management

Final Words

All of the configurations covered here are what I’d say minimum security standard for all Cisco ASA devices. It is, after all, a network security device, so it is a must to secure it properly. Though this post is just a small part of protecting the management plane and network engineers must incorporate other security configurations.

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

NetworkJutsu provides networking and network security consulting services for startups, a more established small and medium-sized business (SMB), or large business throughout the San Francisco Bay Area.

Want to learn more about ASA?

Cisco ASA: All-in-one Next-Generation Firewall, IPS, and VPN Services (3rd Edition)
Cisco ASA for Accidental Administrators: An Illustrated Step-by-Step ASA Learning and Configuration Guide

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Enabling SSH on Cisco ASA

02/15/2012 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Update: Securing Cisco ASA SSH server

Enabling SSH has been covered here but it only talked about routers and switches. How about Cisco ASA? Today, I had to learn how to do it using CLI and not ASDM since I couldn’t find where the equivalent of aaa authentication ssh console LOCAL and crypto key gen rsa mod 4096  in the ASDM. Since I am really new to Cisco ASA, I am not well-versed in issuing commands under CLI. If you are in a similar situation, I suggest to buy this book. Having said that, I’ve always used ASDM when checking out rules, NATs, and etc but I can understand some of the CLI config. Without further ado, here’s how to enable SSH on a Cisco ASA.

ASA-5505# conf t
ASA-5505 (config)# enable password password_here encrypted
ASA-5505 (config)# username user_here password password_here encrypted privilege 15
ASA-5505 (config)# aaa authentication ssh console LOCAL
ASA-5505 (config)# ssh 192.168.0.10 255.255.255.0 inside
! Obviously, you can add/change IPs that you want to allow SSH from.
ASA-5505 (config)# domain-name networkjutsu.com
ASA-5505 (config)# crypto key gen rsa mod 4096
ASA-5505 (config)# ssh version 2
ASA-5505 (config)# ssh key-exchange group dh-group14-sha1

As you know, it is a good idea to enable SSH and disable Telnet. Since ASA does not enable SSH and/or Telnet by default, you have less to worry about. But if you have to choose between them, of course pick the SSH.

I hope this has been helpful and thank you for reading!

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

Want to learn more about ASA?

Cisco ASA: All-in-one Next-Generation Firewall, IPS, and VPN Services (3rd Edition)
Cisco ASA for Accidental Administrators: An Illustrated Step-by-Step ASA Learning and Configuration Guide

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use