Alibaba Cloud Best Security Group Rules to Block Malicious Scans

Why “Block Malicious Scans” Is a Lot Like Guarding a Cookie Jar

Security group rules are your bouncer at the club. Your job isn’t to lock every door in the building until nobody can breathe. Your job is to let the right people in, keep the troublemakers out, and make it painfully boring for anyone trying to sneak in via the side window labeled “Maybe Port 19?”

In the real world, “malicious scans” are often less like a dramatic heist and more like a kid with a flashlight systematically checking every hiding spot. They hit IP ranges, probe open ports, test for known services, and then map your environment into something they can later exploit. The good news: you can reduce the noise and the damage significantly just by tightening security group rules.

Important note: security groups aren’t a magic shield. You still need proper app security, patching, WAF where relevant, and sane configuration. But security groups are one of your first lines of defense, and they’re wonderfully effective when you treat them like a minimalist doorman rather than a doormat.

How Malicious Scanners Actually “Scan” (So You Can Stop Them)

Attackers rarely begin with a complicated exploit. They usually begin with reconnaissance. That reconnaissance often includes:

• Port discovery: Sending connection attempts to a list of ports (common, high-value, and “interesting” ones).
• Service fingerprinting: Identifying what software is listening based on responses, banners, or handshake behavior.
• Protocol probing: Trying TLS/SSL negotiation, HTTP methods, malformed packets, and authentication endpoints.
• Follow-up targeting: Once they find something that looks promising, they try common vulnerabilities or credential-stuffing paths.

That means your security group rules should do two things at once:

• Alibaba Cloud Reduce exposure: Don’t offer unnecessary services to the internet.
• Constrain the attack surface: If you must expose something, limit which source IPs can reach it and consider adding more guardrails (like allowing only known health checkers).

Also, let’s address a common misconception: “Blocking scans” doesn’t always mean dropping packets. Sometimes the best response is to not respond with anything useful, by ensuring ports that shouldn’t be open are closed. Scanners can’t exploit a service that isn’t reachable.

The Core Principle: Least Privilege for Network Traffic

If you remember one rule, make it this one: allow only what you need, only from where you need it, and only when you need it.

Least privilege in security groups typically leads to:

• Default deny inbound: No inbound access unless explicitly permitted.
• Scoped inbound allowlists: Permit from specific IP ranges (your office/VPN/CI runners/CDNs) rather than “0.0.0.0/0” for everything.
• Controlled outbound: In many environments, outbound should be restricted too, or at least monitored, so compromised hosts don’t phone home freely.

Yes, inbound gets most of the attention. But outbound rules matter too, because attackers who get a foothold often immediately try to download tools, exfiltrate data, or connect to command-and-control endpoints.

Start with a Map: Which Traffic Should Exist?

Before writing rules like you’re defusing a bomb using vibes, list your legitimate traffic flows. For example:

• Public web traffic: HTTPS (and maybe HTTP redirect) to a load balancer.
• Admin access: SSH/RDP only via VPN or a bastion host.
• Database access: Only from application subnets, not from the entire internet.
• Monitoring: Metrics/logs from monitoring systems to your instances (or vice versa).
• Health checks: Specific IP ranges or security-group-based permissions from your load balancer.

Once you know the “allowed” list, your security group rules become less about guesswork and more about following the plan.

Baseline Recommended Security Group Rules (In Plain English)

Most “best” configurations follow a pattern that looks like this:

1) Inbound: Default Deny, Then Allow Only Required Ports

Instead of “open a bunch of ports and hope for the best,” do the opposite:

• Inbound rule for HTTPS: Allow TCP 443 to the web tier from the internet (or from a CDN / load balancer IP range).
• Inbound rule for HTTP: Either allow TCP 80 for redirect to HTTPS or block it if you don’t need it.
• Inbound for SSH/RDP: Allow only from your VPN/bastion IP(s). Prefer security-group-to-security-group access over “anywhere.”

This approach drastically reduces what scanners can discover. If port 22 isn’t reachable, the scanner’s “interesting findings” shrink from “ssh exposed” to “hmm, looks boring.”

