Micro-segmentation
If one server is compromised, the attack stops right there
Let the servers on your network talk to each other only over the ports they need; everything else hits a rule. Rules are enforced at each virtual machine's network card, with no agents to install and no single choke point for traffic.
Why now
- In a penetration test the web server fell, and the tester went straight from there to the database port. First finding in the report: 'the internal network is flat, with no rules between servers'.
- A company in your sector lost every server to ransomware over a single weekend. Your board wants an answer to 'what happens if one of ours goes down?'
- A script in the test environment connected to the production database by mistake and deleted records. The two environments have to share a network, but they were never meant to reach each other.
- The auditor asks which servers can reach the ones holding payment data. Right now the answer lives only in a network diagram and in your team's memory.
- Adding each new server's IP to the internal firewall keeps getting forgotten, and the rule table is full of stale addresses nobody dares to delete.
What changes
| Today | With Nesnet |
|---|---|
| From one compromised server, every server on the network is within reach. | Servers talk only over the ports you allow; the first unauthorised connection attempt hits a rule and shows up in the logs. |
| Internal traffic goes through a single security appliance — a bottleneck and a single point of failure. | Rules are enforced at each virtual machine's network card, with no single device that traffic must pass through. |
| A new server's IP is added to the rules by hand, and often forgotten. | The server joins the right group by tag, name or operating system and picks up that group's rules on its own. |
| Separating test from production means rebuilding the network layout. | Tagged into two groups, the environments are sealed off from each other with the network unchanged. |
| Who can reach whom is explained from a diagram and from memory. | Access is shown in rules written with group names, plus exported logs. |
From today to live: how it works
- 1
Discovery call
Walk Nesnet's team through how your applications are tiered and what you want kept apart. You leave knowing which environments will be covered and what drives the price.
- 2
Environments brought together
The environments in scope are gathered into a data centre group and the distributed firewall is switched on for it. Your existing network layout doesn't change.
- 3
Groups and tags
Application tiers become groups through tags, names or static membership. Check in the portal which virtual machines each group contains.
- 4
Watch first, then close
Rules start as allow rules with logging on, showing which connections are really used. What's needed stays; the rest is closed.
- 5
Watching it live
Rule logs are followed in the portal, where unexpected connection attempts show up. New servers launched with the right tag pick up their rules on their own.
What you get
Cut off the attack's path
Once traffic between servers is limited to the ports you allow, lateral (east-west) movement from a compromised server is stopped at the first connection that isn't allowed. Ransomware stays on one server, and the attempt shows up in the logs.
Protection without agents
Rules are enforced in the hypervisor kernel at the virtual machine's network card, and nothing is installed in the guest operating system. An old Windows server, or an appliance whose vendor support has ended, gets exactly the same protection.
An internal firewall with no choke point
Traffic never has to detour through one security appliance; the decision is made in the hypervisor where each machine lives. Enforcement grows as your server count grows, and one device failing doesn't stop internal traffic.
Rules stay put when servers move
When a machine is moved live for maintenance or balancing, its rules travel with its network card. It runs on its new physical host under the same rules, and nobody has to touch the rule table.
Manage your own rules in the portal
Write, enable or disable, reorder, edit and delete rules in the portal yourself. Each rule takes a name, source, destination, application port profile and logging option, with no ticket to Nesnet and no waiting.
The same rule language as the gateway
Rules allow, drop or reject; apply inbound, outbound or both; and cover IPv4, IPv6 or both. A team that knows the edge firewall starts writing server-to-server rules on day one.
The 'nobody but this group' rule
Mark a source or destination group as excluded and the rule applies to everything outside it. 'Nobody reaches the database except the application servers' becomes one line, and it never needs editing for new servers.
Groups that grow with tags
Give virtual machines security tags such as 'web', 'database' or 'production'; tags are shared across your organisation and searchable. The moment a new database server gets the right tag, that tier's rules apply to it too.
Groups by name and operating system
Machines also join groups by name or detected operating system (equals, contains, starts with, ends with). A criterion holds up to four conditions and a group up to three criteria, so with consistent naming, groups fill themselves without any tagging.
Static groups, IP and MAC sets
A whole network can be a static group, and addresses outside your virtual machines can be defined as IP sets or MAC sets. A management network from the office, or a device behind the tunnel, appears in rules by name.
See who a rule really applies to
The portal lists which virtual machines a group contains. You never have to guess where a rule actually lands, and a mistagged server is spotted before the rule goes live.
Rules that match the application
Alongside port profiles, a context profile lets a rule match the application generating the traffic. That's how you tell apart two applications on the same port, or stop an unexpected application from using a standard one.
Several environments, one rule set
Several environments come under one data centre group, together with shared networks, inside the same distributed firewall boundary. Traffic between environments follows the same rules, and dynamic groups can be used in gateway rules too.
No rules needed for return traffic
The distributed firewall tracks connection state, so return traffic for an allowed connection needs no rule of its own. The rule table stays short and readable for whoever joins the team next.
Rule logs in the portal
Logs for rules with logging on are followed and refreshed in the portal's log tab, searched by rule ID and time range, and exported as CSV. That's where you see whether a server has been trying connections it shouldn't.
Seal test off from production
Machines join separate groups through 'test' and 'production' tags, and traffic between the two groups is closed. The environments are sealed off with no network change, and a test script can no longer reach the production database by accident.
Answer the auditor with rules
Who can reach the servers holding sensitive data is shown by rules written in group names, and rule logs are exported into the audit file. The access question is answered by the rule that's actually running and its log, not by a diagram.
See who talks to whom
A reachability map built from your rules shows which server can reach which, and says plainly when there are no rules yet and the network is flat. You see where to start before writing rules, and what you've closed afterwards.
Why Nesnet
Rules without a bottleneck
Each rule is enforced at the virtual machine's network card, in the hypervisor the machine runs on, so there's no single security appliance carrying the traffic. One device failing doesn't take down internal traffic, and rules work regardless of your routing or VLAN layout.
Maintenance and migration never leave rules behind
On the Nesnet platform, virtual machines move live between physical hosts for balancing and maintenance. Because the rule is bound to the machine's network card, a move never leaves it behind, and the maintenance calendar never disturbs your security setup.
Edge, inside and web tier under one team
The gateway firewall guards the edge, the distributed firewall the space between servers, and the load balancer's WAF the web traffic. All three run on one platform under one operations team, so tracing a dropped connection never means stitching together logs from different vendors.
One rule language, at the edge and inside
The distributed firewall uses the same rule model as the gateway firewall, with the same actions, directions and groups on both sides. Your team learns one language, and dynamic groups work at the edge and inside alike.
Your servers stay in Türkiye
Rules and the servers they protect run on Nesnet hardware in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara data centres. Your rule logs are kept in Türkiye too.
Example scenarios
A company closing off a three-tier app tier by tier
Situation
A company's web, application and database servers share a network. In a penetration test, the compromised web server reached the database port directly.
Outcome
Servers join web, application and database groups by tag. Only the application port is open from web to application, and only the database port from application to database; in the repeat test, the attempt from the web server to the database hits a rule.
An organisation narrowing ransomware's path
Situation
An organisation wants to stop ransomware spreading from one compromised server across the whole environment. Today, traffic between its servers is bound by no rules at all.
Outcome
Allow rules with logging on show which connections are really used, then only those remain and the rest is closed. Lateral movement from a compromised server stops at the first connection that isn't allowed.
A development team separating test and production
Situation
A development team keeps test and production servers on one network because of its layout. Last month a test script connected to the production database and deleted records.
Outcome
Machines join separate groups through 'test' and 'production' tags, and traffic between the groups is closed. With the network unchanged, the two environments can no longer reach each other.
A payments team meeting the auditor with rules and logs
Situation
An auditor asks which servers can reach the ones holding payment data. Today the answer is a network diagram and the team's memory.
Outcome
Access is shown with distributed firewall rules written in group names. Rule logs are exported, and the auditor gets the rules and the logs side by side.
A team that launches servers weekly and never forgets a rule
Situation
A team launches new application servers every week during busy periods. Under the old setup, adding each new IP to the internal rules kept getting forgotten.
Outcome
Servers now launch from a template with the right tag and pick up the application group's rules on their own. The rule table stays written in group names rather than IP addresses, and stops growing.
Who does what
| Nesnet | You |
|---|---|
| Operates the distributed firewall, the hypervisors and the cloud portal, and applies patches on a regular cycle. | Write and order rules in the portal and follow their logs. |
| Brings your environments together in a data centre group and switches the distributed firewall on. | Give your virtual machines security tags and build your templates with the right tag. |
| Connects the logging back end so that logs appear in the portal. | Keep your server naming consistent so name-based groups work as intended. |
| Runs the gateway firewall, the distributed firewall and the load balancer as one team. | Review and remove unused permissions at regular intervals. |
Who it is for
Teams running multi-tier applications
Teams with web, application and database tiers. Only the ports each tier needs stay open, so a hole in the web server doesn't open the way to the database.
Organisations shrinking their ransomware risk
Organisations worried that one compromised server could encrypt the whole environment. Once server-to-server traffic is bound by rules, the attack's path narrows and every attempt shows up in the logs.
Teams that must keep test and production on one network
Teams whose network layout puts test and production servers side by side. Tagged into separate groups, the two environments are sealed off from each other without touching the network.
Teams whose server count keeps changing
Teams creating and deleting servers every week. Rules follow tags, server names or operating systems rather than IP addresses, so a new server lands in the right group on its own.
Organisations preparing for an audit
Organisations that must show in writing who can reach the servers holding sensitive data. Access is shown with rules written in group names, backed by logs.
May not be the right fit
Filtering traffic from the internet isn't this service's job. Use the gateway rules on the Firewall page for your network edge; micro-segmentation complements them.
If you run a single server, or two or three servers that never talk to each other, writing server-to-server rules is more work than it's worth; the edge firewall is enough.
Under the hood
Micro-segmentation is delivered by a distributed firewall built into the virtualisation layer and managed from the cloud portal. The distributed firewall runs at the level of a data centre group, which brings several virtual data centres together, rather than on the edge; it is switched on or off per group and managed as one security policy and rule set. Rules are written and ordered in the portal, and their logs are viewed there. Each rule is enforced in the hypervisor at every virtual machine's network card and is stateful, so return traffic needs no rule of its own. Nesnet runs this platform, the perimeter edge firewall and the load balancer as one team, connects the logging back end to the portal, and applies hypervisor and network patches on a regular schedule.
Building blocks
- Distributed firewall
- enforces rules at each virtual machine's network card
- Cloud portal and data centre group
- rule boundary, groups, tags and log view
- Virtualisation layer
- the hypervisor where rules are enforced; automatic workload balancing and live migration
How it compares
| Option | When it is the right choice |
|---|---|
| Edge firewall only | If you have few server groups and your main need is limiting traffic from the internet, edge rules on the Firewall page are enough. Micro-segmentation can be added later when traffic between servers needs rules. |
| A virtual firewall appliance (virtual editions of widely used firewall brands) | If policy requires a particular vendor at the perimeter, one of these appliances can sit at your environment's boundary. It guards the perimeter; rules between servers remain the distributed firewall's job. |
Technical specifications
| Rule boundary | Data Center Group (several virtual data centres) |
|---|---|
| Enablement | Switched on or off per group |
| Enforcement point | Each VM's network card, in the hypervisor kernel; stateful |
| Migration | Rule stays on the network card when the VM moves host |
| Multiple environments | Several environments under one group, with shared networks |
| Single point of failure | No single security appliance in the path |
| Action / direction / IP | Allow, drop, reject; in, out, both; IPv4, IPv6 |
|---|---|
| Exclude | Everything outside the source or destination group |
| Dynamic groups | Tag or name (contains / starts with); AND / OR |
| Static groups | Networks, IP sets; member VM listing |
| Security tags | Organisation-wide; search by tag |
| Rule logs | Query by rule ID and time range |
| Rule management | By the tenant in the portal; context profile, logging, ordering |
| Dynamic group criteria | VM name, OS name, tag; 4 conditions × 3 criteria |
| IP and MAC sets | Yes |
| Portal log view | CSV export |
| Live migration | Fully automated workload balancing |
|---|---|
| Data centres | Equinix Istanbul (Dudullu) and Türk Telekom Ankara |
If something breaks
A hypervisor fails
Each hypervisor enforces its own rules, so the failure of one host or device does not affect internal traffic on the others. Virtual machines from the failed host are restarted automatically on other hosts in the platform.
A virtual machine moves to another host
During live migration for maintenance or balancing, the rule travels with the VM's network card. The machine keeps running under the same rules on its new host.
Frequently asked questions
Pricing and first steps
Pricing
Environments covered by micro-segmentation are billed monthly; application-layer inspection or signature-based intrusion detection, if added, appears as a separate line. The price is set by the environments in scope and the items you choose, and Nesnet’s team prepares your quote.
What the price depends on
- Number and size of the virtual machines in the Data Center Group
- Storage used by those virtual machines (GB)
- The separate per-edge price book line for signature-based intrusion detection and application-layer inspection, if added
How to get started
- 1.Tell us about your applications and the tiers you want separated using the form, or call 0800 606 1071.
- 2.Scope and price are worked out in one call.
- 3.Your environments are grouped, and you write your first rule in the portal with logging on.
Don't let one server's weakness become your whole network's
Tell Nesnet's team how your applications are tiered and what you want kept apart; you'll hear back within the same business day. Rules run at every server's network card, with no agents to install.