That'll do it for my intended purpose?
I should probably clarify there: The "Cloud service" message gets populated into the "Why blocked" field (i.e., I don't actually specifically "profile" for "cloud service" currently). So, to catch requests using that particular message, you'll probably want the "Why blocked" rather than the "Profile" fields in the auxiliary rule. Also, given that "short messages" (messages like "Cloud service", "Generic", "Invalid IP", "Malware", "Spam risk", etc, which get populated into the "Why blocked" field) can be clustered together within a single request, when matching against such "short messages", you'll probably want to add wildcards at the beginning and end of the match, too, just in case there's more than one unrelated signatures triggering for the request in question (i.e., "Cloud service"). Given the use of wildcards, you'll probably also want to use the Windows-style wildcards option for the use. So, all in all, something like this would be best:
Test:
Method: "WinEx"
Logic: "Any"
Reason: "Test"
Suppress output template: true
Block:
If matches:
WhyReason:
- "*Cloud service*"Does capitalization matter for Profile names?
I don't think so. Let me just quickly double-check my code right now though to make sure about that. One sec.
Test:
Method: "RexEx"
Logic: "Any"
Reason: "Test"
Suppress output template: true
Block:
If matches:
WhyReason:
- "~^.*Cloud service.*$~i"Test:
Logic: "Any"
Reason: "Test"
Suppress output template: true
Block:
If matches:
Profile:
- "Cloud"Thanks.
Just to be sure, are these the shorthand words?
ReasonMessage_Attacks:
ReasonMessage_BadIP:
ReasonMessage_Banned:
ReasonMessage_Bogon:
ReasonMessage_Cloud:
ReasonMessage_Generic:
ReasonMessage_Legal:
ReasonMessage_Malware:
ReasonMessage_Proxy:
ReasonMessage_Spam:Or these?
Short_Attacks: "Attacks"
Short_BadIP: "Invalid IP"
Short_Banned: "Banned"
Short_Bogon: "Bogon IP"
Short_Cloud: "Cloud service"
Short_Generic: "Generic"
Short_Legal: "Legal"
Short_Malware: "Malware"
Short_Proxy: "Proxy"
Short_RL: "Rate limited"
Short_Spam: "Spam risk"I ask because in your example you simply used "Cloud" instead of "Cloud service". It must be from the first group. i.e "BadIP" instead of "Invalid IP".
The available shorthand words are:
- Attacks
- Bogon
- Cloud
- Generic
- Legal
- Malware
- Proxy
- SpamThanks. I wasn't aware that the documentation got updated.
Kinda a stupid question I guess: How can one download a file from a repository? I always have to go to raw, copy to Notepad ++ and then save. It seems there should be a better way and I'm not seeing the option. A download option shows up for some repositories on Github, but not all. I just want to update my readme file.
Probably would be forced to just download a tarball or zip for the entire archive, find the file in question, extract, and do as you will with it.
That's what I thought.
And downloaded.
Another question, or rather your opinion. I uploaded my public key to my Repo. and archived it. Whatda think of me doing that? I saw some other website for public keys and user verification for things, but I don't remember it anymore. Actually saw a Github code Dev. use that service actually. I'm reluctant to add the email address though. I'm hoping it serves as a way for me to say, "yeah, this public key can be used with this email I give you to help provide authenticity."
plus there are GPG lookup directories available
I've read about a year or two ago they did away with one due to some flaw they couldn't figure out how to fix due to the way it works. Like being a victim to a DDoS on an email server without being able to use a reverse proxy like Cloudflare et al. Though, a quick Google search for this Info. I remember reading turns up nothing and instead I see some other lookup websites. LOL Go figure.
Question: I see in the update notes that you're now using Github discussions. Should we just abandon this Gitter channel or what?
I've already deleted phpMussel's Gitter channel, so that one'll 404 now. (Nobody had used phpMussel's Gitter channel in over a year and a half now anyway, so I didn't feel much need to bother informing anyone about it beforehand).
I was planning to eventually (hopefully very soon, but pending my available time, which hasn't been too great recently) do the same here for CIDRAM's Gitter channel, but because I haven't yet "formalised" exactly how we'll be using GitHub Discussions for CIDRAM (I had that idea about sharing auxiliary rules and maybe setting up a code library there, but I haven't quite figured out exactly how that's supposed to work just yet), because I also haven't properly told everyone my plans yet, and also because CIDRAM's Gitter channel is still actively used at this time (albeit by just you, me, and mikeruss; and 3 people isn't really many people; the other two people here haven't posted anything since as long as I can actually remember offhandedly), I've delayed deleting CIDRAM's Gitter channel, for now.
(Note: Using the discussions feature the exact same way we use Gitter is totally fine, and I'm cool with that. General chat or whatever is fine as far as I'm concerned. I don't plan to be rigid or strict about it or anything like that. But, by "formalised", I mean I want to think about those ideas first, just in case I realise something doesn't work, or how to make it work properly, or in case I discover we still need the Gitter channel after having already deleted it or whatever; and also, when we're ready, dropping a message somewhere along of lines of, "Hey everyone! Maikuolan here. Just to let you know, we're planning to delete the Gitter channel in X days from now. You can all just use the Discussions feature from now on for that stuff"). But, we can use it now, too, if we want. Whichever is preferable for the moment (albeit noting that stuff here at Gitter won't be staying around for too long, most likely).
The verification.yaml file located in the vault has the IPs that are whitelisted. And those IPs currently are only 14 in total and come from the source here: https://help.duckduckgo.com/duckduckgo-help-pages/results/duckduckbot/
ALL of DuckDuckGo's current IPs are from the Azure cloud except two which are from Amazon AWS. None of DuckDuckGo's PTRs show up except from the AWS assigned IPs. Apparently, the closure is a UA to IP. So maybe the UA doesn't match? The UA pattern is currently this:
~duckduck(?:go-favicons-)?bot~Anything else would be blocked. Maybe DuckDuckGo has a new UA?
For posterity, this people are idiots! 100% confidence!?
DuckDuckGo Profile:
Logic: "Any"
Profile:
If matches:
IPAddr:
- "20.191.45.212"
- "23.21.227.69"
- "40.88.21.235"
- "50.16.241.113"
- "50.16.241.114"
- "50.16.241.117"
- "50.16.247.234"
- "52.5.190.19"
- "52.204.97.54"
- "54.197.234.188"
- "54.208.100.253"
- "54.208.102.37"
- "107.21.1.8"
DuckDuckGo:
Method: "WinEx"
Logic: "Any"
Whitelist:
If matches:
UA:
- "*DuckDuckGo-*"
Profile:
- "DuckDuckGo Profile"I also have this in my htaccess:
#
#Check that the request is for /robots.txt
RewriteCond %{REQUEST_URI} ^/robots.txt
#Check that the request matches an existing file
RewriteCond %{REQUEST_FILENAME} -f
# Check that the user agent does not contain google etc
RewriteCond %{HTTP_USER_AGENT} !google
RewriteCond %{HTTP_USER_AGENT} !yahoo
RewriteCond %{HTTP_USER_AGENT} !bing
RewriteCond %{HTTP_USER_AGENT} !duckduckgo
# If all conditions above are met, then deny access to this request
RewriteRule ^ - [F,L](Will work in Litespeed and probably Apache).
My Cloudflare rules further expand upon this. It seems htaccess can be bypassed and I've tried figuring out how that is done, but couldn't find a resource on it. I guess this is where a php.ini file shines.