2) Inbound: Restrict Administrative Interfaces Hard

Admin panels and management ports are popular scan targets because they’re often accidentally left open during busy deployments. Common pitfalls include:

• Allowing SSH from 0.0.0.0/0 because “it’s temporary.” (Spoiler: it never becomes permanent in a good way.)
• Exposing RDP without network constraints.
• Leaving database ports open to the internet “just for debugging.”

Instead:

• Allow SSH/RDP only from known IPs or via a bastion host.
• Use security groups to restrict database access to the application tier security group, not to the whole internet.
• Consider placing admin interfaces behind VPN, zero-trust access, or a jump host.

Scanners can still scan. But your security group should prevent them from translating scans into success.

3) Database Access: Only from the App Tier

Databases are the “vault room” of your network. They should never be reachable directly from public IP space unless you enjoy thrilling security headlines. Your database security group should usually allow inbound only:

• From the application security group (same VPC / subnet context)
• On the database port(s) you actually use (e.g., 5432 for PostgreSQL, 3306 for MySQL, 1433 for SQL Server, etc.)
• Possibly from a migration/CI security group if you perform automated schema changes

Everything else gets a polite “nope.”

4) Outbound: Be Conservative (or at Least Careful)

Outbound rules are sometimes treated like background noise: “It’s the internet, they’ll use it.” But outbound is where compromised machines get tools and connect to malicious servers. A more secure pattern is:

• Allow outbound only to what you need (DNS, package repositories, specific APIs, logging endpoints).
• If that’s too complex at first, at least log and monitor outbound connections and restrict obviously dangerous destinations where possible.

Even if you don’t lock outbound immediately, you should consider it as a second phase after you clean up inbound. In most cases, cleaning inbound first yields the biggest reduction in scan effectiveness.

Common Malicious Scan Ports (And What to Do About Them)

Attack scanners typically hammer a mix of:

• Known service ports: 21 (FTP), 22 (SSH), 23 (Telnet), 25 (SMTP), 53 (DNS), 80/443 (HTTP/HTTPS), 110/143 (mail)
• Remote management ports: 3389 (RDP), 1099 (Java RMI), and various admin panels
• Database and caching ports: 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB)
• “Weird but popular” ports: 445 (SMB), 5900 (VNC), 8080/8443 (alternate web)

Here’s the practical advice: don’t craft a rule specifically for “port 12345 scanners love.” Instead, decide whether you legitimately need each service. If you don’t, ensure the port is closed by default via your security group posture.

If you do need something, lock it down with source restrictions and ideally with an intermediary (load balancer, reverse proxy, VPN, bastion).

The Security Group “Anti-Pattern” List (What Not to Do)

Let’s save you time. These are the classic ways people accidentally give scanners a VIP pass:

• Alibaba Cloud Allowing all inbound from everywhere: “TCP 0-65535 from 0.0.0.0/0” is not a firewall rule, it’s a donation.
• Opening database ports to the internet: Especially common when copy-pasting tutorials.
• Opening admin ports broadly: SSH from the entire world is like leaving your front door unlocked and hoping your neighbors are honest.
• Allowing internal ports publicly because “it works”: It works until it doesn’t. And when it doesn’t, it tends to fail loudly.
• Relying solely on security groups while leaving the service misconfigured: If the app has a vulnerability, attackers may still find a path through what you allowed.

Security groups help, but they don’t replace secure configuration.

Practical Rule Strategy: Tier Your Services

A reliable method is to structure security groups by role:

• Public web / load balancer security group
• Application security group
• Database security group
• Alibaba Cloud Management / bastion security group

Then you allow traffic from one tier to another using security-group-to-security-group permissions (where supported). This is nicer than raw CIDR ranges because it expresses intent: “App can talk to DB,” not “Some random IP in a range might be okay.”

Example: A Simple Web App That Actually Has Its Act Together

Let’s say you host a web application with the following legitimate flows:

