Configure static NAT for inbound connections

Configure static NAT for inbound connections

by : David Davis
(June 6th, 2007)

Someone recently asked me how to configure Network Address Translation (NAT) so that computers on the Internet could access his internal Web and mail server through his Cisco router. This requires configuring a static NAT translation between the dedicated public IP address and the dedicated private IP address. Here’s how to do it.

Most people use NAT to connect to the Internet these days. NAT transforms private IP addresses to public IP address so users can access the public Internet. Most of us use a form of NAT called Port Address Translation (PAT), which Cisco refers to as NAT overload. (For more information, see “Set up NAT using the Cisco IOS” and “Set up Port Address Translation (PAT) in the Cisco IOS.”)

To start off, let’s get a better idea of what we’re working with. Figure A offers a diagram to help visualize the network.




Our example network

Here’s our goal: We want to configure a static IP translation through the router from the outside (i.e., Internet) network to the inside (i.e., private) network.

On a Linksys router with a basic Web interface, this isn’t very hard to do. However, on a Cisco router using the command-line interface (CLI), you’ll struggle if you don’t know the proper commands or where to apply them.

It’s a good idea to gather the data you’ll need before you start. Here’s the information we need for our example:

* Router inside interface E0/0: IP 10.1.1.1
* Router outside interface S0/0: IP 63.63.63.1
* Web/mail server private IP: 10.1.1.2
* Web/mail server public IP: 63.63.63.2

There are two important steps to get this traffic inside your network and to your Web/mail server:

1. NAT configuration
2. Firewall configuration

In this post, I’ll provide the basic static NAT configuration. However, make sure that whatever you’re using for your firewall also allows this traffic in.

Whether you’re using basic access control lists (ACLs) or the Cisco IOS firewall feature set, make sure you understand the Cisco IOS order of operations to configure your firewall for the right IP addresses (public or private). In other words, what happens first — NAT translation or firewall filtering? For example, when using ACLs, a check of the input ACL occurs before NAT translation. So, you need to write ACLs with the public IP addresses in mind.

Now that we’ve covered the background info, let’s get started with configuring static NAT. For our example, let’s say we start out with this basic configuration:

interface Serial0/0
ip address 63.63.63.1 255.255.255.0
ip nat outside

interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip nat inside

We need the NAT translations to translate the outside IP address of the Web/mail server from 63.63.63.2 to 10.1.1.2 (and from 10.1.1.2 to 63.63.63.2). Here’s the missing link between the outside and inside NAT configurations:

router (config)# ip nat inside source static tcp 10.1.1.2 25 63.63.63.2 25
router (config)# ip nat inside source static tcp 10.1.1.2 443 63.63.63.2 443
router (config)# ip nat inside source static tcp 10.1.1.2 80 63.63.63.2 80
router (config)# ip nat inside source static tcp 10.1.1.2 110 63.63.63.2 110

We used the above port numbers because they fit the description of what we wanted to do, but keep in mind that your port numbers may be different. I chose port 25 for SMTP (sending mail), port 443 for HTTPS (secure Web), port 80 for HTTP (Web traffic), and port 110 for POP3 (receiving mail from the mail server when out on the Internet).

This configuration assumes you have a block of IP addresses. If you don’t, you can use the outside IP address on your router (Serial 0/0 in our case), and you could configure it like this:

router (config)# ip nat inside source static tcp 10.1.1.2 25 interface serial 0/0 25

You can even use this command if you have a dynamic DHCP IP address from your ISP on the outside of your router.

We also need to register the IP address of the mail and Web server in the global Internet DNS registry. So when users enter www.mywebserver.com in their Web browser, the browser would translate it to 63.63.63.2, and the router would then translate it to 10.1.1.2. The Web server would receive that request and respond back through the router, which would translate it back to the global IP address.

In addition to configuring static NAT, you may want to use dynamic NAT at the same time. With this, your inside PCs could access the Internet using dynamic NAT (i.e., NAT overload or PAT). But this gets a little more complex. For more information, see Cisco’s Configuring Static and Dynamic NAT Simultaneously documentation.

