Putting together a constructor or network security architecture. Case 3 - Large Office

All issues

Dog hats are becoming a trend and it is becoming “bad form” to walk dogs without hats. And our business continues to grow.

The number of services is also growing, and, accordingly, the size of the data center. Oddly enough, the attention of regulators to our company is also increasing, but first things first.

We, of course, are at the height of technology, and our state-of-the-art data center is replete with all sorts of SDN (software-defined networking) and other overlay delights, but for the security logic it is not so important at what level of virtualization the network is located, so we will not go into detail on stop there. Let’s just keep in mind that what was said below also applies to SDN-based networks.

First of all, we acquired specially trained fast switches, so we have a separate core of the data center network, and now our network is divided into, in fact, the data center network and a LAN for everything else.

For complete separation of data center segments, even at the routing level, we create several VRFs (Virtual Routing and Forwarding).

Case 3 – Large Data Center

Data center:

When we have a sane data center, there is a need for its adequate protection. And here the ACL on the switches won’t save us. We need a full-fledged firewall, and with good performance – it will need to quickly process and transfer packets between interfaces.

Moreover, it is highly desirable to use the IPS functionality to protect against network attacks from a LAN, where there may be compromised workstations or especially harmful employees. The full functionality of the UTM Security Gateway would be overkill, so you can free up resources only for firewalling and IPS.

We consider each VRF as a separate isolated segment, so traffic between VRFs must also be controlled by the firewall. The logic diagram will look like this:

Protection of personal information:

Almost every organization in its activities uses personal data (PD), the protection of which is spelled out at the legislative level (Federal Law 152-FZ). The first thing that needs to be done in order to comply with the requirements of regulators in terms of personal data is to define information systems of personal data (PDIS) and narrow the area of these very PDIS as much as possible so that the requirements for their protection are applicable only to limited infrastructure. Simply put, collect all ISPDN together and organize dedicated network segments for them. Further, these segments must be protected with certified firewalls. In fact, this is the most common security gateway firewall, but it has the corresponding certificate of the Federal Service for Technical and Export Control (FSTEC). FSTEC verifies that the gateway really performs its firewall functions correctly, after which it issues its certificate.

The plus of a Certified Security Gateway is that it allows you to comply with legal requirements and gives you the confidence that the security gateway’s firewall functionality has been validated by a regulatory agency. But there are also disadvantages:

during the certification procedure, a strictly defined version of the security gateway software is fixed, so it is almost impossible to update the software on the gateway (except for cases when the update distribution kit will also be certified);
a certified gateway according to FSTEC requirements can only have limited functionality: firewalling, IPS and control of network applications. Theoretically, there is an antivirus for class 6 certification, but it is practically useless without SSL inspection, which is inaccessible due to the strong cryptography “cut” on the certified gateway. All other functionality is blocked. By the way, regularly updated IPS signatures must also be certified, so they are usually downloaded from the resource of the applicant certification organization and manually “slipped” onto the gateway.
the certified gateway is sold more expensive due to the fact that significant funds were spent on certification and the applicant organization plans to earn money on this.

Therefore, a certified gateway is only used to comply with regulatory requirements and in certain segments:

In principle, you can make the entire data center security gateway certified, but you need to keep in mind potential problems with updating software and IPS signatures:

Of course, there are times when the entire network of an organization is a ISPDn network, then the certified gateway must be on the network perimeter, but here there is also a small life hack how to meet the requirements of regulators and use the full UTM functionality – we put a certified gateway between the LAN and the perimeter gateway. The perimeter gateway gives us UTM functionality, and the certified gateway “covers” the LAN and allows us to meet the requirements of regulators:

Web server protection:

In order to improve sales, we have developed our own online store and want to place it on one of our servers.

And we asked ourselves a question – where to put the new web server in our network? Of course, all resources to which access from the Internet is provided must be in the DMZ of the perimeter gateway to control traffic between the Internet and the resource, as well as between the resource and the LAN. In addition, traffic from the Internet must be checked very deeply. web servers are very vulnerable. The functionality of the Web Application Firewall (WAF) can help us with this. WAF specializes in preventing attacks against web applications, and in this it is not easy to find the best alternative for it. Many security gateways have built-in WAF functionality, which will protect against a number of attacks, but cannot provide full protection. After all, a specialized tool such as Fortinet FortiWAF or PT Application Firewall undoubtedly wins here.

So, we will place a web server in one of our DMZ and logically put a WAF in front of it:

If our web server is in the cloud, then we also put the WAF in the cloud in a similar way to protecting email.

But protecting your web servers doesn’t stop there.

Of course, we remember our competitors, who are ready for anything in the fight for a four-legged audience. They are even capable of such a “dirty” business as organizing a DDoS attack on our online store in order to discredit our good name and deprive us of customers.

A DDoS attack (Distributed Denial of Service) is characterized by the fact that a large number of infected machines try to access the target server in the usual way for users, but either the server cannot withstand such a load, or the channel cannot copes with such a flow.

How can we identify and separate the traffic of legitimate users and zombie machines? Here you should carefully study the traffic for anomalies and the IPS of the Security Gateway will not help us with this – each web server has its own “normal” traffic profile, which needs to be examined and from which anomaly detection and traffic cleaning will be based. In addition, the gateway itself is stateful, i.e. it keeps track of all established sessions, and if there are a lot of them, it can “lie down” itself from the load.

Therefore, a suitable solution to the issue is a specialized system that will build protection based on training and traffic profiling, and will also be stateless, i.e. will not store information about established connections. Alternatively, it can be Netscout Arbor DDoS, Fortinet FortiDDoS, domestic BIFIT Mitigator, service of a telecom operator, or cloud-based Kaspersky DDoS Protection.

DDoS protection is relevant on Internet channels, so we will place it there. But first, let’s consider the options that the market offers us:

Option 1 – proprietary DDoS protection

DDoS protection is installed on all Internet channels “in-line” between the perimeter gateway and the Internet:

Option 2 – DDoS protection as a service of a telecom operator

Now, many telecom operators provide DDoS protection as a service, while the client receives already cleaned traffic at the entrance. Nothing fundamentally changes here, just a DDoS protection tool is installed in the operator’s cloud and is in his area of responsibility:

Option 3 – cloud-based DDoS protection

The situation is similar to the option with a telecom operator, where traffic filtering is provided as a service, but with a significant difference – now this is done by a third-party organization and you need to redirect traffic to it in some way. The standard option is redirection at the network level through the announcement by a third party of our BGP prefixes, and from us to the organization, for example, a GRE tunnel is built: