finish the intro

This commit is contained in:
midas 2025-02-08 19:06:22 +01:00
parent ec50e6dd59
commit 63d453efd7

View file

@ -88,13 +88,21 @@
</ul>
<h2>How do I do it?</h2>
How you monitor your systems can vary based on your technical requirements. It can be as simple as logging in once a week, check the output of some diagnostic command and calling it a day.
This will give you a snapshot but you will miss a lot of important information. You can also set up a complicated system that reports current metrics, trends and gives you capacity planning alerts
How you monitor your systems can vary based on your technical requirements. It can be as simple as logging in once a week, check the output of some diagnostic command and calling it a day. <br>
This will give you a snapshot but you will miss a lot of important information.
<br><br>
You can also set up a complicated system that reports current metrics, trends and gives you capacity planning alerts
based on the data obtained!
You will have to find the middle-ground yourself, this article will propose one that you can tweak whichever way you need.
<h2>Risks of doing it improperly</h2>
Accessing your server for monitoring purposes is, from a risk perspective, pretty much the same as doing any other administration task or interacting with the services hosted therein. If done improperly (say logging in over the clearweb from your home address) you've just given anyone looking an undeniable link between your overt identity and your clandestine activities.<br><br>
A <b>fail-closed</b> system is what you should strive for: opsec best practices should be the default and if there's a technical issue preventing you from following them (attack on tor, flaky network, client or server-side misconfiguration) the system should prevent access at all in order to keep you safe.
</div>
</div><!-- /row -->
</div> <!-- /container -->