On Fri, 29 May 2020 at 03:26, Andy Smith <andy(a)bitfolk.com> wrote:
On Thu, May 28, 2020 at 08:27:37PM +0100, Adam Spiers
Bitfolk's monitoring service is great:
but it just occurred to me that (IIUC) it only monitors for *reachable*
services, not for unreachable ones - i.e. whether the firewall is
correctly shielding a particular port or protocol.
It looks like there are some existing ideas around using Nagios
(which Icinga is a fork of) to monitor which ports are allowed to be
it makes sense (to me, at least) to try to
implement at least some
basic tests to monitor the correct behaviour of the firewall.
I don't do this, but what I do try to do is manage firewall rules in
config management. If you alter the firewall rules on most of my
hosts then your alteration will be reverted by Ansible at the next
So, that's not monitoring but it is at least maintaining a defined
Sure. I use Uruk, which is a vaguely similar approach, although
of course specific to firewall configuration.
there are way too many ports for such a monitor to check them
all, but even checking a single port for which no services are expected to
be running would be a lot better than nothing, since this could catch a
large number of cases where basic firewall configuration errors have been
made, or where the firewall was accidentally turned off or simply failed to
Does this make sense or has the sun gone to my head?
I'm not sure I see the value of checking if a single arbitrary port
... except that you do:
other than that it may let you know that you forgot to
your firewall at all.
Yes exactly, that's what I said ;-) This is probably a fairly easy
mistake to make
(e.g. accidentally disabling, or some syntax error in the config which prevents
the service from starting), so surely there's significant value in doing this.
Perhaps if you wrote a script that does a thorough
port scan (maybe
you leverage nmap and its machine-readable output for this), records
the state of every port (no response, open, etc) and stores that in
a file, then monitoring any changes in that file would let you know
that something new is listening.
If you ran an NRPE daemon then you could craft your own Icinga check
along that theme. It might simply diff the output of the script
above with the expected output and give OK when there is no diff or
WARNING when there is. That would then enable you to determine if
the change is expected or not.
That would have the advantage that you could manage it all yourself
(once it's set up), but the disadvantage that so could anyone
else who gains root on your VM. Seems like quite a stretch to think
that an attacker would search for such a protection mechanism and
take the time to defeat it though.
Yep thanks, that sounds like a very nice idea for a more sophisticated
approach! I like to start simple though ;-)
I know there's a few others customers here who are
penetration testing business. I'd be interested to hear if they have
any ongoing processes to check that a host's "network footprint"
hasn't changed from some ideal state.