David Davis has worked in the IT industry for 12 years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

David DavisDavid Davis has worked in the IT industry for 15+ years and holds several certifications, including CCIE, CCNA, CCNP, MCSE, CISSP, VCP. He has authored hundreds of articles and numerous IT training videos. Today, David is the Director of Infrastructure at Train Signal.com. Train Signal, Inc. is the global leader in video training for IT Professionals and end users. Read his full bio and profile.

article source = www.techrepublic.com

Get to know your logging options in the Cisco IOS

Get to know your logging options in the Cisco IOS

by
David "Davis CCIE, MCSE+I, SCSA.
(15 Juni 2006)

Takeaway: Knowing how to properly use logging is a necessary skill for any network administrator, and the Cisco IOS offers many options for logging. To help bring you up to speed, David Davis discusses how to configure logging, examines how to view the log and its status, and looks at three common errors when it comes to logging.


Knowing how to properly use logging is a necessary skill for any network administrator. It's vital that you know how to use logging when it comes time to start troubleshooting.

The Cisco IOS offers a great many options for logging. To help bring you up to speed, let's discuss how to configure logging, examine how to view the log and its status, and look at three common errors when it comes to logging.

The logging command in Global Configuration Mode and the show logging command in Privileged Mode are two simple but powerful tools to configure and show all Cisco IOS logging options. Let's take a closer look.

Configure logging in the Cisco IOS

When configuring logging, the most important command to know is the logging command, used when in Global Configuration Mode. Here's an example of this command and its options.

router(config)# logging ?

Hostname or A.B.C.D IP address of the logging host
buffered Set buffered logging parameters
buginf Enable buginf logging for debugging
cns-events Set CNS Event logging level
console Set console logging parameters
count Count every log message and timestamp last occurrence

exception Limit size of exception flush output
facility Facility parameter for syslog messages
history Configure syslog history table
host Set syslog server IP address and parameters
monitor Set terminal line (monitor) logging parameters
on Enable logging to all supported destinations
origin-id Add origin ID to syslog messages
rate-limit Set messages per second limit
reload Set reload logging level
server-arp Enable sending ARP requests for syslog servers when
first configured

source-interface Specify interface for source address in
logging transactions

trap Set syslog server logging level
userinfo Enable logging of user info on privileged mode enabling


router(config)# logging

While the scope of this article prevents us from exploring every one of these options, let's take a look at the most common ones.

You can configure the router to send buffered logging of its events to the memory. (Rebooting the router will lose all events stored in the buffered log.) Here's an example:

Router(config)# logging buffered 16384

You can also send the router's events to a syslog server. This is an external server running on your network. Most likely, the syslog server is running on a Linux or Windows server. Because it's external to the router, there's an added benefit: It preserves events even if the router loses power. A syslog server also provides for centralized logging for all network devices.

To configure syslog logging, all you need to do is use the logging command and the hostname or IP address of the syslog server. So, to configure your Cisco device to use a syslog server, use the following command:

Router(config)# logging 10.1.1.1

To learn more about using syslog with the Cisco IOS, check out this TechRepublic download, "Use syslog to monitor and troubleshooting Cisco devices."

The Cisco IOS enables logging to the console, monitor, and syslog by default. But there's a catch: There's no syslog host configured, so that output goes nowhere.

There are eight different logging levels.

* 0—emergencies
* 1—alerts
* 2—critical
* 3—errors
* 4—warnings
* 5—notification
* 6—informational
* 7—debugging

The default level for console, monitor, and syslog is debugging. The logging on command is the default. To disable all logging, use the no logging on command.

By default, the router logs anything at the level of debugging and greater. That means that logging occurs from level 7 (debugging) up to level 0 (emergencies). If you want to par down what the system logs, use something like the logging console notifications command.

In addition, the router doesn't enable logging to the system buffer by default. That's why you must use the logging buffered command to enable it.
View the status of logging and the logging itself

To view the status of your logging as well as the local buffered log, use the show logging command. Here's an example:

router# show logging

