April 23, 2010 at 14:21Logs at server withdrawal. Guardian daemon (unix)
A little advice on how to protect yourself when removing a server, a hypothetical daemon (in unix terms).
Based on the fact that somewhere in the news information ran through that soon the resource owners 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 could compromise the FS of your server without you.
1. As a suggestion, I believe that it makes sense to store (duplicate) the system logs on a remote server (abroad), as well as on a local one, but both there and in encrypted form. The idea is that if the owner of the site is accused of the fact that it was he who uploaded and holds the file, for example, with child porn and employees of the authorities will point to the file, for example, lying in /opt/some_public_service/childporno.mkv, then 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 located “somewhere outside the host’s site”. Technically, this is easy to implement.
Of course, your logs will most likely not be notarized, but the court can take them into account.
/ * therefore - you do not distribute the DP, but the staff of the structure :) * /
2. You can go a little further and implement the following functionality / daemon: If the server is located outside the host’s site, if the daemon cannot ping a specific ip, then the application / daemon extinguishes external services, encrypting their configuration in parallel, and deleting configuration files from places familiar to the service / daemon. 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?) In such a way that when a resource is unavailable or vice versa - a message on Twitter, a text file on a remote server or otherwise the system parameters you control, but an independent resource, system parameters change - the RO file system, or a complete ban on recording from any context. In general, you can come up with a lot of things, the main thing is to develop a security mechanism and model that allows you to clearly determine what appeared on the server at the time of its control by you and what “spawned” later.
For example, you can enter evaluation criteria for enabling read-only context for FS or its self-destruction:
incorrect shutdown
non-receipt of keep-alive messages from an external source
availability / inadmissibility of a code word / file, for example remove_all.txt on a remote resource
3 attempts to enter the password incorrectly, an
uncharacteristic network picture (unusual routes, unusual pings, etc.)
, etc.
in any combinations / criteria configured by the owner of the resource.
4. In any case, it’s not worth it to erase / self-destroy the FS, but you should leave the opportunity to turn on the server / access the FS only to you and you can do this in the presence of a lawyer / witnesses, etc.
Keep in mind that it is not entirely wise to destroy the server FS, as they might try to classify it as the destruction of evidence.
Based on the fact that somewhere in the news information ran through that soon the resource owners 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 could compromise the FS of your server without you.
1. As a suggestion, I believe that it makes sense to store (duplicate) the system logs on a remote server (abroad), as well as on a local one, but both there and in encrypted form. The idea is that if the owner of the site is accused of the fact that it was he who uploaded and holds the file, for example, with child porn and employees of the authorities will point to the file, for example, lying in /opt/some_public_service/childporno.mkv, then 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 located “somewhere outside the host’s site”. Technically, this is easy to implement.
Of course, your logs will most likely not be notarized, but the court can take them into account.
/ * therefore - you do not distribute the DP, but the staff of the structure :) * /
2. You can go a little further and implement the following functionality / daemon: If the server is located outside the host’s site, if the daemon cannot ping a specific ip, then the application / daemon extinguishes external services, encrypting their configuration in parallel, and deleting configuration files from places familiar to the service / daemon. 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?) In such a way that when a resource is unavailable or vice versa - a message on Twitter, a text file on a remote server or otherwise the system parameters you control, but an independent resource, system parameters change - the RO file system, or a complete ban on recording from any context. In general, you can come up with a lot of things, the main thing is to develop a security mechanism and model that allows you to clearly determine what appeared on the server at the time of its control by you and what “spawned” later.
For example, you can enter evaluation criteria for enabling read-only context for FS or its self-destruction:
incorrect shutdown
non-receipt of keep-alive messages from an external source
availability / inadmissibility of a code word / file, for example remove_all.txt on a remote resource
3 attempts to enter the password incorrectly, an
uncharacteristic network picture (unusual routes, unusual pings, etc.)
, etc.
in any combinations / criteria configured by the owner of the resource.
4. In any case, it’s not worth it to erase / self-destroy the FS, but you should leave the opportunity to turn on the server / access the FS only to you and you can do this in the presence of a lawyer / witnesses, etc.
Keep in mind that it is not entirely wise to destroy the server FS, as they might try to classify it as the destruction of evidence.