• Users access the site via HTTPS.
• Health checks come from the load balancer.
• Admins log in via SSH only through a bastion/VPN.
• The app talks to the database over the database port.
• Servers need outbound access to fetch updates and send logs/metrics.

A sensible setup could look like this (conceptually):

Load Balancer Security Group (Public-facing)

• Inbound: Allow TCP 443 from the internet (or from your CDN provider IP range if applicable).
• Inbound: Optionally allow TCP 80 if you need redirect or plain HTTP for a short period.
• Outbound: Allow TCP 443 to the application security group.

This means scanners can find your load balancer port 443 (because it’s supposed to be there), but they can’t reach app servers directly.

Application Security Group (Private)

• Alibaba Cloud Inbound: Allow TCP 443 from the load balancer security group.
• Inbound: Allow any app-specific ports (like 80) only from the load balancer if needed.
• Inbound: If the app needs internal callbacks (rare), allow only from necessary internal security groups.

Notice what’s absent: you don’t let the internet talk to the application tier on random ports. You only let the load balancer talk to it.

Database Security Group (Ultra-Private)

• Inbound: Allow TCP 5432 (or your database port) from the application security group only.
• Inbound: If needed, allow from a migration runner security group.

Now a scanner can’t just “find the database” and attempt database-specific attacks because the database is unreachable from public IP space.

Management/Bastion Security Group

• Inbound: Allow SSH from your office/VPN IP range.
• Outbound: Allow SSH to the application or admin hosts security group.

This keeps your personal laptop from directly speaking SSH to the world. You speak to the bastion, and the bastion speaks to the servers. Your security posture becomes less “wild west” and more “corporate.”

How to Handle Health Checks (Without Opening a Carnival)

Health checks are a common “exception” that people handle poorly. If your load balancer needs to check instance health, you might be tempted to allow incoming traffic broadly so checks don’t fail. Try instead to:

• Allow health check ports only from the load balancer security group.
• Use a dedicated health check endpoint that doesn’t reveal sensitive data.
• Keep the health check port separate from admin ports if possible.

This prevents attackers from pretending to be “a health checker” by sending the same request from arbitrary IPs.

Logging: Make the Scanners Work for Your Knowledge

Even with tight rules, you’ll still get noise. That noise can be useful. When security group logs are enabled (where supported), you can see:

• Which source IPs are probing your environment.
• Alibaba Cloud What ports are being targeted.
• How frequently the traffic occurs.

Logging won’t stop an attack by itself, but it helps you tune rules and detect changes. If you suddenly see probes for a new port, that can indicate a new vulnerability being targeted or a configuration drift.

Alibaba Cloud Rate Limiting and “Soft Blocking” Strategies

Security groups are not application-layer firewalls. They don’t always provide rate limiting in the way a WAF or reverse proxy does. However, you can still reduce scan impact by combining:

• Close unnecessary ports: Scanners can’t stress what isn’t reachable.
• Use WAF/reverse proxy: For HTTP(S) endpoints, rate limiting and bot detection help a lot.
• Application-level protections: Fail2ban-like tools, request throttling, and proper authentication barriers.

Think of security groups as “stop the door from opening,” and rate limiting as “stop the person from punching repeatedly through the crack.”

Geo Restrictions: Helpful, Not Perfect

Some environments use geofencing (blocking traffic from certain countries) to reduce noise. This can be effective but also imperfect. Reasons:

• Attackers can use VPNs/proxies.
• Your users may be global; blocking regions could harm legitimate customers.
• It doesn’t solve the underlying issue if your services are open.

If you choose to use geo restrictions, treat them as a secondary layer. Your primary protection should still be least privilege and allowlists.

Testing: Tight Rules Without Breaking Your Own Website

Here’s a fun security fact: defenders can accidentally lock out the very traffic they meant to protect. To avoid turning your production site into a charming error page, use a safe process:

• Test in staging: Apply strict rules in a non-production environment first.
• Use incremental changes: Tighten one service at a time.
• Confirm health checks: Make sure load balancer checks still pass.
• Validate from real source IPs: Especially for admin access (SSH/RDP). Your VPN IP may differ from your home IP.

