Moderation of groups/forums

Keeping a group/forum civil and on track can be quite a challenge.

Moderators have a range of challenges dealing with keeping a group on a track:

• Posters who don't understand what a group/forum is about (its core focus) and post stuff way outside that focus.  Clutter. 
• Bad actors: those spammers/scammers trying to pull attention away to other things that have nothing to do with the group/forum, even if they make their post look superficially like it belongs. I've often seen these go to incompatible or even competing products/services, and beyond to straight out scams and malware. These bad actors are hoping that readers are careless, thinking that those links have been vetted already, and that all vetting is perfect.
• Posters who have a real question or concern, but provide insufficient information about it, assuming the other participants are mind readers. There are often several ways the issue or concern could be taken, so others have to ask clarifying questions back at you to better understand, and as part of vetting your post.  
• Posters who don't speak the same language/culture as the group default/majority.

Tips: 

• If posts get through without being held for review, they have NOT been vetted and can't be trusted like you might others you already know in the group. Look who posted it, and even there could be a masqueraded or compromised account. 
• Even if the content of a group/forum looks all good, and you see active moderation happening, bad stuff still sneaks in and can take some time to be cleared out. Making sure you report such content helps the moderators see it as they aren't in the group 24/7 (most are unpaid volunteers!).
• If a group/forum has lots of out of scope and/or junk content, that is probably a group without active moderation. If it is an area that you'd like to be cleaner and be a part of, try to moderate it by flagging bad content as moderators can't see it all. You might even be invited to help moderate, or you can even offer if there is even someone there who could grant you those technical permissions. 
• If your post is answered with questions, they are usually honest, and jumping back at them makes you appear more like the spammer/scammers. Bad actor posters will often use bullying approach to push their suspicious content through, inviting the wrath of the BanHammer (a range of control moderators have to pause or block bad actors).

Summary:
Groups/forums can be useful and fun, but as with any other human activity, we can have misunderstandings among honest caring people, and we can have bad actors trying to mess things up one way or another. So be ready for the occasional such misunderstanding, because none of us are perfect, whether flesh or artificial.  Being nice is just the least friction path forward, especially for those of us trying to keep the arena of conversation nice.

 

Helping to keep yourselves safe on the interent

Here is an idea that you can share with your business, friends, and/or family to help keep everyone as safe as possible.

Subject: Keeping your work and personal data safe 

All our systems are increasingly under attack from growing hordes of bad actors (whom actively use automation to probe Everywhere/Everything).  There are some things we can all do to keep our data and identities safe from abuse, loss, and/or exposure.

A) Make sure that you are routinely restarting all your systems (phones, computers, tablets, etc.) at least once a week, so that the background patching can finish.  All patches require that the running software is stopped for the newer software to take its place. While some software can do this while we work, several key security sensitive parts can't do that without a full restart/reboot.

B) Make sure your Security Awareness training is complete, to help you keep clear of the ever-evolving scams facing us all, whether though work or personal communications, whether targeting the business or you personally. 

Your IT team is working all the time to make sure your systems and processes are as secure as they can get them. It is a never-ending game as the bad actors figure new ways to get at us and try to catch us in those slip ups in getting the safe things done in a timely manner. Please remember that just putting your device to sleep or closing your laptop is not restarting/rebooting your system.

As for all automation you may have setup, "Fire and Forget" is fine, provided you never actually forget. Check the automation regularly to ensure they are working. 

The risk of inactive/off-line systems

 The risk of inactive/off-line systems if just turned on and used

In our fast-paced world with cyber warfare going on, from nation states jockeying for the secrets of other nations with zero day hacks, to the many criminals looking for every way to get value out of everyone they can, software is constantly being patched to try and keep ahead. With so many people and businesses not patching, even old bugs are being probed all the time, and getting attacked. Using unpatched systems is a huge risk, sometimes even if just a few weeks, or sometimes days, out of date.

There are many reasons why a system might be unused for a while. They aren't just sitting there for no reason, but generally in one of the following paths

