networking/datto-firewall-rules.md

@@ -0,0 +1,35 @@
+# Datto Firewall Config
+Rules to open ports specifically for a Datto appliance, without exposing the port, or truly 'opening' it.
+
+Note that if you don't allow these systems port 443 outgoing, you'll have to add the [certificate authorities](datto-troubleshooting.md) to get Datto paired with the backup agent.
+
+## Windows Server
+The Datto agent installer will pre-install incoming and outgoing rules in Windows Server firewall.
+
+By default, the incoming port is open to every device on the same network.
+
+**Lock the Datto port down**
+
+- Open **Windows Defender Firewall with Advanced Security** with elevated permissions
+- Select **Inbound rules** in the left menu
+- Double-click the **Datto Windows Agent In** rule
+  - Select the **Scope** tab
+  - Under *Remote IP address*, tick **These IP addressess**
+    - Add your Datto appliance IP
+    - Repeat the same, but for **Outbound** rules if you whitelist outgoing traffic
+
+## Linux-based Servers with CSF firewall
+[ConfigServer Firewall](https://www.configserver.com/cp/csf.html) running on any Linux-based distro:
+
+In my example, the Datto appliance is `172.16.4.50`
+
+- Allow TCP traffic only to/from the client machine and Datto appliance by whitelisting on `/etc/csf/csf.allow`
+  ```bash
+  # datto in
+  tcp|in|d=25566:25669|s=172.16.4.50
+  # datto out
+  tcp|out|d=3260:3262|d=172.16.4.50
+  ```
+  - Run `csf -r` to activate
+  - KB for [ports used](https://help.datto.com/s/article/KB204953800#System)
+  - [Supported Distros](https://help.datto.com/s/article/KB204953800#Supporte) Ubuntu 20.04.4 LTS (Focal Fossa) isn't listed, but appears to do successful backups (restore testing still required, at the time of writing)

networking/datto-troubleshooting.md

@@ -0,0 +1,41 @@
+# Unable to Backup Machines
+Problems I ran into during initial Datto deployment.
+
+## Windows
+For systems that aren't quite air-gapped, but close enough to it (allowing only 1 or 2 services network activity) you'll run into Schannel errors when first deploying the Datto agent to a Windows machine -- you'll have to allow more network activity.
+
+Pre-setup:
+
+- Have the proper [firewall rules](datto-firewall-rules.md) in place to lock down the ports Datto listens on, so only Datto can communicate on them
+- Initial deployment requires access to `*.dattobackup.com` - add the wildcard entry in your firewall appliance to open it up for the target host (I didn't do any of this on the client firewall, as the machine is on an isolated VLAN, governed by a firewall appliance that sits between client machines and the internet)
+
+Post-setup:
+
+- While attempting to pair an agent-based setup, the following error appears in **Event Viewer > Custom Views > Administrative Events**:
+  > The certificate received from the remote server has not validated correctly.  The error code is 0x80092013.  The SSL connection request has failed.  The attached data contains the server certificate.
+
+    - Click on the Details tab
+    - Scroll a bit, until you see some semblance of a FQDN:
+    ![schannel error](../img/schannel-error.png)
+      - `*.dattobackup.com` is using the CA `cr13.digicert.com`, so allowing this FQDN as an outgoing connection should allow the backup to commence.
+      - I allowed the following, for outgoing traffic (if you have an AV client like Sophos, the following should work for it, too):
+      ```bash
+      crl.globalsign.com
+      crl.globalsign.net
+      crl3.digicert.com
+      crl4.digicert.com
+      ocsp.digicert.com
+      ocsp.globalsign.com
+      ocsp2.globalsign.com
+      ```
+
+## Linux
+Datto's [Linux support table](https://help.datto.com/s/article/KB360040893811) doesn't list Debian 9, despite supporting every other version back to Debian 6.
+
+Attempting to use Datto with Debian 9 will find the `/tmp` directory become read-only, until a reboot or re-mount.  The issue will resurface with each subsequent attempt.
+
+Fix:
+- Upgrade to Debian 10
+
+Cause:
+- Unknown.  Datto support didn't have the technical details as to why this version is unsupported.

networking/fortigate/wildcard-addresses.md

@@ -0,0 +1,31 @@
+# Wildcard Addresses on a Fortigate
+> Support for wildcard FQDN addresses in firewall policy has been included in FortiOS 6.2.2.
+
+Source: [Using wildcard FQDN addresses in firewall policies](https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/217973/using-wildcard-fqdn-addresses-in-firewall-policies) and [Technical Tip: Using wildcard FQDN](https://community.fortinet.com/t5/FortiGate/Technical-Tip-Using-wildcard-FQDN/ta-p/196118)
+
+1. After adding a wildcard FQDN to the Addresses panel of the firewall, they appear as unresolved until a contact attempt is made.
+  >  As compared to the standard FQDNs, the wildcard FQDN does not use system DNS settings (Network -> DNS).
+The wildcard FQDN is updated when a DNS query is made from a host connected to FortiGate (DNS traffic passing through a FortiGate.).
+If the query matches the wildcard FQDN, the IP address is added to the cache for that object on the FortiGate.
+
+2. To initiate the contact, SSH into the firewall and run:
+  ```bash
+  diagnose firewall fqdn list | grep cloudflare
+  ```
+  - Address entries for `*.cloudflare.com` should now be resolved
+
+> Note that all IP addresses are assigned to that wildcard FQDN object for an unlimited time by default.
+**If FortiGate is rebooted, all IP addresses has to be learned again.**
+
+## Troubleshooting
+> Some of the domains (For example., google.com) have very short TTL and resolves to different IPs for different request to implement DNS based load balance. That will result in discrepancy of the IP resolved between FortiGate and by the other host. A workaround to the problem is to set a large cache-ttl so that IP address will be saved longer even its TTL expires.
+
+  ```bash
+  # config firewall address
+      edit "wildcard.google.com"
+          set type fqdn
+          set fqdn "*.google.com"
+          set cache-ttl 86400          < -----
+      next
+  end
+  ```