28 May
2020
28 May
'20
7:27 p.m.
Bitfolk's monitoring service is great:
https://tools.bitfolk.com/wiki/Monitoring
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.
Now, I know that best practice is to ensure that all running services are
correctly configured to only listen to traffic from the networks from which
they can safely receive it, and that a good sysadmin should be able to
sleep comfortably at night even when his firewall is off (wide open).
However, that does not invalidate defence in depth; I don't think anyone
who advocates the above best practice would seriously recommend ditching
firewall rules. Therefore it makes sense (to me, at least) to try to
implement at least some basic tests to monitor the correct behaviour of the
firewall.
The kind of test I imagine is an attempted connection to a TCP or UDP port
which passes when the response is ICMP port unreachable (in the case of a
REJECT rule), or when a timeout expires without any response (in the case
of a DROP rule). The test could fail if a RST was received in the TCP
case, or in any case if any other response was received.
Of course 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
start.
Does this make sense or has the sun gone to my head?
Cheers,
Adam
29 May
29 May
2:26 a.m.
Hello,
On Thu, May 28, 2020 at 08:27:37PM +0100, Adam Spiers wrote:
Bitfolk's monitoring service is great:
https://tools.bitfolk.com/wiki/Monitoring
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
accessible:
https://exchange.nagios.org/directory/Plugins/Security/check_open_port/deta…
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
run.
So, that's not monitoring but it is at least maintaining a defined
state.
Of course 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
start.
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
is open, other than that it may let you know that you forgot to load
your firewall at all.
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.
I know there's a few others customers here who are in the
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.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
8:01 p.m.
On Fri, 29 May 2020 at 03:26, Andy Smith <andy(a)bitfolk.com> wrote:
... except that you do:
On Thu, May 28, 2020 at 08:27:37PM +0100, Adam Spiers
wrote:
Sure. I use Uruk, which is a vaguely similar approach, although
of course specific to firewall configuration.
Bitfolk's monitoring service is great:
https://tools.bitfolk.com/wiki/Monitoring
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
accessible:
https://exchange.nagios.org/directory/Plugins/Security/check_open_port/deta…
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
run.
So, that's not monitoring but it is at least maintaining a defined
state. Of course
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
start.
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
is open, other than that it may let you know that you forgot to
load
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
in the
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.
Me too!
Cheers,
Adam
1667
days inactive
1668
days old
2 comments
2 participants
participants (2)
-
Adam Spiers -
Andy Smith