Messages

good day,

here at the office, we use opnsense with the following plugins enabled:

unbound dns  - for managing dns on unencypted traffic
dnsscrypt       - for managing dns on encrpyted traffic
ftpproxy         - for managing ftp services for our webserver

intrusion detection and prevention - for implementing information security using suricata
icap server     - to complement clamav implementation
clamav           -  to serve as layer 3 antivirus
sensei            - to serve as web application protection

we also implemented port forwarding to make our webservers public
we have all black lists, intrusion detection rules and antivirus signatures updated on a regular basis.

before, we use our default setup of 4Gb physical ram coupled with 8Gb swap (the swap automatically identified by opnsense during installation). at this setup, opnsense will consume 90 to 98 percent physical ram then will transfer some of the load to the swap file especially when all of sensei, idps, and clamav featuresets are all enabled. what happens is that the 8gb swap will be easily consumed and opnsense will freeze, and its lan and wan interfaces will start to have an offload error.

what we did is to increase both the physical ram and the swap file. we now currently have 8 gb physical ram and 16gb swap are we do not experience opnsense freezing or other issues since.

as for the swap file increase, in particular sensei relies both on swap and physical memory. even if the phycial memory is sufficiently large, when swap file is at default, sensei will readily consume 8gb swap and it will halt.

with that in mind, we increased from 8gb to 16gb to also accommodate other plugins and opnsense features that uses swap.
               

Good day,

it seems a lot of performance issues involves opnsense performance can be directly linked to memory and swap file allocation

1. when considering a production grade opnsense build, it is preferred that physical memory must be 8Gb (or higher) coupled with a high bus rate to effectively accomodate many of opnsense features and plugins

2. when facing on budget constraints on implementing production grade builds, it is best to have 4Gb physical memory with high data bus speed

3. always remember that you have to increase the swap file capacity to at least four times the physical memory amount

the three above recommendations are considered because opnsense heavily relies on memory intensive processes.

hope this helps

thank you.

good day,

thanks for the clarification everyone.

will check into the unbound and dns crypt blacklists via ssh terminal

maybe the blacklist issue must be reported to unbound?

so that blacklist providers can remove the entry.

Good day,

Opnsense is used in our production webserver network to provide the following security implementations:
- DNS over HTTPS by both Unbound DNS for uncrypted traffic and DNS Crypt for encrypted traffic
- integrated C-ICAP and CLAMav implementation
- DNS server, recursion and caching thru Unbound DNS
- IDPS through suricata

the vulnerability is actually based on the error log i have submitted here in the forum which describes the nature of the over flow error leading to the malfunction by Unbound DNS.

the incident happened after upgrade to 20.7.5 

we confirm that the attack is coming from the outside since there are no other workstations connected to opnsense except the monitoring pc that i use and the production webservers, and the webserver infrastructure is isolated from the rest of the productivity network infra that we are currently using.

what we did is to revert the opnsense build to 20.1.9 and all services including Unbound DNS and DNS Crypt returned to expected operation.


 

Good Day,

Reporting Unbound DNS vulnerability consisting of the following:
- error parsing local data resulting in a Label Length Overflow
  - happens when Unbound DNS cannot resolve a non standard DNS FQDN
    - when the FQDN exceeds the limit of standard DNS naming 
- Label Length Overflow error resulting in a Bad local-data error
- resulting in Unbound DNS fatal error: Could not set up local zones
- Unbound DNS then stops working entirely, even configuration is reverted to factory default

the issue is further aggravated if Split DNS is implemented using Unbound DNS and DNS Crypt
- DNS Crypt also stops working together with Unbound DNS after the DDOS attack

the DDOS attack originated in the ster.co.uk site with the following non standard FQDN:
- ster.co.uk/2014/10/07/adobe_digital_editions_4_caught_snooping_into_ebook_collections_of_users/
- has an A record with a broadcast address of 0.0.0.0
- has multiple public ip as detected by the sensei plugin

vulnerabilities:
- Unbound DNS has observed failure to resolve long non standard FQDN
- there is a difficulty to directly edit the unbound.conf to block or mitigate the said issue
- Unbound DNS results to a DNS fatal error: Could not set up local zones that persists even the
  opnsense configuration is reverted to factory defaults

workaround:
- to momentarily use Unmasq DNS as the DNS resolver
  - has no capability to implement Split DNS with DNS Crypt

additional issues:
- Sensei plugin cant implement its web and application filtering properly when opnsense is upgraded to its
  latest version.

Can we find an immediate remidiation for this kind of DDOS attack?

Thank you

Good day,

Reporting solution on WSUS update servers problem when suricata IPDS is active

when activating suricata IDPS, suricata scans and applies policies to networks or groups of networks using the assigned interface.

when you set WAN as the listening interface, make sure that networks that you want to scan are the networks that are within your LAN.

this setting is found in Intrusion Detection > Administration > Settings > Home Networks

if you put your WAN network in Home Networks, Suricata will scan the network and detect unconventional network ranges in which, incidentally WSUS uses. Thus WSUS networks will be dropped and the windows update will not function.

the same goes for Linux update servers

Hope this helps. 

Good day,

I recently installed and upgraded OPNSENSE to its latest version to use the Unbound DNS and DNS Crypt in providing a DNS Server for my office websites.

When doing the EICAR Test it worked very perfectly, as Unbound DNS and DNS Crypt had done these jobs:

for Unbound DNS:
forwards all queries to dnscrypt-proxy while itself is listening on all interfaces on port 53 (IPv4 + IPv6) and handle the dns requests for the local network unencrypted. (compliments to p1n0ck10)

for DNS Crypt:
dnscrypt-proxy is only listen on the localhost addresses 127.0.0.1 (IPv4) and ::1 (IPv6) on port 5353 and handle the dns requests to the internet encrypted. (compliments to p1n0ck10)

This means that DNS Crypt handles and manages security for outgoing requests to the internet while Unbound DNS is the one responsible for DNS requests management inside LAN.

This is the reason that my office websites passed WICAR tests and even improved the rating from C to B+ in DNS performance thru the DNSStuff website.

It also works very well with the Suricata IDPS even when realtek NIC's are used, might upgrade it to intel NIC for better IDPS performance. 

However, when Mal trail is introduced in this setup, it seems to confuse the Black List rule sets of both DNS Crypt and Unbound DNS resulting to some WICAR tests not blocking as expected.   

Can anyone help what seems to be the problem in this setup?