{"id":37437,"date":"2019-10-31T22:17:38","date_gmt":"2019-10-31T19:17:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\/"},"modified":"2019-10-31T22:17:38","modified_gmt":"2019-10-31T19:17:38","slug":"flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","title":{"rendered":"Flow protocols as a tool for monitoring the security of the internal network","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>When it comes to monitoring the security of an internal corporate or departmental network, many associate it with controlling information leaks and implementing DLP solutions. But if we clarify the question and ask how you detect attacks within the internal network, the typical response will mention Intrusion Detection Systems (IDS). What was once the only option 10-20 years ago is now becoming an anachronism. There exists a more effective, if not the only feasible, method for monitoring internal networks\u2014using flow protocols originally designed for troubleshooting network issues but over time transformed into a very interesting security tool. In this article, we will discuss the types of flow protocols, which ones are best for detecting network attacks, where it is most effective to implement flow monitoring, what to pay attention to when deploying such a scheme, and even how to set it up on local equipment.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>I will not dwell on the question, 'Why is monitoring the security of internal infrastructure necessary?' The answer seems evident. However, if you still want to confirm that this is essential today, <noindex><a rel=\"nofollow\" href=\"https:\/\/gblogs.cisco.com\/ru\/17attackvectors\/\">check out<\/a><\/noindex> a short video discussing 17 different ways to breach a corporate network secured by a firewall. Therefore, we can conclude that internal monitoring is indeed necessary, and we just need to figure out how to organize it.<\/p>\n<p>I would highlight three key data sources for monitoring infrastructure at the network level:<\/p>\n<ul>\n<li>the 'raw' traffic that we capture and send for analysis to certain systems,<\/li>\n<li>events from network devices through which the traffic passes,<\/li>\n<li>traffic information obtained through one of the flow protocols.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/09c7087593661d5b159ecc9e9ab39d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCapturing raw traffic is the most popular option among security professionals, as it historically emerged as the first method. Traditional network intrusion detection systems (the first commercial intrusion detection system was NetRanger from Wheel Group, acquired by Cisco in 1998) were focused on capturing packets (and later sessions), looking for specific signatures (termed \u201cdecisive rules\u201d in the FSTEC terminology) that indicate attacks. Naturally, raw traffic can be analyzed not only with IDS but also with other tools (for example, Wireshark, tcpdump, or the NBAR2 functionality in Cisco IOS), but they typically lack the knowledge base that differentiates security solutions from regular IT tools.<\/p>\n<p>So, intrusion detection systems. The oldest and most popular method of detecting network attacks, which performs reasonably well at the perimeter (regardless of whether it's corporate, data center, segment, etc.), but falls short in modern switched and software-defined networks. In a network built on standard switches, the infrastructure for attack detection sensors becomes too large\u2014you would need to place a sensor on every connection to a node you want to monitor. Any manufacturer would be happy to sell you hundreds or thousands of sensors, but I doubt your budget could sustain such expenses. I can say that even at Cisco (where we are developers of NGIPS), we weren't able to implement this, although, it seems, pricing shouldn't be an issue for us\u2014it's our own solution. Moreover, there's the question of how to connect the sensor in such a scenario? In-line? What if the sensor itself fails? Should we require a bypass module in the sensor? Use taps? All of this increases the cost of the solution and makes it unfeasible for companies of any scale.<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/4763c13237dbe9ffa38d62075939ffba.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nYou can try to 'hang' a sensor on a SPAN\/RSPAN\/ERSPAN port and direct traffic from the necessary switch ports to it. This option partially alleviates the problem described in the previous paragraph, but introduces another one \u2014 the SPAN port cannot accept all the traffic directed at it due to bandwidth limitations. You will have to make some sacrifices. Either leave some nodes without monitoring (in which case you need to prioritize them beforehand), or only direct certain types of traffic from the node. In any case, we may miss some attacks. Additionally, the SPAN port could be occupied for other purposes. Ultimately, we will need to reconsider the current network topology and possibly make adjustments to maximize coverage of your network with the available number of sensors (and coordinate this with IT).<\/p>\n<p>What if your network uses asymmetric routes? What if you have implemented or plan to implement SDN? What if you need to monitor virtualized machines or containers, whose traffic does not even reach the physical switch? These questions are not liked by traditional IDS manufacturers because they do not know how to answer them. They may try to convince you that all these trendy technologies are hype and not needed. They might talk about the necessity of starting small. Or they may suggest that you need to install a powerful appliance in the center of the network and redirect all traffic to it using load balancers. Whatever option is suggested, you need to clearly understand how suitable it is for you. Only after that should you make a decision about the approach to monitoring the cybersecurity of the network infrastructure. Returning to packet capture, I want to say that this method remains very popular and important, but its primary purpose is border control; the borders between your organization and the Internet, the borders between the data center and the rest of the network, the borders between automated control systems and the corporate segment. In these areas, classical IDS\/IPS still have a right to exist and cope well with their tasks.<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/7a5898e0aa9e3e9275dda3e2c7b75c5c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLet's move on to the second option. Analyzing events from network devices can also be used for intrusion detection, but it shouldn't be the primary mechanism since it only detects a limited class of intrusions. Additionally, it has a reactive nature \u2014 an attack must first occur, then it must be recorded by the network device, which will signal a problem with information security in one way or another. There are several methods for this. It can be syslog, RMON, or SNMP. The last two protocols are only used in the context of information security if we need to detect a DoS attack on the network equipment itself, as RMON and SNMP can track the CPU load of the device or its interfaces, for example. This is one of the most 'cost-effective' methods (syslog or SNMP are available to everyone), but it is also the least effective for monitoring information security of the internal infrastructure \u2014 many attacks simply go unnoticed. Of course, they should not be overlooked, and analyzing syslog helps you promptly identify configuration changes in the device itself, its compromise, but it is not very suitable for detecting attacks on the entire network.<\/p>\n<p>The third option is analyzing traffic information passing through a device that supports one of several flow protocols. In this case, regardless of the protocol, the infrastructure for working with flows always consists of three components:<\/p>\n<ul>\n<li>Flow generation or export. This role is usually assigned to a router, switch, or another network device that, by passing network traffic through itself, allows key parameters to be extracted from it, which are then sent to a collection module. For example, Cisco's Netflow protocol is supported not only on routers and switches, including virtual and industrial ones, but also on wireless controllers, firewalls, and even servers.<\/li>\n<li>Flow collection. Considering that there are usually more than one network device in a modern network, the task of collecting and consolidating flows arises, which is solved using so-called collectors that process the received flows and then forward them for analysis.<\/li>\n<li>Flow Analysis. The analyzer takes on the main intellectual task and, applying various algorithms to streams, draws certain conclusions. For instance, within the IT function, such an analyzer can identify bottlenecks in the network or analyze the traffic load profile for further network optimization. For security purposes, it can detect data leaks, malware propagation, or DoS attacks. <\/li>\n<\/ul>\n<p>Don't think that such a three-tier architecture is too complicated\u2014all other options (except perhaps network monitoring systems that work with SNMP and RMON) also operate according to it. We have a data generator for analysis, which can be a network device or a standalone sensor. We have a system for collecting alarm signals and a system for managing the entire monitoring infrastructure. The last two components can be combined within a single node, but in moderately large networks, they are usually distributed across at least two devices to ensure scalability and reliability.<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/65de74b0a7556606355f9b176ef7e19c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnlike packet analysis, which is based on examining the headers and body of each packet and the sessions they consist of, flow analysis relies on gathering metadata about network traffic. When, how much, from where to where, and how... these are the questions answered by network telemetry analysis using various flow protocols. Initially, they were used for statistics analysis and identifying IT issues in the network, but later, as analytical mechanisms evolved, they became applicable to the same telemetry for security purposes. It is important to note that flow analysis does not replace or negate packet capture. Each of these methods has its area of application. However, in the context of this article, flow analysis is best suited for monitoring internal infrastructure. You have network devices (and it doesn't matter whether they operate in a software-defined paradigm or according to static rules) that cannot be bypassed by an attack. A classic IDS sensor can be evaded, but a network device supporting a flow protocol cannot. This is the advantage of this method. <\/p>\n<p>On the other hand, if you need evidence for law enforcement or your own incident investigation team, you can't avoid packet capture \u2014 network telemetry is not a copy of the traffic that can be used for collecting evidence; it is needed for real-time detection and decision-making in the field of cybersecurity. Conversely, by using telemetry analysis, you can 'write' not all network traffic (if that's the case, Cisco and data centers are involved :-), but only that which is involved in the attack. Telemetry analysis tools complement traditional packet capture mechanisms well by allowing selective capture and storage. Otherwise, you'll have to maintain a colossal storage infrastructure.<\/p>\n<p>Let's consider a network operating at a speed of 250 Mbps. If you want to store all this volume, you will need 31 MB of storage for one second of traffic transmission, 1.8 GB for one minute, 108 GB for one hour, and 2.6 TB for one day. To store daily data from a network with a bandwidth of 10 Gbps, you will need 108 TB of storage. And some regulators require data to be retained for years... The 'on-demand' recording that stream analysis helps implement significantly reduces these figures. By the way, when it comes to the ratio of the volume of recorded network telemetry data to full data capture, it is approximately 1 to 500. For the aforementioned values, storing the complete decryption of all daily traffic will amount to 5 and 216 GB respectively (you can even write it on a regular flash drive).<\/p>\n<p>If the methods of capturing raw network data are almost indistinguishable from vendor to vendor, the situation is different when it comes to flow analysis. There are several types of flow protocols, and it's essential to understand their differences in the context of security. The most popular is the Netflow protocol, developed by Cisco. There are several versions of this protocol, which differ in their capabilities and the amount of traffic information recorded. The current version is the ninth (Netflow v9), on which the industrial standard Netflow v10, also known as IPFIX, is based. Today, most network vendors support either Netflow or IPFIX in their equipment. However, there are various other flow protocol options \u2014 sFlow, jFlow, cFlow, rFlow, NetStream, etc., with sFlow being the most popular. This is often supported by domestic network equipment manufacturers due to its simplicity of implementation. What are the key differences between Netflow, which has become a de facto standard, and sFlow? I would highlight several key differences. Firstly, Netflow has user-configurable fields, unlike the fixed fields in sFlow. Secondly, and this is most important in our case, sFlow collects what is called sampled telemetry, unlike the unsampled data in Netflow and IPFIX. So what distinguishes them?<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/96782b57ccaddd731d5084c127076d49.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nImagine you decided to look into the book \u201c<noindex><a rel=\"nofollow\" href=\"http:\/\/www.ciscopress.com\/store\/security-operations-center-building-operating-and-maintaining-9780134052014\">Security Operations Center: Building, Operating, and Maintaining your SOC<\/a><\/noindex>\u201d by my colleagues \u2014 Gary McIntyre, Joseph Muniz, and Nadeem AlFardan (you can download part of the book through the link). You have three options to achieve your goal: read the entire book, skim through it stopping at every 10th or 20th page, or try to find a summary of the key concepts on some blog or a service like SmartReading. Thus, unsampled telemetry is akin to reading every \u201cpage\u201d of network traffic, analyzing metadata for each packet. Sampled telemetry, on the other hand, is a selective study of traffic in the hope that in the chosen samples, you'll find what you need. Depending on channel speed, sampled telemetry will return every 64th, 200th, 500th, 1000th, 2000th, or even 10000th packet for analysis.<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/28b798498a11a5e6f72ef847ea2dbaaa.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn the context of information security monitoring, this means that sampled telemetry is well-suited for detecting DDoS attacks, scanning, and malware propagation, but it may miss atomic or multi-packet attacks that do not appear in the sample sent for analysis. Non-sampled telemetry does not have these drawbacks, and with its help, the range of detectable attacks is much broader. Here is a brief list of events that can be detected using network telemetry analysis tools.<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/be3a11d4826978d9c882074f22ee97c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOf course, an open-source NetFlow analyzer won\u2019t allow you to do this, as its primary task is to collect telemetry and conduct basic analysis from an IT perspective. To identify threats based on flows, the analyzer needs to be equipped with various engines and algorithms that will detect cybersecurity issues based on standard or custom NetFlow fields, enriching standard data with external data from various Threat Intelligence sources, etc.<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/60e876dbfbdffd160e9899f87aa6303c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTherefore, if you have a choice, opt for NetFlow or IPFIX. But even if your equipment only works with sFlow, as with domestic manufacturers, you can still derive benefits in terms of security. <\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/ee75809ccde4f366ca5f5ead7beed58c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn the summer of 2019, I analyzed the capabilities available from Russian network hardware manufacturers, and all of them, except for NSG, Poligon, and Kraftway, claimed to support sFlow (at least Zelax, NatEx, Eltex, QTech, and Rusteletech). <\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/acd1ed477af59e1439d941374c596d16.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThe next question you will face is where to implement flow support for security purposes. In fact, the question is not entirely correctly posed. On modern equipment, flow protocol support is almost always present. Therefore, I would rephrase the question \u2014 where is the most effective place to collect telemetry from a security standpoint? The answer is rather obvious \u2014 at the access level, where you can see 100% of all traffic, where you have detailed information about hosts (MAC, VLAN, interface ID), where you can even track P2P traffic between hosts, which is critical for detecting scanning and the spread of malware. At the kernel level, you may simply not see part of the traffic, and at the perimeter level, you might see only a quarter of your entire network traffic. However, if there are any unauthorized devices in your network that allow attackers to \u201center and exit\u201d bypassing the perimeter, analyzing telemetry from it will not be beneficial. Therefore, for maximum coverage, it is recommended to enable telemetry collection precisely at the access level. It is worth noting that even when we talk about virtualization or containers, modern virtual switches often also support flow, allowing traffic control in those scenarios.<\/p>\n<p>But since I brought up the topic, I should address the question: what if the equipment, whether physical or virtual, does not support flow protocols? Or if its activation is prohibited (for example, in industrial segments to ensure reliability)? Or if its activation leads to high CPU loads (this can happen with outdated equipment)? To address this task, there are specialized virtual sensors (flow sensors), which are essentially regular splitters that pass traffic through and transmit it as flow to the collection module. However, in this case, we encounter a whole host of problems that we previously discussed regarding packet capture methods. Thus, it is important to understand not only the advantages of flow analysis technology but also its limitations.<\/p>\n<p>Another point to remember when discussing flow analysis tools. While event-based security measures typically utilize the metric EPS (events per second), this metric is not applicable for telemetry analysis; it is replaced by FPS (flows per second). Similar to EPS, it cannot be pre-calculated, but one can estimate the approximate number of flows generated by a particular device based on its function. You can find tables online with estimated values for various types of corporate devices and conditions, helping you determine what licenses you need for analysis tools and what their architecture will be. The fact is, an IDS sensor is limited by a specific bandwidth that it can 'handle', and the flow collector has its own limits that need to be understood. Therefore, in large, geographically distributed networks, there are usually multiple collectors. When I described, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">how the network is monitored within Cisco<\/a><\/noindex>, I already mentioned the number of our collectors \u2014 there are 21. And this is for a network spread across five continents, with about half a million active devices).<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/a5935ef7f7a3511cbf291fce59e96d71.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAs a monitoring system for Netflow, we use our own solution <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Cisco Stealthwatch<\/a><\/noindex>, which is specifically aimed at addressing security tasks. It has many built-in engines for detecting anomalous, suspicious, and clearly malicious activities, allowing it to identify a wide range of various threats \u2014 from cryptocurrency mining to data leaks, from malware distribution to fraud. Like most flow analyzers, Stealthwatch is built on a three-tier scheme (generator \u2014 collector \u2014 analyzer), but it is augmented with several interesting features that are important in the context being considered. First, it integrates with packet capture solutions (for example, Cisco Security Packet Analyzer), which allows recording selected network sessions for subsequent in-depth investigation and analysis. Second, specifically to expand security tasks, we developed a special protocol called nvzFlow, which allows \u201cstreaming\u201d application activity on endpoint nodes (servers, workstations, etc.) into telemetry and transmitting it to the collector for further analysis. While in its original version Stealthwatch works with any flow protocol (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) at the network level, the support for nvzFlow allows for data correlation also at the node level, thereby increasing the efficiency of the entire system and enabling the visibility of more attacks than typical network flow analyzers.<\/p>\n<p>It is clear that when discussing Netflow analysis systems from a security perspective, the market is not limited to a single solution from Cisco. You can use both commercial and free or conditionally free solutions. It would be rather strange for me to cite competitor solutions in a Cisco blog, so I'll say a few words about how network telemetry can be analyzed using two popular, similarly named but still different tools \u2014 SiLK and ELK.<\/p>\n<p>SiLK is a toolkit (the System for Internet-Level Knowledge) for analyzing traffic, developed by the American CERT\/CC. In the context of today's article, it supports NetFlow (versions 5 and 9, the most popular ones), IPFIX, and sFlow, allowing various operations on network telemetry using different utilities (rwfilter, rwcount, rwflowpack, etc.) to detect signs of unauthorized actions. However, there are a couple of important points to note. SiLK is a command-line tool and conducting operational analysis requires continuously entering commands (for detecting ICMP packets larger than 200 bytes):<\/p>\n<p><code>rwfilter --flowtypes=all\/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15<\/code><\/p>\n<p>which is not very convenient. You can use the iSiLK graphical interface, but it won't significantly ease your life, as it serves only for visualization and not as a substitute for an analyst. This is the second point. Unlike commercial solutions, which already have a solid analytical base, anomaly detection algorithms, corresponding workflows, etc., with SiLK, you will have to do all of this yourself, which requires slightly different competencies than using an already ready-to-use toolkit. This is neither good nor bad \u2014 it\u2019s a feature of almost any free tool, based on the assumption that you know what to do, and it will just help you in that process (commercial tools are less dependent on the competencies of their users, although they also assume that analysts understand at least the basics of network investigations and monitoring). But let's return to SiLK. The analyst\u2019s workflow with it looks as follows:<\/p>\n<ul>\n<li>Formulating a hypothesis. We need to understand what we will be looking for within the network telemetry, to know the unique attributes by which we'll identify certain anomalies or threats.<\/li>\n<li>Building a model. Having formulated a hypothesis, we implement it using Python, shell, or other tools not included in SiLK.<\/li>\n<li>Testing. It is time to verify the accuracy of our hypothesis, which can be confirmed or refuted using SiLK utilities that start with 'rw', 'set', 'bag'.<\/li>\n<li>Analysis of real data. In the industrial implementation of SiLK, we help identify something, and the analyst must answer the questions: 'Did we find what we expected?', 'Does this align with our hypothesis?', 'How will it reduce false positives?', 'How can we improve recognition levels?', etc.<\/li>\n<li>Improvement. At the final stage, we enhance what has been done earlier \u2014 creating templates, improving and optimizing code, rephrasing and refining the hypothesis, among other tasks.<\/li>\n<\/ul>\n<p>This cycle will also apply to Cisco Stealthwatch, but the latter automates these five steps as much as possible, reducing the analyst's errors and increasing the promptness of incident detection. For example, in SiLK, you can enrich network statistics with external data on malicious IPs using self-written scripts, while Cisco Stealthwatch has this as a built-in function, which immediately displays an alarm if network traffic interacts with blacklisted IP addresses.<\/p>\n<p>If you go higher up the 'cost' pyramid of flow analysis software, the completely free SiLK will be followed by conditionally free ELK, consisting of three key components: Elasticsearch (for indexing, searching, and analyzing data), Logstash (data input\/output), and Kibana (visualization). Unlike SiLK, where you have to write everything yourself, ELK already has many ready-made libraries\/modules (some paid, some free) that automate the analysis of network telemetry. For example, the GeoIP filter in Logstash allows correlating observed IP addresses with their geographic locations (this is a built-in function in Stealthwatch).<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/addd9d9656f64f81d86a0cce8ee0810b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nELK also has a large community that writes missing components for this monitoring solution. For example, to work with Netflow, IPFIX, and sFlow, you can use the module <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/robcowart\/elastiflow\">elastiflow<\/a><\/noindex>, if you are not satisfied with the Logstash Netflow Module, which supports only Netflow.<\/p>\n<p>While providing greater responsiveness in collecting flow and searching in it, ELK currently lacks rich built-in analytics for detecting anomalies and threats in network telemetry. This means that, following the lifecycle described above, you will have to manually define violation models and then utilize them in the operational system (there are no built-in models).<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/6d8368f4c130c3a5770890cb6c5fe5ab.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThere are certainly more advanced extensions for ELK, which already include some models for detecting anomalies in network telemetry, but such extensions come at a cost, raising the question of whether it's worth the effort \u2014 to write a similar model oneself, to purchase its implementation for one's monitoring tool, or to buy a ready-made solution in the Network Traffic Analysis category.<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/d938ebb4271c4dfb73a1e4b6e94c91d6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI really don\u2019t want to dive into the debate over whether it\u2019s better to spend money and buy a ready-made solution for monitoring anomalies and threats in network telemetry (such as Cisco Stealthwatch) or to figure it out independently and tweak SiLK, ELK, or nfdump or OSU Flow Tools for each new threat (I'm talking about the last two). <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/348532\/\">discussed<\/a><\/noindex> Every individual has their own motives for choosing either option. I just wanted to show that network telemetry is a crucial tool in ensuring the security of one\u2019s internal infrastructure, and it shouldn't be neglected to avoid becoming one of the companies mentioned in the media along with epithets like 'hacked', 'not complying with cybersecurity requirements', 'not considering the security of their data and their clients\u2019 data'.<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/de7df67df66b7abe89170c7f92fcefca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn conclusion, I would like to list key recommendations to follow when building cybersecurity monitoring for your internal infrastructure:<\/p>\n<ol>\n<li>Do not limit yourself to just the perimeter! Use (and select) your network infrastructure not only for transmitting traffic from point A to point B but also for addressing cybersecurity issues.<\/li>\n<li>Explore existing cybersecurity monitoring mechanisms in your network equipment and utilize them.<\/li>\n<li>For internal monitoring, prioritize telemetry analysis \u2014 it can detect 80-90% of all cybersecurity incidents, achieving what is impossible with packet capturing and saving storage space for all cybersecurity events.<\/li>\n<li>For flow monitoring, use Netflow v9 or IPFIX \u2014 they provide more information in terms of security and allow monitoring not only of IPv4 but also of IPv6, MPLS, etc.<\/li>\n<li>Use a non-sampled flow protocol \u2014 it provides more information for threat detection. For example, Netflow or IPFIX.<\/li>\n<li>Check the load on your networking equipment \u2013 it may not be able to handle processing the flow protocol as well. In that case, consider using virtual sensors or a Netflow Generation Appliance.<\/li>\n<li>Implement control primarily at the access level \u2013 this will allow you to see 100% of all traffic.<\/li>\n<li>If you have no choice and are using Russian networking equipment, choose one that supports flow protocols or has SPAN\/RSPAN ports.<\/li>\n<li>Combine intrusion detection\/prevention systems at the perimeters with flow analysis systems inside the network (including in the clouds).<\/li>\n<\/ol>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/c54e4b02a906f470bbfb617f48cdd216.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nRegarding the last piece of advice, I would like to present an illustration that I mentioned earlier. You see that whereas the Cisco security service used to build its monitoring system almost entirely based on intrusion detection and signature methods, now they account for only 20% of incidents. Another 20% comes from flow analysis systems, indicating that these solutions are not a luxury but a real tool in the activities of modern enterprise security services. Moreover, you have the most important aspect for their implementation \u2013 a network infrastructure, the investments in which can also be protected by assigning monitoring functions to the network.<\/p>\n<p><img decoding=\"async\" alt=\"Flow protocols as a tool for monitoring the security of the internal network\" src=\"\/wp-content\/uploads\/2019\/08\/2166f265222c43b0b2cbbcf4091c1f8c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI specifically avoided the topic of responding to anomalies or threats detected in network flows, but I think it's clear that monitoring should not stop at just detecting threats. It should be followed by a response, preferably in an automated or semi-automated manner. But that is a topic for a separate piece.<\/p>\n<p>Additional information:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/products\/ios-nx-os-software\/ios-netflow\/index.html\">Description of Cisco IOS Netflow<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/community.cisco.com\/t5\/security-documents\/netflow-support-matrix\/ta-p\/3644638\">Netflow support matrix in various Cisco solutions<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/dam\/en\/us\/td\/docs\/security\/stealthwatch\/netflow\/Cisco_NetFlow_Configuration.pdf\">Guide to configuring Netflow on various Cisco platforms<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/sflow.org\">sFlow community<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.ciscolive.com\/c\/dam\/r\/ciscolive\/us\/docs\/2015\/pdf\/LTRSEC-3336.pdf\">Lab work on using Stealthwatch, SiLK, and ELK for Netflow analysis from a security perspective<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/\">SiLK website<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tools.netsa.cert.org\/silk\/analysis-handbook.pdf\">Three-hundred-page guide on using SiLK with plenty of examples<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/logstash\/current\/netflow-module.html\">Logstash Netflow Module<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.cisco.com\/security\/step-by-step-setup-of-elk-for-netflow-analytics\">Step-by-step Cisco guide on analyzing Netflow in ELK<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/307528\/\">NetFlow v.9 Cisco ASA analysis using Logstash (ELK)<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/ru_ru\/products\/security\/stealthwatch\/index.html\">Cisco Stealthwatch solution<\/a><\/noindex><\/li>\n<\/ul>\n<p>P.S. If it's easier for you to perceive everything written above by ear, you can watch an hour-long presentation that formed the basis of this note.<\/p>\n<p><center><div class=\"youtube-placeholder\" data-id=\"ncDRZsueETo\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/ncDRZsueETo\/hqdefault.jpg\" alt=\"Play video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><br \/>\n<br \/>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cisco\/blog\/464601\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439. \u0410 \u0435\u0441\u043b\u0438 \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0443\u0442\u043e\u0447\u043d\u0438\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441 \u0438 \u0441\u043f\u0440\u043e\u0441\u0438\u0442\u044c, \u043a\u0430\u043a \u0432\u044b \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0432\u0430\u0435\u0442\u0435 \u0430\u0442\u0430\u043a\u0438 \u0432\u043e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u043e\u0442\u0432\u0435\u0442\u043e\u043c \u0431\u0443\u0434\u0435\u0442, \u043a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u0443\u043f\u043e\u043c\u0438\u043d\u0430\u043d\u0438\u0435 \u0441\u0438\u0441\u0442\u0435\u043c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u044f \u0430\u0442\u0430\u043a (intrusion detection systems, IDS). \u0418 \u0442\u043e, \u0447\u0442\u043e \u0431\u044b\u043b\u043e \u0435\u0434\u0438\u043d\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28091,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37437","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Flow-\u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u043a\u0430\u043a \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:17:38+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:17:38+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Flow Protocols as a Tool for Monitoring Internal Network Security | ProHoster","description":"When it comes to monitoring the security of an internal corporate or governmental network, many people associate it with controlling information leaks and implementing DLP solutions.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Flow-\u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u043a\u0430\u043a \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0441\u0435\u0442\u0438 | ProHoster","og:description":"\u041a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0437\u0430\u0445\u043e\u0434\u0438\u0442 \u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0438\u043b\u0438 \u0432\u0435\u0434\u043e\u043c\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438, \u0442\u043e \u0443 \u043c\u043d\u043e\u0433\u0438\u0445 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u0430\u0441\u0441\u043e\u0446\u0438\u0430\u0446\u0438\u044f \u0441 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0435\u043c \u0443\u0442\u0435\u0447\u0435\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0438 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435\u043c DLP-\u0440\u0435\u0448\u0435\u043d\u0438\u0439.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/flow-protokoly-kak-instrument-monitoringa-bezopasnosti-vnutrennej-seti","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:17:38+00:00","article:modified_time":"2019-10-31T19:17:38+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37437","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 17:49:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:26:28","updated":"2026-01-23 17:49:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/37437","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=37437"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/37437\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/28091"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=37437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=37437"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=37437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}