If you can’t test, at least schedule changes during low traffic windows and have rollback steps ready.

Don’t Confuse “Blocking Scans” with “Blocking Attacks”

Scanners are a stage in the attack lifecycle. Blocking them helps, but you should assume that some attackers will eventually find reachable services. That means you should still:

• Patch known vulnerabilities promptly.
• Harden services (disable default credentials, remove unnecessary modules).
• Use strong authentication and MFA for admin access.
• Monitor for abnormal behavior after traffic gets through.

Your security group reduces the chances of success, but it doesn’t make attackers vanish like magicians running out of rabbits.

A Checklist of “Best Security Group Rules” That Actually Hold Up

If you want a quick audit list, use this checklist to review your current security groups:

Inbound Invariants

• Do you have a default deny inbound posture (no blanket “allow all”)?
• Are public ports limited to what you truly serve (often 80/443 only)?
• Is SSH/RDP restricted to VPN/bastion IPs or security groups?
• Is database access restricted to the application tier only?
• Are internal services reachable only from necessary internal security groups?
• Are health checks restricted to the load balancer security group?

Outbound Invariants

• Do your rules allow only necessary outbound traffic where feasible?
• Do you have monitoring/alerts for unusual outbound connections?
• Are egress rules not overly permissive if you can realistically restrict them?

Operational Good Habits

• Are logs enabled for denied traffic (or at least important acceptance events)?
• Do you review logs regularly for new scan patterns?
• Is rule drift controlled via infrastructure-as-code?
• Do you document why each rule exists (so future-you doesn’t remove it incorrectly)?

Infrastructure as Code: Because “Clicking Around” Is How Mistakes Multiply

If you manage security groups manually through a console, you eventually accumulate rules like socks in a dryer you don’t remember owning. Infra-as-code (IaC) helps because it:

• Makes changes reviewable via diffs
• Ensures repeatability across environments
• Reduces accidental open rules during hurried deployments

Even if you’re not fully adopting IaC, treat security group changes like production code. Version them, review them, test them, and don’t “just quickly add a rule” without documenting it.

Advanced Tuning: Make Rules Resilient to Change

As your environment grows, rules can become messy. To keep them resilient:

• Prefer security group references over broad CIDRs when possible.
• Keep service ports consistent and document them.
• Use naming conventions that reflect tier and purpose (e.g., “web-public-sg”, “app-private-sg”).
• Remove dead rules periodically (monthly or quarterly).

Clean rules are easier to reason about, and reasoning beats luck.

Frequently Asked Questions (Without the Usual Hand-Waving)

Will blocking scanner IP addresses help?

Sometimes, but usually it’s a cat-and-mouse game because scanners use many sources. Better than IP blocking is closing ports you don’t need, restricting admin access, and limiting access between tiers.

Should I open HTTP (port 80) if I only use HTTPS?

Alibaba Cloud Only if you need redirects or plain HTTP for some specific reason. If not, block it. If you do allow it, consider restricting it to the load balancer tier.

Alibaba Cloud What’s better: many small rules or fewer broad rules?

Many small rules with clear intent are usually better than fewer broad rules that are hard to understand and risky to modify later. Clarity prevents accidental overexposure.

Can a security group “fully block” scans?

No. Attackers can still send traffic. Your goal is to block or deny connections to services you don’t want exposed, so scanning doesn’t translate into reachable targets.

Final Thoughts: Make Scanners Bored and Admins Happy

The best security group rules to block malicious scans aren’t glamorous. They’re not secret sauce. They’re discipline. They’re the simple, stubborn insistence that the internet gets only what the internet needs, and nothing more.

So go build your tiers. Allow only the ports you truly serve. Lock down admin access like it contains either your payroll spreadsheets or your dignity. Restrict database access to application tiers. Log the denials so you can see what attackers are trying next. And whenever you’re tempted to open something broadly “just this once,” remember: “this once” has a long history of becoming “always.”

If you want a single mantra to keep by your keyboard, here it is: least privilege, clear intent, and boring networks beat exciting breaches every time.