On 4/26/23 08:46, jonathon575 wrote:
Greetings,
I have OpenBSD configured strictly as a dedicated firewall. Only BSD,
BSD.rd, BSD.mp, and Base are installed (supposedly, this is the
minimum installation). Blocked All, and only few selected out going
IP addresses are allowed (strictly vpn ip addresses).
which basically means, you blew a huge hole in the firewall.
VPNs don't ADD security, they let infested computers you can't properly
maintain enter your network from all over the world. They take a
horrible idea (let people into your network) and make it less bad.
But there's a gap between "less bad" and "good". No firewall can
fix this.
I maintained rc.conf at its default configuration, including disabled
ntpd, smtpd, sndiod, sshd, then deleted sshd binary file and related
library directory, as well as deleted the portmap file. However, the
penetration is still happening. IPS is not helping. DHCP is enabled
and configured for LAN.
So...totally non-default config.
you can't track activity by accurate time stamps (no NTP), you can't
remotely manage the machine, and you have a management nightmare on
your hands.
I do have few clarifications, and kindly need your expertise:
1) Regarding the log files, how to sappnd the .history file? I could
not locate it. Kindly advise.
just..don't.
When you start worrying about stuff like that, you are no longer
preventing attack, you are just measuring it.
2) I read the publications of Mr. Michael Lucas, he did state that he
had intruders to his openbsd systems few times, and the way to stop
and frustrate the bugger was to make every file immutable, but, he
did not specify how to do that without breaking the system.
"I want to shoot myself in the foot, but I want to be ok"
No, what you are proposing is a very good definition of "breaking
the system".
and again... It is far better to keep people out of your system
through proper maintenance than try to slow 'em down once they
are in it. Now, if you have a horrible web application, ok, sure,
you might want to go all defense-in-depth here, because, well your
application sucks and we know you aren't going to fix that, and some
C-level said, "This is the answer, make it work". But a firewall
should be a pretty robust thing and a bad target anyway.
If I want into your network, I'm not going to waste time on your
firewall, I'll work over the things you expose *through* the
firewall. That's where the data is anyway...
I had the> directories /bin, /sbin, /usr/bin, /usr/sbin, /etc, schg immutable
(chflags -R schg ), however, when applying it to other directories
including the lib related directories such as /usr/lib, /lib, ..etc I
get the error message "relink reorder failed..." when restarting the
system.
yep. You shot yourself in the foot, and it hurts. You haven't even
started to experience the pain of bleeding out, either. That comes
when you try to upgrade this frankensystem.
How to make every file/directory, the file-system, schg immutable
without breaking the system?
you don't.
3) [CVE-2019-14899] Inferring and hijacking VPN-tunneled TCP
connections.
The above outgoing IP addresses are strictly related to VPN TCP ip
addresses, so I hope the mentioned CVE is rectified in openbsd,
however, I am not sure what new vulnerabilities are present with the
existing, latest openbsd and VPN protocols that would have similar
effects.
Well, your comments on that CVE are about as clear as the CVE itself
is. Looks like it boils down to "if someone can get into your systems
enough to see packets, they can guess where they are going."
How did you decide THIS was your big concern?
I included the below lines in the pf.conf to try to mitigate this
vulnerability:
set reassemble yes match in all scrub (no-df random-id reassemble tcp
max-mss 1440)
However, it was still not sufficient to prevent the penetration.
that wasn't how your systems were penetrated. Almost certain of that.
I did not come across any literature on how to mitigate the mentioned
CVE in OpenBSD.
that's a big hint.
4) Perl: How to remove Perl and other scripting languages from the
base installation without affecting other utilities that use it?! I
do not have comp.tgz installed, but if perl is present, Perl can do
anything that most compiled languages allow and can often do it
quicker.
:eyeroll:
This idea is stupid. Just plain stupid.
(Granted, it is a common stupid idea. But there's a lot of stupid
in the world)
Do you discard all the tools in your house because a thief might
use them to disassemble stuff inside your house? Discard the soap
because they might want to wash their hands? Turn off the water
in case they get thirsty? Turn off the heat and AC so they won't be
comfortable? That's what this line of logic boils down to. Any
self-respecting burglar will bring their own tools, meanwhile stuff
will be falling apart all around you over your misguided sense of
security.
5) Disabled Services.
The services in the file rc.conf are kept in its default state which
is mostly disabled. the binary files sshd, portmap, ntpd are deleted
from the /bin directory. Other binary files telnet, ssh, scp, sftp
are removed to prevent any file transfer from the firewall to the LAN
network.
so .. you have rendered your machine unmaintainable, un-patchable.
NO. DON'T DO ANY OF THIS.
Strictly for a firewall, what additional services/binary files that
should be disabled/removed to prevent firewall penetration, and/or
prevent any rootkit, malware from getting executed and/or accessing
the LAN network. Managing the firewall is only through direct
terminal access.
NONE. You are proposing doing this wrong.
You are confusing administrative pain with security. My opinion
backed up with lots of experience: if you can't administer and
maintain your systems, it won't be secure.
I am trying to make the openbsd firewall bulletproof as much as
possible, sealing all possible gaps, otherwise, IDS/IPS is useless.
Just do this:
Do a base install of the entire OpenBSD system (yes, comp73, x*,
games73. Leave all the boxes checked. Say "no" when it asks
if you want to run X, say you don't want root to be able to login
via SSH (or prohibit password).
Assuming multiple administrators, set up doas. when done, disable
root logins by password, both in ssh and by adding or deleting a few
characters in the PW hash in vipw. Install all your administrator's
public keys. Disable PW logins in ssh. (yeah, I kinda said that
three times. kinda). (this paragraph, you could call "hardening".
That will make a C-level happy).
Set up a tight set of PF rules. Probably block ssh from the outside.
Don't add anything to the machine you don't absolutely need, but
don't delete or "disable" stuff, either. I usually add rsync to a
FW (helps with backups, though for other things, included openrsync
is probably sufficient). I can't think of anything else you want to
add to a basic, tight firewall...but don't remove anything, either.
Now...update it whenever the urge or need hits you -- at least every
six months. But it's easy to do.
Do this, and your firewall won't be how people break into your systems.
They will do it like they always do...bad C-level executive decisions,
stupid managers, bad applications, indifferent users (in roughly that
order). But it won't be your firewall that is the entry point, nor a
resource for the attackers.
As others said, be realistic about what the firewall does and doesn't
do for your security. Your firewall isn't how bad guys are getting
into your systems. Set up properly, it will slow 'em down, and perhaps
slow the spread from one vulnerable system to another.
Nick.
