On Mon, 2020-02-03 at 13:23 +0100, Janne Johansson wrote:
> And refine the risk strategies, since the above conversation seem to be
> centered around the concept of a hacker that
>
> 1. Someone successfully attacks your site over the internet, using your
> outward facing IP A.A.A.A
> 2. Manages to run code on your webserver
That outward facing address A.A.A.A seems to be hidden behind a tor web,
which means the attacker can access a server without knowing its real IP
address. Knowledge of this real IP address may be the ultimate aim of the hack.
> 3. May or may not divinate your internal IP B.B.B.B from that code.
If that address B.B.B.B is an internal IP address, the hacker may not be able
to succeed in the original quest. Note, that the hacker may also find the MAC
address of the device, and all connected devices, which may give away the owner
of the device.
> 4. The communicates information back to a server of their choice, perhaps
> using a third (external) ip C.C.C.C or not
This appears to be the crucial part. If the hacker can initiate connections from
the hacked device, the public facing IP address is prone to discovery.
Therefore I propose the following solution:
1. Put the potentially vulnerable device behind a firewall. The firewall
forwards
requests to the device and back, but allows no outgoing connections from the
protected device to the firewall or beyond.
2. Lock down the vulnerable device. If the device does not allow changing its
MAC
address, patch the kernel to report something else. Also make sure, that
your
vulnerable device creates no logs. Make sure, that the user account running
the potentially vulnerable application can not write to any directory, from
which executables can be started or dynamic libraries can be linked against.
3. Barriers are only effective, if they are properly defended. Your firewall
must
monitor and reliably unusual network activity from the vulnerable host, and
shut
down all network connections, if suspicious stuff happens. Consider a
configuration,
in which all disk access goes to a RAM disk, such that a simple reboot
restores
normal operation.
4. Obviously, no other device must be in the same network, especially not
devices,
which could provide hints about your identity.
