Re: DoH Ruleset missing
Jonathan Lee via Snort-users <[email protected]> Tue, 25 Nov 2025 08:26:43 -0800
| Newsgroups | gmane.comp.security.ids.snort.general |
|---|---|
| Message-ID | <[email protected]> |
--===============2971885725053297852== Content-Type: multipart/alternative; boundary=Apple-Mail-65AFA377-EBD7-4088-9C20-8F57327A6737 Content-Transfer-Encoding: 7bit --Apple-Mail-65AFA377-EBD7-4088-9C20-8F57327A6737 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am wondering if IDS/IPS has a solution as of know. Or maybe I thought to b= ring some attention to this as 2018 is when DoH really started to take off.=20= Sent from my iPhone > On Nov 25, 2025, at 08:24, Jonathan Lee <[email protected]> wrote: >=20 > =EF=BB=BFYou=E2=80=99re right, but looking further into this I found DoH i= s actually ran over https and it=E2=80=99s starting to be known as an abusiv= e vector point. Leading to, most firewall rules not having a real ability to= really 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 b= eing abused. Wouldn=E2=80=99t you agree? I mean sure we can set the dns to w= hatever we want and some encrypted invasive container will do whatever it wa= nts masked inside of port 443.=20 > Sent from my iPhone >=20 >>> 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 fir= ewall 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@li= sts.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 standardize= d 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 Sno= rt news! >>>=20 >>> Please follow these rules: https://snort.org/faq/what-is-the-mailing-lis= t-etiquette --Apple-Mail-65AFA377-EBD7-4088-9C20-8F57327A6737 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">I am wondering if IDS/IPS has a solution as of know. Or maybe I thoug= ht to bring some attention to this as 2018 is when DoH really started to tak= e off. <br id=3D"lineBreakAtBeginningOfSignature"><div dir=3D"ltr">Sent= from my iPhone</div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Nov 2= 5, 2025, at 08:24, Jonathan Lee <[email protected]> wrote:<br><= br></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<m= eta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8">You=E2= =80=99re right, but looking further into this I found DoH is actually ran ov= er https and it=E2=80=99s starting to be known as an abusive vector point. L= eading to, most firewall rules not having a real ability to really mitigate i= t outside of a wake-a-mole response. Without some elevated IDS IPS rules to h= elp fix this it=E2=80=99s kind of never going to be stop being abused. Would= n=E2=80=99t you agree? I mean sure we can set the dns to whatever we want an= d some encrypted invasive container will do whatever it wants masked inside o= f 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><blockquote type=3D"c= ite"><div dir=3D"ltr">=EF=BB=BF<meta http-equiv=3D"content-type" content=3D"= text/html; charset=3Dutf-8"><span style=3D"-webkit-text-size-adjust: auto; b= ackground-color: rgb(58, 58, 60);">Not sure the IDS is the proper place to h= andle this. Network firewall rules and DNS servers are probably the best pla= ce to handle this. </span><br id=3D"lineBreakAtBeginningOfSignature"><= div dir=3D"ltr"><div><br></div>=E2=80=94 <div><span style=3D"background= -color: rgba(255, 255, 255, 0);">Sent from my =F0=9F=93=B1iPhone</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]> wrote:= <br><br></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB= =BF<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8">= Hello based on the following <div><br></div><div><p data-start=3D"115" d= ata-end=3D"247">=E2=80=9CNSA recommends that an enterprise network=E2=80=99s= DNS traffic, encrypted or not, be sent only to the designated enterprise DN= S resolver.=E2=80=9D</p><p data-start=3D"249" data-end=3D"831">Building on t= hat guidance, there should ideally be an RFC or standardized mechanism for l= ocking down browsers and operating systems so they can use only approved DoH= servers. With such controls in place, clients could be configured to direct= all DNS queries to a local resolver (such as pfSense Unbound), while the fi= rewall enforces that any DNS-over-HTTPS traffic is forwarded exclusively to a= n authorized upstream resolver. This would re-establish enterprise DNS secur= ity controls, especially given prior incidents where attackers have abused D= oH for command-and-control purposes.</p><p data-start=3D"249" data-end=3D"83= 1"><br></p><p data-start=3D"249" data-end=3D"831">Since this does not curren= tly exist when can the Snort user base expect DoH rules to help with securit= y concerns of users bypassing official enterprise DNS servers?</p></div><spa= n>_______________________________________________</span><br><span>Snort-user= s mailing list</span><br><span>[email protected]</span><br><span>G= o to this URL to change user options or unsubscribe:</span><br><span>https:/= /lists.snort.org/mailman/listinfo/snort-users</span><br><span></span><br><sp= an> To unsubscribe, send an email to:</span><br><span> &= nbsp;[email protected]</span><br><span></span><br><span>Plea= se visit http://blog.snort.org to stay current on all the latest Snort news!= </span><br><span></span><br><span>Please follow these rules: https://snort.o= rg/faq/what-is-the-mailing-list-etiquette</span><br></div></blockquote></div= ></blockquote></div></div></blockquote></body></html>= --Apple-Mail-65AFA377-EBD7-4088-9C20-8F57327A6737-- --===============2971885725053297852== 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 --===============2971885725053297852==--