OPS345 Lab 2

THIS PAGE IS A DRAFT, NOT A REAL COURSE PAGE

The current schedule for OPS345 is here: OPS335_Weekly_Schedule

AWS Networking

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:

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 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.

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 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.
• 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

• 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.

• • Internet Gateway: Create ops345-internet-gateway, attach to vpc-ops345
  • Create new Route table ops345-route-table, add route for 0.0.0.0/0 through ops345-internet-gateway. Then add explicit subnet association to subnet-ops345
• Create a new security group "ops345sg" in vpc-ops345 with only the SSH port open.
• Create a new VM named "router", in the new vpc/subnet, with primary IP 10.3.45.10 (first 4 addresses on AWS subnet are not usable), default storage, ops345sg.
  • Follow the instructions in lab 1 to set up your user, except use the subnet-ops345 and ops345sg and assign private ip 10.3.45.10. Also create a new key called ops345-all-aws-machines
  • Note that "Auto-assign Public IP" is enabled by default, but don't change it.
  • Wait till it starts, then go to "Elastic IPs" and associate an elastic IP with router. Call the elastic ip router_public_ip
  • Name the network interface router-nic

Firewalls

• The purpose of a firewall on a server on the internet
• AWS Security Groups and iptables

iptables setup

• Install iptables-services, then enable and start the service (same as you did in OPS245).
• iptables fundamentals
• Securing services that need to be publicly accessible

Port forwarding SSH

• Create another VM the same way as "router" but without the elastic IP. Call it www. Name the network interface www-nic and set a secondary private IP to 10.3.45.11
  • We won't set it up as a web server in this lab, we just need something to forward SSH requests to.
• firewall:
  • iptables diagram source: https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-security-firewall.html
  • forward incoming tcp port 2211 packets to port 22 on www

    iptables -t nat -A PREROUTING -p tcp --dport 2211 -j DNAT --to 10.3.45.11:22

  • allow forwarding to www (or just remove default reject rule)

    iptables -D FORWARD 1

  • perform ip masquerading

    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

  • trubleshooting

    iptables -I FORWARD -j LOG
    tail -f /var/log/messages

  • resulting firewall looks like this:

    [root@router ~]# iptables -L -n
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
    REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination         
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         
    [root@router ~]# 
    [root@router ~]# iptables -L -n -t nat
    Chain PREROUTING (policy ACCEPT)
    target     prot opt source               destination         
    DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:2211 to:10.3.45.11:22
    
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         
    
    Chain POSTROUTING (policy ACCEPT)
    target     prot opt source               destination         
    MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0

• kernel:

  vi /etc/sysctl.conf # add to the end: net.ipv4.ip_forward = 1
  sysctl -p
  cat /proc/sys/net/ipv4/ip_forward

• test:

  tcpdump -n -i eth0 port 2211

• aws:
  • allow access to port 2211 in security group
  • disable source/dest check for router in aws console (might not be necessary)
• Save the iptables rules when it looks like they're working.

~. will break out of locked up ssh session

Private security group

• Create a new security group "ops345sgprivate" to be used later for all VMs except the router.
• Add an inbound rule for ssh from ops345sg only