Building out a VPC Part 2

Following on from my previous post, we’ll now continue building out our VPC and perform some tests to prove all is as it should be (and as secure as it should be).

Security Groups

Security Groups are our firewalls in the AWS cloud, they allow us to permit/deny protocol and port access level.

We’re going to create two new Security Groups, one to permit the outside world across the www into our public facing instance – a web server as an example.

Our second SG will be permitting our EC2/public facing resources to talk to our backend – perhaps we have our database tier in the private addressing space.

Navigate to your VPC Dashboard and select “Security Groups” from the left hand pane.

Create a new Security Group. Give it a useful name, description and associate it with your VPC. Hit “Create”.

Select your newly created SG and add your required rules. This is our web facing instance in our public subnet, therefore for this web server we’re going to allow SSH and HTTP access from the internet.

Here you can see I have added two rules into the “Inbound Rules” tab within the SG. The top rule allows me to SSH into my instances sharing the same Security Group, and the second allows clients to come in over TCP/80 – HTTP.

To prove this SG we’ll spin up an EC2 instance and check two things:

  • If we can SSH into the instance
  • If the instance can get out to the internet.

There are a few details we need to make sure are correct on the “Configure Instance Details” screen, these are:

  • Network – You want the instance provisioned into your VPC
  • Subnet – You want the instance in the correct public subnet we created earlier
  • Auto-assign Public IP – As this is going to be a public facing instance/server, we want a public IP address to be automatically configured for us.

Before we try to SSH to our newly created instance we need to assign it to the Security Group we created earlier for our public facing instances.

Navigate to “Actions > Networking > Change Security Groups”.

Deselect the wizard SG, as that was created when we spun up the instance and select the appropriate SG that was created earlier to permit SSH and HTTP. This step could have been set during instance creation, but I find it easier to do it post as I get a better feel for what the new instance can and can’t do.

SSH

Attempt to SSH into the instance via PuTTy. If you’ve not done this before I suggest reading this article as the process if different for MAC and Windows.

Grab your instances public IP address – right hand side of the “Description” tab and head over to PuTTy.

Populate your hostname and save the session for future use if required. Then navigate down the left pane to SSH > Auth and browse for your PPK file which will authenticate you and permit you into the instance.

Head back to the Session window and hit Open, if successful you’ll receive the below screen. If this fails it’s likely to be a PuTTy issue with the ppk file, an Security Group issue or a issue with your instance being in the wrong subnet.

Hit Yes here.

We’ve now successfully SSH’d into our AWS EC2 instance, which resides in our configured subnet, inside our VPC.

Increase your privileges using the command “Sudo Su” – this is a Linux VM we’ve created.

Let’s see if our instance in the public subnet can get out to the internet to Yum repositories for example, to update. We know we can get in, but can it get out?

Looks good.

Web Server

We know we can SSH into our instance, as we’ve just done that, but how can we tell if port 80 (HTTP) is open. To test that we’re going to install Apache onto the instance and create a little web page for us to target.


This command will install Apache onto our instance and turn it into a web server.

Now change directory to /var/www/html and create an index.html file, which will be the file our web server will present when we try and access it over the web!

Type a message, or add some ascii art 😉 and exit and save via a CTRL+x and Return.

As you can see, our newly created index.html file now sits in the /var/www/html directory for us to hit when we browse to our server – all going well.

The final thing to do before testing is to start the httpd service, which will make our web server listen for incoming request on port 80.

We can confirm the server is now listening by looking at it’s open ports


The acid test is bringing up the webpage (index.html) in a browser so let’s try that.

And there we are, we’re now serving web pages to anyone on the internet from our EC2 web server. This sits in our defined subnet, inside our VPC, and is restricted by our Security Groups.

That was another long one, so in part 3 we’ll:

  • Spin up a backend server and drop it into our Private Subnet
  • Secure the backend, so only the instances in our public subnet can talk to it – not anyone on the internet!
  • Create a NAT Gateway, so our instances in the private subnet can get secure internet access.

I.

Favourite AWS Services

I’m a fan of Amazon Web Services. Mainly from a technical perspective, as it’s not necessarily cheaper to move from on-prem to on-cloud – so always read the small-print before uplifting your whole datacentre ;). Infact, it interested me so much I sat the Certified Solutions Architect exam last year and thoroughly enjoyed going through the material and labbing along the way.

