Re: DoH Ruleset missing
Jonathan Lee via Snort-users <[email protected]> Tue, 25 Nov 2025 08:23:52 -0800
| Newsgroups | gmane.comp.security.ids.snort.general |
|---|---|
| Message-ID | <[email protected]> |
--===============8940882141509758807== Content-Type: multipart/alternative; boundary=Apple-Mail-6F31ACC9-E37C-4A74-A6BF-C1C36F4D251E Content-Transfer-Encoding: 7bit --Apple-Mail-6F31ACC9-E37C-4A74-A6BF-C1C36F4D251E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You=E2=80=99re right, but looking further into this I found DoH is actually r= an over https and it=E2=80=99s starting to be known as an abusive vector poi= nt. Leading to, most firewall rules not having a real ability to really miti= gate it outside of a wake-a-mole response. Without some elevated IDS IPS rul= es to help fix this it=E2=80=99s kind of never going to be stop being abused= . Wouldn=E2=80=99t you agree? I mean sure we can set the dns to whatever we w= ant and some encrypted invasive container will do whatever it wants masked i= nside of port 443.=20 Sent from my iPhone > On Nov 25, 2025, at 07:15, Joel Esler <[email protected]> wrote: >=20 > =EF=BB=BFNot sure the IDS is the proper place to handle this. Network fire= wall rules and DNS servers are probably the best place to handle this. =20 >=20 > =E2=80=94=20 > Sent from my =F0=9F=93=B1iPhone >=20 >>> On Nov 24, 2025, at 21:03, Jonathan Lee via Snort-users <snort-users@lis= ts.snort.org> wrote: >>>=20 >> =EF=BB=BFHello based on the following=20 >>=20 >> =E2=80=9CNSA recommends that an enterprise network=E2=80=99s DNS traffic,= encrypted or not, be sent only to the designated enterprise DNS resolver.=E2= =80=9D >>=20 >> Building on that guidance, there should ideally be an RFC or standardized= mechanism for locking down browsers and operating systems so they can use o= nly approved DoH servers. With such controls in place, clients could be conf= igured to direct all DNS queries to a local resolver (such as pfSense Unboun= d), while the firewall enforces that any DNS-over-HTTPS traffic is forwarded= exclusively to an authorized upstream resolver. This would re-establish ent= erprise DNS security controls, especially given prior incidents where attack= ers have abused DoH for command-and-control purposes. >>=20 >>=20 >>=20 >> Since this does not currently exist when can the Snort user base expect D= oH rules to help with security concerns of users bypassing official enterpri= se DNS servers? >>=20 >> _______________________________________________ >> Snort-users mailing list >> [email protected] >> Go to this URL to change user options or unsubscribe: >> https://lists.snort.org/mailman/listinfo/snort-users >>=20 >> To unsubscribe, send an email to: >> [email protected] >>=20 >> Please visit http://blog.snort.org to stay current on all the latest Snor= t news! >>=20 >> Please follow these rules: https://snort.org/faq/what-is-the-mailing-list= -etiquette --Apple-Mail-6F31ACC9-E37C-4A74-A6BF-C1C36F4D251E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html class=3D"apple-mail-supports-explicit-dark-mode"><head><meta http-equi= v=3D"content-type" content=3D"text/html; charset=3Dutf-8"></head><body dir=3D= "auto">You=E2=80=99re right, but looking further into this I found DoH is ac= tually ran over https and it=E2=80=99s starting to be known as an abusive ve= ctor point. Leading to, most firewall rules not having a real ability to rea= lly mitigate it outside of a wake-a-mole response. Without some elevated IDS= IPS rules to help fix this it=E2=80=99s kind of never going to be stop bein= g abused. Wouldn=E2=80=99t you agree? I mean sure we can set the dns to what= ever we want and some encrypted invasive container will do whatever it wants= masked inside of port 443. <div><div dir=3D"ltr">Sent from my iPhone</= div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Nov 25, 2025, at 07:15= , Joel Esler <[email protected]> wrote:<br><br></blockquote></div><bloc= kquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<meta http-equiv=3D"content-t= ype" content=3D"text/html; charset=3Dutf-8"><span style=3D"-webkit-text-size= -adjust: auto; background-color: rgb(58, 58, 60);">Not sure the IDS is the p= roper place to handle this. Network firewall rules and DNS servers are proba= bly the best place to handle this. </span><br id=3D"lineBreakAtBeginni= ngOfSignature"><div dir=3D"ltr"><div><br></div>=E2=80=94 <div><span sty= le=3D"background-color: rgba(255, 255, 255, 0);">Sent from my =F0=9F=93=B1iP= hone</span></div></div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Nov= 24, 2025, at 21:03, Jonathan Lee via Snort-users <[email protected]= t.org> wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div di= r=3D"ltr">=EF=BB=BF<meta http-equiv=3D"content-type" content=3D"text/html; c= harset=3Dutf-8">Hello based on the following <div><br></div><div><p dat= a-start=3D"115" data-end=3D"247">=E2=80=9CNSA recommends that an enterprise n= etwork=E2=80=99s DNS traffic, encrypted or not, be sent only to the designat= ed enterprise DNS resolver.=E2=80=9D</p><p data-start=3D"249" data-end=3D"83= 1">Building on that guidance, there should ideally be an RFC or standardized= mechanism for locking down browsers and operating systems so they can use o= nly approved DoH servers. With such controls in place, clients could be conf= igured to direct all DNS queries to a local resolver (such as pfSense Unboun= d), while the firewall enforces that any DNS-over-HTTPS traffic is forwarded= exclusively to an authorized upstream resolver. This would re-establish ent= erprise DNS security controls, especially given prior incidents where attack= ers have abused DoH for command-and-control purposes.</p><p data-start=3D"24= 9" data-end=3D"831"><br></p><p data-start=3D"249" data-end=3D"831">Since thi= s does not currently exist when can the Snort user base expect DoH rules to h= elp with security concerns of users bypassing official enterprise DNS server= s?</p></div><span>_______________________________________________</span><br>= <span>Snort-users mailing list</span><br><span>[email protected]</= span><br><span>Go to this URL to change user options or unsubscribe:</span><= br><span>https://lists.snort.org/mailman/listinfo/snort-users</span><br><spa= n></span><br><span> To unsubscribe, send an email to:</span><br= ><span> [email protected]</span><br><span></spa= n><br><span>Please visit http://blog.snort.org to stay current on all the la= test Snort news!</span><br><span></span><br><span>Please follow these rules:= https://snort.org/faq/what-is-the-mailing-list-etiquette</span><br></div></= blockquote></div></blockquote></div></body></html>= --Apple-Mail-6F31ACC9-E37C-4A74-A6BF-C1C36F4D251E-- --===============8940882141509758807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Snort-users mailing list [email protected] Go to this URL to change user options or unsubscribe: https://lists.snort.org/mailman/listinfo/snort-users To unsubscribe, send an email to: [email protected] Please visit http://blog.snort.org to stay current on all the latest Snort news! Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette --===============8940882141509758807==--