Syslog logging: enabled (0 messages dropped, 394 messages rate-limited,
91 flushes, 0 overruns, xml disabled, filtering disabled)
Console logging: level debugging, 2766982 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 12370 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 2754146 messages logged, xml disabled,
filtering disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Trap logging: level debugging, 3420603 message lines logged
Logging to 10.1.1.1, 3420603 message lines logged, xml disabled,
filtering disabled

Log Buffer (10000000 bytes):
i96
Feb 7 13:34:00.065 CST: %LINK-3-UPDOWN: Interface Serial1/1:22, changed state
to up
Feb 7 13:34:00.069 CST: %DIALER-6-BIND: Interface Se1/1:22 bound
to profile Di96

Note that this router has enabled syslog logging and is sending it to host 10.1.1.1. In addition, console logging is at the debugging level, and the setting for local buffered logging is 10,000,000 bytes.


Look out for these common logging errors

Logging can be frustrating at times. To help prevent some of that frustration, let's look at three common errors.

Not setting the terminal to monitor logging

If you Telnet into a router and can't see some of the logging you're expecting, check to see if you've set your terminal to monitor the logging. You can enable this with the terminal monitor command. To disable it, use the terminal no monitor command.

To determine whether you've enabled monitoring, use the show terminal command, and look for the following:

Capabilities: Receives Logging Output

If you see this, you're monitoring logging output. If it returns None for capabilities, then the monitoring is off.

Using the incorrect logging level

If you can't see logging output, you should also check whether you've set the level correctly. For example, if you've set the console logging to emergencies but you're running debugging, you won't see any debugging output on the console.

To determine the set level, use the show logging command. Keep in mind that you need to set the level to a higher number to see all levels below it. For example, setting logging at debugging shows you every other level.

In addition, make sure you match the type of logging that you want to see with the level you're configuring. If you configure monitor logging to debug but you're on the console and you've set it to informational, you won't see the debug output on the console.

Displaying the incorrect time and date in logs

You may see log messages that don't exhibit the correct date and time. There are a variety of options to control the date and time that appear on logging output (either to the screen or to the buffer). To control this, use the following command:

Router(config)# service timestamps debug ?
datetime Timestamp with date and time
uptime Timestamp with system uptime


Remember that many problems require some kind of historical log to help find a solution. That's why it's important to make sure you've properly configured logging so you can use your logs to see the past.

Miss a column?

Check out the Cisco Routers and Switches Archive, and catch up on David Davis' most recent columns.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

David Davis has worked in the IT industry for 12 years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.

source : www.techrepublic.com

10 dumb things you can do to your Cisco router and how to fix them

10 dumb things you can do to your Cisco router and how to fix them

Author: David Davis

(December 4th, 2008)

TechRepublic author Deb Shinder detailed network administrator mistakes in her very popular article “10 Dumb Things IT Pros Do That Can Mess Up Their Networks.” Deb’s 10 Things article inspired me to come up with one of my own with Cisco routers as the focus.

——————————————————————————————————————

As IT pros, we have many stories about end users who did something dumb with their computers (how many times have you heard the CD-ROM drive as a cup holder story?). However, we tend to keep our Cisco networking mistakes to ourselves, right? I am not too bashful to admit that I have taken down a network before due to a dumb mistake that could have been prevented (but I won’t tell you what it was). In order to help other network admins avoid costly mistakes, I’ve come up with a list of 10 dumb things you can do to your Cisco router.

#1: Not having a backup of your Cisco router configuration

While these aren’t listed in any particular order, if they were, I would say that this belongs at the top of the most common router mistakes. Picture this: your Cisco router dies, but you’re getting a replacement overnight, so your boss is ecstatic. However, you, as the Cisco network admin, can’t seem to make the router pass traffic as you have no backup of the config. Don’t get put in the doghouse over this. It’s easy to make a backup using:

Router# copy running-configuration tftp

Built into routers with newer IOS versions is IOS configuration archiving. This can automatically copy your router’s configuration off of the router when configuration changes are made. To learn more about it read, “Use the Cisco IOS Archive Command to Archive Your Router’s Configuration.”