• Primary user on extended vacation or other extended leave.

• Pending deployment, with an active plan to do so.

• In reserve, with not active plan, other than to be available if needed. Perhaps on an eventual path to be decommissioned.
  

• On the way to being decommissioned and disposed.

If there is any intention of bringing a system into active use with little warning, they must be kept up to date, otherwise they represent a security risk as breachable/hackable defects are found but not patched. These machines would need to be regularly (every week or two) brought online and the full patch process run (Not just the few obvious ones, but the whole patch management process). This does not mean for all the system in reserve inventory, just enough for quick deployments (loaner or replacement) and the next ones are brought up to ready from extended off-line status.

Or

Any system that has been off-line for an extended time, is a huge safety risk to us if it is just deployed, until it has been through a few restarts, with time in between for the patch process to see what is needed and deployed. After the OS has gotten its patches, open the primary apps, and go to their ‘Help’ ‘About’ menu to check for any updates there. Browsers and email clients are a big target and the front lines of many cyberattacks.

If a system is on the path to likely being decommissioned, but we are just keeping it around "Just in case" then pull it out of any active monitoring systems it might be a part of, as those usually have a licensing cost you can free up, and they usually alarm/bug someone when they haven’t “called home”. Essentially some effort to ‘Mothballing’ the device, just like the Navy does with their ships, Air-forces often do with planes, or even clothes kept in the attic for that ‘maybe some day we might need this again’

There is a very active cyberwar going on, nation states juggling for control to avoid bullets, through all the criminals trying to get at what every they can grab. This has been accelerating at a rapid pace, and we can not rest on "it won't hit us" as we are all being actively probed all the time.

To be safe or as safe as possible, it is important that you keep your systems (both personal and business) as up to date as possible before and when actively using them.

Moving a GroupWise System

Through the life of a typical GroupWise system, it will likely move platforms at some point. No fancy migrations needed as all the database changes get done in place.

This could be hardware replacement, changing virtualization types, to hitting the limits of the OS at the time of the original installation. After all, you can only upgrade a box so much before there become issues with the OS. Even when you otherwise love that OS, a new install gains you so many of the advantages of it that are blocked in just upgrading it in place. Any GroupWise system of any real age has likely been moved a few times, such as from NetWare to NetWare to OES to OES

For this document, I will stick to current (late SLES15 era) and most common GroupWise hosting OS, with pure SLES or OES (built on SLES). Assuming GroupWise is the only application on the system so that the old box can be retired, and running an incremental copy of some sort. Imaging the data such as moving/copying a virtual drive can be done as well. This is for any and each server with a Domain and/or PostOffice on it. A GroupWise upgrade can be a part of this process if desired, but is assuming at least a GroupWise 2014 or greater source system.

This process allows you to build the new server in advance, and get the bulk of the files copied over in advance without downtime as those OFFILES are bulky, don't change much, and take a while (possibly many hours) for that initial copy. You are typically just looking at a couple of hours of downtime for the final move, under an hour if all goes smoothly.

Pre-migration is a good time to make sure your GroupWise maintenance is running properly, also check the results and files that are not part of the GroupWise system are removed from the GroupWise folders.

Build the new system with a different IP from the old server and a separate logical drive for GroupWise, either as NSS or XFS. Both are excellent options, both needing specific settings made, ideally at creation. NSS needs Salvage turned off, XFS (or any DB safe Linux type) mount points need the noatime and nodiratime set for optimal performance.

• Install GroupWise, but do NOT configure it!

• Restart the server at least once before the final migration to really finish that install.

• Copy the data with either rsync or dbcopy. rsync is very native with any Linux and is worth knowing for all platforms. I find it is the faster and easier of the two. It does every file that has ended up in the source (junk included) and doesn't get you restorable db files if the GW Agents are running, which is not a problem with such a migration. DBCopy requires a mount point to the new location to work, only does GroupWise files, is slower, and doesn't delete files. A script of the combination of them make for a decent low budget backup. Example in the Community.  

