Intrusion Detection & Prevention
Detect and stop attacks in network traffic before they reach your servers
Traffic arriving from the internet and moving between your servers is inspected against automatically updated attack signatures in the network layer of Nesnet's cloud, with no appliance to install.
Why now
- On Wednesday morning a critical flaw in a popular web server package is announced, and exploit code is circulating by the afternoon. Testing and rolling out the patch will take two days, and for those two days requests aimed at the flaw need to be met on the network.
- Your firewall only checks which port is open. A request on port 443 gets through even when it carries an attack inside, and there's no second layer looking at the content.
- A customer's security questionnaire asks whether you run intrusion detection and prevention and how long you keep events. Today the answer is no, and the tender depends on it.
- A strange account turned up on the accounting server, and the team doesn't know if the attacker reached other servers. Without a record of traffic between servers, any answer is a guess.
- A dedicated intrusion prevention appliance means hardware, licenses, a signature subscription and a second unit for high availability. In the cloud the same protection comes as part of the network layer, and installing, patching and backing up an appliance stops being your team's job.
What changes
| Today | With Nesnet |
|---|---|
| The firewall can't see an attack riding inside an allowed port. | Allowed traffic is inspected against attack signatures, and matching requests are alerted on or stopped. |
| When a critical flaw is announced, the system is exposed until the patch lands. | Traffic aimed at the flaw is caught on the network as signatures update automatically. |
| Movement inside the network is invisible, and a compromised server spreads quietly. | Traffic between servers is inspected too, and lateral movement attempts are recorded as events. |
| A new security layer comes with the fear of false alarms stopping the business. | You start in detect-only mode and move to blocking once tuning is done. |
| You budget for an appliance, a signature subscription and a standby unit. | Inspection is part of the network layer and comes as a monthly line per gateway. |
From today to live: how it works
- 1
Protection workshop
You and the Nesnet team map your internet-facing services, your critical servers and the traffic to inspect. You leave knowing which gateways are covered and which items set the price.
- 2
Inspection starts in detect-only mode
Inspection is switched on for the chosen gateways and server groups in detect-only mode first. Your traffic is never cut; events are simply recorded.
- 3
Events reviewed together
The first weeks of events are reviewed by severity, and signatures that catch legitimate traffic are excluded or given a different action. Noise drops and real threats stand out.
- 4
Move to prevention
Once tuning settles, critical and high-severity signatures move to prevention mode, and matching traffic is stopped before it reaches its target. The switch happens rule by rule, with a way back kept open.
- 5
Always-current protection
Signatures update automatically and events flow into the central log system. When you launch a new service or a critical flaw is announced, profiles are reviewed together.
What you get
Recognize known attacks by signature
Traffic is compared with signatures describing known attack patterns, and a match either raises an alert or blocks the traffic before it reaches its target. SQL injection, remote code execution and attempts on known software flaws are caught this way.
Flag unusual behavior
Activity that matches no signature but departs from normal traffic is flagged as an informational event at suspicious severity. The first traces of a threat nobody has named yet come into view, even before they count as a confirmed attack.
Start by watching, block when ready
Every rule runs in detect-only or detect-and-prevent mode. In a new environment you start by recording events without cutting any traffic, then switch to prevention once tuning settles and matching traffic is dropped.
The right action for each attack
Each signature can alert, drop or reject. A reject resets the connection at both ends, so the attacker and your application both learn straight away that it's closed and no resources sit waiting.
Profiles by severity
Signatures are selected by severity (critical, high, medium, low, suspicious) and filtered by attack type, CVSS score, attack target and affected product. A web server group gets web attacks; a database group gets database attacks.
Signatures that update themselves
New signatures are checked at regular intervals, and because automatic updates are on, they're downloaded and applied to hosts and gateways. The previous signature version is kept too, so you can roll back if a new one causes trouble.
See lateral movement between servers
Traffic between servers is inspected on each virtualization host, right next to the protected server, and this inspection can be enabled for your tenant. Scans and exploit attempts from a compromised server toward the others are recorded as events.
Protection at the internet edge
Traffic to and from the internet is inspected at the gateway with a prevention profile defined specifically for the perimeter. Scans and exploit attempts from outside are met in front of your servers.
Buy time for systems awaiting a patch
When a critical flaw is announced, traffic targeting it is caught on the network once the signature updates. While you test and roll out the patch, your server isn't left alone against exploit traffic.
Fix a false alarm with one signature
A signature that trips on legitimate traffic is excluded in the global settings or switched to alert-only. Profile settings take priority over global ones, so the exception affects only that application's traffic and protection continues everywhere else.
Cut noise with thresholds and rate filters
A threshold filter limits how often a signature raises events, so thousands of attempts from one scanner become a meaningful summary instead of hundreds of lines. A rate filter turns a rule's action into drop for a set period when matches repeat in a short time.
The full story of every event
Each event records severity, attack type and target, CVE and CVSS details, the MITRE ATT&CK technique and tactic, source and destination address, port, protocol and the action taken. Your security team doesn't go hunting for missing pieces during an investigation.
Capture the packets behind an event
Packet capture can be enabled per profile for east-west inspection, so the packets that triggered an event are saved and exported as a PCAP file. Whether an event is a real attack or just an odd request from your application becomes clear from the traffic itself.
Signatures written for your own application
On top of the vendor signatures, custom signatures can be added for your in-house applications and for newly emerging threats. A flaw that exists only in your application can get a protection rule of its own.
Application-layer firewall
The application-layer (L7) firewall in the same line separates traffic by the application itself rather than the port number. If a port expected to carry one application is speaking another protocol, the rule sees it and stops it.
Apply rules exactly where you need them
Rules are written by source and destination group or IP range and applied to specific server groups. You choose inbound, outbound or both directions, and IPv4 and IPv6 traffic can be handled separately.
A second layer behind the firewall
East-west inspection runs on top of the distributed firewall, so traffic the firewall already blocks never reaches inspection. The firewall controls the door, while intrusion detection and prevention checks what walks through it.
Events flow into central logging
Intrusion events are forwarded over syslog to the central log system and kept alongside your other security records. When you need to look at what happened before and after an event, the records are in one place.
Event reports and joint reviews
Caught events are reported periodically, and critical events are reviewed together with the Nesnet team. Decisions about false-alarm tuning, profile changes and moving to prevention are made in those reviews.
Inside the network, no appliance
Protection runs in the network layer of your virtual data center, with no security appliance for you to install or patch. When you create a new server, it's inspected the moment it joins the right group.
Why Nesnet
No appliance, part of the network
The inspection engine is built into the network layer of Nesnet's cloud, and installing, patching and backing it up is Nesnet's job. As your servers grow, protection stays in place alongside them.
Inspection right next to the server
Traffic between servers is inspected on every virtualization host, right next to the protected server. Movement between two servers on the same network is visible too, without steering traffic through a central box.
Signatures that stay current on their own
Automatic signature updates are switched on, and the latest signature set is active. When a new flaw is announced, tracking, downloading and loading the signature is Nesnet's job.
Run by Nesnet, supported locally
The same Nesnet team builds and runs the network and security layer, and events flow into a central log system. For an event or a false alarm, Nesnet’s support team helps you in Turkish or English.
Your data stays in Türkiye
Traffic and event records are processed in Türkiye, on Nesnet's infrastructure in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara facilities. Your traffic is never sent to a service abroad for inspection.
A monthly invoice instead of appliance spend
Invoices are issued as e-invoices or e-archive invoices. Instead of an upfront spend on appliances, the service is billed monthly per gateway.
Example scenarios
Two days between a flaw and its patch
Situation
A critical remote code execution flaw is announced in the web server software an e-commerce company uses. Testing the patch and putting it live will take two days.
Outcome
After the signature update, requests aimed at the flaw were caught at the gateway, with the critical signature already in prevention mode. The patch went in two days later as planned, and the attempts in between showed up in the event log.
Scanning from a compromised server
Situation
At a services company, someone guessed the password of an internet-facing test server. The attacker started scanning the database server on the same network from there.
Outcome
East-west inspection recorded the scan and an exploit attempt as events, and the exploit attempt was dropped in prevention mode. The team found the source server in the event log, isolated it and rotated passwords.
An accounting app that survives a false alarm
Situation
At a manufacturer, an old plug-in of the accounting application sends requests that look like a web attack signature. Switching to prevention would have broken one of its screens.
Outcome
The application ran in detect-only mode for the first weeks, and that signature was set to alert-only in its profile alone. On every other server, the same signature keeps blocking.
Evidence for a security questionnaire
Situation
A software company was asked for evidence of intrusion detection and event logging in an enterprise customer's supplier security questionnaire.
Outcome
The company showed the inspection in front of its internet-facing services and that events flow into the central log system. The periodic event report went into the questionnaire.
Who does what
| Nesnet | You |
|---|---|
| Builds and runs the network and security layer, the inspection engine and the gateways. | Decide which services and server groups are protected. |
| Keeps automatic signature updates on and tracks signature versions. | Approve when to move to prevention and any exceptions for critical applications. |
| Defines and maintains the prevention profile for the internet edge. | Investigate reported events on your side and clean up compromised servers. |
| Forwards events to the central log system. | Patch your servers' operating systems and applications; inspection doesn't replace patching. |
| Works with you on false-alarm tuning and profile changes. | Keep your firewall rules as narrow as you need. |
Who it is for
Organizations with internet-facing servers
Companies running websites, remote desktop, VPN or API servers exposed to the internet. Requests targeting known vulnerabilities and scanning traffic are caught at the gateway before they reach the server's operating system.
Teams with hard-to-patch legacy systems
Teams running applications whose vendor support has ended or whose next maintenance window is months away. Traffic trying to exploit a known flaw can be stopped on the network until the patch arrives.
Teams that need to see lateral movement
Security teams who want to know whether an attacker moved on after compromising one server. Because traffic between servers is inspected too, movement inside your network is recorded as events.
Audited organizations
Finance, healthcare and e-commerce companies that must show they run intrusion detection and keep records of events. Every event is logged with its severity, CVE number and attack technique.
May not be the right fit
If you're looking for endpoint protection that watches malicious files, OS vulnerabilities or user behavior inside a server, this isn't it; intrusion detection and prevention looks at network traffic, not files.
Under the hood
The service runs on an intrusion detection and prevention engine built into the network and security layer of Nesnet's cloud; it is part of the network layer itself, not a separate box. The engine works at two points: server-to-server traffic is inspected on every hypervisor host, right next to the virtual machine, and internet traffic is inspected at the gateway. Traffic is first matched against signatures describing known attack patterns, and unusual behaviour is additionally flagged with a "suspicious" severity. Profiles decide which signatures apply to which traffic, by severity, attack type, CVSS score, attack target and affected product. Every rule runs in either detect-only or detect-and-prevent mode. An application-layer (L7) firewall comes in the same item. Nesnet builds this layer with its own team, keeps signatures updated automatically and forwards events to its central log system.
Building blocks
- Software-defined network and firewall
- networks, gateway, distributed and gateway firewall
- Signature engine — at the gateway and between servers
- signature- and behaviour-based intrusion detection and prevention
- Virtualisation layer
- the hypervisor where server-to-server traffic is inspected, next to each virtual machine
- Gateway (edge)
- where internet ingress and egress traffic is inspected
- Application-layer (L7) firewall
- rules by the application generating the traffic
How it compares
| Option | When it is the right choice |
|---|---|
| Run your own virtual security appliance | If your team is tied to a particular security vendor's console, rule set and reports, running that vendor's virtual appliance in your environment may be the better fit. You then own sizing, licensing, signature updates and the routing that forces traffic through the appliance, and server-to-server traffic needs a design of its own. |
| A firewall alone | If you publish nothing to the internet and your servers only make outbound connections, an address-and-port firewall may be enough. The first inbound service you open is the point at which the content of traffic on that port starts to matter. |
| A web application firewall (WAF) | If all you need to protect is a single web application and you want application-specific rules on the content of HTTP requests, a WAF is the narrower, deeper choice. IDS/IPS instead matches all traffic, regardless of protocol and including server-to-server flows, against known attack signatures. |
Technical specifications
| Detection method | Signature-based; alert or block on match |
|---|---|
| Behaviour-based detection | Unusual activity flagged with a "suspicious" severity |
| Inspection points | Server-to-server traffic in the hypervisor; internet traffic at the gateway |
| Server-to-server licence | Licensed; enabled per tenant |
| L7 firewall | Included in the same item |
| Rule modes | Detect only · detect and prevent |
|---|---|
| Signature actions | Alert · drop · reject (TCP reset or ICMP error) |
| False positives | Exclude a signature or change its action; profile setting takes precedence |
| Threshold / rate filter | Limit event frequency; temporarily switch to drop on repeats |
| Signature updates | Automatic; checked every 20 minutes by default; two versions kept |
|---|---|
| Update status | Automatic update on |
| Profile selection | Severity (critical, high, medium, low, suspicious); attack type, CVSS, attack target, affected product |
| Own signatures | Organisation-specific signatures can be added |
| Event details | Severity, attack type, CVE, CVSS, MITRE ATT&CK, source/destination, action |
|---|---|
| Event forwarding | Syslog to an external log system |
| Packet capture | PCAP for server-to-server events, exportable |
| Billing unit | Per gateway (edge) |
If something breaks
A signature blocks legitimate traffic
The signature is excluded or set to alert, and if needed the rule goes back to detect-only mode for a while. Because a setting inside a profile overrides the global one, the exception affects only that application's traffic.
Traffic exceeds the engine's capacity
When more traffic arrives than the engine can process, whether the excess is dropped or passed without inspection is a choice made globally and per rule. That is why intrusion detection and prevention should be treated as a second line of defence behind the firewall, not as a layer promised to inspect every packet under every condition.
The signature source cannot be reached
The engine does not need an internet connection to work and keeps inspecting with the signatures it has; the platform keeps two signature versions. If connectivity stays down for long, a signature bundle can be downloaded and uploaded by hand.
A platform host fails
Your protected virtual machines are restarted automatically on the other hosts in the cluster, and a virtual machine whose guest OS stops responding is restarted. During planned maintenance, virtual machines are moved live to other hosts, one host at a time.
Frequently asked questions
Pricing and first steps
Pricing
The service is priced per gateway (edge) and billed monthly; intrusion detection and prevention and the application-layer firewall come in the same line. The price is set by the number of gateways and the items you choose, and Nesnet’s team prepares your quote.
What the price depends on
- The number of gateways the inspection is added to
- The gateway itself (firewall and NAT), a separate per-gateway item in the catalogue
- Whether server-to-server traffic is inspected as well
How to get started
- 1.Fill in the form or call 0800 606 1071.
- 2.We agree on gateways and services to protect in one call and prepare a price.
- 3.Inspection starts in detect-only mode and events are reviewed together.
Look inside the traffic that gets through the door
Tell the Nesnet team about your internet-facing services and critical servers, and you'll hear back within the same business day. Inspection starts by watching only, and becomes part of your network with no appliance to install.