Also, there are many third-party GUI applications that will schedule this for you so that you can “set it and forget it.” For example, see my article on Kiwi CatTools and products from ManageEngine OpUtils and PacketTrap pt360 Pro.

#2: Not having a backup of your Cisco router IOS software

Not only is a Cisco router completely useless if it isn’t properly configured, but it is also useless if it has no IOS or it has the wrong IOS. As a Cisco network admin, you had better have a repository of all the different Cisco IOS router and switch IOS versions in use on your network today, stored on a file share somewhere.

By doing this, you can copy the proper IOS back onto a Cisco router that is shipped to you from Cisco or reconfigure another Cisco router (say an older router off the shelf) to take the place of a broken Cisco router.

Backing up the IOS is easy. Just TFTP it to your server with a command like this:

Router# copy flash tftp

And you will be prompted to answer all the questions needed to back up your Cisco IOS.

#3: Not having spare router hardware

I have found Cisco hardware to be extremely reliable. Still, I have had to replace both Cisco routers and switches periodically, over the years. These days, it’s not acceptable for the Internet connection to be down for a few days should a Cisco router go bad or an interface in the router start taking errors. You must be prepared to replace that hardware at a moment’s notice. The replacement hardware must have the same configuration (or a config that delivers the same network connectivity to the end users) and the IOS should also be the same (or offer the same features as needed by the config).

Trust me, you don’t want to be making calls all over the country asking if anyone can overnight you a router for a hefty charge.

If you aren’t going to have spare hardware on site, you should at least have a Cisco SmartNET contract on your router hardware that is able to deliver a replacement router to you in an acceptable amount of time.

#4: Never document changes

When you discover that you are having networking issues, the first questions are always “when did this start?” and “did we change anything?” By setting up a change documentation or change management procedure, you can have a history of changes — what was changed and when. If you set up change management, you typically also have approval processes in there so that someone must have tested and then approved the changes before they went in.

Another way to document changes is to use router configuration archiving. To learn more about it read “Use the Cisco IOS Archive Command to Archive Your Router’s Configuration.”

#5: Don’t log your router events

When issues do come up in the network, you first want to check out router logs. Not only should you have some buffered logs on the router for temporary storage, you should also have a central syslog repository of Cisco router logs. Cisco IOS logging is easy to configure, and you can use a free Linux syslog server or buy one for Windows such as Kiwi Syslog.

To learn all about configuring logging in the Cisco IOS, please see my article “Get to Know Your Logging Options in the Cisco IOS.”

#6: Not upgrading your Cisco IOS