• Both tools can and the one you choose should be used incrementally, with a primary full copy of both the Domain and PostOffice folders, making sure the size at the destination is about what you see on the source. Identify any notable differences, as there may be issues to take care of. You can/should do this in the days leading to the actual flip outage of a couple of hours. If different versions, it tends to be best to use the newest dbcopy if you are using it, otherwise the direction of copy doesn't matter much.

• the rsync command that works well on SLES/OES with the only preparation of having the destination folder created. Alter the folders to match your system, and user if applicable. The command will want the password for root on the destination system or other if you changed it.
  
  
• # rsync -avh /grpwise/ root@xx.xx.xx.xx:/grpwise/ --delete

• Easy comparison tools:

• # du -h --max-depth=1 /GWdomain|GWpostoffice (the PO will take a while due to OFFILES)

• or install and use ncdu from GWdomain|GWpostoffice folders

• Is your GroupWise system the same IP as the server it is on, this is where we will change that. It makes these moves so much easier, is mandatory if you were to go to cluster services (where I learned this trick), and is how the containerized future of IT generally works.

• On the new server, make sure the /etc/hosts file has the GroupWise agents as FQDN entries as needed for GroupWise since 18.4, and that they match what you have in the agents' settings.

• On the new box, make sure the GroupWise agents ports are all open on the Firewall. Firewalls on servers are becoming less and less an option in the whole Zero Trust path of things.

• Firewall ports references

• https://www.novell.com/documentation/groupwise18/gw18_guide_admin/data/adm_appndx_port_numbers.html

• https://support.microfocus.com/kb/doc.php?id=7009520

• on MTA system: 7100, 7180, 9710

• on POA system: 1677, 8301, 7181, 7101, 7191, 9711,

• on GWIA system: usually an MTA set and 25, 9850

• For the final migration, make sure the source server's agents are shutdown, and preferably can't be turned back on

• # rcgrpwise stop

• # systemctl disable grpwise.service

• Perform the final sync.  With rsync, just repeat the command above.

• While that final sync is running, copy the following files to the new system.

• /etc/opt/novell/groupwise/gwha.conf

• /opt/novell/groupwise/agents/share/gwdva.dva

