The 1srt rule was the only one not enabled. Can I enable it when I use non local, but a DNS server on the LAN (google compute engine)?mikeshinn wrote:Yes. If you have these rulesets enabled:
https://www.atomicorp.com/wiki/index.ph ... _00_THREAT
https://www.atomicorp.com/wiki/index.ph ... SEC_03_DOS
https://www.atomicorp.com/wiki/index.ph ... C_12_BRUTE
Note: If you use litespeed it doesnt support outbound inspection, so unfortunately what we can do with litespeeds against this very limited. Eventually it will get caught, but the process is much slower.
Code: Select all
; generated by /sbin/dhclient-script
search c.lamp-kvm1.internal. 5145307xxxxxx.google.internal. google.internal.
nameserver 169.254.169.254
nameserver 10.240.0.1Thanks for the clarification. but can I enable it when I use non local, but a DNS server on the LAN (google compute engine)?mikeshinn wrote:Well for this specific attack, and only this one, you could get away with not turning it on. But in general brute force attacks are stopped better if you can enable all of these. The TI rules are stopping 75% of the attacks we see, so we highly recommend enabling them.
You'll have to test their DNS servers yourself to see if they are fast enough for your needs. We recommend you run a local DNS resolver, they are always faster than a network DNS.Thanks for the clarification. but can I enable it when I use non local, but a DNS server on the LAN (google compute engine)?
I also have a preference for local DNS resolvers, but what you are stating is not necessarily true. Sure, the network latency will always be lower, but if the nearby resolver already has the record in it's cache (or is simply faster in resolving) the non-local but nearby resolver will be faster.mikeshinn wrote:You'll have to test their DNS servers yourself to see if they are fast enough for your needs. We recommend you run a local DNS resolver, they are always faster than a network DNS.Thanks for the clarification. but can I enable it when I use non local, but a DNS server on the LAN (google compute engine)?
I did say that the network latency to a remote server should be higher if compared to using a local server. However, relatively the most time will be consumed by resolving the actual DNS query. So, in some cases, the nearby remote server can be faster. (Even when the network of handing over your query to the resolver is slower.)hostingg wrote:i have to respectfully disagree, a local socket to a local process is always going to be faster than a remote network query.