Saturday, September 24, 2016

Configuring SSH on IOS Devices

 on  with No comments 
In , ,  
According to Wikipedia, "Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network.  The best known example is application is for remote login to computer systems by users."  SSH was designed to be a secure replacement for protocols such as telnet, rlogin, and rsh, which transmits data in clear text across the wire.  SSH support a number of additional use cases such as file transfer and forwarding the X protocol, but we'll focus on remote logins as used on Cisco IOS devices here.

SSH comes in two versions, 1 and 2.  Version 1 was found to be susceptible to a remote integer overflow vulnerability, so the newer but incompatible Version 2 was developed.   You'll sometimes see "Version 1.99" used, however this isn't another version but instead it indicates that the SSH server supports both versions 1 and 2.

Moving along to the SSH specific configuration, you want to begin by configuring a hostname for the device.  This is accomplished with the hostname command.  Give this some thought now, because you can't change it once your keys are generated.

Router# configure terminal
Router (config)# hostname R1
R1 (config)#

Next, you need to configure a domain name for the device.  Ideally, you would want to be a valid DNS domain, however, not everyone owns one.  Microsoft has the domain name that it uses for documentation and help files, I'm not sure if Cisco has a similar domain.  Use your own domain, use contoso, or just make one up here.

R1 (config)# ip domain-name

Next, generate or import a certificate for your device.  This certificate will be used to encrypt the SSH packets that your device will send out on the wire.

R1 (config)# crypto key generate rsa
The name for the keys will be:
Choose the size of the key modulus in the range of 36o to 2048 for your
   General Purpose keys. Choosing a key modulus greater than 512 may take
    a few minutes.

How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

Note the name of the keys, which corresponds to the FQDN of this device.  Also note the default key length is 512 bits. 

Now that we've generated the key, we'll move on to configuring the VTY lines for SSH access.

R1 (config)# line vty 0 4
R1 (config-line)# login local
R1 (config-line)# transport input ssh

You can configure the VTY lines to accept telent as well as SSH if you have devices that will be accessing this device via the VTY lines that does not support SSH. 

Now we'll need a user.  In this example, we'll keep it simple and use a local user contained within the local device's database.  In addition to the local user database, we can use either RADIUS or TACACS+ as well.

R1 (config)# username alan privilege 15 secret **********

And then finally, let's look at some advanced parameters for SSH.

Configure the switch to run SSH version 1 or 2.  By default IOS devices are set for SSH Version 1.99.

ip ssh version [1 | 2]

Configure the SSH control parameters.  The SSH timeout is for the negation phase. It has a range of 0 to 120 seconds, with a default of 120.  The number of authentication-retries is the number of times a client can re-authenticate to the server.  The range is 0 to 5, with a default of 3.

ip ssh timeout seconds authentication retries number 

After authenticating via SSH, the device will use the default time-out value for CLI sessions.  This is set on the VTY lines with the exec-timeout command.

R1 (config-line)# exec-timeout 15 0

And finally, you have two show commands to monitor SSH.

show ip ssh - shows the version and configuration of the SSH server
show ssh - shows the status of the SSH server


Saturday, September 17, 2016

Discovery Protocols - Part II

 on  with No comments 
In , ,  
In Part One of this series, I covered the Cisco Discovery Protocol.  It is definitely the best known of discovery protocols, and the one that a student of Cisco certifications is going to care most about.  Cisco Discovery Protocol, or CDP, is used by most Cisco network devices to share topology information.  It is also used by a number of other manufacturers who may call their implementation CDP or Industry Standard Discovery Protocol (ISDP) in order to not reference Cisco.  But other manufacturers have their own protocols, and there have been a few attempts at an industry standard over the years.  In this post, I'm going to present a brief overview of a few of these other discovery protocols.  I may also cover one or more of them (particularly LLDP and LLDP-med) more in depth in the future if and when I feel the need to dig in further.  Most of these protocols are well known by Wireshark, and Wireshark will have display filters for those that are known.

Saturday, September 10, 2016

The Official CCNA Group Rules

 on  with No comments 