I like to keep a track of updates to current AWS services, but also new ones that are released and thought I’d highlight 5 of my current favourite offerings.

5. Elastic Compute Cloud (Amazon EC2)

EC2_Icon

EC2 is the bread and butter of AWS. It provides you with all the compute grunt you could ever wish for or need. Need 5 Linux VMs for a web server cluster? Or how about the ability to auto-scale when demand requires it, then spin those same servers down automatically when demand tails off? Don’t worry, EC2 can do just that, as well as a vast amount more.

To spin up an EC2 instance (VM) you have a few options. You can:

  • Use their quick start utility, which provides you with ~30 of the most popular AMI’s (Amazon Machine Images) to choose from. Think your standard, hardened versions of Amazon Linux, RedHat, SUSE, Fedora and then your Windows and Ubuntu variants too
  • Choose an AMI that you have created yourself, perhaps a specific build of server with pre-install software
  • Head over to the AWS Marketplace and utilise for free, or buy specific software that runs in the cloud. Think F5 from Big-IP, Splunk or Juniper etc
  • Launch a community AMI that has been created by a member of the community

It’s frighteningly easy to get up and running, just make sure to terminate the instance/s when you’re finished playing otherwise the costs can soon start to build without you even knowing.

Intro to EC2 Video

4. Kinesis

Kinesis_Icon

If you’re interested in processing or analyzing streams of data – think Twitter for example, then Kinesis and  is a really useful service.

You can use it to build custom applications to collect and analyze streaming data for a bespoke set of needs or requirements. One example could be monitoring Twitter for every time the tag #JustinBieber (whoever he is….) is seen, then pushing that data through Firehose to the analytics engine to present users with personalised content – graphs, diagrams, feeds etc. Powerful stuff.

As per AWS Kinesis FAQs , a Kinesis stream flow:

Kinesis_Flow

Amazon Kinesis Streams enables you to build custom applications that process or analyze streaming data for specialized needs. You can continuously add various types of data such as clickstreams, application logs, and social media to an Amazon Kinesis stream from hundreds of thousands of sources. Within seconds, the data will be available for your Amazon Kinesis Applications to read and process from the stream.

3. Trusted Advisor

Trusted_Advisor

Trusted Advisor is like having your own AWS architect on-hand, 24 hours a day, to audit your AWS account and tell you where it’s vulnerable, where you could save money and how you could increase performance. Whenever you want.

Trusted_Advisor_Checks

It’s pretty simple – if you use AWS, you should be using TA.

2. Identity & Access Management

IAM

IAM is certainly in the top 3 of the most important AWS services. With it you can pretty much control all access to all of your accounts resources, whether they be groups or individuals.

Straight out of the box you will want to create users (then swallow your root credentials to keep them safe…) and manage their identities by granting generic or bespoke permissions. This way they’ll only have access to the resources they need.

1. Virtual Private Cloud (VPC)

VPC

As a Network bod myself, VPC is of real interest to me. It allows you to provision you own isolated CIDR block, allocate subnets and configure routing tables, all within AWS. You can then architect your solutions in a virtual network that you have defined and could, in theory replicate your on-prem, private IP schema’s in the cloud!

You can also create a hardware Virtual Private Network (VPN) connection between your corporate datacenter and your VPC and leverage the AWS cloud as an extension of your corporate datacenter.

AWS VPC FAQ.

I feel that the VPC gives a little bit back to the Network Engineer, as in they’ve just seen half their DC shifted to VM’s in the cloud so still get to play with IP subnetting and IP allocation in the Cloud.

A Quick AWS explanation of VPC can be found here.

If you want more AWS content than any normal person could ever be able to digest, then head over to the AWS YouTube channel.

I.

AWS_Services_Feature_Image

My Tech Visits

During the working day – over lunch usually, and when I have some time to waste I’ll frequent a number of tech related sites so I thought I’d jot them down here for reference.

Packet Pushers

Packet_Pushers_Logo

http://packetpushers.net/

I don’t visit the Packet Pushers website too often, but they are probably my most frequently listened to podcast. There are some informative blog posts on their site and you can also access all of the podcasts there too.

The Register

the_register_2

https://www.theregister.co.uk/

