On 4/17/2024 10:49 AM, Edward Rawde wrote:
You could ping me if you knew my IP address.
>
You can't see me, at all. You have to know the right sequence of packets
(connection attempts) to throw at me before I will "wake up" and respond
to the *final*/correct one. And, while doing so, will continue to
ignore *other* attempts to contact me. So, even if you could see that
I had started to respond, you couldn't "get my attention".
I've never bothered with port knocking.
Those of us with inbound connectable web servers, database servers, email
servers etc have to be connectable by more conventional means.
As with installing updates and other "maintenance issues", I have
no desire to add to my workload. I want to spend my time *designing*
things.
I run the server to save me time handling requests from colleagues for
source code releases. This lets them access the repository and
pull whatever versions they want without me having to get them and
send them. Otherwise, they gripe about my weird working hours, etc.
(and I gripe about their poorly timed requests for STATIC resources)
There is some overhead to their initial connection to the server
as the script has to take into account that packets aren't delivered
instantly and retransmissions can cause a connection attempt to be
delayed -- so, *I* might not see it when they think I am.
But, once the connection is allowed, there is no additional
overhead or special protocols required.
I wouldn't bother. I'd just not connect it to wifi or wired if I
thought
there was a risk.
>
What I mean by that is I'd clean it without it being connected.
The Avira boot CD used to be useful but I forget how many years ago.
>
If you were to unplug any of the above mentioned ("house") drops,
you'd find nothing at the other end. Each physical link is an
encrypted tunnel that similarly "hides" until (and unless) properly
tickled. As a result, eavesdropping on the connection doesn't
"give" you anything (because it's immune from replay attacks and
it's content is opaque to you)
I'm surprised you get anything done with all the tickle processes you must
need before anything works.
I wouldn't "unplug any of the above mentioned drops". I'd let them connect
using their native protocols. This is already baked into the code so "costs"
nothing.
The hiding prevents an adversary from cutting an exposed (e.g., outside the
house) cable and trying to interfere with the system. Just like an adversary
on a factory floor could find a convenient, out-of-the-way place to access the
fabric with malevolent intent. Or, a guest in a hotel. Or, a passenger
on an aircraft/ship. Or, a CAN node in an automobile (!).
They should be secure from the threats they are LIKELY TO FACE.
If the only access to my devices is by gaining physical entry
to the premises, then why waste CPU cycles and man-hours protecting
against a threat that can't manifest? Each box has a password...
pasted on the outer skin of the box (for any intruder to read).
Sounds like you are the the only user of your devices.
I'm a "development lab". I want to spend my time using my tools to
create new products. I don't want to bear the overhead of trying to
keep up with patches for 0-day exploits just to be able to USE those
tools. I am more than willing to trade the hassle of walking
down the hall to another computer (this one) to access my email.
And, if I DL a research paper, copying it onto a thumb drive to
SneakerNet it back to my office. To me, that's a HUGE productivity
increase!
Consider a small business.
Here you want a minimum of either two LANs or VLANs so that guest access to
wireless can't connect to your own LAN devices.
Your own LAN should have devices which are patched and have proper
identification so that even if you do get a compromised device on your own
LAN it's not likely to spread to other devices.
The house network effectively implements a VLAN per drop. My OS only lets
"things" talk to other things that they've been preconfigured to talk to.
So, I can configure the drop in the guest bedroom to access the ISP.
Or, one of the radios in the ceiling to do similarly. If I later decide that
I want to plug a TV into that guest bedroom drop, then the ISP access is
"unwired" from that drop and access to the media server wired in its place.
And, KNOW that there is no way that any of the traffic on either of those
tunnels can *see* (or access) any of the other traffic flowing through the
switch. The switch is the source of all physical security as you have
to be able to convince it to allow your traffic to go *anywhere* (and WHERE).
[So, the switch is in a protected location AND has the hardware
mechanisms that let me add new devices to the fabric -- by installing
site-specific "secrets" over a secure connection]
Because a factory floor would need the ability to "dial out" from a
drop ON the floor (or WiFi) without risking compromise to any of
the machines that are concurrently using that same fabric.
Imagine having a firewall ENCASING that connection so it can't see *anything*
besides the ISP. (and, imagine that firewall not needing any particular rules
governing the traffic that it allows as it's an encrypted tunnel letting
NOTHING through)
You might also want a firewall which is monitored remotely by somone who
knows how to spot anything unusual.
I have much written in python which tells me whether I want a closer look at
the firewall log or not.
Yet another activity I don't have to worry about. Sit in the guest bedroom
and you're effectively directly connected to The Internet. If your machine
is vulnerable (because of measures YOU failed to take), then YOUR machine
is at risk. Not any of the other devices sharing that fabric. You can get
infected while sitting there and I'm still safe.
My "labor costs" are fixed and don't increase, regardless of the number
of devices and threats that I may encounter. No need for IT staff to handle
the "exposed" guests -- that's THEIR problem.
Do I *care* about the latest MS release? (ANS: No)
Do I care about the security patches for it? (No)
Can I still do MY work with MY tools? (Yes)
But only for your situation.
If I advised a small business to run like that they'd get someone else to do
it.
And they would forever be "TAXED" for their choice. Folks are starting
to notice that updates often don't give them anything that is worth the
risk/cost of the update. Especially if that requires/entices them to have
that host routed!
My colleagues have begrudgingly adopted a similar "unrouted development
network" for their shops. The savings in IT-related activities are
enormous. And, they sleep more soundly knowing the only threats
they have to worry about are physical break-in and equipment
failure.
You want to check your email? Take your phone out of your pocket...
Need to do some on-line work (e.g., chasing down research papers
or browsing a remote repository)? Then move to an "exposed"
workstation FOR THAT TASK.
[Imagine if businesses required their employees to move to such
a workstation to browse YouTube videos or check their facebook
page! "Gee, you're spending an awful lot of time 'on-line',
today, Bob... Have you finished that DESIGN, yet?"]
I have to activate an iPhone, tonight. So, drag out a laptop
(I have 7 of them), install the latest iTunes. Do the required
song and dance to get the phone running. Wipe the laptop's
disk and reinstall the image that was present, there, minutes
earlier (so, I don't care WHICH laptop I use!)
You'll have to excuse me for laughing at that.
Cybersecurity is certainly a very interesting subject, and thanks for the
discussion.
If I open one of the wordy cybersecurity books I have (pdf) at a random page
I get this.
"Once the attacker has gained access to a system, they will want to gain
administrator-level access to the current resource, as well as additional
resources on the network."
Hence the reason for NOT letting anything "talk" to anything that it shouldn't.
E.g., the oven has no need to talk to the front door lock. Or, the garage
door opener. Or, the HVAC controller. So, even if compromised, an adversary
can only do what those items could normally do. There is no *path* to
the items that it has no (designed) need to access!
With a conventional fabric, anything that establishes a beachhead on ANY
device can start poking around EVERYWHERE. You have to monitor traffic
INSIDE your firewall to verify nothing untoward is happening (IDS -- yet
another cost to install and maintain and police!)
Well duh. You mean like once the bank robber has gained access to the bank
they will want to find out where the money is?
Banks keep the money is well-known places. Most commercial (and free) OS's
are similarly unimaginative. So, *looking* for it is relatively easy.
Especially OSs which use a unified file system as a naming mechanism
for everything in the system ("Gee, let's go have a peek at passwd(5)...")
In my approach, an actor only knows about the items that he SHOULD know about.
So, you may *SUSPECT* that there is a "front door" but the only things you
have access to are named "rose bush" and "garden hose" (if you are
an irrigation controller).
In a conventional (50 year old design!) system, you would *see* the names
of all of the devices in the system and HOPE that someone had implemented
one of them incorrectly. Your task (pen-test) would be to figure out
which one and how best to exploit it.
Had the designers, instead, adhered to the notions of information hiding,
encapsulation, principle of least privilege, etc. there's be less attack
surface exposed to the "outside" AND to devices on the *inside*! (But,
you need to approach the design of the OS entirely differently instead of
hoping to layer protections onto some legacy codebase)