Like any operating system, the Cisco IOS periodically has bugs (see tip #7 on searching for bugs). Plus, over time, you will get new routers with new IOS versions and you want router IOS versions to maintain compatibility. For these reasons and others, you need to make sure that your Cisco IOS stays up to date.

To upgrade your Cisco IOS, see my article “Upgrading” and my video on upgrading your Cisco IOS.

#7: Don’t know where to search for Cisco documentation and troubleshooting tips

I get many Cisco IOS technical questions via e-mail, and many of these can be answered by using your favorite search engine. However, here are a couple of tips:

* Use Google search with the “site:cisco.com” keyword to search only for articles on Cisco’s official Web site or the “site:techrepublic.com” keyword to search for articles at TechRepublic.

* Install the Cisco Search Toolbars to your browser. With these, you can search the Cisco Bug database, Command Line lookups, error message decoder, your RMA orders, TAC Service requests, and Cisco netpro discussions. Trust me, these tools are very cool and make it easier to find the answer to your Cisco IOS problem. For more information read “Adding Cisco.com Searches and Tools to Your Browser.”

#8: Forgetting your password and not knowing how to reset it

At some point, you may forget the password on a router. Or, an admin could leave and not tell you the password to a router. While these things can happen, what you need to know is how to reset a lost Cisco router password. To do this, check out these two resources:

* Cisco’s Master Password Recovery Instructions page
* My video on how to reset your Cisco router password

#9: Not securing your router

Security? Who has time for that, right? Well, if you don’t secure your routers and network, it could all be lost (and so could the company’s most critical data). Make sure you follow best practices to lock down your routers and your network. I recommend you start with reading my TechRepublic download on locking down your Cisco IOS router in 10 steps.

#10: Not spending the time to create documentation

Most of us loathe having to create documentation, but let’s face it, we forget things and we aren’t going to be here forever. Wouldn’t you just love to tell a junior admin to “go read my document on how to reset a Cisco router password” when he asks you how to do it? To prevent mistakes and downtime in the future, make sure you keep your Cisco network documentation up to date.

David DavisDavid Davis has worked in the IT industry for 15+ years and holds several certifications, including CCIE, CCNA, CCNP, MCSE, CISSP, VCP. He has authored hundreds of articles and numerous IT training videos. Today, David is the Director of Infrastructure at Train Signal.com. Train Signal, Inc. is the global leader in video training for IT Professionals and end users. Read his full bio and profile.

source : www.techrepublic.com

Five ways to secure your Cisco routers and switches

Fundamentals:
Five ways to secure your Cisco routers and switches

Author: David Davis
(april 2008)

Recently, Cisco Subnet blogger Brad Reese wrote the article, “Expert warns of scam to blackmail companies for cash to get back access to their Cisco routers.” In that post, he wrote about hackers who manage to hijack a company’s routers and then extort money from them by threatening to take down the network. The hackers were able to obtain control of the network because of poorly written Cisco IOS ACLs, easily guessed passwords, and unencrypted SNMP community strings (or easily guessed community strings).

Don’t let this happen to you and your network. Here are my top five best practices to secure your routers, your network, and your company from malicious attacks.

1. Understand the basics of router security

You must understand the basics of router security. Here are the essentials:

Physically secure the routers
If your routers are not physically secured, anyone can walk up, perform a password reset, and gain full access to that router’s configuration. Even if this isn’t a core router, they could take down your network by poisoning the routing tables on all routers. For this reason, routers should be in a locked room and preferably have video surveillance. Additionally, reliable electrical power and cooling must be provided.

Lock down the router with passwords
Routers must be secured with passwords at both the login mode (to prevent initial access) and the privileged mode (to prevent configuration changes). For more information on these different levels in the Cisco IOS, please see my article, “Understand the levels of privilege in the Cisco IOS.”

Apply login mode passwords on Console, AUX, and VTY (telnet/ssh) interfaces
Password controlled access needs not only to be on the VTY lines to prevent network access, but also on the Console and AUX ports. If the Console port is locked but the AUX port doesn’t have a password, then locking the Console wasn’t of much use, was it?

Set the correct time and date
To ensure that logs are correct and have not been tampered with, you must ensure that the router has the correct time and date. For more information, please see “Synchronize a Cisco router’s clock with Network Time Protocol (NTP).”

Enable proper logging
Logging should be enabled, preferably, back to a central source like a syslog server. At minimum, you need to configure a buffered log on the router. However, if the power is lost to that router, that local buffered log is lost. For this reason, to really be secure, you need to configure a syslog server (see the article, “SolutionBase: Monitor your network with Kiwi Syslog“), and send all router logs to that server. You could also put in the open source or commercial version of Tripwire. Preferably, you should increase the level of logging and even log configuration changes to the router. For example, you can use the following command to enable SNMP traps for configuration changes:

snmp-server enable traps config

For more information on Cisco router logging, please see, “Get to know your logging options in the Cisco IOS.”

Back up router configurations to a central source
Let’s say that someone does take control of your router or wipes out your router configurations. To replace that router quickly or replace the configuration, you need to have a backup of that configuration. To do this, ensure that your routers are backed up whenever configuration changes are made or each week or day. I have enjoyed using Kiwi CatTools to do this. For more information, see “Automate changes to your Cisco router with Kiwi CatTools.”

Secure other network devices such as switches and wireless access
Most of the items listed here also apply to Cisco switches and wireless access points. Here are a couple of articles on those topics that you should check out:

* 10 things you should know about securing wireless connections
* Lock Down Switch Port Security

Two more areas that I consider to be at the basic level of router security are locking down network access to the router with a stateful firewall or ACL and encrypting sensitive network traffic, but I will cover these points in more detail below (sections three and five, respectively).


2. Know your network: Diagram, audit, and document

If you are responsible for the security of a network you should know that network like you know the vulnerable doors and windows (think entry points) of your house.

You should diagram your network so that you have a map to help you and others visualize the entire network.

You should have the router configurations backed up (see Kiwi CatTools above). Finally, you should periodically audit your network security, both internally and externally (via a third party). There are tons of network scanning and auditing tools available. Here is a recent article of mine that covered one of them: “Audit your Cisco router’s security with Nipper.”

3. Protect your router with a firewall and ACLs

In Reese’s post about the hackers, he mentioned the fact that the company had poor access control lists (ACLs) in place on their routers. ACLs are typically what protect routers from attack. However, due to their complexity, many of them end up being misconfigured or ineffective. Make sure that your ACLs allow only traffic to the router and through the router that should be there. For internal routers this will only be internal traffic.

Make sure you understand that whatever isn’t permitted will be denied (the implicit deny), that ACLs are processed from the top down, that there should never be a permit any in the ACL, and that the ACL must be applied to an interface in the proper direction to be enabled. For more information on ACLs, please see some of my articles and video on this topic:

* Secure your router with Cisco’s SDM Firewall Policy Wizard
* Cisco IOS access lists: 10 things you should know
* Use advanced parameters on your Cisco IOS ACLs
* VIDEO: Harden your Cisco Router with IOS ACLs

Keep in mind that ACLs aren’t just used to prevent traffic from going through the router. They are also used to control SSH traffic, routing update, and to throttle traffic. For more information, see:

* Learn additional uses for Cisco IOS access control lists
* Control unwanted traffic on your Cisco router with CAR

Besides ACLs, the Cisco IOS offers a real stateful firewall if you use the Security/Firewall version of the IOS. A stateful firewall will be much better than just using ACLs. I recommend checking out my article, “Protect your network with the Cisco IOS Firewall,” and consider implementing one on your routers.

4. Change your passwords and make them complex

Another method that hackers use to take control of networks is password guessing or password sniffing. To prevent this, you should CHANGE YOUR PASSWORDS TO COMPLEX PASSWORDS TODAY. Don’t wait another day! An example of a complex password is MySuper!S3cr3tPa$.

Make sure you always use type 5 password encryption on your routers (see “Be aware of how easily someone can crack a Cisco IOS password“).

Make sure this command is on your router to encrypt most (but not all) passwords with type 5 encryption:

service password-encryption

Also, keep in mind that we aren’t just talking about login passwords. This includes all SNMP community strings and routing protocol update passwords. All of those should be complex and changed periodically.

For more information on this topic, please see, “How to Configure Passwords to Secure your Cisco Router.”

5. Always encrypt sensitive network traffic

Finally, hackers can obtain passwords to your routers by sniffing network traffic when you log in to your router with telnet, perform a “show run” via telnet, or use unencrypted SNMP strings.

You should always encrypt sensitive network traffic by using SSH and SNMP encryption. Start by enabling SSH and disable telnet to all network devices that support it (see “Configure SSH on your Cisco Router“).

If you are using SNMP, enable SNMP v3 with encryption and use it exclusively (for more information, see AES and 3-DES Encryption Support for SNMP Version 3).

Be careful

The point of this article is to (1) encourage you to take action to secure your network before malicious attackers take control of it and (2) to show you exactly which actions you need to take.

You shouldn’t assume that your network isn’t a target because your company isn’t high profile or your data wouldn’t be valuable to an attacker. Take every reasonable step to protect your network; as you can see from this post, these steps aren’t necessarily difficult or costly.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

David DavisDavid Davis has worked in the IT industry for 15+ years and holds several certifications, including CCIE, CCNA, CCNP, MCSE, CISSP, VCP. He has authored hundreds of articles and numerous IT training videos. Today, David is the Director of Infrastructure at Train Signal.com. Train Signal, Inc. is the global leader in video training for IT Professionals and end users. Read his full bio and profile.

souce : www.techrepublic.com