ET INFO Outbound RRSIG DNS Query Observed
-
On a new install I'm seeing
ET INFO Outbound RRSIG DNS Query ObservedI have DNS forwarded to QuadDNS at the moment so it makes sense that this rule is being flagged. What I don't get is what I'm being alerted to. I could turn off the rule, sure, but what is the purpose of identifying that a DNS request went out and requested a DNSSEC record? I'm guessing that's all this rule is checking. Or am I missing something?
Edit: Any why would it be classified as Potentially Bad Traffic? What would be bad about it? It seems like using DNSSEC and RRSIG just a more secure way to doing DNS.
-
The ET Info rules are just that-- "information". They are designed to alert an admin that a particular action is happening. That action may be fine, may be bad, or may be a little of both. It is up to the security admin to make the determination.
What was the source IP address of the alerting rule? Was it your local DNS server (or maybe
unboundon the firewall itself)? Or was it some other host on your network? One use for rules like this one is to identify when rogue, or otherwise unauthorized hosts on the network are doing DNS themselves and bypassing your network-configured DNS.You need to review carefully the rules that you enable so that you can determine if you really need or want them in service. Running an IDS/IPS properly is a ton of work. You spend a lot of time checking each rule to determine if you really want that one enabled or not. This is especially true of these "Information" rules.
-
@bmeeks I'm going through the rules now. It's currently alerting and not blocking and I figure I'll have it all set up by the end of the week. The IP triggering is inside of the network and not unbound itself going to 198.203.28.134. Looks like one of the laptops reaching out, but I don't know why yet. This is a newer client for us and this particular site was only using the cable modem as the router with a Fast Ethernet switch. Ouch! We're modernizing the network as we go. While I don't know what some of the rules do, I've set up enough of these to have a fairly standard deployment of Suricata. I just saw this rule and it got me curious as to what could be potentially bad about it? Unless it's just a matter of users not being allowed to circumvent assigned DNS servers I don't see what the inherent risk is.
-
@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
@bmeeks I'm going through the rules now. It's currently alerting and not blocking and I figure I'll have it all set up by the end of the week. The IP triggering is inside of the network and not unbound itself going to 198.203.28.134. Looks like one of the laptops reaching out, but I don't know why yet. This is a newer client for us and this particular site was only using the cable modem as the router with a Fast Ethernet switch. Ouch! We're modernizing the network as we go. While I don't know what some of the rules do, I've set up enough of these to have a fairly standard deployment of Suricata. I just saw this rule and it got me curious as to what could be potentially bad about it? Unless it's just a matter of users not being allowed to circumvent assigned DNS servers I don't see what the inherent risk is.
The ET Info category of rules does not necessarily mean "bad" or "questionable". It is simply designed to detect certain things and let the security admin know about them through alerts. Don't mix the ET INFO rules up with rules that do denote "bad" things like the ET MALWARE or CNC BOT rules, etc. The INFO rules just let you know what kind of traffic is zipping around. Up to you to decide if that traffic is okay, or bad.
So in this case, it alerted you that a client on the network (that is not the official DNS server) is doing its own resolving and bypassing the configured DNS server. However, this might be expected if you have configured DHCP on the network to hand out say both pfSense and Quad 9 as valid DNS servers. You can never control which DNS server a client will use. Lots of people think when you give a client two or more choices, it will always try them in order, and the first to respond wins. That is not necessarily true. In most controlled networks, it's best to have DHCP give clients only the local firewall (and thus
unbound) or a designated local DNS server for all lookups. -
@bmeeks said in ET INFO Outbound RRSIG DNS Query Observed:
@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
@bmeeks I'm going through the rules now. It's currently alerting and not blocking and I figure I'll have it all set up by the end of the week. The IP triggering is inside of the network and not unbound itself going to 198.203.28.134. Looks like one of the laptops reaching out, but I don't know why yet. This is a newer client for us and this particular site was only using the cable modem as the router with a Fast Ethernet switch. Ouch! We're modernizing the network as we go. While I don't know what some of the rules do, I've set up enough of these to have a fairly standard deployment of Suricata. I just saw this rule and it got me curious as to what could be potentially bad about it? Unless it's just a matter of users not being allowed to circumvent assigned DNS servers I don't see what the inherent risk is.
The ET Info category of rules does not necessarily mean "bad" or "questionable". It is simply designed to detect certain things and let the security admin know about them through alerts. Don't mix the ET INFO rules up with rules that do denote "bad" things like the ET MALWARE or CNC BOT rules, etc. The INFO rules just let you know what kind of traffic is zipping around. Up to you to decide if that traffic is okay, or bad.
So in this case, it alerted you that a client on the network (that is not the official DNS server) is doing its own resolving and bypassing the configured DNS server. However, this might be expected if you have configured DHCP on the network to hand out say both pfSense and Quad 9 as valid DNS servers. You can never control which DNS server a client will use. Lots of people think when you give a client two or more choices, it will always try them in order, and the first to respond wins. That is not necessarily true. In most controlled networks, it's best to have DHCP give clients only the local firewall (and thus
unbound) or a designated local DNS server for all lookups.It makes sense that someone out there wants to track it. I just didn't see how it could be a bad thing unless it's to circumvent. Thanks for the replies!
-
@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
ET INFO Outbound RRSIG DNS Query Observed
I wouldn't call it 'bad' but this notification is at least 'questionable'.
The issue - for me - is clear and sound :@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
I have DNS forwarded to QuadDNS
and
@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
a DNS request went out and requested a DNSSEC record?
DNS Forwarding
and
DNSSEC
usage is mutual exclusive from a security point of view.If you 'forward' your DNS, you have to trust fully the DNS upfront server you forward to, as it can do anything with the records it send, as the local forwarder isn't doing full DNSSEC.
If it was, you were forwarding a DNS request first, and then you do the same request again, fully resolved it, to get all the DNSSEC records from top to bottom, to get a valid DNSSEC result.
Only a resolver (the default unbound mode, as it was when you installed pfSense) can DNSSEC that means something.Which brings me to my favourite conclusion :
a) forwarding is something of the past (last century).
b) maybe useful if you have really bad - or with big latyency - uplink (I do accept exceptions - but not the 'hand me over your private DNS requests for free'. At least, get paid for it.
c) It's resolving now, and then you have DNSSEC as a bonus.When yo install pfSEnse, it has the perfect DNS settings. And that is resolving, certainly not forwarding (which was kept for historical reasons - remember the good old dnsmasq days).
If not, the pfSense guys were mistaken ?? They signed a 'secret' contact with 1.1.1.1 9.9.9.9 8.8.8.8
??edit :
The "IDS/IPS" merits a big
here.
Maybe it always does, but this one is from me.
Using software is one thing.
Understands (at least : interpreting) what it 'says' is another ^^ -
@gertjan said in ET INFO Outbound RRSIG DNS Query Observed:
@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
ET INFO Outbound RRSIG DNS Query Observed
I wouldn't call it 'bad' but this notification is at least 'questionable'.
The issue - for me - is clear and sound :@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
I have DNS forwarded to QuadDNS
and
@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
a DNS request went out and requested a DNSSEC record?
DNS Forwarding
and
DNSSEC
usage is mutual exclusive from a security point of view.If you 'forward' your DNS, you have to trust fully the DNS upfront server you forward to, as it can do anything with the records it send, as the local forwarder isn't doing full DNSSEC.
If it was, you were forwarding a DNS request first, and then you do the same request again, fully resolved it, to get all the DNSSEC records from top to bottom, to get a valid DNSSEC result.
Only a resolver (the default unbound mode, as it was when you installed pfSense) can DNSSEC that means something.Which brings me to my favourite conclusion :
a) forwarding is something of the past (last century).
b) maybe useful if you have really bad - or with big latyency - uplink (I do accept exceptions - but not the 'hand me over your private DNS requests for free'. At least, get paid for it.
c) It's resolving now, and then you have DNSSEC as a bonus.When yo install pfSEnse, it has the perfect DNS settings. And that is resolving, certainly not forwarding (which was kept for historical reasons - remember the good old dnsmasq days).
If not, the pfSense guys were mistaken ?? They signed a 'secret' contact with 1.1.1.1 9.9.9.9 8.8.8.8 ??I'd love to do resolving, I really would. In most locations I do but I've learned the hard way that I can't just install it like that. I always have to start with forwarding enabled since so many of the Arris modems that Spectrum uses have PUMA chipsets and fall apart when DNS queries get sent out. (Don't know about the newer Spectrum branded units they are using now.) Of all the installs over the last couple of years I've found that roughly 10% will have problems. Once I have everything stable and configured then I switch from forwarding to resolving and monitor for a couple of weeks to see if the installed modem buckles under the weight of simple DNS traffic. I also monitor any time a modem gets swapped. Was it resolving before and can it stay that way? Was it forwarding before and can I switch it back? Does the new one suffer from the PUMA failures and now I need to drop it back to forwarding? You don't know until you try.
You can't just say that it's perfect the way it ships because it isn't. Not that the pfSense team is doing anything wrong. I prefer to do it that way myself. It's just that it simply isn't compatible with a lot of equipment out there and I can't go installing equipment and having the network fall apart right away. It certainly takes more time doing it this way but at least I can make sure everything works as it gets set up.
-
@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
Spectrum uses have PUMA chipsets and fall apart
Oh .... that name does ring a bell. Isn't that chipset/modem part of the top ten on badmodens.org (or something like that).
@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
You can't just say
Well .....
Right, I admit : I say so, because it, pfSense, ships in a configuration that works out of the box. They choose this build-in setup because it's probably valid for most of us.
And that's valid for me.
( so extra true ^^)
Don't worry, I live in France, so I know that there as as many exceptions as habitants.Still .... using a modem that goes haywire because you throw some off the mill, plain vanilla DNS requests through it makes me wonder :
You pay your ISP - or your ISP pays you ? ;)
Do you have to use this type of modem ? (I've read somewhere, sometimes that you probably do not have any choice).IMHO : a more basic router/firewall a pfSense doesn't exist **. I guess it's even setting that reference right now.
What I should have said above :
On the Resolver settings page : un check the DNSSEC option, as it it worthless anyway.
The "ET INFO Outbound RRSIG DNS Query Observed" log line will go away.@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
modem buckles under the weight of simple DNS traffic
This intrigues me.
Dono what the ratio of "DNS traffic"/"All traffic is".
1 or 2 %, maybe ? I should investigate.** with probably far to many bells and whistles.
-
@gertjan said in ET INFO Outbound RRSIG DNS Query Observed:
@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
Spectrum uses have PUMA chipsets and fall apart
Oh .... that name does ring a bell. Isn't that chipset/modem part of the top ten on badmodens.org (or something like that).
Why yes. Yes it is. I believe PUMA chipsets is the sole reason that site exists.
@gertjan said in ET INFO Outbound RRSIG DNS Query Observed:
@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
You can't just say
Well .....
Right, I admit : I say so, because it, pfSense, ships in a configuration that works out of the box. They choose this build-in setup because it's probably valid for most of us.
And that's valid for me.
( so extra true ^^)I realize that there may be a bit of a language barrier if you're primary language is French. I realize if read a certain way it could be an argumentative statement. It wasn't meant to be so, so please don't take offense.
Don't worry, I live in France, so I know that there as as many exceptions as habitants.
Still .... using a modem that goes haywire because you throw some off the mill, plain vanilla DNS requests through it makes me wonder :
You pay your ISP - or your ISP pays you ? ;)
Do you have to use this type of modem ? (I've read somewhere, sometimes that you probably do not have any choice).Residential customers can use an approved modem. Commercial customers must use the ones provided by the ISP.
IMHO : a more basic router/firewall a pfSense doesn't exist **. I guess it's even setting that reference right now.
What I should have said above :
On the Resolver settings page : un check the DNSSEC option, as it it worthless anyway.
The "ET INFO Outbound RRSIG DNS Query Observed" log line will go away.@stewart said in ET INFO Outbound RRSIG DNS Query Observed:
modem buckles under the weight of simple DNS traffic
This intrigues me.
Dono what the ratio of "DNS traffic"/"All traffic is".
1 or 2 %, maybe ? I should investigate.It's not the overall amount of bandwidth that's used. It's that DNS throws out a bunch of UDP packets in quick succession when doing the resolving and the modems become unresponsive during that time.
** with probably far to many bells and whistles.
