A firewall is not a list of rules. It is an ordered list of rules, and the order is the whole thing. Put the same two rules in the wrong sequence, and you either block traffic you meant to allow or allow traffic you meant to block. Day 13 drove that home, then taught me that snapshotting a server has a side effect the name does not warn you about.
One Linux task, one AWS task. Lock a port down so only the load balancer can reach it, then capture a running EC2 instance as an AMI. The tasks come from the KodeKloud Engineer platform.
iptables: allow the one source, drop the rest, in that order
The goal was to let one machine, the load balancer, reach a port and block everyone else. That is two rules, and their order decides whether it works. First, install and enable the iptables service:
sudo yum install -y iptables-services
systemctl enable iptables
systemctl start iptables
Then the two rules that do the work:
# Allow the port FROM the load balancer's IP only
iptables -R INPUT 5 -p tcp --destination-port 5004 -s 172.16.238.14 -j ACCEPT
# Drop all other traffic to that port
iptables -A INPUT -p tcp --destination-port 5004 -j DROP
iptables reads the INPUT chain top to bottom and stops at the first rule that matches. So the ACCEPT for the load balancer has to come before the DROP for everyone else. If the DROP sat first, it would match the load balancer's packets too and drop them before the ACCEPT was ever reached. The -R INPUT 5 replaces the rule at position 5 to slot the ACCEPT into the right place, and -A appends the DROP to the end, which is exactly where a catch-all belongs.
# Persist the rules so a reboot doesn't wipe them
service iptables save
# Confirm what is saved
sudo iptables-save
iptables -L
Same persistence trap as Day 12. service iptables save writes the rules to /etc/sysconfig/iptables. Until you run it, everything you configured lives in memory only and vanishes on reboot. And a naming gotcha: iptables-save does not save, it prints the current rules to your screen. The command that actually persists is the service iptables save one.
AMI: a full-instance image, with a reboot in the middle
The AWS task was to capture a running instance as an AMI, a reusable image you can launch fresh instances from:
# Create the image from the instance
aws ec2 create-image \
--instance-id i-1234567890abcdef0 \
--name "My server" \
--description "An AMI for my server"
# It takes a few minutes to become available
aws ec2 describe-images --image-ids ami-xxxxxxxxxx
Here is the detail my notes glossed over, and it matters. By default, create-image reboots the instance. AWS shuts it down and restarts it to snapshot the volumes in a consistent state, with all buffered and in-memory data flushed to disk first (per the AWS create-image docs). That is the safe default, but an unexpected reboot on a production box in the middle of the day is not something you want to trigger by accident. If you cannot take the reboot, you add --no-reboot, and then AWS warns it cannot guarantee the filesystem integrity of the image. So it is a real tradeoff, consistency with a reboot or no reboot with a small risk, not a free action either way.
Two more things. The AMI includes snapshots of every attached EBS volume by default, so it is a full-instance image, not just the root disk. And AMIs are region-specific. If you need one elsewhere, you copy it with aws ec2 copy-image.
What connects them
Both tasks looked like a single action and were really about a hidden mechanic. The firewall worked or failed on rule order, something invisible until you know to look for it. The AMI looked like a passive snapshot but carried an active reboot. The theme of the week keeps coming back: the command is easy, and the behaviour underneath it is where the real knowledge lives.
So here is the Day 13 question. Would you rather run commands and get surprised by what they do underneath, or learn the mechanics so nothing about the outcome catches you off guard?
Day 13 down. Eighty-seven to go.
Top comments (0)