Messages

1

Zenarmor (Sensei) / Re: My server always shows cloud intel down

« on: March 27, 2023, 09:53:49 pm »

Hi

I have found the issue. I normally check things from my phone as its just easier for me but I see now that checking from your phone produces different information for the zenarmor plugin, one of the bits of information being that all the servers are down. I happened to rarely be in the web interface from a pc and noticed everything was working that tipped me off. I believe I did not need to actually reinstall the entire package either and this was done based on the information being wrong displayed when using safari on an iphone.

P

2

Zenarmor (Sensei) / Re: My server always shows cloud intel down

« on: March 27, 2023, 05:36:53 pm »

Hi. No icmp works fine and this started being an issue a few updates ago. It always used to work fine. My entire network goes through my firewall and all traffic so I believe it’s something else.

3

Zenarmor (Sensei) / My server always shows cloud intel down

« on: March 25, 2023, 11:02:22 pm »

Unsure how to troubleshoot this. I just uninstalled and then reinstalled and changed to mongo db in the hope it would fix it but it still shows servers are down for cloud threat intel even in the setup as per below. How can I troubleshoot this? Unsure how to access logs. 


https://imgur.com/a/Lyu628m

4

General Discussion / Re: Python -- multiple vulnerabilities found on OPNsense to v22.7.9_3

« on: December 12, 2022, 02:32:15 pm »

You have to wait for an update to opnsense. When a problem is found there is a period of time that must pass between a solution being found to mitigate it and then that solution to then make it into the various applications that use it including opnsense so you are being informed of an issue in case its such a problem that you need to make another arrangement because you cannot wait (ie pay someone to code a fix for you immediately because its so critical no waiting is possible). Or like the rest of us you can wait if you are not in that situation.

5

Zenarmor (Sensei) / Re: Blocking quic in policies also blocks whatsapp messenger voip calls

« on: December 04, 2022, 01:46:21 pm »

So far adding the following IP's to zenarmor whitelist/exclusions seems to have fixed whatsapp:

1    102.132.100.62       
2    102.132.99.62       
3   Invalid, something else for different purpose.
4    157.240.19.52       
5    157.240.229.62       
6    157.240.240.62       
7    157.240.249.62       
8    157.240.254.12       
9    157.240.254.35       
10    157.240.254.62       
11    157.240.254.7       
12    31.13.66.53       
13    31.13.71.48       
14    31.13.80.12       
15    31.13.80.36       
16    31.13.80.8       
17    31.13.88.62

6

Zenarmor (Sensei) / Re: Blocking quic in policies also blocks whatsapp messenger voip calls

« on: November 28, 2022, 10:05:53 pm »

Yes I agree that opening up udp443 is 100% going to make you vulnerable to dns over the same UDP port if the same destination IP has both services available on that endpoint. This is always the struggle and compromise, but in some cases it is required that the functionality can take prescience over the possible risk of allowing the traffic. This is the situation I am in since whatsapp traffic must flow, even if it means allowing quic traffic (risk is accepted due to compatibility taking precedence).

As it happens I am when a user makes a whatsapp call, if it has an issue I am now checking the logs at the exact time, finding the IP's and adding then to the whitelist for zenarmor. This is similar to what you would do your side but has the disadvantage of nobody else in the world being able to benefit from my capturing of IP's and sharing that information.  So while eventually after a few months the situation will get resolved or me, nobody else is assisted by this method.

P

7

Zenarmor (Sensei) / Re: Blocking quic in policies also blocks whatsapp messenger voip calls

« on: November 27, 2022, 07:58:58 pm »

Yes I was hoping zenarmor had a list of ips that needed whitlisting because otherwise how can I predict what they are?

8

Zenarmor (Sensei) / Blocking quic in policies also blocks whatsapp messenger voip calls

« on: November 26, 2022, 03:24:34 pm »

While blocking quic (under the media streaming policy) does precent dns over quic from working, it also blocks whatsapp audio calls as they use udp 443 also for their calls. How can I allow whatsapp calls while still blocking quic In general? Unfortunately the current rule is too blunt and instrument so I have had to turn it off as whatsapp audio calls are used on the network. This exposes allowing all quic traffic however.

Kind regards
P

9

General Discussion / Re: How to block every DNS Request on any Protocol and Port

« on: August 28, 2022, 04:55:38 am »

I do this more simply thusly:

1) Outbound NAT rules to redirect port 53 TCP/UDP to Pihole (Log to locate devices trying to bypass your DNS and remove them from your network).
2) Outbound NAT rules to redirect port 853 TCP/UDP to Pihole(Log to locate devices trying to bypass your DNS and remove them from your network).
3) Zenarmor tick rule to block DNS over TLS (Zenarmor has a logging interface automatically)
4) Zenarmor tick rule to block DNS over HTTPS
5) LAN rule to block 8853 UDP out (Dont bother logging any chrome browser will trigger log).
6) LAN rule to block 443 UDP out (Dont bother logging any chrome browser will trigger log).
7) LAN AllowList Alias to allow out CND networks if required
8 ) LAN BlockList Alias to block outbound IP's on lists (LOG THIS RULE SO YOU CAN SEE WHEN IP's BLOCKED):
    https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/master/doh-ipv4.txt
    https://raw.githubusercontent.com/pallebone/TheGreatWall/master/TheGreatWall_ipv4
    https://raw.githubusercontent.com/oneoffdallas/dohservers/master/iplist.txt
    https://raw.githubusercontent.com/jpgpi250/piholemanual/master/DOHipv4.txt
    https://raw.githubusercontent.com/cbuijs/accomplist/master/doh/plain.black.ip4cidr.list
    List of manual IP's I have found:
    Manual added DOH IP's: 1.1.1.1,1.0.0.1,1.1.1.2,1.0.0.2,1.1.1.3,1.0.0.3,104.17.64.4,104.17.65.4,203.107.1.4,193.161.193.99
    Manual added DOH ranges: 101.36.166.0/24,203.107.1.0/24

