|
|
| (2 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | = Basic AWS networking components =
| + | [http://wiki.littlesvr.ca/wiki/OPS345_Lab_2 This page has moved.] |
| − | | |
| − | The fundamentals you've learned about networking in your previous courses apply to AWS as well. The only difference from what you may be used to is that most of it is virtual in AWS. There are obviously still wires and cables and switches and routers, but their infrastructure has a layer of software on top to allow it to be more dynamic to deploy, configure, and use.
| |
| − | | |
| − | This diagram is a very simple overview of the parts of AWS networking you're going to use in this course:
| |
| − | | |
| − | [[File:AWSVPCComponents.png|center]]
| |
| − | | |
| − | == Security ==
| |
| − | | |
| − | '''You're working on the real inetnet now!''' In many previous courses you were working in VMs on your virtual machines, on private networks, where attackers couldn't get to your servers even if they were super-dedicated and qualified. That is not the case in this course. Now an attacker doesn't even need to know who you are and they can take over your server.
| |
| − | | |
| − | The VMs and networks you create in this course are likely to be accessible by anyone on the planet. That means you ''have to'' think of security.
| |
| − | | |
| − | If you imagine that noone will attack your servers because you have nothing worth attacking: you're wrong. Every CPU connected to the internet is worth something. A most common scenario is an attacker (or organisation) finds a great number of vulnerable servers online, and make those part of a bot net. Then they will use the bot net they created (effectively a supercomputer) to launch attacks on targets that matter to them. They won't spend the time to attack your servers individually, but they have automation that exploits the most common security holes that lazy administrators leave open.
| |
| − | | |
| − | This is not a security course, but you should be able to understand that different parts of your system are susceptible to different types of attacks. The more components you configure with security in mind: the less likely you are to become a victim of an attack.
| |
| − | | |
| − | == VPC ==
| |
| − | | |
| − | The general idea of '''cloud''' is that your servers and services are not physically located on the premises of your business, but somewhere else. Typically wherever you can rent cheaper computers. Cloud providers have the advantage of economies of scale and the great flexibility of resource assignment. When you're not using some component: someone else will pay to use it. So hardware isn't sitting idle getting old and wasting electricity.
| |
| − | | |
| − | VPC stands for '''Virtual Private Cloud'''. That means the resources you're using are not dedicated to you, but they are separated from other users by software configuration. For all but the most high-value targets that's secure enough.
| |
| − | | |
| − | Inside your private cloud you can have networks, file storage, compute (processing VMs), databases, etc.
| |
| − | | |
| − | Access to your resources from the outside is available through an [https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html '''Internet Gateway'''], which does port forwarding. It is used even if your VMs have public IP addresses. That is done in order to simplify securing your resources.
| |
| − | | |
| − | If your software uses any resources from outside your AWS VPC: those will also connect via the Internet Gateway.
| |
| − | | |
| − | == Subnets ==
| |
| − | | |
| − | Your VPC can have any number of private subnets, as long as they fit in the allocated private subnet ranges. In this course we'll use a part of the 10.0.0.0/16 subnet to make two smaller ones. Your VMs will be in 10.3.45.0/25 ('''not 24''').
| |
| − | | |
| − | Your machines on your subnets can automatically connect to each other. They do not have access to the internet automatically.
| |
| − | | |
| − | == Public IPs ==
| |
| − | | |
| − | AWS automatically assigns a public IP to oyur VMs from its pool of addresses. These are dynamic. Every time you shut down your VM and turn it back on: it will get a new public IP.
| |
| − | | |
| − | Note if you look inside a VM: the public IP isn't actually configured as the IP on that interface. The IP is assigned to your VPC, and incoming connections to it are port-forwarded to the VM which you assigned the IP to. This is very different from what you saw in your previous courses.
| |
| − | | |
| − | [[File:AWSIPs.png|800px|border|center]]
| |
| − | | |
| − | You may have configured port forwarding on your router at home at some point to enable some game or service which requires an open port on your public IP address. This is the same idea. On AWS this port forwarding is done via the Internet Gateway.
| |
| − | | |
| − | == Static IPs ==
| |
| − | | |
| − | Private IPs don't cost any money, so they are static by default. AWS has a DHCP system where you can reserve a static address from your private pool for your VM. If you do: the VM will automatically get that static IP from an AWS-configured DHCP server. If you don't: the VM will get an unused IP from the same subnet, and will continue using that dynamically-assigned address even after it reboots.
| |
| − | | |
| − | You can also assign a static public IP to one of your VMs. You could use your own but since you don't own any: your only option here is to use an '''Elastic IP'''. This comes from the same pool of addresses as the dynamic AWS public IPs.
| |
| − | | |
| − | Interestingly Elastic IPs are free when you use them, but cost money if you don't use them. That's because there's a limited pool of public IPv4 addresses, and once you request one of these addresses: noone else can use it. So you better use it, or pay for keeping it from other users. Since our VMs are going to be shut down most of the time: this is one of the costs that will come out of your 100$ credit.
| |
| − | | |
| − | = Your Network Setup =
| |
| − | | |
| − | You need lots of practice to get used to these concepts. It's not enough to just read about them.
| |
| − | | |
| − | * In the AWS Management Console you've looked at EC2 so far. Now open the VPC Management Console. As most things in AWS: this interface is overwhelming at first. Once you go through it several times you'll get more comfortable with it.
| |
| − | | |
| − | == VPC ==
| |
| − | | |
| − | * Click "Your VPCs". Note that there is a default one there which was created automatically with your account. Click '''Create VPC'''.
| |
| − | ** Set the name to vpc-ops345
| |
| − | ** Set the CIDR block to 10.3.45.0/24 (larger than the subnet you will create later)
| |
| − | ** No IPv6
| |
| − | [[File:AWSvpc-ops345.png|800px|border|center]]
| |
| − | | |
| − | == Subnet ==
| |
| − | | |
| − | * Now create a subnet in your new VPC: click on Subnets (note all the default ones, make sure you dont forget to name yours or else you'll quickly get confused). Click '''Create subnet'''.
| |
| − | ** Pick vpc-ops345
| |
| − | ** Set the name to subnet-ops345
| |
| − | ** Availability zone must be us-east-1a, in your environment that's a limitation that comes with using AWS Academy.
| |
| − | ** Set the CIDR block to 10.3.45.0/25 (to fit inside the VPC but leave room for other subnets later)
| |
| − | ** Under "Actions" click "Edit subnet settings" and check "Enable auto-assign public IPv4 address". Don't forget to click Save.
| |
| − | [[File:AWSsubnet-ops345.png|800px|border|center]]
| |
| − | | |
| − | == Internet gateway ==
| |
| − | | |
| − | The machines in your private subnet won't have internet access, even if they have public IP addresses. An internet gateway is required.
| |
| − | | |
| − | * Click Internet Gateways, then '''Create internet gateway'''
| |
| − | ** Set the name to ops345-internet-gateway.
| |
| − | ** Attach it to your new VPC.
| |
| − | ** [[File:AWSAttachInternetGateway.png|800px|border|center]]
| |
| − | | |
| − | == Route table ==
| |
| − | | |
| − | Finally: create a route table to connect your subnet to your VPC's internet gateway. We could modify the existing one, but we'll make a new one instead.
| |
| − | | |
| − | * Click Route Tables, then '''Create route table'''.
| |
| − | ** Name it ops345-route-table
| |
| − | ** Set the VPC to vpc-ops345
| |
| − | ** Add a route for destination 0.0.0.0/0 through ops345-internet-gateway
| |
| − | ** [[File:AWSCreateRouteTable.png|800px|border|center]]
| |
| − | | |
| − | = Router VM =
| |
| − | | |
| − | We'll make a VM named router. It won't do much routing, but it will give us more practice with basics.
| |
| − | | |
| − | {{Admon/tip|If your SSH session locks|While you're messing with the network configuration of your VMs: existing SSH sessions may freeze, to the point that you can't even quit in order to reconnect. If this happens to you: use the key combination '''Enter+~+.''' to break out of the connection.}}
| |
| − | | |
| − | == Security group ==
| |
| − | | |
| − | Your network environment is now done, but before you create your next VM: make a security group for it. Just like you did in the previous lab.
| |
| − | | |
| − | * The Security groups are back in the EC2 Management Console
| |
| − | ** Call it ops345routersg
| |
| − | ** Since a description is required, give it something like "Security group for router instance"
| |
| − | ** It will be in the vpc-ops345 VPC.
| |
| − | ** Only the SSH server port (TCP 22) is to be open for inbound connections, from anywhere in the world.
| |
| − | | |
| − | == Create & configure VM ==
| |
| − | | |
| − | * Create a new VM (instance) named "router". The process is almost identical to the "ops435-first" VM from the last lab.
| |
| − | ** In your new VPC and subnet
| |
| − | ** Note that "Auto-assign Public IP" is enabled by default, but don't change it.
| |
| − | ** With primary IP 10.3.45.10 (first 4 addresses on AWS subnet are not usable)
| |
| − | ** Default storage options
| |
| − | ** With security group ops345routersg
| |
| − | ** Using your existing key ops345-first-key, unless you lost that already.
| |
| − | * Follow the instructions in lab 1 to change your username.
| |
| − | * Also follow the instructions in lab 1 to set your hostname to router.youruserid.ops345.ca
| |
| − | * After router starts: go to "Elastic IPs" and associate a new elastic IP named '''router_public_ip''' with the router instance.
| |
| − | ** This is now your static public IP for router. You will use it a lot, so write it down somewhere.
| |
| − | * Name the network interface '''router-nic''', so when you look at the list of your network interfaces in the future you know at least which this one is. The link to it is in router's Networking tab near the bottom:
| |
| − | [[File:AWSNetworkInterfaceLink.png|800px|border|center]]
| |
| − | | |
| − | = Firewalls =
| |
| − | | |
| − | Firewalls are a very important but often overrated means of securing network resources. They're basic function is to prevent access to network ports or protocols no matter how the server software is configured. For example you can have a web server that listens on port 80 from any source, but you might configure a firewall to only allow access to port 80 from a specific subnet.
| |
| − | | |
| − | Some firewalls have extra features as well. For example iptables is also capable of providing port forwarding functionality.
| |
| − | | |
| − | {{Admon/important|A firewall alone is not enough to secure a server!|It will prevent many types of attacks, but it will be completely useless against many other types of attacks. A firewall is only one tool in an administrator's security toolbox.}}
| |
| − | | |
| − | One basic component in an AWS VPC is a Security Group. It's very similar to iptables in that it is a list of rules for incoming and outgoing traffic. You create a security group and assign it to an instance. There are some differences from iptables though:
| |
| − | * A security group can be assigned to more than one machine, so they all share the same rules.
| |
| − | * A security group can also be configured as a source/destination paramter in another security group. That's probably where the "group" part of security group comes from.
| |
| − | | |
| − | In this course we'll learn to use both AWS security groups and iptables, because AWS security groups are too AWS-specific.
| |
| − | | |
| − | == Install iptables ==
| |
| − | | |
| − | '''iptables-services''' is not installed by default on Amazon Linux, but it is available in the repositories. We're going to use it on the router to provide port forwarding for SSH access to all your AWS VMs.
| |
| − | | |
| − | * Install iptables-services on router, then enable and start the service (same as you did in OPS245).
| |
| − | * Notice that the default rules are the same as the ones you've seen in OPS245 in CentOS. These rules are evaluated ''after'' the incoming traffic makes it past the rules in ops345routersg.
| |
| − | | |
| − | [[File:AWSVPCandiptables.png|border|center]]
| |
| − | | |
| − | * In the future you'll need to remember when you modify router's security group that there is another firewall following it, so you'll need to modify that as well.
| |
| − | | |
| − | == Temporary VM for port forwarding practice ==
| |
| − | | |
| − | We'll set up a temporary instance for this lab (called ww, not www) just as a target for port forwarding. After this lab you can delete it.
| |
| − | | |
| − | * Create a new instance the same way as "router" but without the elastic IP. Call it ww. Name the network interface ww-nic and set a secondary private IP to 10.3.45.11.
| |
| − | ** At step 6 of the creation process: create a new security group named ops345wwsg with only port 22 open for the source ops345routersg.
| |
| − | [[File:AWSsgSshFromRouter.png|800px|border|center]]
| |
| − | | |
| − | We won't set ww up as a web server in this lab, we just need something to forward SSH requests to.
| |
| − | | |
| − | Now you have a new VM (ww) which you can't ssh to even though it has a public ip. That's because the security group won't allow it. It does allow SSH from the router. But the router doesn't have the private key you're using as a password. Test all that to make sure.
| |
| − | [[File:AWSsshFirewalled.png|800px|border|center]]
| |
| − | | |
| − | The private key is on your workstation, but your workstation isn't allowed to connect to ww. You could copy your private key to router, but that's not a great solution from a security point of view. The tricky solution here is to ssh to router, and have that connection forwarded to ww.
| |
| − | | |
| − | == Port forwarding SSH ==
| |
| − | | |
| − | Port forwarding is when an incoming connection to a particular port is not processed by the machine receiving the connection, but instead it's forwarded to a different machine. You can forward a port to the same port on another machine, or one port on the first machine to another port on the second.
| |
| − | | |
| − | We're going to set up iptables on router to forward incoming requests to TCP port 2211 to port 22 on ww.
| |
| − | | |
| − | This [https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-security-firewall.html Open Suse Documentation page] has a nice simple diagram of iptables: | |
| − | [[File:SuseIptablesDiagram.png|400px|border|center]]
| |
| − | | |
| − | * Since we're forwarding traffic: the router is neither the source or the destination, therefore the INPUT and OUTPUT chains don't apply. We'll add one rule to the PREROUTING chain of the NAT table, remove the default blocking rule from the FORWARD table, and add one rule to the POSTROUTING chain.
| |
| − | [[File:AWSportForwardingIptables.png|800px|border|center]]
| |
| − | | |
| − | That would have been enough on a CentOS install, but in Amazon Linux routing is disabled by default in the kernel. So we have to enable it:
| |
| − | | |
| − | * Edit /etc/sysctl.conf and add this line to the end:
| |
| − | ** <source>net.ipv4.ip_forward = 1</source>
| |
| − | ** Then run <source>sysctl -p</source>
| |
| − | ** Check that it worked: <source>cat /proc/sys/net/ipv4/ip_forward</source>
| |
| − | * Don't forget to add TCP port 2211 to ops345routersg. If you forget: the traffic will never make it to your iptables rules.
| |
| − | | |
| − | Once you're done you should be able to ssh from your workstation to ww via port 2211 on router:
| |
| − | [[File:AWSportForwardingSetUp.png|800px|border|center]]
| |
| − | | |
| − | There are many variables in this setup. A couple of troubleshooting tools you can use are iptables logs and tcpdump:
| |
| − | * <source>iptables -I FORWARD -j LOG
| |
| − | tail -f /var/log/messages </source>
| |
| − | * <source>tcpdump -n -i eth0 port 2211</source>
| |
| − | | |
| − | = Submit evidence of your work =
| |
| − | | |
| − | For this lab, please submit screenshots that show you've completed the work, unless your professor has given you different instructions. As a minimum that's:
| |
| − | | |
| − | * Your new VPC
| |
| − | * Your new subnet
| |
| − | * Your new internet gateway
| |
| − | * Your new route table
| |
| − | * Your router vm with the:
| |
| − | ** Updated username
| |
| − | ** Private IP and Elastic IP
| |
| − | ** Port forwarding rules
| |
| − | * An ssh session from your workstation to your ww instance
| |
| − | | |
| − | [[Category:OPS345]]
| |
