Huawei Cloud Cashback Credits Huawei Cloud server security group setup

Huawei Cloud / 2026-04-26 15:34:00

Introduction: Security Groups Are Your Server’s Bouncer

If your servers were a nightclub, a security group would be the bouncer at the door—deciding who gets in, who can leave, and who absolutely cannot enter under any circumstances. Huawei Cloud Security Groups help you control traffic to and from compute resources (like ECS instances) by using firewall-like rules. They’re one of the simplest ways to reduce exposure while still keeping your applications reachable.

This article walks you through setting up Huawei Cloud server security groups in a practical, human way. No mysterious incantations. No “just click here” hand-waving. Instead, you’ll get a clear process, helpful best practices, and troubleshooting tips for the classic issues: opened ports that still don’t work, rules that look correct but aren’t applied, and security policies that are quietly blocking you like a cat on a keyboard.

We’ll cover:

What a security group is and how it behaves
Planning inbound and outbound rules
Creating a security group and configuring rules
Assigning the security group to servers
Verifying connectivity and checking logs
Security best practices (the “don’t accidentally expose everything” section)

Let’s get your servers properly guarded—without turning them into hermits.

Understanding Huawei Cloud Security Groups

What is a security group?

A security group is a virtual firewall that you attach to one or more server instances. It evaluates network traffic based on rules you define. Think of it as a set of allow/deny instructions that determines which traffic is permitted.

In most setups, the security group model is allow-list oriented: you explicitly allow traffic that matches your rules. Anything not allowed is generally blocked by default, especially for inbound traffic.

Inbound vs outbound rules

You typically configure two categories of rules:

Inbound rules: Traffic coming into your instances. This is where you open ports like 22 (SSH), 80 (HTTP), 443 (HTTPS), etc.
Outbound rules: Traffic leaving your instances. In many real deployments, outbound is less frequently locked down, but you can still restrict it for tighter security.

A very common beginner mistake is to open a port on inbound, then forget the return path or protocol mismatch. Another classic: opening 22 to the entire world because “it’s just for now,” and then later realizing the “just for now” period lasted three months.

Statefulness and connection tracking (why things sometimes work)

Security groups in cloud environments are usually stateful, meaning that if you allow inbound traffic to establish a connection, the return traffic is allowed automatically without you explicitly opening outbound responses for that flow. However, you still need to ensure your rules match the actual protocol, port, and direction correctly.

So if you allow TCP on port 22 inbound from a trusted IP range, your SSH session responses generally flow back fine—assuming the security group (and the OS firewall) aren’t blocking you.

Before You Touch Anything: Plan Your Rules

Before you create rules, take a breath and answer a few questions. This planning step saves hours later.

Know your application ports

Make a list of what you need:

SSH admin access: TCP 22
Web server: TCP 80 and/or 443
Database: commonly TCP 3306 (MySQL) or 5432 (PostgreSQL)
Huawei Cloud Cashback Credits Custom app: your app’s listening port, e.g., TCP 8080

If your application uses UDP (DNS, some streaming setups, game servers), include that too. Protocol mismatch is a silent killer.

Decide who can talk to you (source/destination)

For inbound rules, decide the source:

Your office static IPs or VPN egress IPs
Your bastion host security group (best practice, if applicable)
Load balancer / reverse proxy IP ranges
Other internal services (for example, your web tier talking to your database tier)

Try not to use broad ranges like 0.0.0.0/0 unless you truly mean it. If you must open something publicly, open only the minimum set of ports and restrict as tightly as possible.

Decide the network segments (tiering strategy)

A clean approach is to separate servers by role—web tier, app tier, database tier—and apply different security groups accordingly. For example:

Web servers: inbound allow 80/443 from the internet (or from a load balancer)
App servers: inbound allow only from web tier on app ports
Database: inbound allow only from app tier on database ports

This way, even if someone gets into your web tier, your database isn’t automatically wide open like a vending machine.

Step-by-Step: Set Up a Huawei Cloud Security Group

Step 1: Access the Security Group configuration page

In the Huawei Cloud console, navigate to the relevant networking section where security groups are managed. The exact menu wording can vary slightly by region and product version, but you’re looking for the place where you can create and manage “Security Groups.”

Make sure you’re working in the correct region and project/tenant. Cloud consoles love to hide your changes in the wrong region like socks in a dryer.

Step 2: Create a new security group

Click “Create Security Group.” You’ll usually be asked for:

Name: a human-friendly label, e.g., sg-web-prod
Description: what it’s for
VPC / network context: the VPC in which this security group applies

Best practice naming convention (example):

Environment: dev / staging / prod
Role: web / app / db / admin
Optional: region or project tag

Example names:

sg-web-prod-ap-southeast-1
sg-db-staging-restricted

Descriptions help future-you remember why you chose those ports and IP ranges.

Step 3: Add inbound rules (the part that matters most)

Now you add rules. Typically you’ll click “Add Inbound Rule” and specify:

