Archive for the ‘ Security ’ Category

Building a Juniper Lab with Remote Access – The Access Gateway

GNS3 is a great tool that can help us in many ways. One thing that may not be very evident, however, is how we can set up our GNS3 lab for remote access so we can practice when we’re not at home. The aim of this article is to show you how to do that.

This is part one in a series. This article describes how to install OpenBSD in a virtual machine (using VirtualBox). We go through the initial installation as well as assigning IP addresses to our interfaces. In part 2, we install Python and write a Python script that controls access to our gateway server.

This article assumes that you have already created virtual machines in VirtualBox before. If you have not, it is extremely intuitive. If you still need help, please see the VirtualBox website (here) or search Google.

Before we get started, here is our finished product in GNS3:

10 routers connected to a switch.  Two interfaces on a server connected to same switch.  Cloud connected to same switch

GNS 3 Topology

First, please create a new Virtual Machine with the OS type of BSD and OpenBSD. You can use the defaults throughout the wizard. Now open up the settings for the VM. Go to the storage tab and set the CD/DVD image to be the install50.iso you obtained from the OpenBSD website (here). Next, go to the Network tab. We need two interfaces. One will be bridged while the other will be internal.

The bridged adapter will be the one that is on our physical LAN. It is what will let us into the box. The internal adapter will get us to the actual GNS3 lab, but it will not automatically pass traffic between the GNS3 lab and our LAN (and thus the internet). In this way, although we have given ourselves remote access to the GNS3 lab (through this OpenBSD server), we have also isolated the GNS3 lab because there are no routes on the OpenBSD box. We will later use hostnames on the OpenBSD box to simplify accessing equipment, but there still will be no routes.

Next, start your VM. Press enter at the “boot>” prompt. The system will run through some internal loading and present you with the following screen:

Installation screen for OpenBSD 5.0

Installation Screen

Please accept the defaults until you get to the network configuration. For em0, we will want to use DHCP. This is our first adapter–the one that is bridged. When that is finished, you should see it ask you if you wish to configure any additional interfaces. We do. Type “em1.”

The screen for if em1

Interface em1 Configuration

Now we need to enter some information. I use the following to match the requirements of my GNS3 lab:

  • IP Address – 10.0.0.1
  • Subnet Mask – 255.255.255.240 – This mask accommodates 14 interfaces total. My lab example has 11.

The installation will ask you to set a root password. Do this. Also create a new user with a password. Enable sshd by default. Disable root login for sshd.

Enter defaults until the system asks if you want to use a graphical environment, XWindows. Say no here. We don’t need a GUI.

No GUI option

Removing X Windows

Again, accept defaults until it asks you if you would like to create a new add or remove packages. YES! We want to remove all of the XWindows packages and the games package. Prepend the package name with a hyphen to remove it. So, enter the following commands:


-xserv50.tgz
-xfont50.tgz
-xshare50.tgz
-xetc50.tgz
-xbase50.tgz
-games50.tgz

Removing X WIndows and Games

Remove Packages

If there are more prompts, accept defaults. Finally, type reboot to restart the system. Remove the installation media.

At this point, we have a working OpenBSD system and gateway to the GNS3 network. We could stop here, but we are going to go farther in future articles because we might want to have access to this system for more than one person.

To access your network, be sure you open your firewall to the IP of your OpenBSD system. SSH to your public IP. You will be directed to your OpenBSD server. From here, ssh or telnet to your GNS3 routers.

Please ask if you have questions!

Feature Lab Friday #3 – Securing Telnet Access

Feature Lab Friday #3 – Securing Telnet Access

This coincides with the previous JNCIA Question of the Week regarding how to secure access via telnet. Our objective here is to limit telnet access to a router to only a specific subnet. We want to allow telnet access only from the router’s loopback address. To test this, we will make use of advanced pinging techniques available in the Junos software.