In , ,  
Group Rules:
1.This is a network for the network associate. All legitimate things CCNA related, as well as most other I.T. topics may be discussed here.
2.Things that may not be discussed here include (but is not limited to): Brain-dumps, any other form of copyright infringement, any illegal activity, spam, politics, and personal attacks. It doesn’t matter if it’s legal where you live, Facebook is an American website. If you like a post, that is considered the same as if you posted it yourself.
3.If says it’s a dump, then it’s a dump and this isn’t open to negotiation.
4.Do not post homework questions with the expectation that the answers will just be provided. We are willing to help if you don’t understand something, but this group isn’t here to just do it for you.
5.The admins, and only the admins, will decide and enforce the rules.
6.Not knowing is no excuse. You shouldn’t be posting anywhere on the Internet if you don’t know the rules. Violators of any rule are subject to immediate banning.
7. No new accounts. No offense to anyone, it's just that accounts newer than 30 days are where the majority of spam comes from. If you get turned away for this, feel free to try again later.
8. No one word answers. If you can't explain why the answer is d, then you don't need to be the 15th person saying d. Contribute something meaningful to the conversation.
9. Don't try to add people to the group. Nobody gets in without an admin's approval, and I do not approve anyone who did not join on their own.

Group FAQ:

Saturday, September 3, 2016

Printer Security

 on  with No comments 
In , ,  
Here's a quick and dirty post on a serious class of vulnerabilities in Hewlett Packard printers, and most likely other manufacturers devices as well.  It's old information, but a lot of the more gruesome details were news to me at the time I read about it.  It caught my attention when I was researching the proper remediation after seeing the vulnerability flagged by a recent scan.  So naturally, rather than just implement the fix stated in HP's bulletin, I made a detour to Google Scholar and did some additional reading.  I'm not one to just take HP at their word that a firmware update will fix you all up.  Especially when the firmware was already the latest greatest and had been since at least January.

To continue to build fear of all these devices being directly connected to the home network, and then to the Internet, Cui, Costello and Stolfo took a look at HP printers.  They presented a case study of the HP-RFU vulnerability which allows an attacker to inject malware into the printer's firmware by simply sending malicious documents to be printed.  This vulnerability is known to effect 373 different LaserJet firmware images.  Prior work shows the same overall design flaws exist in other embedded systems, however HP is the lucky one to be exploited.  The paper mentions that ATMs, enterprise routers, and PBX equipment can also be vulnerable to a similar attack.  The attack is effective against the majority of LaserJet printers on the market at the time.  Sales numbers show 11.9 million units shipped by HP in just one quarter of 2010.

Not only can malware be uploaded to these printers, in some cases it can be injected permanently.  The boot flash used on some of these printers feature a one time programmable (OTP) feature which allows areas of memory to be permanently programmed.  If an attacker were to write to this area of memory, the malware would not be able to be erased or overwritten, it would take a replacement of the chip at a minimum to remediate, which isn't always possible.   And on the extreme end of this vulnerability, an attacker can theoretically set your printer on fire remotely using this technique.  HP has, of course, denied this last charge claiming that safeguards are in place to prevent it.

More concerning than the ease of which these printers are exploitable is the fact that they found so many vulnerable printers directly accessible across the Internet.  In other words, printers that can theoretically receive print jobs directly from anywhere in the world.  After a scan of the IPv4 address space, they were able to identify 90,847 printers in government, educational, and other sensitive institutions.  Of the printers identified, just over 1% were patched.  They also found that 24.8% of the printers that were patched still had open telnet interfaces with no root password.  64% of the vulnerable printers were located in North America.  65% were found within educational institutions.  201 printers were identified within the U.S. Department of Defense.

Not only are the 90,000+ printers noted in the study vulnerable to this attack, but they also contain third party libraries such as zlib and OpenSSL, which are known to contain several other highly exploitable vulnerabilities.  Note that the 90,000 printers identified only contain vulnerable printers which can be exploited by this attack.  There are no doubt countless other printers (and a wide array of devices besides printers) with other flaws available directly on the Internet.

As for the vulnerability being flagged in the August scan despite the firmware being update between 7 and 8 months prior, your guess is as good as mine.