Tuesday, April 12, 2016

Creating Global Aliases in Linux (CentOS 7/RHEL 7)

If you're like me and like to use aliases to simplify administration of your Linux servers, here's the easy way to create global aliases for all users.

  • Create a file in /etc/profile.d such as aliases.sh.
  • Add your aliases to the file.
  • Log off and log back on.
  • Your aliases should work.

As an example, I do a lot of administration through my smart phone (Nexus 6P on Google Fi), so I hate typing long commands. The two commands I use more than any others are "sudo yum -y update" and "exit". (Okay, "exit" isn't a long command, but still...)

Here's the contents of the aliases.sh file I created in /etc/profile.d:
alias yu="sudo yum -y update"
alias x="exit"

Now, all I have to do to run a yum update is type "yu" and all I have to do to exit is type "x".

I can (and will) add whatever other aliases I want to simplify my life to /etc/profile.d/aliases.sh.

Hope that helps.

Peace.

Saturday, February 13, 2016

Allowing PING Through an ASA

The ASA Security Appliance, by default, blocks ICMP packets which includes PING. In the following post, I'll show you how to create an Access-Control List (ACL) which will permit ICMP traffic through the firewall from the inside to the outside.

In order for an ACL to have any effect, it must be applied to an interface or a function.  In the following example, the ACL is designed to permit inside hosts to ping hosts on an outside network such as the public Internet. In the example shown, “101” is just a label for the list. It could just as easily be a descriptive name such as “permit_ping”. (ICMP stands for Internet Control Message Protocol, the protocol used by ping and some other network utilities.)

The first four lines in the following example identify and permit the traffic flows.  The last line applies the list to inbound traffic on the outside interface.  Note the use of the “access-group 101” statement which applies access-list 101 to the interface.

access-list 101 permit icmp any any echo-reply
access-list 101 permit icmp any any source-quench
access-list 101 permit icmp any any unreachable 
access-list 101 permit icmp any any time-exceeded
access-group 101 in interface outside


The above access-control list permits several types of ICMP traffic in addition to ping packets. If you want to allow only ping packets, use the following commands:

access-list 101 permit icmp any any echo-reply
access-group 101 in interface outside


The above post is taken from my book Cisco ASA Security Appliance for Accidental Administrators, available in Kindle and paperback editions through Amazon and other resellers.

Monday, March 30, 2015

Installing dig and host on a Windows computer

I'm getting ready to teach a class on BIND DNS for a client. I thought you might find a quick and easy guide to installing the dig and host utilities on Windows systems helpful, so here it is.

To Install dig and host on a Windows Computer

The dig and host utilities are available for Windows computers. This guide assumes you’re running a 64-bit version of Windows. If you’re running a 32-bit system, the procedures are similar, but not the same.

Download the BIND package from www.isc.org/downloads. As of this writing, the recommended package is 9.10.2. Download the 64-bit version for Windows.

The download is a .zip file. Open the .zip file and copy the following files to %SystemRoot%\System32\ (copying files into %SystemRoot%\System32\ requires admin privileges):

  • dig.exe
  • host.exe
  • libbind9.dll
  • libdns.dll
  • libeay32.dll
  • libisc.dll
  • libisccfg.dll
  • liblwres.dll
  • libxml2.dll

The 64-bit version also requires the Microsoft Visual C++ Redistributable package, which is available at http://www.microsoft.com/en-us/download/details.aspx?id=30679#. Download it and install it before continuing.

Once you’ve installed the Visual C++ Redistributable package and copied the above files into System32, you can run dig and host from a command prompt. In the following screen capture, I ran a dig query in Windows Powershell.


Also, check out my Linux server book, based on CentOS 6.5/6.6 at http://amzn.com/1453689923


Monday, December 29, 2014

Learning the Cisco IOS

I've been absent from this blog for a while, because I'm working on completing two more books in the Accidental Administrator series. I'm hoping to finish both of them by the end of January and then I can get back to blogging.

In the meantime, I just received an email from a reader asking about using a Cisco 1720 router to learn IOS commands and thought I'd share my response here.

I used to own six 1720s and found them excellent for learning, experimenting, and teaching. Are you familiar with GNS3 (www.gns3.com)? It's a free router emulator platform which is used by millions of people to learn and test Cisco IOS commands. You have to provide the router software, but GNS3 itself is free. It supports the following platforms: 7200, 3600, 3620, 3640, 3660, 3700, 3725, 3745, 2600-series, and 1700-series. An easy way to get the software is to purchase one of the supported routers, making sure that the router you purchase has the most recent version of the software, such as 12.3 or 12.4. It's important to realize that on older platforms such as those supported on GNS3, the most recent software available could be three or four years old. Still, for practicing basic IOS commands, setting up access-control lists, and experimenting with routing protocols, the older versions of the software will be helpful.

Several of the screen captures from The Accidental Administrator Cisco Router Step-by-Step Configuration Guide were taken using emulated routers running in GNS3.

Hope that helps.

Sunday, February 23, 2014

What is a Default Gateway?

If you're new to networking, you've probably heard the term default gateway and wondered what it meant. You see it in the IP address configuration on hosts and routers, but what does it do?

The default gateway, also known as simply the gatewaythe default route, and on Cisco routers as the gateway of last resort, is the path packets use when there is no explicit route to a destination. Without a default gateway, each host would have to have a routing table containing explicit paths to every host on the Internet, an absurd and unworkable solution. When we configure a default gateway, we're saying to the host, "If you don't know what else to do with a packet, send it to the default gateway and let the gateway figure out what to do with the packet."

In order for a host's default gateway to work, there are certain criteria that must be met:
  • It must be an interface on a network already known to the host (If it's not known to the host, how will the host know how to get the packets to the gateway?)
  • It must be an interface on a device connected to the rest of the world, usually the public Internet.
Consider this diagram in which the three computers connected to the Cisco ASA use the ASA's inside interface as their gateway. The ASA then uses the ISP's router as its gateway.
In the above scenario, suppose the top laptop wants to visit a website, say www.soundtraining.net. It probably doesn't have an explicit route in its local routing table for www.soundtraining.net's IP address, so it hands the request off to its default gateway, the ASA. The ASA also doesn't have an explicit route in its routing table for www.soundtraining.net's IP address so it hands the packet off to its default gateway, which is the ISP's router. The process may be repeated through several routers before the packet finally arrives at its destination. You can see the entire process by using the command traceroute www.soundtraining.net in a terminal window.

One word of caution, on hosts with multiple interfaces, you can sometimes end up with multiple default gateways which can produce unpredictable results. Generally, you want only one default gateway configured per device, regardless of the number of interfaces on the device.

For More Resources for I.T. Pros

You'll find books on Cisco and Linux technologies at my bookstore at soundtraining.net/bookstore. Also, check out my video channel at soundtraining.net/videos.

Please Leave a Comment

If you find this networking tutorial helpful or if you notice something that needs to be corrected, please leave a comment.

Monday, December 23, 2013

Basic DNS Client Troubleshooting or How to Solve Name Resolution Problems

Sometimes, the network is up, all the link lights are on, pings by IP address work fine, but you still can't connect to a website. A likely culprit is name resolution.

The Name Resolution Process

Suppose you need to connect to www.soundtraining.net. Here's what happens when you type that URL into your browser:
  • Your computer has to find a way to associate www.soundtraining.net with an IP address. It's a lot like looking up a phone number in an old-fashioned phone book.
  • In the early days of the Internet, every host had a hosts file which held the hostname-to-IP address mapping for every host on the Internet. Although most systems today use DNS, all computers still contain a hosts file which usually takes precedence over other name resolution methods. On computers running modern Windows operating systems such as Windows 7 or 8, the hosts file is located in c:\windows\system32\drivers\etc.
  • Most computers maintain a local DNS cache containing the hostname-to-IP address mappings from previous lookups. A computer first checks its DNS cache to see if there's an entry for it from a previous connection attempt or from a static entry in the hosts file. (Computers running modern versions of the Windows operating system pre-load entries from hosts files into the DNS cache. Other operating systems may handle hosts file entries differently.)  On computers running the Windows operating system, you can view the contents of the DNS cache with the command ipconfig /displaydns. (Hint: You can filter the output using PowerShell's select-string capability. For example, the output of ipconfig /displaydns can get pretty lengthy. If you want to check for the existence of a particular text string, such as soundtraining.net, use the following syntax in PowerShell:
    ipconfig /displaydns | select-string -pattern "soundtraining.net".)
  • If the requested hostname doesn't exist in the DNS cache, the DNS resolver (the client) queries DNS servers in the order listed in the computer's configuration.
  • If the DNS server(s) is not reachable or can't resolve the hostname to an IP address, an error is returned.

Troubleshooting DNS and Name Resolution

Here are some steps to help you perform basic troubleshooting of name resolution issues.
  1. Confirm that name resolution is the issue by pinging the target host first by hostname, such as www.soundtraining.net, then by IP address. If the ping by hostname fails, but the ping by IP address is successful, the problem is most likely a name resolution issue.
  2. Determine the scope of the issue. If local name resolution works, but Internet name resolution doesn't, the problem is most likely with the service provider's DNS server. Try changing to the Google DNS servers (8.8.8.8 or 8.8.4.4) or OpenDNS servers (208.67.222.222 and 208.67.220.220) as a way of testing. If, on the other hand, Internet name resolution works, but local resolution doesn't the problem is most likely on the local DNS server.
  3. Check the TCP/IP settings on the local computer. If the problem exists on only a single computer, check its TCP/IP settings.
  4. Use the nslookup tool (it's included with most operating systems) to test connectivity with a DNS server. It's a powerful tool with many options, but it can also be used to perform a simple DNS query using the following syntax:
    nslookup soundtraining.net
    A simple query such as this will tell you whether name resolution is working at all and, if it is, which DNS server is being queried first. If nslookup returns an error stating that the server can't be reached, check for connectivity issues with the DNS server. If it returns an error stating that the domain or host doesn't exist, there's a problem with the DNS server configuration. If it returns what you believe to be a correct response, the problem may be an incorrect entry in the DNS cache or even an incorrectly configured hosts file.
  5. Check to see how widespread the problem is. If it's just users on a single subnet, it could be a misconfigured DHCP server providing incorrect IP settings.
  6. Check for malicious software. If the user is being directed to questionable websites, their computer may have been compromised with software that intercepts name resolution requests and redirects them to undesirable websites.
  7. Check the DNS cache with the command ipconfig /displaydns for incorrect entries or just do a precautionary clearing of the DNS cache with the command ipconfig /flushdns (administrator privileges are required to clear the DNS cache).
  8. Check for an incorrect entry in the hosts file. (This is not very likely, but it has happened to me when I made changes in the hosts file for testing purposes and forgot to change it back.)
  9. Try a reboot. As with most things digital, sometimes the problem can't be identified, but it can be solved with a reboot. This is especially true if you're using consumer grade routers that act as DNS forwarders, which is most of them. Just power-cycle the router or DNS server to see if the problem goes away.

DNS Troubleshooting Tools

The following tools and websites may also be helpful in name resolution troubleshooting.
BIND is the most commonly used DNS server. A download of BIND includes the dig utility which provides similar functionality to nslookup. You can download BIND from http://www.isc.org/downloads/.

For More Resources for I.T. Pros

You'll find books on Cisco and Linux technologies at my bookstore at soundtraining.net/bookstore. Also, check out my video channel at soundtraining.net/videos.

Please Leave a Comment

If you find this tutorial helpful or if you notice something that needs to be corrected, please leave a comment.

Wednesday, December 4, 2013

The Beginning Network Admin's Network Troubleshooting Checklist

I've recently been asked to work with groups of non-network admins to help them understand the basics of computer networks. Each of the groups has, as part of their jobs, installation of proprietary systems that must integrate with existing computer networks. None of the people in these classes is ever going to use tools like Fluke network testers or similar tools. They simply need to be able to install their software or hardware and do basic network troubleshooting. If that sounds like your situation, or if you're a new network administrator, here is a simple, ten-step checklist for network troubleshooting. It should be helpful for both beginning network administrators and non-network admins, too.
  1. Do a quick check of the rest of the network. Before you start running all kinds of tests on your system, check to make sure the rest of the network is functioning properly. Are other people or systems on the network having the same or similar problems as you? The problem may have nothing to do with your system or configuration.
  2. Gather information. What has changed since things were working properly? Has any new software been installed? Has any new hardware been installed? What settings may have been changed, either by you, another administrator, a vendor, or an end user? Have there been any power outages? Have there been any maintenance crews doing work which involved moving network equipment? Ask end users what was being done at the time of the failure. (Be careful not to be accusatory when asking questions like this. You want to get honest, helpful answers. You don't want people to get defensive or try to hide things.)
  3. Start at the physical layer. Check link lights, power cables, circuit breakers, cables, heat and dust (too much of either will down any electronic device including routers, switches, access points, firewalls, and servers). You can purchase an inexpensive cable tester for around $40.00. Such testers can be helpful, but if you don't have one, test a cable by replacing a known working cable with the cable in question. If it works with the first cable, but not the second, you've identified the problem. Make sure network cards are enabled. Check in the network settings on each affected device to ensure that network cards are enabled and active.
  4. Use ping, tracert (traceroute in Unix/Linux/Cisco), and pathping to test connectivity. Use ping within a single IP subnet and tracert or pathping when multiple IP subnets are involved. Here's how to use ping: Start by pinging your localhost (ping localhost or ping 127.0.0.1), then ping the IP address of the system you're working on, then ping another host on the same subnet, then ping the default gateway, and finally ping a remote system on another subnet. If all of the pings work except the remote system, try using tracert or pathping to see where connectivity fails. Try a ping by hostname instead of IP address. If a ping by hostname doesn't work, but a ping by IP address does work, the problem is most likely related to name resolution. See my post on DNS client troubleshooting.
  5. Check the routing table. If pings to systems on different networks fail, check the routing table for explicit entries, the correct default gateway, or duplicate default gateways (there should be only one). On a Windows computer, use the command route print to see the routing table. On a Cisco router, use the command show ip route.
  6. Check IP address settings. Use the Windows command line utility ipconfig to make sure the IP address is what you expect.
  7. Check for problems with MTU size. Use the mturoute tool to check MTU sizes on the network.
  8. Check for DHCP server connectivity. If you see an address starting with 169.254, that's an indication that the device or system could not reach a DHCP server to get an IP address.
  9. Is the IP address on the correct network? Check to ensure that the IP address of the device is on the same network or subnet as the rest of the devices. (If the subnet mask is 255.255.255.0 or /24, check to ensure that the first three octets of each of the connected devices match.)
  10. Check for a firewall blocking traffic. If you can ping out from a device, but not to the device, a likely culprit is a firewall on the device. Check the security settings. If the Windows firewall is disabled, check to see if a third-party firewall is enabled such as ZoneAlarm or Norton Internet Security. I once was stymied in troubleshooting by a surprise firewall that was included with a VPN client, so check for any other security-oriented software that might include a firewall.
Most network administrators have plenty of stories about forehead-slapping moments in troubleshooting when they missed something obvious. By following the above steps, hopefully you'll avoid flattening your forehead.

For More Resources for I.T. Pros

You'll find books on Cisco and Linux technologies at my bookstore at soundtraining.net/bookstore. Also, check out my video channel at soundtraining.net/videos.

Please Leave a Comment

If you find this networking tutorial helpful or if you notice something that needs to be corrected, please leave a comment.