• /opt/novell/groupwise/certificates/*

• # scp /etc/opt/novell/groupwise/gwha.conf root@DestinationServer:/etc/opt/novell/groupwise/

• # scp /opt/novell/groupwise/agents/share/gwdva.dva root@DestinationServer:/opt/novell/groupwise/agents/share/

• # scp -r /opt/novell/groupwise/certificates/* root@DestinationServer:/opt/novell/groupwise/certificates/

• Once the sync is complete, remove the secondary IP from the source server if already using such, or down that server.

• Add the secondary IP to the new server

• # systemctl status grpwise.service

• may not be enabled yet. enable it and start it

• Test system, can you send & receive email, and manage the system

• A reboot to make sure it all behaves is a good thing as well.

If this feels overwhelming, and you are in Canada, please reach out to us, as we can help. For other feedback and comments, post a comment below. 

Is your email system ready to keep delivering email as the spam wars escalate?

Google's new restrictions on the email they will accept starting February 1st 2024 are just good practices we should be following.  But what are they really, and how can we make sure they are in place?

This applies to any sending email system, whether on your own servers, or hosted in the cloud such as with Microsoft or Google, to be successfully delivered. 

The pieces have all been here for a while as good optional settings, but now Google is just the first enforcing them:

1. The IP address of the server(s) your mail comes from must-have a reverse lookup.  PTR
2. The server must have a functioning encryption running.  STARTTLS
3. You must have published where your domain's mail is coming from.  SPF
4. Your server has to sign the message (like a wax seal).  DKIM
5. You have to publish your domain's alignment rules for #3 & #4, and where to send reports. DMARC

Note:

#3 & #4 are either/or for low volume senders, but both must be there for high volume senders.

#5 is mandatory for large volume senders.

It is a good idea to get all of them working, as inevitably, we will need to have this for all systems. #5 is the part that ties SPF and DKIM together to close the loop holes the spammers found in them. 

How to check:

Much of this is checked in DNS, checking the header/source of an email from the system, and talking directly to your mail server from another "mail server".  

• You can see if your system is good to go, or if you have problems by sending an email to a Gmail account you can log into. For each message in Gmail, you can check much of the status of a message that was sent to you, as to how the sending system was working or not at the new levels, at the time the message was sent.
• in Gmail, open the message,  then from the message 'more' stacked dots, select "<> Show original" 
• This view will show any results for any SPF, DKIM, or DMARC settings that are in place. If doesn't show, then that protection level doesn't yet exist for that internet domain or mailserver (i.e. it needs to be added).
• To check if it was encrypted, Ctl-F(search) for TLS, and there should be at least one (such as TLS1_3 or TLS1_2) for the connection from the sending server to Gmail's first server in.   

Summary:

Google is just the first, Yahoo! and AOL have committed to doing the same thing very soon, and Microsoft won't be far behind (looks like they may just be letting the others take the heat for being more secure)

These are also all good things to check and filter at your inbound / receiving mail systems.

Offering:

Would you like someone from outside your organization to validate how ready your organization is for these upcoming changes. Konecny Consulting for $99CDN + HST (payment via credit card) will do this checking for you. To engage with us please complete the contact form and we will get back to you. This offer is available to organizations within North America.

 

 

Google making major changes to email acceptance requirements

Will your email be blocked by Google, or are you ready for the changes they are making? Google will be blocking emails from weakly configured systems as of February 1^st, 2024. Make sure your system isn’t one of them that will be blocked.

Starting February 1st, Google will be imposing requirements on any emails being sent to a Gmail account.  They are asking for you to have some basic email system hygiene in place for your mail system.  If you are at all responsible for your own domain (the part after the @ symbol, such as username@gmail.com), then you must pay attention, whether you have an email server in your own data centre, or your email is hosted such as with 365 or Google.

Two other large email systems (Yahoo! and AOL) have already stated they are following in Google's footsteps, Microsoft is expected to follow before long.

These are Googles new requirements as of February 1st, 2024, and your email administrators need to make sure they are in place:

• All your outbound email servers must now do TLS encryption.  Without this, your email can be intercepted and read, or worse. There are still so many systems running without this, as it is Not a default on most of the ones you setup yourself.  Most hosted solutions do have this already, but not a bad thing to check.
• For systems with lower send rate, you need at least one of SPF and/or DKIM setup and working correctly.
• For systems that sometimes send more than 5,000 messages a day to Google Mail servers (including their customer domains they are hosting), then you must have both SPF AND DKIM working correctly AND DMARC setup.

 The most basic SPF and DMARC records you can setup for you domain is (in standard BIND notation):

@ TXT "v=spf1 a mx ~all"

_dmarc TXT "v=DMARC1; p=none; rua=mailto:{emailAddress2processReports}"

That SPF record is NOT guaranteed to work, as it must identify your email server(s). That DMARC record is very safe with an email address that does accept mail. Checking DKIM requires a proper analysis of those DMARC reports, though some spot checking can be done looking at the source header of received messages. 

For more details of Google’s current requirements, including the other 'little' details, read their "Email sender guidelines." https://support.google.com/a/answer/81126

Expect Google and others to increase their requirements in the future, such as the number of messages per day trigger point to be reduced, as well as requiring DMARC enforcement (not just reporting).

Yes, this can seem overwhelming. If you would like some assistance checking to see if your email system is ready for this major change, we may be able to assist you. Please reach out to us and we can discuss this with you.

Let Sleeping Services Be

AKA, latest scam attempted on me, with most of the caller's fumbles of his script left out.

A call claiming to be my ISP (never used it for home internet, but the phone number had been with them at one point, so others may have a match claiming your ISP based on who your phone has been with), that they had a failure on their server and that there 70% services stopped, and we need to fix them. 

Caller: How many devices do you have using the internet?  

Me: (quickly count the list) I have 15 IPs active today as seen on WhoIsConnectedSniffer (software I have running on my computer most of the time), but some of them should never get to the internet.   

Caller:  Then I need you to get in front of your computer.

Me:  OK, since that is where you caught me, where did you think I had WhoIsConnectedSniffer running?  yes I am there.

Caller: confused sounding

(a bit of back and forth with this drone in a call centre, to get him back on track of the scam to see where it is going)

Caller:  Do you see the Windows key?  Hold it down and press R

Me:  Ah, you want the Run prompt, OK, I am there.

Caller:  type in msconfig   and then press the OK button

Me: (I know this first bit is safe, so I proceed) Oh, it looks a bit different since I last looked this way, I see the Tabs: General, Boot, Services, ...

Caller:  OK, need you to click on Services, now see how many are stopped. 

Me:  Yes, I see many of  them stopped and that is the normal amount I expect there.

Caller: Then we need to remote into your computer to fix these stopped services as part of the service you paid for.

Me: But those services aren't needed, in fact some of them really shouldn't be running most of the time, rather like one doesn't leave their car running in the garage when they aren't driving it.

Caller:  But you paid for this service, so we need to restart them for you.

Note: This goes on back and forth for nearly 5 minutes until a meeting reminder gets me to wrapping up.  I could have so dragged him along for ages if I had the free time.

Me:  I have several ways to prove you are a scammer. 

• I'm not with the ISP you claim to be, though I have worked with them.
• It is normal for Windows to have stopped services as many are use only occasionally and the system knows how to trigger them on when needed, or are only on when the applicable hardware is turned on, example: the Bluetooth support service is stopped because I don't currently have Bluetooth turned on. 
• Clearly, as someone who mainly works on Linux servers, I still know way more about Windows than you do. 

Caller:    Ahh..ahh....ahhh..........

The line goes dead.  He was clearly very new at this, or was just following the script in front of him. 

Summary:

If you ask a question and they immediately re-ask their question, it is almost certainly a scam. 

Stopped Services on your computer is a normal thing, just like your microwave or shower are not running much of the time.  A server failure at your ISP is not going to impact the services on your computer, as, if necessary, a reboot of your system is all you should need.  Never let one of those callers remote into your system, as that is a disaster waiting to happen.  What exactly they will do varies, bit it won't be in your interest. 

Security Awareness Training Issues

Issues we've seen of some Security Awareness Training that limit its effectiveness, and ideas on how to improve them.

Does your solution suffer from these issues?

Training notifications resemble spam in a few ways (sense of urgency, a link) in addition to being overly annoying, and that is likely why we have seen them blocked, labelled Junk/spam, and otherwise ignored.  
   

* The notifications don't give the assignee an idea of how long the training will take.  For busy staff, especially those who have to track every hour (or less, as is the case for many professional service people) as billable,  this makes it very hard to schedule in to their plans.  Therefore, making it more likely for them to defer until they have a larger block of time and ability to listen to content to make sure they can complete in one go.   
      To Fix:  List the estimated time to complete, can it be paused or must it be completed in one go,  if Video, with or without Audio, just a slide-deck, or something else.
   

* Training is presented very piecemeal. Each element/training has its own mail stream, such that a busy person, in crunch time, can build up several queued training assignments and end-up with multiple nagging messages a day.  Junk mail handling is the easiest way to get them out of the way, cluttering up the key production communication tool of email.
      To Fix:  Consolidate those nag messages in some fashion.  A default should be One a day, with options both administratively and end user to set preferred time and timings to better reflect the local conditions of The Work (the reason the business exists, the training is a secondary support function that won't be allowed to wag the dog).

 

* Training alerts are currently oblivious to work schedules, even the most standard one of Monday to Friday.  The alert nag is based on X calendar days, not even X business days, so that trainees are getting alerts on off business hours. 

 

* If an assignee has been able to disconnect from email (weekends, vacations, collapse from overdoing a crunch, etc..), then they get a flood of those nags mixed in with all the other built up demands on their time leading to the nags being added to the rest of junk mail handling.

 

* If an assignee is trying to use a weekend to get The Work done during a normally quiet time, it's an interruption during a normally quiet time, again off to junk mail handling or similar in favour of The Work.

 * If an assignee is only paying attention to email on a weekend for emergencies (because normally a quiet time, vendors who send their marketing on weekends get down voted!)  Then any training alerts will only add up to frustration at the training and be invited to junk mail handling process.
      To Fix:  Default to X Business Days, not X Calendar Days for the training reminders, with those as clearly separate options.  And the Business Days needs to reflect the local Statutory and common Holidays, configurable would be nice to add business specific days that are reserved for things other than such secondary functions.   Bonus would be for a way to include(sync?) people vacation schedules to pause the training timers over peoples' scheduled time off.  Perhaps this could be the way to include Business and/or regional specific off days.
      
Related to the off hours notifications the system currently does, is that these notifications do trip up against a new legislative trend to protect employees personal time (that whole work/life balance thing).  Ontario is the first of the pack to have such legislation and off hours notifications put organizations based here in a rough spot, and we may well be forced to find other training providers that respect the Right to Disconnect.  
https://www.ontario.ca/document/your-guide-employment-standards-act-0/written-policy-disconnecting-from-work 

Why SSL(TLS) is a must for all websites.

What is SSL/TLS?

They are the evolving encryption tools that are the difference between a web page (via HTTP) that can be clearly Intercepted and ALTERED, and a page (via HTTPS) that is both encrypted with a chain of trust that makes it extremely difficult to view and even more difficult to alter in any way.  If you want to know more, you can read more here. 

To answer the questions of:

 - Why are some browsers making so much noise about why your unSSLized site is so untrustworthy?

 - Why your unsecured site is so low on the search engines?

Reason #1, the big one.

If your website doesn't have a proper TLS/SSL encryption in place, then if someone can intercept a person's browsing, it is easy to inject whatever hostile code is desired. It could be to just change what is showing on the page (this site hacked!), to silently injecting the latest ransomware or worse. 

You want your readers to get the message you so carefully crafted, not something else. You don't want them to equate you with putting malware on their system.

Reason #2
There is a pile of constant malicious scanning going on all the time, and just forcing your site to HTTPS causes a good portion of it hitting your site, to just go away.  One of my sites was getting many dozens a month of links from very dubious sites before I forced a switch to SSL, then they just went away.

There is then the whole Cyberwar part it of, where you could be caught in the middle of the big boys playing, as what was clearly happening as a part of a real hot war with the Russian Invasion of Ukraine as written up at the Internet Storm Center   where an entire block of IP addresses are redirected to another set of servers away from Twitter for a portion of the world.  Just too many ways for Man-In-The-Middle attacks.

So assuming you:

 - Don't want your readers scared away by the browser warnings

 - Don't want your readers to get used to a bad security practice because you taught them to

 - Don't want your readers' devices to become part of a hostile bot-net and/or worse.  

 - Would like (love?) your content to be more readily found by having a higher position in the search engines.

To get there

 This is done on the web-server itself, where you either pay for a certificate or use a free certificate service such as Let's Encrypt.  First you want to make sure your site works with the certificate so that you can get that lock in front of your URL (aka address) in the browser, and then you want to set it so that all attempts to come in unencrypted (port 80) get flipped/redirected to encrypted (port 443)

If you built your server, it is time to go RTFM for this as it is well documented for all Web-servers, as well as many others have written about the process. Your favourite search engine can also point you to resources.

If you are using a more typical hosted service, there is a very good chance the ability is sitting there in your control panel, just waiting to be turned on. Automatic free encryption has been a part of CPanel for a couple of years now (my hosters turned it on automatically for me), and a quick search shows that many of the others have a similar feature.  So take a look at your control panel, use the knowledge base most hosters setup, or even contact your support to see how good they are. 

There will be attempts to up-sell you to a higher grade of certificate.  If you just have a basic, low volume static site, then there is no real value in the "enhanced protections".  If you are gathering anything beyond comments and email addresses, such as e-commerce orders, then an actual purchased certificate makes some sense.  If you do go with a purchased certificate, make sure your hoster manages it and the update/renewal process, that they should have, is automated as certificates only last a year or less.

Do you require any assistance in securing your systems? Perhaps we can help.

Firefox's DNS settings

Managing Firefox's DNS settings rather than them controlling you.

Firefox does a few things intending to make your browsing experience better, but this isn't without its own issues.  This article is about the things Firefox does with DNS, some of the issues with what they do, and how to manage some of it. Some basic understanding of DNS required.

Firefox for starters, adds its own level of DNS that it even exists makes life more challenging to troubleshoot problems:

• It has its own layer of cache that, by default, remembers a given DNS lookup for 60 seconds. Clearing your host's DNS cache does not clear this one, and I've seen it remember failures, which is the straw that pushed me to learn all of this.

• It looks up all the links on a page when you load the page. So if a page has many links like I have in my bookmark pages or my client site admin pages, then it actually slows things down in addition to effectively advertising what page you were on to whoever might be watching DNS traffic.  Never mind all the additional traffic/packets to sieve through when troubleshooting.

Recently, Mozilla has added a new feature that will tunnel the DNS traffic over HTTPS through to their own DNS servers, aka DoH.  While good to protect the otherwise easy to read DNS traffic from prying eyes, it does mean that Mozilla/Cloudflare gets to see all your browsing DNS traffic.  Cloudflare is the current provider of this service for Firefox, and it is a changeable setting.  This makes it a question of which do you trust more, your local DNS path or Mozilla/Cloudflare?  Mozilla's stated intention is to have DoH be the default in the future, and they are 'just testing,' and now they are giving unsure messages of it given the push-back. ZDNet article on the downsides of DoH.  A way of blocking Firefox DoH

To see and possibly edit the settings for these, we need to get under the hood where we can do damage if we fumble finger anything.  So the first thing you want to do is backup your Firefox profile.  You can (and should periodically do) backup the entire profile as per Mozilla Support.

•  I make a point of clearing my Firefox cache beforehand to keep the backup size manageable.
• The file that gets touched in the following is the prefs.js, so making multiple copies of this as you edit your settings is a good thing.

Steps to see/edit Firefox DNS configuration:

• Type "about:config" in Firefox's address bar and press the Enter key.  
• Accept the warning/risk and be very careful here.
• On older Firefox (or newer after clicking on "Show All") : Scroll down to the network.dns....  selections about 3/4 the way down,  where a capital 'I' is ahead of the lowercase 'd' (ASCII sort rather than alphabetic sort)
• On Firefox starting with version 71 you get a prompt where you enter 'dns' for one set of below and then replace with 'trr' for the rest.

The settings of note are:
network.dns.disablePrefetch
   I set this to true as it doesn't make much sense for my use having FF go and look up all the things on the pages when I only go to one of them at a time.

network.dnsCacheExpiration
network.dnsCacheEntries
network.dnsCacheExpirationGracePeriod
   Setting either expiration or entries to '0' (zero) stops Firefox from caching DNS entries, leaving that up to your OS and upstream DNS server(s). Setting all three to '0' (zero) makes sure Firefox's cache is not being used.

network.trr.mode 0
network.trr.uri https://mozilla.cloudflare-dns.com/dns-query
   This is for the DNS over HTTPS, where the mode is a 0 or 5 has it disabled, and the URI is where it goes for content.     For more about this setting or the easier/safer way to set them


Any changes appear to be immediate, so just close you're about:config tab and proceed as per normal. Some browsing may be faster; some may be slower, but either way, you are that much more in control of your surfing.

Update 2019-12-15  After first writing this, Firefox made some nice changes with version 71 on how the about:config page works and this is now included.   Further reading on the (Anti-)Competitive and Network Neutrality aspects of DoH that shows how for most of us DoH is more pain than gain with out much of the touted benefit.