Thank you very much Nick. I truly appreciate your advise. Jonathon.
Sent with Proton Mail secure email. ------- Original Message ------- On Tuesday, May 2nd, 2023 at 2:01 AM, Nick Holland <n...@holland-consulting.net> wrote: > 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.