The Register is easily my number one IT news website I visit. It not only has up to date news, but the writers add their own satirical/comical slant on the news, which I really like. Highly recommended.

IPSpace

IP_Space

http://www.ipspace.net/

IPSpace is an networking orientated blog not affiliated to any vendors (for the record) that’s run by CCIE #1354 Ivan Pepelnjak. On this blog you’ll find excellent articles, webinars, books relating to architectures, real-life solutions, technologies and more.

Packet Life

Packet_Life

http://packetlife.net/

Packet Life is a blog by Jeremy Stretch, an extremely knowledgeable network engineer who enjoys sharing what he’s learned with his readers.

There are some fantastic networking cheat sheets on this site, along with lots of great tech posts, packet capture trace files, software and book recommendations and much, much more. Definitely worth a look.

I.

the_register

TCPDUMP’ing

Within Network Security & Support roles it’s normal practice to, at some point, have to jump onto a CLI and start messing around with tcpdump.

For me it’s usually when there’s a connectivity issues either between two hosts, i.e. server/client or server/server. That’s where TCPDUMP is a massive help, as packets don’t lie. If you can show said server/developer bod, in black and white what is going on, they can’t argues – although they still may. 😉

If I had a penny for every time a colleague blamed a firewall or the network for why their server isn’t communicating as it should, I’d be a wealthy man.

Below are some of my most frequently utilised tcpdump commands and switches, and what they do and print.

My Favourite TCPDUMP Commands

tcpdump -i any host 10.1.1.1 and host 10.2.2.2

This is a good starter to see all traffic between two hosts. After you’ve confirmed you’re receiving output you can then look to add further switches to filter further.

Useful Switches

tcpdump -D shows the interfaces you can capture on

tcpdump -i any will capture traffic on all available interfaces

Use -c to stop your tcpdump after a specific number of packets have been captured

To display IPs and not hostnames use the -n switch

The default packet capture byte size is 65535, i.e. the full packet, therefore if you only want to capture the first 64 or 96 bytes of each packet, use the -s switch

-S will turn off relative sequence numbers and give you the complete, harder to read strings

Use the -w <filename>.pcap to write a capture to a file, but use -v to display how many packets have been captured to file.

You can view your written capture files on the CLI, however they display just the same, therefore I prefer to review them in Wireshark.

That’s a whole series of blog posts in itself though, happy capturing 🙂

I.

Ubuntu_TCPDUMP

 

Ansible & GNS3 Lab

With the constantly moving landscape in IT it’s always worth your while to get to know new stuff, if nothing more than to know what someone in a meeting is talking about.

To that extent I’ve recently been playing around with Ansible, which is a method to automate IT infrastructure – Networking kit in my realm. I’d read through a few articles on the web and so far I’ve built the beginning of a Cisco Ansible lab within GNS3 so wanted to share this with you.

Taken from the Ansible website:

“Ansible delivers simple IT automation that ends repetitive tasks and frees up DevOps teams for more strategic work.”

Or, for me as a Network Engineer, it can stop me having to log into 30 different switches to create a new vlan :p.

What I Have

At the moment I have the following setup, which I’ll run through:

  • 2 Routers setup in GNS3
  • an Ubuntu server VM
  • Ansible comms from VM into GNS3 and the ability to run Ansible code on the Ubuntu server and retrieve output from the Routers in GNS3

How It’s Setup

  1. Firstly I downloaded the latest Ubuntu Desktop image off their website and created myself a VM within VM Workstation in my case, but you can you Oracle Virtual Box or VM Player.

Ubuntu_Desktop

You will then want to update the VM with the latest repository code and install Ansible, so you’ll need to make sure the VM has internet access.

  1. Update all of your packages

sudo apt-get update -y

Sudo will raise your privileges to a root user and the -y switch will accept any forthcoming yes/no prompts during the update.

2. Update your VM firewall – May be required depending on Ubuntu version

sudo ufw allow 22

3. Install Ansible on your Ubuntu VM

sudo apt-get install software-properties-common

sudo apt-add-repository ppa:ansible/ansible

sudo apt-get update -y

sudo apt-get install ansible

4. Create your lab within GNS3

Create a new project and drag a Cloud onto your topology window. Then configure your Cloud to reside on the same subnet as you plan to have your 2, 3, 4, 20 routers on.