Note : AllowList I have had to open so far contains this port/ip combinations:

Allow out port 443: 151.101.66.133, 151.101.2.133, 151.101.130.133, 172.67.75.103, 104.26.2.13, 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153, 104.26.3.13, 151.101.194.133, 216.239.34.21, 44.235.246.155, 151.101.65.195, 104.26.4.174, 172.67.70.80, 104.21.39.13, 172.67.170.203, 151.139.128.10, 104.26.5.174, 151.101.1.195, 141.193.213.21, 172.67.212.2, 104.21.85.239, 44.236.72.93, 104.16.132.229, 141.193.213.20, 217.64.148.8, 104.21.68.104, 96.126.123.244, 45.33.20.235, 44.236.48.31, 216.239.36.21, 216.239.38.21, 104.19.155.92, 104.21.15.239, 167.172.139.120, 216.239.32.21, 90.155.62.13, 90.155.62.14, 95.216.25.250, 162.159.138.85, 162.159.137.85 172.224.62.11 172.224.63.11 172.224.63.19 23.227.38.65

Allow out port 123: 69.1.1.251, 129.250.35.250, 129.250.35.251, 162.248.241.94, 194.36.144.87, 95.216.24.230, 45.76.113.31, 94.16.114.254

Allow out port 80: 151.101.66.133, 151.101.194.133, 151.101.2.133, 151.101.130.133, 141.193.213.20, 172.67.70.80, 104.26.4.174, 184.168.131.241, 17.253.85.204, 162.159.138.85, 162.159.137.85

With this combination I have not been able to find a way to bypass the block unless an IP is added to the allowlist (required if you want to access a site that is a CDN).

I occasionally update this page with new IP's or lists I find (the DOH stuff is near the end):
https://github.com/pallebone/PersonalPiholeListsPAllebone

10

22.7 Legacy Series / Re: lack of support for opnsense hardware

« on: August 15, 2022, 05:12:56 pm »

I recently purchased an opnsense appliance for a client.  It appears 1500 dollars was not spent wisely.  it appears 22.7 is not supported on official hardware as their fix for any problem is to reinstall 22.1.  Right now the only email contact i can get to is sales....is there an actual support mailbox at the parent company?

You should be running the business version in a business setting, or doing extensive testing prior to deploying updates yourself. You are given choices to ensure safe upgrade (latest business version is based on 22.1.7 as of this message) or you are given the choice to do this yourself for free (cost is your time). You must choose what is appropriate for your use case. That is fair, considering they are giving you the choice to use the software for free or pay and have them test it on your behalf. We have to be reasonable here. I personally find this arrangement extremely reasonable and cost effective.

11

Development and Code Review / Re: Redundant domain override pages in Unbound?

« on: August 12, 2022, 04:36:57 pm »

Thanks Franco, you are as always, a gentleman, a legend and a force against all chaos in this world.

12

Development and Code Review / Re: Redundant domain override pages in Unbound?

« on: August 11, 2022, 07:32:17 pm »

I guess you are right, then I dont know. I did notice you can also specify a port on the domain overrides by using <ip>@<port> so you can change the port there also.

13

Development and Code Review / Re: Redundant domain override pages in Unbound?

« on: August 11, 2022, 02:54:20 pm »

They do 2 different things. Domain overrides tells unbound to locally resolve the domain to whatever you set there. Query forwarding forwards the query to an upstream dns server or internal dns server that can be administered and have record values change by someone else or you without intervention on the unbound side. There could be many reasons for this eg: someone runs an AD install and needs unbound to be able to resolve dynamically created records that appear via DHCP registration internally etc or any number of reasons like that.

14

22.7 Legacy Series / Re: Bug? Alias updates no longer logged to system log (or anywhere?)

« on: August 03, 2022, 08:53:33 pm »

Thanks this was correct and I could find the entries.

15

22.7 Legacy Series / Bug? Alias updates no longer logged to system log (or anywhere?)

« on: August 02, 2022, 04:11:52 am »

Before updating to 22.7 aliases that were of type "URL Table (IPs): with a refresh interval, when updating on the refresh interval would write to the system log "fetched alias <name> from <url>" or something to that effect I dont remember the exact wording. I used this during my daily audits but now it appears this no longer occurs. Where is this information being logged/how can I turn logging back on for the aliases that update. Was this change intentional or a bug? I would like to view the log/when aliases update in some log somewhere, dont mind where but should be exposed in my opinion.

Kind regards
Peter