Page 1 of 2 12 LastLast
Results 1 to 10 of 14
  1. #1
    Untanglit
    Join Date
    Aug 2018
    Posts
    16

    Default Threat Protection blocking a quad9.net DNS IP

    I notice in my "Reports:Threat Prevention / Non-Web Blocked Events" that the Threat Protection App is blocking outward traffic to the DNS server 149.112.112.9, stating that the server reputation is high risk.

    149.112.112.9 is a quad9.net DNS IP as listed at https://quad9.net/doh-quad9-dns-servers/

    I would appreciate any comments on this, please.

  2. #2
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,012

    Default

    These kinds of things can come and go.

    You can immediately put in a pass rule if it hinders operations.

    You can pass a report on to Webroot BrightCloud using this tool.
    https://www.brightcloud.com/tools/url-ip-lookup.php

    It appears to be trustworthy / benign at this hour.
    f1assistance likes this.
    If you think I got Grumpy

  3. #3
    Untangle Ninja f1assistance's Avatar
    Join Date
    Apr 2009
    Location
    Holly Springs, NC
    Posts
    1,399

    Default

    Quote Originally Posted by woodsky View Post
    I notice in my "Reports:Threat Prevention / Non-Web Blocked Events" that the Threat Protection App is blocking outward traffic to the DNS server 149.112.112.9, stating that the server reputation is high risk.

    149.112.112.9 is a quad9.net DNS IP as listed at https://quad9.net/doh-quad9-dns-servers/

    I would appreciate any comments on this, please.
    Curious, are these servers configured in your endpoint(s) and not the WAN on UT?
    If endpoint(s), is this due to them being promiscuous devices, and reason you don't use their 'recommended' servers?
    Vanguard Untangle...because nothing's worse than doing nothing!
    -------
    2, Pentium (R) Dual-Core CPU E5300 @ 2.60GHz 2599.968, 2089.96MB RAM
    And building #7 didn't kill itself!

  4. #4
    Untangle Ninja Sam Graf's Avatar
    Join Date
    Feb 2016
    Location
    Michigan
    Posts
    1,011

    Default

    Quote Originally Posted by woodsky View Post
    I notice in my "Reports:Threat Prevention / Non-Web Blocked Events" that the Threat Protection App is blocking outward traffic to the DNS server 149.112.112.9, stating that the server reputation is high risk.

    149.112.112.9 is a quad9.net DNS IP as listed at https://quad9.net/doh-quad9-dns-servers/

    I would appreciate any comments on this, please.
    I would "credit" Threat Prevention with a false positive here, probably temporary. My brief experience with the TP app (I had to shut it down) is that even at a moderate setting it blocks such things as NTP pool servers. More understandable but not automatically tolerable are Web hosts’ shared servers, where a given server’s reputation might not be sterling. But blocking mail isn’t friendly.

    All that to say, I would suggest you view TP as aggressive, perhaps operating on an assumed guilty until proven innocent algorithm. In any case, it’s too aggressive for me. I suggest you monitor the non-web blocks carefully.
    f1assistance likes this.

  5. #5
    Untanglit
    Join Date
    Aug 2018
    Posts
    16

    Default

    Quote Originally Posted by Jim.Alles View Post
    These kinds of things can come and go.

    You can immediately put in a pass rule if it hinders operations.

    You can pass a report on to Webroot BrightCloud using this tool.
    https://www.brightcloud.com/tools/url-ip-lookup.php

    It appears to be trustworthy / benign at this hour.
    Thanks Jim. When I try it with a pass rule that resolves it. I've also advised Quad9.net about the issue, along with a link to https://www.brightcloud.com/tools/url-ip-lookup.php so Quad9.net can follow up there if they wish.
    Last edited by woodsky; 05-20-2020 at 01:23 AM.

  6. #6
    Untanglit
    Join Date
    Aug 2018
    Posts
    16

    Default

    Quote Originally Posted by f1assistance View Post
    Curious, are these servers configured in your endpoint(s) and not the WAN on UT?
    If endpoint(s), is this due to them being promiscuous devices, and reason you don't use their 'recommended' servers?
    Good question f1assistance. The DNS server is configured on dnscrypt-proxy (https://github.com/DNSCrypt/dnscrypt-proxy/) which I'm evaluating with pi-hole.
    Last edited by woodsky; 05-20-2020 at 01:26 AM.
    f1assistance likes this.

  7. #7
    Untanglit
    Join Date
    Aug 2018
    Posts
    16

    Default

    Quote Originally Posted by Sam Graf View Post
    All that to say, I would suggest you view TP as aggressive, perhaps operating on an assumed guilty until proven innocent algorithm. In any case, itís too aggressive for me. I suggest you monitor the non-web blocks carefully.
    Thanks Sam. That makes good sense.

  8. #8
    Untangle Ninja f1assistance's Avatar
    Join Date
    Apr 2009
    Location
    Holly Springs, NC
    Posts
    1,399

    Default

    Quote Originally Posted by woodsky View Post
    Good question f1assistance. The DNS server is configured on dnscrypt-proxy (https://github.com/DNSCrypt/dnscrypt-proxy/) which I'm evaluating with pi-hole.
    Not sure you answered my question...
    Anyway, I clearly missed it, when was the industry shown what's at issue in the problem of DNS was the transport from origination to termination beyond the endpoint(s) (i.e., bandwidth consumers)?
    I've always understood the problem as a lack of risk security downstream of the ISP's (i.e., origination and/or termination ends) which gets infiltrated (i.e., maliciously compromised) which contaminates the advancement, and that if the proper controls were in place no issue(s) exist. No?
    With that said, other than resolving a latency issue, I believe DNS is the least of problems and complicating one such portion does not a secure and dependable communication make. Yes?
    Last edited by f1assistance; 05-20-2020 at 10:20 AM.
    Vanguard Untangle...because nothing's worse than doing nothing!
    -------
    2, Pentium (R) Dual-Core CPU E5300 @ 2.60GHz 2599.968, 2089.96MB RAM
    And building #7 didn't kill itself!

  9. #9
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,012

    Default

    Quote Originally Posted by f1assistance View Post
    Not sure you answered my question...
    Anyway, I clearly missed it, when was the industry shown what's at issue in the problem of DNS was the transport from origination to termination beyond the endpoint(s) (i.e., bandwidth consumers)?
    I've always understood the problem as a lack of risk security downstream of the ISP's (i.e., origination and/or termination ends) which gets infiltrated (i.e., maliciously compromised)
    I think cache poisoning can occur anywhere
    https://en.wikipedia.org/wiki/Dan_Kaminsky

    DNSSEC mitigates it
    https://leeneubecker.com/dnssec-what...t-your-domain/

    And can be configured on NGFW for ISPs that support it.
    https://forums.untangle.com/off-topi...w-opendns.html
    Last edited by Jim.Alles; 05-20-2020 at 08:53 AM.

  10. #10
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,012

    Default DNS spoofing & dnsmasq

    Code:
    -Q, --query-port=<query_port>
    Send outbound DNS queries from, and listen for their replies on, the specific UDP port <query_port> instead of using random ports. NOTE that using this option will make dnsmasq less secure against DNS spoofing attacks but it may be faster and use less resources. Setting this option to zero makes dnsmasq use a single port allocated to it by the OS: this was the default behaviour in versions prior to 2.43.
    From the 2.43 changelog: http://www.thekelleys.org.uk/dnsmasq/CHANGELOG
    Implement random source ports for interactions with
    upstream nameservers. New spoofing attacks have been found
    against nameservers which do not do this, though it is not
    clear if dnsmasq is vulnerable, since to doesn't implement
    recursion.
    By default dnsmasq will now use a different
    source port (and socket) for each query it sends
    upstream. This behaviour can suppressed using the
    --query-port option, and the old default behaviour
    restored using --query-port=0. Explicit source-port
    specifications in --server configs are still honoured.
    If you think I got Grumpy

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2