Alibaba Cloud 2-factor authentication setup How to Whitelist Specific IPs in Alibaba Cloud Security Groups

Alibaba Cloud / 2026-05-21 22:32:15

If you’ve ever stared at a firewall rule and thought, “I wonder if this will work… or if I’ve just locked myself out forever,” welcome to the club. Security groups are the bouncers of Alibaba Cloud: they only let people in who match the guest list. And sometimes the guest list needs to be very specific—like, “Allow only these few IP addresses, please,” not “Let everyone roam free like it’s a beach day.”

This article is a practical, human-friendly walkthrough of how to whitelist specific IPs in Alibaba Cloud Security Groups. We’ll cover the basics, then get into the nuts and bolts: where to click, what to choose, how to avoid common mistakes, and how to verify your changes so you’re not troubleshooting in the dark.

What “Whitelisting IPs” Actually Means in Security Groups

Whitelisting IPs means you create inbound rules in a security group that allow traffic from a specified IP range (usually in CIDR format) to reach specific ports on your Elastic Compute Service (ECS) instances or other resources associated with that security group.

Alibaba Cloud 2-factor authentication setup Think of it like a restaurant reservation system:

Security group = the restaurant’s policy for who gets in.
Rule = a reservation line: “Allow John (this IP) to enter and order at counter #1 (this port/protocol).”
CIDR = the zip code range on your membership card.

Instead of allowing all IPs, you only allow the specific source IP addresses you trust. You can still keep your security group strict while giving your own office, VPN, or partner network access.

Before You Start: A Quick Checklist

Before jumping into the console, confirm a few things. It’s amazing how often people lose time because they’re trying to open the wrong door for the wrong person.

1) Know the IP address (or IP range) you want to allow

You’ll typically need one of these:

A single public IP address (example: 203.0.113.10). In CIDR form, that becomes 203.0.113.10/32.
A range of IPs (example: 203.0.113.0 to 203.0.113.255). In CIDR form, that might be 203.0.113.0/24.

Note: Security groups usually operate with CIDR blocks, not “just an IP string.” If you give a single IP, use /32 for IPv4.

2) Know which protocol and port(s) you want to allow

Examples:

SSH: TCP port 22
HTTP: TCP port 80
HTTPS: TCP port 443
RDP: TCP port 3389 (Windows)
Custom app port: whatever your application listens on

Pro tip: Only open what you need. Opening a port is like leaving a window cracked: sometimes you forget, and then you regret it.

3) Make sure you’re editing the correct security group

If you have multiple ECS instances, load balancers, or environments (dev/staging/prod), it’s easy to accidentally tweak the wrong security group and then wonder why nothing changed.

4) Confirm the direction: inbound vs outbound

Whitelisting is usually about inbound rules (incoming connections from your client IP to your server). Outbound rules control what your server can connect to, which is a different conversation.

Where to Find Security Groups in Alibaba Cloud Console

The Alibaba Cloud console UI can evolve (because dashboards love making us work for our joy), but the general path stays familiar.

Typically:

Go to the ECS section (or search for “Security Groups” in the top search bar).
Select Security Groups.
Choose the correct region.
Open the security group associated with the instance or resource you want to protect.

Alibaba Cloud 2-factor authentication setup If you’re unsure which security group is attached to your instance, open the ECS instance details and look for the security group assignment.

Step-by-Step: Whitelist Specific IPs for Inbound Access

Alibaba Cloud 2-factor authentication setup Now we’ll do the actual “whitelisting.” The goal is: create a rule that allows traffic from your chosen IP(s) to a particular port.

Step 1: Open the target Security Group

In the Alibaba Cloud console:

Navigate to Security Groups.
Find your security group (by name, ID, or description).
Alibaba Cloud 2-factor authentication setup Open its details page.

Once you’re there, you should see existing rules—maybe a list of inbound rules and outbound rules. If there are no rules, that’s not unusual, but if you think you already opened something, check that the rule is actually present in the correct section.

Step 2: Go to the Inbound Rules section

Look for an area labeled something like:

Inbound rules
Inbound traffic control
Permissions

Click the option to manage inbound rules (often a button like “Add Rule,” “Authorize,” or “Add Inbound Rule”).

Step 3: Choose the rule type: Protocol, Port, and Source

You’ll usually be asked for:

Protocol (TCP/UDP/All)
Port range (example: 22 or 22/22, or a range)
Source (CIDR block of allowed IPs)

Let’s do an example. Suppose you want to allow SSH (TCP 22) only from your office IP: 203.0.113.10.

Protocol: TCP
Port: 22
Source CIDR: 203.0.113.10/32

If your office has a whole range—say 203.0.113.0/24—then your rule becomes more forgiving:

Source CIDR: 203.0.113.0/24

Be careful: the wider your CIDR block, the more IPs you’re implicitly allowing. Sometimes that’s fine. Sometimes it’s like donating your spare key to the universe. Choose wisely.

