Skip to main content
Security Groups are the core of Altostrat’s centralized firewall management. They are stateful, policy-based firewalls that allow you to define granular rules for inbound and outbound traffic and apply them consistently across multiple sites. This approach replaces the need to manage complex, error-prone firewall configurations on individual routers. You define your security posture once in a Security Group, and SDX orchestrates its deployment to your entire fleet.

​
Core Concepts: Security Groups and Prefix Lists

Our firewall system is built on two key components that work together:

What is a Security Group?

A Security Group is a container for a set of ordered firewall rules. It defines what traffic is allowed to enter or leave the networks at the sites it’s applied to. By default, all traffic that is not explicitly allowed by a rule is denied.

What is a Prefix List?

A Prefix List is a reusable, named collection of IP addresses and CIDR blocks. Instead of hardcoding IPs into your firewall rules, you can reference a Prefix List. This makes your rules cleaner, easier to read, and simpler to manage.

​
Workflow: Building Your Firewall Policy

The most effective workflow is to first define your IP address collections (Prefix Lists) and then create the Security Group that uses them.

​
Phase 1: Create a Prefix List

1

1. Navigate to Prefix Lists

In the SDX dashboard, go to Security → Prefix Lists and click + Add.
2

2. Define the List

  1. Give the list a descriptive Name (e.g., “Corporate Office IPs”, “Payment Gateway APIs”).
  2. Add one or more Prefixes in CIDR notation (e.g., 203.0.113.0/28). You can add a description for each entry.
  3. Click Add to save the list.
Your Prefix List is now a reusable object that can be referenced in any Security Group rule.

​
Phase 2: Create and Configure a Security Group

1

1. Navigate to Security Groups

In the SDX dashboard, go to Security → Security Groups and click + Add.
2

2. Define the Security Group

Give the group a descriptive Name (e.g., “Web Server Access Policy”) and an optional Description.
3

3. Add Firewall Rules

Click Add Rule to define your access policies. For each rule, you must specify:
  • Direction: Inbound (traffic coming into your site) or Outbound (traffic leaving your site).
  • Order: A number from 1-250 that determines the processing order. Rules are evaluated from the lowest number to the highest.
  • Protocol: The network protocol (e.g., TCP, UDP, ICMP).
  • Port: The destination port or range (e.g., 443 for HTTPS). Leave blank for protocols like ICMP.
  • Address: The source (for inbound) or destination (for outbound). This can be a CIDR block (0.0.0.0/0 for “any”) or a reference to a Prefix List you created.
  • Description: A brief note explaining the rule’s purpose.
4

4. Apply to Sites

In the Sites section of the editor, select all the sites where this Security Group should be applied.
5

5. Save and Deploy

Click Save. SDX will begin orchestrating the deployment of these firewall rules to all associated sites. The group’s status will show as syncing during this process.

​
Best Practices

Use Prefix Lists Extensively

Avoid hardcoding IP addresses in rules. Using Prefix Lists makes your policies cleaner and allows you to update an IP in one place and have it apply to all relevant rules instantly.

Be Specific with Rules

Follow the principle of least privilege. Instead of opening broad port ranges, create specific rules for the exact protocols and ports your applications need.

Order Matters

Pay close attention to rule order. A broad allow rule placed early can negate more specific deny rules that follow it (though Security Groups are implicitly deny-all). Place your most specific rules first.