First, we will assume that you have two routers configured in the following way:

  • R1 – em0.0 172.16.0.1/30
  • R1 – em1.0 192.168.1.1/24
  • R1 – lo0.0 10.1.1.1
  • R2 – em0.0 172.16.0.2/30
  • R2 – em1.0 192.168.2.1/24
  • R2 – lo0.0 10.2.2.2

We will assume that you have the em0.0 interfaces directly connected to each other. We will also assume that we have routes to all subnets, whether they are statically or dynamically configured.

First, log into R2 and issue the following command:
telnet source 192.168.2.1 10.1.1.1
It should succeed. Now issue this command:
telnet source 10.2.2.2 10.1.1.1
This should also succeed. Right now, we can telnet to this device from anywhere in the world. We’re going to apply a firewall filter that allows us to restrict telnet access to R1 to only the 10.2.2.2 address. Obviously this isn’t very practical in the real world since you would only be able to access R1 by first being in R2, but this will give you an idea as to how to configure for a more practical situation.

The following commands will restrict telnet access to R1. Only the 10.2.2.2 IP address will be able to access the router remotely.

[edit]
root# edit firewall filter restrict-telnet term accept-telnet

[edit firewall filter restrict-telnet term accept-telnet]
root# set from source-prefix-list trusted-subnets

[edit firewall filter restrict-telnet term accept-telnet]
root# set from protocol tcp

[edit firewall filter restrict-telnet term accept-telnet]
root# set from destination-port telnet

[edit firewall filter restrict-telnet term accept-telnet]
root# set then accept

[edit firewall filter restrict-telnet term accept-telnet]
root# up

[edit firewall filter restrict-telnet]
root# edit term reject-telnet

[edit firewall filter restrict-telnet term reject-telnet]
root# set from protocol tcp

[edit firewall filter restrict-telnet term reject-telnet]
root# set from destination-port telnet

[edit firewall filter restrict-telnet term reject-telnet]
root# set then discard

[edit firewall filter restrict-telnet term reject-telnet]
root# up

[edit firewall filter restrict-telnet]
root# set term accept-other-traffic then accept

[edit firewall filter restrict-telnet]
root# top

[edit]
root# set policy-options prefix-list trusted-subnets 10.2.2.2

Now, if we try to telnet from our 192.168.2.0/24 subnet, telnet will simply hang.

root> telnet source 192.168.2.1 10.1.1.1
Trying 10.1.1.1…
^C
root>

But if we telnet from the 10.2.2.2 address, we will get our login prompt:

root> telnet source 10.2.2.2 10.1.1.1
Trying 10.1.1.1…
Connected to 10.1.1.1.
Escape character is ‘^]’.

(ttyp0)

login:

JNCIA Question of the Week #4 – Securing Remote Access

JNCIA Question of the Week #4

After several weeks off due to heavy work load and vacation, we’re back with the JNCIA Question of the Week. And to start the week off, we’re going to be asking a more complicated question than has been customary.

Q:

This week, we want to allow telnet access only from a specific subnet.

Assume we have the following scenario:

  • Two routers directly connected through their em0 interfaces on the 172.16.0.0/30 subnet
  • R1’s lo0.0 address is 10.1.1.1
  • R2’s lo0.0 address is 10.2.2.2
  • R1 has the 192.168.1.0/24 network attached to its em1 interface
  • R2 has the 192.168.2.0/24 network attached to its em1 interface
  • We only want to allow telnet access to R1 from R2 from the 10.2.2.2/32 address.

What firewall filter(s) need to be created, to which device(s) and interface(s) must it/they be applied to and in which direction (ingress/egress), and how can we verify the firewall filter(s) work as intended?

This is a very open-ended question. Substitute IP addresses as you want. These were provided strictly as guidelines.

The answer to this week’s question will not be provided until Friday due to its complexity relative to previous questions. Also on Friday will be a Feature Lab Friday detailing how this can be accomplished and why we would want to accomplish such a thing.

[edit]

A:

Please refer to the post here for details on how to answer this question.
[/edit]