Step 4: Specify priority (if your security group supports it)

Some configurations include a priority or rule order. If the UI shows a priority field, use a sensible number and keep track of your changes. When rules overlap, priority can determine what effectively applies.

In many security group systems, rules are additive: if any rule allows it, traffic is permitted. But overlaps and special behaviors vary. When in doubt, keep your rules clean and non-overlapping.

Step 5: Add the rule and save

After filling in your fields:

Click OK, Confirm, or Save.
Wait for the rule to appear in the list.

Don’t skip the save step. The number of times people assume they clicked “Apply” when they actually clicked “Cancel” is… enough to qualify as a historical event.

Step 6: Repeat for additional ports or IPs

If you need to allow:

SSH from multiple IPs
HTTPS from a different IP range
A custom service port from another partner network

Then create separate inbound rules for each unique combination of protocol/port and source CIDR (unless the UI allows multiple CIDRs per rule, which not all setups do).

Whitelisting Multiple IPs: Your Options

Most whitelisting requests boil down to “I have a handful of IPs.” You have a few ways to handle that, depending on what Alibaba Cloud’s security group UI supports in your environment.

Option A: Create multiple rules (one per IP)

If you have, say, 5 IP addresses you want to allow, create 5 inbound rules. Each rule can be simple, like:

TCP 22 from 203.0.113.10/32
TCP 22 from 203.0.113.11/32
TCP 22 from 198.51.100.20/32

This is straightforward and easy to audit later, but it can clutter your rule list if you have lots of IPs.

Option B: Combine IPs into a CIDR range (when possible)

If your IPs are contiguous or belong to a known subnet, you can reduce rule count by using a broader CIDR block. Example:

Instead of allowing five individual IPs inside one /29 or /28, allow the entire block.

This is tidy, but it may allow a few extra IPs you didn’t explicitly intend to whitelist. Only do this if you’re confident the subnet is safe.

Option C: Use a trusted gateway/VPN IP instead

If your access comes through a VPN, bastion host, or corporate gateway, you might only need to whitelist the public IP of that gateway. Then your security group rules stay stable even if individual employee IPs change.

It’s like telling the bouncer, “Let in anyone who shows a badge issued by HR.” Much easier than listing every single person’s face.

Testing: How to Confirm the Whitelist Works

Once the rule is in place, you’ll want to verify it. Otherwise, you’ll end up doing the classic “I changed something but nothing happened” dance, which includes coffee and existential regret.

1) Test from the whitelisted IP

Attempt a connection from a machine using your allowed source IP. For SSH, try:

SSH to the instance’s public or private IP (depending on your setup)
Use the correct port and protocol

If it works, your security group rule is doing its job.

2) Test from a non-whitelisted IP

Try the same connection from a different IP that you did not whitelist. It should fail (or at least be blocked by your security group).

If it succeeds, your rule may be too broad (for example, you accidentally used 0.0.0.0/0) or you may have other rules that allow access.

3) Check server-side firewalls too

Security group rules are only one layer. Your instance may also have OS-level firewall settings (like iptables, firewalld, or cloud-init scripts). Even if the security group allows traffic, the OS might still block it.

So if you’re stuck, remember: traffic must be allowed by both the network ACL/security group layer and the instance firewall layer. Two doors, two locks, one key.

Common Pitfalls (aka “Why Isn’t It Working?”)

Here are frequent mistakes people make when whitelisting IPs. If you recognize yourself, don’t worry—you’re not alone. Cloud consoles are designed to be clicked quickly and regretted slowly.

Pitfall 1: Using the wrong CIDR format

If you want a single IP, you generally need /32 for IPv4. Many people enter only the IP number, and the system either rejects it or interprets it in an unexpected way.

Examples:

Correct: 203.0.113.10/32
Potentially wrong: 203.0.113.10 (without /32)

Pitfall 2: Allowing the wrong port

Maybe your service listens on 2222, not 22. Or your application is behind a different port. Whitelisting the “standard” port is a common guess that doesn’t always match reality.

Double-check the listening port on the instance.

Pitfall 3: Editing inbound when you needed outbound (or vice versa)

If the problem is that your instance can’t reach an external service, inbound rules won’t help. That’s usually outbound. Conversely, if you can’t connect to your instance from outside, inbound is the relevant part.

Pitfall 4: Forgetting to associate the security group with the instance

Security groups don’t magically apply to everything. Make sure your ECS instance is actually using the security group you edited.

Pitfall 5: Accidentally whitelisting everything

Using 0.0.0.0/0 means “allow from any IPv4.” Sometimes you’ll see this as an option labeled “Any” or “All IPs.” If your goal is tight whitelisting, don’t do that unless you enjoy dramatic security surprises.

Pitfall 6: Overlapping rules and confusion

If you already have broad inbound rules and you add narrow ones, you might still have access from unintended IPs. Review existing rules to ensure nothing else is granting access.

