Hiding the actual place where the company's server is located: practical methods and question
Hello! I lead a small IT outsourcing, and last year we were approached by several clients with similar tasks at once - to make sure that no one knew where exactly the company's servers are located.
In the first case, it was a construction business, they have one of the features of the sphere that there should not even be a trace of correspondence on the machines, especially before tenders. Therefore, they have a RDP farm and terminals in the office. It was necessary to hide the core. In the second case, a service company that works with well-known personalities (this is just a security layer for them, which they do not consider superfluous). In the third - production for the oil sector, in which the sphere has an unrealistic unfair competition with the abandonment of insiders into foreign offices.
We came up with the following scheme:
')
In the center - the core, around the core - perimeter relay servers (cheap proxy machines, each with its own service), then - end-user terminals. Criticize, please, well, or try to calculate the kernel server IP using the example at the end.
The general idea is that only the business owner and the main admin know where the servers are physically located. Houses at the customer, in the basement of the office, in the garage or in the data center in Germany or Tula ... - it does not matter.
Naturally, big business is able to solve such problems (or they do not arise at all for a number of reasons, developed information security). But small and medium - no, and even by the forces of the admin it is not always possible to do this more or less correctly. Therefore, they knocked to us.
The idea of ​​protection is that:
- It is difficult to find the server IP, because for this you have to capture one of the relays-machines and the router.
- Relay machines are controlled by the routing server, which is protected by the traditional set: anti-DDoS, QoS, active intrusion prevention system and so on.
- The relays themselves are so weak in terms of resources that any attempt to push DDoS through them will result in cutting off the connection with the node and lifting another relay machine anywhere in the world for 5–6 minutes.
Relays are taken from random cheap web hosts (including those already tested by us) and are automatically picked up from the routing server dashboard. We do not have access to this dashboard - we make the installation and show what to change. After that, the customer sets a new password and specifies the IP of the parent server. This is confirmed by open source, which we give to the customer.
Naturally, the weak link is admin. But if he outbid him or forced to knock, still little will help.
The points give standard services such as mail, internal site, messenger, terminal, 1C applications. In general, the same thing as two classic servers, immured in the basement, but instead of the IP “basement” friends behind the masonry in the config of the user terminal - the IP machines of the perimeter.
As a result, a situation arises when:
More details:
We are still completing clustering - roundrobin and replication of the router server. Access points are fundamentally non-duplicable, because this is a very simple and cheap thing - it’s easier to deploy a new one than to duplicate it.
From unfair competition - quite a defense. The question is, have we foreseen everything on our bike?
Well, I invite you to try to check where the central server. Here are two machines with a web application published on them (in the expanded perimeter there are also access points):
45.32.154.167 - route number 1 to the site.
151.236.15.175 - route number 2 to the same site.
If you find the IP of the central server - from my bottle. Show me exactly how you found it - the second one. Contact mail: binfini@yandex.ru
UPD 03/01/16 6:33 PM Some people found a third route to the server, but not the server itself.
UPD 03/01/16 9:38 PM Someone else found a third route to the server, but not the server itself.
UPD 03/04/16 00:00 Thank you all very much for the attempts and advice, I suspend the kunkurs, the web server address was not found.
In the first case, it was a construction business, they have one of the features of the sphere that there should not even be a trace of correspondence on the machines, especially before tenders. Therefore, they have a RDP farm and terminals in the office. It was necessary to hide the core. In the second case, a service company that works with well-known personalities (this is just a security layer for them, which they do not consider superfluous). In the third - production for the oil sector, in which the sphere has an unrealistic unfair competition with the abandonment of insiders into foreign offices.
We came up with the following scheme:
')
In the center - the core, around the core - perimeter relay servers (cheap proxy machines, each with its own service), then - end-user terminals. Criticize, please, well, or try to calculate the kernel server IP using the example at the end.
Why do you need it?
The general idea is that only the business owner and the main admin know where the servers are physically located. Houses at the customer, in the basement of the office, in the garage or in the data center in Germany or Tula ... - it does not matter.
Naturally, big business is able to solve such problems (or they do not arise at all for a number of reasons, developed information security). But small and medium - no, and even by the forces of the admin it is not always possible to do this more or less correctly. Therefore, they knocked to us.
The idea of ​​protection is that:
- It is difficult to find the server IP, because for this you have to capture one of the relays-machines and the router.
- Relay machines are controlled by the routing server, which is protected by the traditional set: anti-DDoS, QoS, active intrusion prevention system and so on.
- The relays themselves are so weak in terms of resources that any attempt to push DDoS through them will result in cutting off the connection with the node and lifting another relay machine anywhere in the world for 5–6 minutes.
Relays are taken from random cheap web hosts (including those already tested by us) and are automatically picked up from the routing server dashboard. We do not have access to this dashboard - we make the installation and show what to change. After that, the customer sets a new password and specifies the IP of the parent server. This is confirmed by open source, which we give to the customer.
Naturally, the weak link is admin. But if he outbid him or forced to knock, still little will help.
The points give standard services such as mail, internal site, messenger, terminal, 1C applications. In general, the same thing as two classic servers, immured in the basement, but instead of the IP “basement” friends behind the masonry in the config of the user terminal - the IP machines of the perimeter.
As a result, a situation arises when:
- You can not find the server of the kernel - that is, for example, you can not steal or pick up something that does not exist.
- The router server protects against standard threats and filters untargeted traffic.
- At the entry point is low productivity - it lays down like a fuse.
More details:
We are still completing clustering - roundrobin and replication of the router server. Access points are fundamentally non-duplicable, because this is a very simple and cheap thing - it’s easier to deploy a new one than to duplicate it.
Details:
Installing a router server
The installation happens automatically, but in its process the following actually happens:
• On a clean system, a new user is created with sudo privileges.
• Disables root.
• Install OpenVPN, iptables-persistent, Prometheus, MongoDB, Nginx, management scripts, backup, monitoring, etc.
• Configure iptables.
• Prometheus is configured.
• Prometheus and node-exporter are configured.
• Nginx and MongoDB are configured.
• All scripts, agents and system images that will be involved in the installation of access points and connecting protected servers are unpacked and configured.
• On a clean system, a new user is created with sudo privileges.
• Disables root.
• Install OpenVPN, iptables-persistent, Prometheus, MongoDB, Nginx, management scripts, backup, monitoring, etc.
• Configure iptables.
• Prometheus is configured.
• Prometheus and node-exporter are configured.
• Nginx and MongoDB are configured.
• All scripts, agents and system images that will be involved in the installation of access points and connecting protected servers are unpacked and configured.
From unfair competition - quite a defense. The question is, have we foreseen everything on our bike?
Well, I invite you to try to check where the central server. Here are two machines with a web application published on them (in the expanded perimeter there are also access points):
45.32.154.167 - route number 1 to the site.
151.236.15.175 - route number 2 to the same site.
If you find the IP of the central server - from my bottle. Show me exactly how you found it - the second one. Contact mail: binfini@yandex.ru
UPD 03/01/16 6:33 PM Some people found a third route to the server, but not the server itself.
UPD 03/01/16 9:38 PM Someone else found a third route to the server, but not the server itself.
UPD 03/04/16 00:00 Thank you all very much for the attempts and advice, I suspend the kunkurs, the web server address was not found.
Source: https://habr.com/ru/post/278271/
All Articles