Logs when removing the server. Demon Guard (unix)
A little advice on how to protect yourself when removing a server, a hypothetical daemon (in terms of unix).
Based on the fact that somewhere in the news ran through the information that from a short time the owners of the resources will not be responsible for the content posted by users (and statements).
In short - for those who are too lazy to read. The task is to ensure that no one without you could compromise the file system of your server without you.
1. As a proposal, I believe that it makes sense to store (duplicate) the system logs on a remote server (abroad), as well as locally, but also there and there in encrypted form. The point of the idea is that if the site owner is blamed for the fact that it was he who uploaded and holds the file, for example, with child porn and the staff of the authorities will point to a file, for example, lying in /opt/some_public_service/childporno.mkv in court, you can show your logs, a copy of them from a remote server and, on the basis of this, prove that the file was not uploaded by you, but appeared in an unknown way while the server was “somewhere outside the hoster site”. Technically it is easy to implement.
Of course, your logs will most likely not be notarized, but the court may take them into account.
/ * therefore - not you are distributing DP, but employees of the structure :) * /
')
2. You can go a little further and implement the following functionality / daemon: When the server is located outside the hoster site, if the daemon cannot ping a certain ip, then the application / daemon extinguishes external services, simultaneously encrypting their configuration, and deleting configuration files from the usual ones / demon places. Thus, you can protect yourself from the fact that compromising material will be uploaded to your server through public services.
3. In addition, to our hypothetical daemon: It makes sense to configure security settings (for example, SE Linux) or zones (Solaris zones?) So that if a certain resource is unavailable or vice versa - a message on Twitter, a text file on a remote server, or controlled by you, but an independent resource, the system parameters change - the RO file system, or a complete ban on writing from any context. In general, you can think of a lot of things, the main thing is to develop a mechanism and a security model that allow you to clearly define what appeared on the server at the time of its control by you, and what “self-generated” later.
For example, you can enter evaluation criteria for the inclusion of a read-only context for a file system or for its self-destruction:
incorrect shatdaun
not receiving keep-alive messages from an external source
availability / inaccessibility of the code word / file, for example, remove_all.txt on the remote resource
3 attempts to enter a wrong password
uncharacteristic picture of the network (unusual routes, unusual pings, etc.)
etc.
in any combinations / criteria configured by the resource owner.
4. In any case, in my opinion it’s not worth erasing / self-destructing a file system, but you should leave the option to enable the server / access the file system only for you and you can do it in the presence of a lawyer / witnesses and so on.
Keep in mind that it is not entirely reasonable to destroy a server FS, since this may try to classify as the destruction of evidence.
Based on the fact that somewhere in the news ran through the information that from a short time the owners of the resources will not be responsible for the content posted by users (and statements).
In short - for those who are too lazy to read. The task is to ensure that no one without you could compromise the file system of your server without you.
1. As a proposal, I believe that it makes sense to store (duplicate) the system logs on a remote server (abroad), as well as locally, but also there and there in encrypted form. The point of the idea is that if the site owner is blamed for the fact that it was he who uploaded and holds the file, for example, with child porn and the staff of the authorities will point to a file, for example, lying in /opt/some_public_service/childporno.mkv in court, you can show your logs, a copy of them from a remote server and, on the basis of this, prove that the file was not uploaded by you, but appeared in an unknown way while the server was “somewhere outside the hoster site”. Technically it is easy to implement.
Of course, your logs will most likely not be notarized, but the court may take them into account.
/ * therefore - not you are distributing DP, but employees of the structure :) * /
')
2. You can go a little further and implement the following functionality / daemon: When the server is located outside the hoster site, if the daemon cannot ping a certain ip, then the application / daemon extinguishes external services, simultaneously encrypting their configuration, and deleting configuration files from the usual ones / demon places. Thus, you can protect yourself from the fact that compromising material will be uploaded to your server through public services.
3. In addition, to our hypothetical daemon: It makes sense to configure security settings (for example, SE Linux) or zones (Solaris zones?) So that if a certain resource is unavailable or vice versa - a message on Twitter, a text file on a remote server, or controlled by you, but an independent resource, the system parameters change - the RO file system, or a complete ban on writing from any context. In general, you can think of a lot of things, the main thing is to develop a mechanism and a security model that allow you to clearly define what appeared on the server at the time of its control by you, and what “self-generated” later.
For example, you can enter evaluation criteria for the inclusion of a read-only context for a file system or for its self-destruction:
incorrect shatdaun
not receiving keep-alive messages from an external source
availability / inaccessibility of the code word / file, for example, remove_all.txt on the remote resource
3 attempts to enter a wrong password
uncharacteristic picture of the network (unusual routes, unusual pings, etc.)
etc.
in any combinations / criteria configured by the resource owner.
4. In any case, in my opinion it’s not worth erasing / self-destructing a file system, but you should leave the option to enable the server / access the file system only for you and you can do it in the presence of a lawyer / witnesses and so on.
Keep in mind that it is not entirely reasonable to destroy a server FS, since this may try to classify as the destruction of evidence.
Source: https://habr.com/ru/post/91812/
All Articles