Security Best Practices (Because Good Fences Make Good Neighbors)

Whitelisting is good, but you can make it better. Here are sensible practices that reduce risk.

Use least privilege: narrow ports and narrow CIDR blocks

Alibaba Cloud 2-factor authentication setup Only open the necessary ports. Only open the necessary IP ranges. Your firewall rules should read like a shopping list, not like a grocery giveaway.

Prefer stable entry points

If possible, whitelist your VPN gateway, jump host, or bastion IP rather than many individual client IPs that change. This reduces the need to keep editing rules.

Keep rule names and descriptions meaningful

Some consoles let you label rules or mention which service they apply to. Use that. Future-you will thank present-you when you’re debugging six months from now and feeling emotionally brittle.

Document why each rule exists

If a rule is there for a partner integration, label it. If it’s for temporary access, set an expiration plan (even if the console doesn’t support automatic expiration). Chaos loves undocumented exceptions.

Worked Examples (Practical Scenarios)

Let’s run through a few realistic cases.

Example 1: Allow SSH only from your office

Your office public IP is 203.0.113.10, and you want SSH access on port 22.

Protocol: TCP
Port range: 22
Source CIDR: 203.0.113.10/32

Result: Only your office IP can connect via SSH.

Example 2: Allow HTTPS from multiple partner networks

Partner A uses 198.51.100.0/24, partner B uses 203.0.113.64/26.

Protocol: TCP
Port: 443
Source CIDR: 198.51.100.0/24

and another rule:

Protocol: TCP
Port: 443
Source CIDR: 203.0.113.64/26

If your service is public but only trusted networks should access specific endpoints, you still may need application-level controls. Security groups handle network-level access, not authorization semantics inside your web app.

Example 3: You’re using a VPN and want stable access

Your VPN gateway has public IP 192.0.2.123. Instead of whitelisting every employee laptop, whitelist the gateway.

Protocol: TCP
Port: 22 (or your management port)
Source CIDR: 192.0.2.123/32

Result: Everyone inside the VPN can connect, but the internet can’t.

Alibaba Cloud 2-factor authentication setup Troubleshooting Guide (When Whitelisting Fails)

Let’s say you whitelisted the correct IP and port, yet your connection still fails. Here’s a logical sequence to debug without spinning in circles.

Step 1: Verify the rule appears in the correct security group

Confirm you’re editing the correct security group and that the inbound rule you added is listed. Copy the rule details (protocol, port, CIDR) and compare them to what you intended.

Step 2: Confirm the instance is associated with that security group

Open the ECS instance details and check the security group association. If the instance is attached to a different group, your changes won’t matter.

Step 3: Confirm your client’s public IP actually matches the CIDR

Sometimes people whitelist their home IP but then connect via mobile data or a different network. Your “public IP” can change depending on routing, carrier-grade NAT, or VPN setup.

Confirm the source IP you are connecting from, then check whether it falls inside the whitelisted CIDR.

Step 4: Check instance firewall and listening service

Even with allowed inbound rules:

Is your service running?
Is it listening on the expected port?
Is the OS firewall allowing inbound traffic on that port?

Step 5: Check routing and networking (especially private IP scenarios)

If you’re trying to access a private IP from the public internet, it won’t work regardless of whitelisting unless you have a route, VPN, bastion host, or a load balancer setup. Whitelisting addresses the source, but it doesn’t create connectivity by itself.

Frequently Asked Questions

Can I whitelist an IP address for only one service port?

Yes. Security group inbound rules can be scoped by protocol and port. You should create a rule for each service you want to expose.

Do I need to whitelist both IPv4 and IPv6?

If your clients connect using IPv6, you’ll need IPv6 rules too (if supported). Otherwise, IPv4-only whitelisting won’t help IPv6 traffic. Many setups are IPv4-centric, but it’s worth checking.

What if my IP changes frequently?

Alibaba Cloud 2-factor authentication setup Then whitelisting individual IPs becomes a maintenance headache. Use a VPN gateway with a stable public IP, a NAT gateway, or a bastion host. If your environment changes, revisit your security strategy.

Is it safe to use CIDR blocks larger than /32?

It can be safe if the CIDR block contains only trusted sources. If it includes unknown public addresses, you may be granting more access than intended. The bigger the range, the bigger the blast radius.

Conclusion: Tight Whitelisting Without the Headaches

Whitelisting specific IPs in Alibaba Cloud Security Groups is one of those tasks that’s easy when you know what you’re doing and surprisingly annoying when you don’t. The key steps are simple: find the right security group, add an inbound rule with the correct protocol and port, specify the source CIDR accurately (use /32 for single IPs), save the rule, and then test from both allowed and not-allowed IPs.

Do that, and you’ll keep your services protected while still letting the right people in. Because the best security rules aren’t just strict—they’re strict for the right reasons, with the fewest possible surprises. And nobody wants a surprise firewall. It’s the networking equivalent of stepping on a LEGO in the dark.