GNS3_Cloud_Config

In my case I have all of my devices on the Host-only network 1, however I have also given my Ubuntu server a second NIC, which is NAT’d to my local host so it has internet access. Oh and I changed the icon of my cloud to be a server, as it looks prettier……

VM_Network

5. Configure your end-hosts that you want to pull config from using Ansible. In our case these are our routers.

*Your IP’s will obviously relate to the subnet your hosts reside in and your interface will be whatever you’ve chosen.

conf t

interface fa0/0

ip address 192.168.134.25 255.255.255.0

no shut

You should now, all being well be able to ping between your Ubuntu VM and your routers, and vice versa.

R1#ping 192.168.134.131

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.134.131, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/16 ms
R1#

R2#ping 192.168.134.131

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.134.131, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/9/12 ms
R2#

ish@ubuntu:~$ ping 192.168.134.25
PING 192.168.134.25 (192.168.134.25) 56(84) bytes of data.
64 bytes from 192.168.134.25: icmp_seq=1 ttl=255 time=9.18 ms
64 bytes from 192.168.134.25: icmp_seq=2 ttl=255 time=4.23 ms
^C
— 192.168.134.25 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.230/7.758/11.212/2.658 ms
ish@ubuntu:~$
ish@ubuntu:~$ ping 192.168.134.30
PING 192.168.134.30 (192.168.134.30) 56(84) bytes of data.
64 bytes from 192.168.134.30: icmp_seq=1 ttl=255 time=9.48 ms
64 bytes from 192.168.134.30: icmp_seq=2 ttl=255 time=11.1 ms
^C
— 192.168.134.30 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 4.042/7.733/11.194/2.785 ms
ish@ubuntu:~$

* If ping doesn’t work it’s always worth turning off your Windows firewall temporarily a re-check.

6. Configure SSH on your end-hosts

I am using 3725 series Cisco Routers in my lab – IOS c3725-adventerprisek9-mz.124-25d.bin, but you should be OK using any router image as long as it supports K9 – just remember to set that Idle PC!

conf t

ip domain name lab

crypto key generate rsa general-keys modulus 1024

aaa new-model

aaa authentication login default local

username cisco secret cisco

enable secret cisco

7. Add your end-host IP addresses to the /etc/ansible hosts file within your Ubuntu VM

ish@ubuntu:~$ cd /etc/ansible/

ish@ubuntu:/etc/ansible$ sudo nano hosts

[Routers]

R1 ansible_host=192.168.134.25

R2 ansible_host=192.168.134.30

Ctrl + x + y to save your edited file and exit out

ish@ubuntu:/etc/ansible$ cat hosts

R1 ansible_host=192.168.134.25
R2 ansible_host=192.168.134.30

ish@ubuntu:/etc/ansible$

8. Test your configuration

We can run the following command from the command line of our Ubuntu VM.

cd /etc/ansible

ansible all -m raw -a ‘show version | i uptime’ -u cisco -k

You should be prompted for the device password and if that’s entered correctly the following should be printed.

ish@ubuntu:/etc/ansible$ ansible all -m raw -a ‘show version | i uptime’ -u cisco -k
SSH password:
R2 | SUCCESS | rc=0 >>
R2 uptime is 2 hours, 4 minutes
Shared connection to 192.168.134.30 closed.

R1 | SUCCESS | rc=0 >>
R1 uptime is 2 hours, 4 minutes
Shared connection to 192.168.134.25 closed.

ish@ubuntu:/etc/ansible$

There we have it. I plan to delve into this much more and the use of Ansible Playbooks, but to simply test Ansible commands over SSH this should do nicely.

Router Config, if required, can be found here.

I.

GNS3_Lab

The First (of Many)

Hi, welcome to my blog. I hope in the coming weeks, months and years this blog will be filled with useful posts to interest a wide range of tech readers.

The main focus will involve aspects of my job, as a Network Security & Support Engineer, and notably revolve around Cisco, but also a few other vendors. I tend to lab plenty, therefore I plan to share these with you.

I am a Cisco Certified Networking Professional, hence the Cisco focus, but also an AWS Certified Solutions Architect, therefore expect some post on the current king of the cloud too.

Thanks for coming by.

I.

post

Website Powered by WordPress.com.

Up ↑