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).
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.
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.
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 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.
How to make every file/directory, the file-system, schg immutable without
breaking the system?
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.
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.
I did not come across any literature on how to mitigate the mentioned CVE in
OpenBSD.
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.
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.
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.
I am trying to make the openbsd firewall bulletproof as much as possible,
sealing all possible gaps, otherwise, IDS/IPS is useless.
Appreciate your kind support.
Many thanks.
------- Original Message -------
On Thursday, September 8th, 2022 at 9:49 AM, jonathon575
<jonathon...@protonmail.com> wrote:
> from a quick glance the firewall seems ok. However, if the clients in
> your network route all their traffic through VPN OpenBSD on the local
> firewall cannot help. And on those VPN_IPs, what are the firewall rules?
>
> Hint: if the VPN_IPs are compromised traffic can be probably forwarded
> to your hosts in the network which then might be the same as having
> those client computers directly connected to the internet, without any
> firewall. Also, restrict outgoing traffic on the VPN_IPs - it's quite
> simple for a malware to e.g. make a reverse tunnel (like with ssh).
>
> Be sure to have your linux desktop devices updated. What firewall was
> compromised - your OpenBSD based firewall? ... hope you did a fresh
> install from scratch on this device...
>
> =============================================================================
>
> Thank you very much for your feedback. Highly appreciated.
>
> Yes, you are correct. The spyware did generate a reverse tunnel, and we were
> able to isolate and identify the traffic and the ip addresses that the
> spyware was connecting to.
>
> ==============================================================================================================================================================================
>
> #"However, if the clients in your network route all their traffic through VPN
> OpenBSD on the local firewall cannot help."#
>
> With the constants attacks we are getting, we had to route all traffic
> through the VPN. Any transmission other than VPN is easily be cracked by the
> attacker including TOR, through MiTM attack.
>
> =============================================================================================================================================================================
>
> #"And on those VPN_IPs, what are the firewall rules?"#
>
> Kindly find below the rules for the VPN_IPs and the related DNS. Those below
> rules are on the OpenBSD firewall which is also the gateway to the internet,
> and the VPN is generated from the desktops connected to the LAN which is
> behind the firewall. Every desktop has VPN and its firewall configured to
> route all traffic through the VPN:
>
> pf.conf:
>
> block drop in quick on $ext_if from <abusive_hosts> to any
>
> #Allow on LAN int_if
> pass log (all) on $int_if inet proto tcp from $lan_net to <VPN_IPs> port
> $VPN_TCP_Ports modulate state \
> (if-bound, max 200, source-track rule, max-src-nodes 3, max-src-states 3, \
> max-src-conn 10, max-src-conn-rate 5/3, overload <abusive_hosts> flush global)
>
> #DNS
> pass log (all) on $int_if inet proto tcp from $lan_net to $VPN_DNS port
> $VPN_DNS_Ports modulate state \
> (if-bound, max 200, source-track rule, max-src-nodes 3, max-src-states 3, \
> max-src-conn 10, max-src-conn-rate 5/3, overload <abusive_hosts> flush global)
>
> #Allow outbound on WAN ext_if
> pass out log (all) on $ext_if inet proto tcp to <VPN_IPs> port $VPN_TCP_Ports
> modulate state (if-bound, max 200,\
> source-track rule, max-src-nodes 2, max-src-states 3, max-src-conn 10,
> max-src-conn-rate 5/3,\
> overload <abusive_hosts> flush global)
>
> #DNS
> pass out log (all) on $ext_if inet proto tcp to $VPN_DNS port $VPN_DNS_Ports
> modulate state \
> (if-bound, max 200, source-track rule, max-src-nodes 3, max-src-states 3, \
> max-src-conn 10, max-src-conn-rate 5/3, overload <abusive_hosts> flush global)
>
> ==================================================================================================================================================================================
>
> #Hint: if the VPN_IPs are compromised traffic can be probably forwarded to
> your hosts in the network which then might be the same as having those client
> computers directly connected to the internet, without any firewall. Also,
> restrict outgoing traffic on the VPN_IPs - it's quite simple for a malware to
> e.g. make a reverse tunnel (like with ssh).#
>
> Yes, you are correct. However, please allow me to elaborate further.
>
> When I first got OpenBSD, I configured it and put it in place as firewall,
> since then, our network was totally secured for a while. You won't believe
> the constant attacks we kept getting trying to penetrate the firewall, yet,
> OpenBSD was solid and all attacks failed, even with the VPN passing through
> OpenBSD as explained above. The time that the attacker penetrated the
> firewall was when it was revealed that the platform was OpenBSD, it was then
> that the attacker was able to penetrate within 24 hours, even though I was
> blocking all incoming connections.
>
> Now, how the attacker knew that I used OpenBSD firewall?!!
>
> Well, I made the most stupid mistake, which was updating OpenBSD online. When
> updating OpenBSD online, obviously, it connected to the relevant server. That
> connection/transmission to OpenBSD servers for update revealed that I was
> using OpenBSD platform. Instead, what I should have done was to download the
> files and update it manually. But as I said, I was stupid to update online.
> The mentioned firewall rules did not protect the firewall from penetration
> once the platform was revealed.
>
> That's why I said in the previous post, either I am doing something wrong in
> the rules which caused easy penetration (even if the platform was revealed),
> or there is something missing in the configuration/package that could provide
> higher protection and I failed to take advantage of, or there is a
> vulnerability in openbsd that is unknown in which they took and still taking
> advantage of. God forbid, there is a hidden built in backdoor. IDS/IPS was
> useless once the platform was revealed.
>
> Specifically, regarding IPs getting compromised or spoofed. In my situation,
> before the platform was revealed, that happened only once. It was when I
> switched the VPN transportation protocol from TCP to UDP. When I switched to
> UDP, the penetration happened almost instantly during the UDP based VPN
> connection even when the attacker did not know what platform I was using.
> Just the use of the UDP caused the security breach. So yes, you are
> absolutely correct about compromising IPs, injecting with malware and
> spoofing it ...etc, but with us, that was successful only when using UDP
> protocol. This was not the case with TCP protocol for the VPN. With TCP based
> VPN, the only time the penetration happened was when the platform was
> revealed. Transmission wise, maybe, both are equally secured, however, with
> UDP, the node generating the UDP based transmission would be much more
> vulnerable to attacks and penetration, thereby by passing the encryption.
>
> That's why if you noticed in my configuration, based on our experience, I
> only allow TCP including for the DNS and completely avoid UDP.
>
> In the mentioned rules and configuration in pf.conf for the TCP and firewall,
> I did the best to my knowledge to protect the TCP transmission from getting
> spoofed, corrupted, injected, port penetration...etc. but if there is
> something that I missed, then I would really need yours and the bsd community
> advise on what should I do better to provide higher/maximum protection, and
> what was I doing wrong.
>
> Hint: A word of advise, whether intentionally, or unintentionally, never,
> ever reveal your platform, firewall, system...etc publicly or to any one
> untrusted whether for corporate or home. We learned that the hard way. Keep
> the outside world completely blind. This could be the first and most
> important security rule. Even if using previous and older versions, still, it
> will be safer as long as the attacker is blind to what you are using. Also,
> try to avoid UDP whenever possible. From educational perspective,
> consultation...etc, it would be very valuable to explain the systems,
> technologies, platforms...etc. and the best most secured utilization for
> various scenarios, but try to avoid mentioning that your organization/home is
> using so and so.
>
> =========================================================================================================================================================================================
>
> #Be sure to have your linux desktop devices updated.#
>
> Always updated.
>
> =========================================================================================================================================================================================
>
> #What firewall was compromised - your OpenBSD based firewall? ... hope you
> did a fresh
> install from scratch on this device...
>
> Yes, it was OpenBSD based firewall 7.1. Fresh install from scratch didn't
> help as the attack appeared again.
>
> ========================================================================================================================================================================================
>
> Based on the above, when I said in the previous post the phrase "extreme
> hostile environment", I was not exaggerating. The attacker has a huge
> database with every single platform, program, systems and related releases,
> with all its vulnerabilities and successful attacks. Please put your self in
> my situation, what should I do? What better configuration/package for the
> TCP/OpenBSD protocol/platform/Firewall should I use to have maximum
> protection? What am I doing wrong that I should do better.
>
> One last thing, as I mentioned previously, I am using the latest
> OpenVPN/OpenSSL, TCP based VPN on the linux based desktops. The VPN was solid
> and could not be cracked if constantly updated to the latest versions. I
> suppose the same should be for OpenBSD. If updated, it should not be breached
> even if the platform was revealed.
>
> Appreciate the support.
>
> Below is the full pf.conf configuration:
>
> ***********
> * pf.conf *
> ***********
>
> ext_if = "re0"
> int_if = "em0"
> lan_net = "192.x.x.0/xx"
>
> table <abusive_hosts> persist
>
> table <private_networks> const {10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,
> 127.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4,
> 100.64.0.0/10, 127.0.53.53, 192.0.0.0/24, 198.18.0.0/15, 198.51.100.0/24,
> 203.0.113.0/24, 224.0.0.0/4, 255.255.255.255/32}
>
> table <VPN_IPs> { #.#.#.#, #.#.#.#.#....etc }
>
> VPN_DNS = "{ #.#.#.#, #.#.#.#.#....etc }"
>
> VPN_TCP_Ports = "{ ####, ####, #### ...etc }"
>
> VPN_DNS_Ports = "{ ###, ### ...etc }"
>
> #Drop All on Block
> set block-policy drop
>
> set state-policy if-bound
>
> #Reassemble Packets
> set reassemble yes
>
> #SKIP LOOPBACK
> set skip on lo0
>
> #SCRUB PACKETS
> match in all scrub (no-df random-id max-mss 1440 reassemble tcp)
> match all scrub (reassemble tcp)
>
> #SET UP NAT:
> #match out on $ext_if inet from !($ext_if) nat-to ($ext_if) # when behind a
> router
>
> match out log (all) on $ext_if inet from $lan_net to any nat-to ($ext_if) #
> when facing the internet
>
> # activate spoofing protection for all interfaces
> block in from no-route
> block in log (all) quick from urpf-failed
>
> # BLOCK THE OBVIOUSLY BOGUS **QUICK**
> block in quick log on $ext_if from any to $lan_net
> block in quick log on $ext_if from no-route to any
> block in quick log on $ext_if from any to 255.255.255.255
> block in quick log on $ext_if from any to <private_networks>
> block in quick log on $ext_if from <private_networks> to any
> block return out quick log on $ext_if from any to <private_networks>
>
> #This times out idle connections more quickly, reducing memory and processor
> use.
> set optimization aggressive
>
> #set ruleset-optimization
>
> #ANTI-SPOOF **QUICK**
> #antispoof log (all) quick for $ext_if
> #antispoof log (all) quick for lo0
> #antispoof log (all) quick for $int_if
>
> #Block All Traffic
> block log (all) all
>
> #IPV6 CURRENTLY IRRELEVANT, DROP IT **QUICK**
> block drop in quick inet6
>
> block drop in quick on $ext_if from <abusive_hosts> to any
>
> #Allow on LAN int_if
> pass log (all) on $int_if inet proto tcp from $lan_net to <VPN_IPs> port
> $VPN_TCP_Ports modulate state \
> (if-bound, max 200, source-track rule, max-src-nodes 3, max-src-states 3, \
> max-src-conn 10, max-src-conn-rate 5/3, overload <abusive_hosts> flush global)
>
> #DNS
> pass log (all) on $int_if inet proto tcp from $lan_net to $VPN_DNS port
> $VPN_DNS_Ports modulate state \
> (if-bound, max 200, source-track rule, max-src-nodes 3, max-src-states 3, \
> max-src-conn 10, max-src-conn-rate 5/3, overload <abusive_hosts> flush global)
>
> #Allow outbound on WAN ext_if
> pass out log (all) on $ext_if inet proto tcp to <VPN_IPs> port $VPN_TCP_Ports
> modulate state (if-bound, max 200,\
> source-track rule, max-src-nodes 2, max-src-states 3, max-src-conn 10,
> max-src-conn-rate 5/3,\
> overload <abusive_hosts> flush global)
>
> #DNS
> pass out log (all) on $ext_if inet proto tcp to $VPN_DNS port $VPN_DNS_Ports
> modulate state \
> (if-bound, max 200, source-track rule, max-src-nodes 3, max-src-states 3, \
> max-src-conn 10, max-src-conn-rate 5/3, overload <abusive_hosts> flush global)
>
> #===================================================================================================================
