DEV Community

Nnamdi Felix Ibe
Nnamdi Felix Ibe

Posted on

100 Days of DevOps, Day 2: Expiring Linux Users and Locking Down Security Groups

#aws #devops #security #linux

Day 2. Not Day 1, not Day 50. Day 2 is the day the motivation from starting has worn off, and the finish line isn't in sight yet. This is where most challenges quietly die.

So here's mine.

Same format as yesterday: the Linux task and the AWS task from the session, plus what actually matters about each one once you've done it a few hundred times in production. Today, both tasks come down to the same idea. Controlling access. Who gets in, and from where.

Task 1 (Linux): Create a User That Expires on Its Own

The task: create an account that switches itself off on a set date. This is what you set up for a contractor, an auditor, anyone with temporary access.

# Create the user with an expiry date (format: YYYY-MM-DD)
sudo useradd -e 2026-12-31 username

# Verify the expiry date is set
sudo chage -l username
Enter fullscreen mode Exit fullscreen mode

Key points:

  • useradd -e sets the expiry at the moment you create the account, so there's no follow-up task to remember.
  • chage -l lists the account's ageing settings. Confirm Account expires shows the date you set.

The accounts that cause incidents aren't the ones you remember to remove. They're the ones you forget. Setting the expiry at creation means there's nothing to forget. In a regulated environment, a contractor account with no end date is exactly the kind of thing that turns up in an access review with your name next to it.

Task 2 (AWS): Create a Security Group and Open One Port

Goal: create a security group and allow a single port in. Here, that's RDP on 3389.

# Create the security group in the default VPC
aws ec2 create-security-group \
  --group-name my-sg \
  --description "My security group"

# Add an inbound rule. Allow TCP 3389 (RDP) from a specific CIDR
aws ec2 authorize-security-group-ingress \
  --group-id <GroupId> \
  --protocol tcp \
  --port 3389 \
  --cidr x.x.x.x/x

# Verify the rule was added
aws ec2 describe-security-groups --group-ids <GroupId>
Enter fullscreen mode Exit fullscreen mode

Key points:

  • A new security group blocks all inbound traffic and allows all outbound by default. You only add what you want to let in.
  • Security groups are stateful. Allow the inbound request and the return traffic is automatic. You don't need a matching outbound rule.
  • Scope the CIDR. 0.0.0.0/0 on a port like 3389 or 22 means the entire internet can reach it.

Read enough breach write-ups, and a pattern shows up. There's almost always a security group in the story, opened wider than it needed to be, for a reason nobody can remember. 0.0.0.0/0 is convenient on a Friday afternoon and a liability by Monday. Scope it to the address that actually needs it.

What Day 2 Is Really About

Both tasks today limit something. The user expires. The port opens to one address, not the whole internet.

None of it is advanced. All of it is the difference between a system that passes an audit and one that becomes a story other engineers read later.

Day 3 is already done. If you're documenting your own work, here's my question: do you write down the boring controls, the expiry dates and the scoped CIDRs, or only the clever stuff? Because in my experience, the boring controls are the ones that save you.

Top comments (0)