Huawei Cloud Cashback Credits Protocol (TCP/UDP/ICMP if supported)
Huawei Cloud Cashback Credits Port range (single port or range)
Source type (CIDR block, security group, or internal network—depends on what Huawei Cloud exposes)
Source IP or source security group
Priority or rule ID (sometimes visible; sometimes implicit)

Let’s build a practical example.

Example A: Web server security group (public 80/443)

Suppose you have a web server that should accept HTTP/HTTPS traffic. You might create the following inbound rules:

Allow HTTP: TCP port 80 from your load balancer IP range or (temporarily) from your public ingress IP range
Allow HTTPS: TCP port 443 from your load balancer IP range or permitted internet sources
Allow SSH: TCP port 22 from your admin IPs only (not from the internet)

For the “source,” prefer specific IP ranges. If Huawei Cloud supports referencing other security groups for source, you can allow traffic from a bastion security group instead of CIDR blocks. That keeps rules consistent and reduces the chance of forgetting to update IP ranges later.

Example B: App server security group (only from web tier)

Your app server likely doesn’t need to be reachable directly by the internet. A typical setup:

Allow app port (e.g., TCP 8080): source = web tier security group
Allow SSH: TCP 22 from admin IP range or bastion security group

This locks down the app tier so only web tier instances can talk to it on the app port.

Example C: Database security group (from app tier only)

Databases should be the most restricted. A safe baseline:

Allow MySQL: TCP 3306 from app tier security group (not from the internet)
Allow PostgreSQL: TCP 5432 from app tier security group
Allow SSH** (optional)**: for emergency admin access via bastion IP/security group

Even if your database credentials are strong, network exposure increases risk. Don’t accidentally publish your database because “we just need to test.”

Step 4: Add outbound rules (don’t ignore this)

Outbound rules decide what your instance is allowed to send to others. Many organizations leave outbound open initially for convenience, but that’s not a long-term security strategy.

If you want a more secure stance, consider:

Allow outbound to the internet only for required destinations (package repositories, license servers, external APIs)
Or allow outbound only within your VPC for internal communication
Huawei Cloud Cashback Credits Block everything else by default (where supported)

Huawei Cloud Cashback Credits But here’s the pragmatic note: restrictive outbound rules can break updates, monitoring agents, and certificate checks. So apply them carefully—especially if you don’t yet have a clear dependency map.

Step 5: Confirm the rule details and save

Before saving, double-check:

Protocol is correct (TCP vs UDP)
Port range matches exactly what the service listens on
Source addresses are correct and not overly broad
The security group is associated with the correct VPC

Then save your security group.

Assign the Security Group to Your Server Instances

Step 6: Attach the security group to ECS (or your compute instances)

Creating rules is only half the battle. Next, attach the security group to the server(s). In the console, go to your instance management, find the security group attachment area, and add the new security group.

Huawei Cloud Cashback Credits Some setups allow multiple security groups to be attached to a single instance. When multiple security groups apply, the effective behavior is typically the union of allowed rules (exact behavior depends on platform design). In practice, that means you should still keep each security group intentionally limited—because “union” can quietly turn into “oops, everything is allowed.”

Step 7: Validate that the instance actually uses the intended network context

If your instance is in a different VPC/subnet than you think, or you attach a security group from a different network context, rules won’t behave as expected. Ensure the VPC matches.

Also confirm the instance has the correct network interface. Multi-NIC setups can make troubleshooting feel like chasing a rumor through the hallway.

Verify Connectivity (Aka: Prove It Before You Celebrate)

Step 8: Check OS-level firewall and service binding

Security group rules control traffic at the cloud network layer, but your OS can still block it. So verify on the instance:

The service is running
The service listens on the expected interface and port (e.g., 0.0.0.0 vs 127.0.0.1)
The OS firewall allows inbound traffic (iptables/firewalld/ufw)

A common scenario: security group allows TCP 443, but your web server only listens on localhost. Result: your browser sees silence, like a stage with no actors.

Step 9: Test from the correct source

Security group rules are source-aware. That means testing from your laptop when your rule expects a VPN IP range might fail. Test from a machine that truly matches the source conditions.

Examples of correct testing:

SSH test from your office IP or bastion host
Huawei Cloud Cashback Credits HTTP/HTTPS test from a load balancer or internal reverse proxy
Database test from an app server in the allowed security group

Testing from the wrong place is the #1 “it should work” trap.

Step 10: Use basic network tools

On Linux, tools like curl, telnet (if installed), or nc can help. For example:

Verify web port: curl to the instance IP/hostname
Verify TCP connectivity: use nc -vz <ip> <port>
Optionally confirm DNS resolution if hostnames are involved

If you can connect but the application still fails, that’s an application-layer issue, not a network-layer one. Security groups are network bouncers, not mind readers.

Troubleshooting: When Things Don’t Work

Huawei Cloud Cashback Credits Problem 1: Port is “open” but connection still fails

Check these in order:

Protocol/port mismatch: Is your rule TCP while you’re using UDP? Is your service on a different port?
Source mismatch: Is the test coming from an allowed IP range or security group?
Instance attachment: Did you attach the security group to the instance’s correct network interface?
OS firewall: Does the OS firewall block the port?
Service binding: Is the service listening on the right address (0.0.0.0)?

If your rule is correct but the connection fails, it’s usually one of these. Cloud networking tends to be consistent—humans are inconsistent.

Problem 2: You opened SSH to 0.0.0.0/0 (and now it’s scary)

First: don’t panic. Second: fix it fast. Modify the inbound rule for port 22 to only allow your admin IP range or bastion security group. Then consider:

Disable password authentication and use SSH keys
Enable fail2ban or equivalent protections
Use a bastion host and restrict direct SSH access

It’s not that the cloud will attack you—it’s that the internet is full of people who enjoy scanning ports like it’s a hobby.

Problem 3: Database can’t be reached from app tier

Common causes:

You allowed the database port from the wrong source security group
Your app tier is in a different VPC/subnet context
The database listens only on localhost
Database authentication fails (this can look like network failure)

Test TCP connectivity from the app server to the database port first. If TCP works, then you’re in the authentication/config realm.

Problem 4: Outbound rules block something unexpected

If you restrict outbound traffic, things like:

System package updates
Monitoring agents
Huawei Cloud Cashback Credits Time synchronization
Certificate validation for HTTPS

can fail. If you see weird application errors after tightening outbound rules, temporarily broaden outbound rules or identify required destination endpoints and ports, then re-restrict carefully.

Best Practices: Make Security Groups Boring (In a Good Way)

1) Use least privilege

Only allow the minimum ports needed, from the minimum set of sources. If you don’t need it, don’t open it. “Maybe we’ll use it later” is not a security strategy; it’s a future incident.

2) Separate roles by security group

Use different security groups for different tiers (web, app, db, admin). Then reference those groups in rules where possible. This reduces the complexity of maintaining CIDR-based rules across changing infrastructure.

3) Prefer security-group-to-security-group rules over wide CIDR ranges

When supported, allow traffic from specific security groups rather than broad IP ranges. It makes the design more resilient to IP changes.

4) Add audit-friendly naming and descriptions

A security group named “default” is like a book titled “stuff.” It tells you nothing. Use descriptive names and document:

What application it serves
What traffic is allowed
What sources are trusted
Why those choices were made

5) Limit public exposure

Only expose the ports that truly need public access. For most internal services, keep inbound restricted to internal security groups.

6) Keep SSH access locked down

Use one of these approaches:

Allow SSH only from your static office/VPN IP range
Use a bastion host and restrict SSH to it
Use VPN/zero-trust access if available

And please, don’t open SSH to the entire internet. Your logs will become a horror movie.

7) Consider logging and monitoring

If Huawei Cloud provides flow logs or security-related logs for security groups, enable them. Monitoring helps you quickly detect:

Unexpected inbound attempts
Misconfigurations after deployments
Traffic spikes that indicate scanning or attack attempts

Visibility is a feature, not a luxury.

A Simple Baseline Template (Copy This Mindset)

Here’s a practical starting point you can adapt. Think of it as “minimum safe configuration” for common server roles.

Admin / Jump Host security group

Inbound TCP 22 from your admin IP range (or your corporate VPN range)
Optional: outbound to internal subnets on needed ports

Web server security group

Inbound TCP 80 and 443 from load balancer / trusted ingress sources
Inbound TCP 22 from jump host security group (not internet)

App server security group

Inbound TCP app port from web security group
Inbound TCP 22 from jump host security group

Database security group

Inbound database port (3306/5432/etc.) from app security group
Inbound TCP 22 from jump host security group (optional)

Then, if outbound restrictions are desired, apply them gradually after confirming dependencies. Security is a journey; your services should still be able to breathe.

Quick Checklist Before Going Live

Rules: Inbound ports match the service ports exactly, with correct protocols
Sources: IP ranges or security groups are restricted to what you actually trust
Attachment: Security group is attached to the correct instance and network interface
OS Firewall: OS-level firewall allows the same ports
Service Binding: Service listens on the right interface (not only localhost)
Testing: Connectivity tests are performed from allowed sources
Monitoring: Logging/monitoring enabled so you can see what happens

If all of these pass, you can deploy with confidence. If something fails, you now know where to look first—rather than guessing and accidentally creating a new mystery.

Conclusion: You’re Now the Bouncer, Not the Guest

Setting up Huawei Cloud server security groups isn’t complicated, but it is easy to do sloppily. The difference between “it works” and “it’s secure” usually comes down to careful planning of ports, correct source restrictions, correct attachment to instances, and verification at both the cloud and OS layers.

Use security groups to:

Allow only required inbound traffic
Restrict admin access tightly
Segregate tiers (web/app/db) using separate security groups
Validate connectivity using realistic test sources

Once you establish a baseline template and follow the checklist, security group setup becomes repeatable. And that’s the best kind of security: the kind that doesn’t require heroic debugging every time you deploy.

Now go ahead—set your rules, tighten your sources, and let your servers enjoy the peace of being properly guarded. If you run into a specific error (like “SSH timeout” or “port open but connection refused”), tell me your intended ports, protocols, and test source IPs, and I’ll help you pinpoint the missing step.