I have started my learning journey about AI. With that I started reading Artificial Intelligence & Generative AI for Beginners. One of the use cases it went through for NLP (Natural Language Processing) was Chatbots.
To the internet I went – ready to go down a rabbit hole and came across a Python library called ChatterBox. I knew I did not want to bloat and taint my local environment so I started using a Docker instance in Podman.
Down the Rabbit Hole
I quickly realized the project has not been actively maintained in a number of years and had some specific and dated dependencies. For example, it seemed to do best with python 3.6 whereas the latest at the time if this writing is 3.12.
This is where Docker shines though. It is really easy to find older images and declare which versions you want. The syntax of Dockerfile is such that you can specify the image and layer the commands you want to run on it. It will work every time, no matter where it is deployed from there.
I eventually found a somewhat updated fork of it here which simplified things but it still had its nuances. chatterbox-corpus (the training data) required PyYaml 3.13 but to get this to work it needed 5.
Dockerfile
FROM python:3.6-slim
WORKDIR /usr/src/app
#COPY requirements.txt ./
#RUN pip install --no-cache-dir -r requirements.txt
RUN pip install spacy==2.2.4
RUN pip install pytz pyyaml chatterbot_corpus
RUN python -m spacy download en
RUN pip install --no-cache-dir chatterbot==1.0.8
COPY ./chatter.py .
CMD [ "python", "./chatter.py" ]
Here we can see, I needed a specific version of Python(3.6) whereas at the time of writing the latest is 3.12. It also required a specific spacy package version. With this I have a repeatable environment that I can reproduce and share (to peers or even to production!)
Dockerfile2
Just for grins, when I was able to use the updated fork it did not take much!
FROM python:3.12-slim
WORKDIR /usr/src/app
#COPY requirements.txt ./
#RUN pip install --no-cache-dir -r requirements.txt
RUN pip install spacy==3.7.4 --only-binary=:all:
RUN python -m spacy download en_core_web_sm
RUN apt-get update && apt-get install -y git
RUN pip install git+https://github.com/ShoneGK/ChatterPy
RUN pip install chatterbot-corpus
RUN pip uninstall -y PyYaml
RUN pip install --upgrade PyYaml
COPY ./chatter.py .
CMD [ "python", "./chatter.py" ]
Without Docker
Without Docker(podman) I would have tainted my local environment with many different dependencies. At the point of getting it all working, I couldn’t be sure it would work properly on another machine. Even if it did, was their environment tainted as well? With Docker, I knew I could easily repeat the process from a fresh image to validate.
Previous projects I worked on that were python related could have also tainted my local to cause unexpected results on other machines or excessive hours troubleshooting something unique to my machine. All of that avoided with a container image!
Declarative Version Management
When it becomes time to update to the next version of Python, it will be a really easy feat. Many tools will even parse these types of files and do dependency management like Dependabot or Snyk
Aren’t these titles getting ridiculous? When talking about some of these stacks, you need a laundry list of names to drop. In this case I was working on publishing my CloudFlare Tunnels FTW work that houses my kind lab into my public GitHub Repository. I wanted to tie in FluxCD to it and essentially be able to easily blow away the cluster and recreate with secrets all through FluxCD.
I was able to successfully achieve that with all but the private key which needs to be manually loaded into the cluster so it can decrypt the sensitive information.
Why Do We Care About This?
While trying to go fully GitOps for Kubernetes, everything is stored in a Git Repository. This makes change management extremely simple and reduces complexities of compliance. Things like policy bots can automate change approval processes and document. But generally everything in Git is clear text.
Sure, there are private repositories but do all the the developers that work on the project need to read sensitive records like passwords for that project? Its best that they don’t and as a developer you really don’t want that responsibility!
Mozilla SOPS To The Rescue!
Mozilla SOPS is very well documented. In my case I’m using Flux which also has great documentation. For my lab, this work is focusing on “cluster3” which simply deploys my https://www.woohoosvcs.com and https://tools.woohoosvcs.com in my kind lab for local testing before pushing out to production.
Create Key with Age
Age appears to be the preferred encryption tool to use right now. It is pretty simple to use and going by the flux documentation we simply need to run
age-keygen -o age.agekey
This will create a file that contains both the public and private key. The public key will be in the comment and the command line will output the public key. We will need the private key later to add as a secret manually to decrypt. I’m sure there are ways of getting this into the cluster securely but for this blog article this is the only thing done outside of GitOps.
Let’s Get To the Details!
With Flux I have a bootstrap script to load flux into the environment. I also have a generate_cluster3.sh script that creates the yaml.
The pertinent lines to add to it above the standard are the following. The first line indicates that sops is a decryption provider. The second indicates the name of the secret to be stored. Flux requires this to be in the flux-system namespace
From there you simpley need to run the bootstrap_cluster3.sh which just loads the yaml manifests for flux. With flux you can do this on the command line but I preferred to have this generation and bootstrapping in Git. As you want to upgrade flux there’s also a upgrade_cluster3.sh script that is really a one liner.
This will update the components. If you’re already bootstrapped and running flux, you can run this and commit to push out the upgrades to use flux to upgrade itself!
In the root of the cluster3 folder I have .sops.yaml. This tells the kustomization module in flux what to decrypt and which public key to use.
Loading Private Key Via Secret
Once you have run the bootstrap_cluster3.sh you can then load the private key via
CloudFlare provides VPN tunnels between your web application and the CloudFlare network for private and direct access. There are a multitude of use cases for this. The nice part about this is the tunnels are available in all tiers (including free).
Use Cases
The main use case for this is Least Privileged Security. Without tunnels, the common use case for CloudFlare is to add ACLs to your edge allowing in connections from CloudFlare. With Tunnels you run an appliance or daemon/service internally that creates an outbound tunnel to CloudFlare for your web applications. What this allows is only allowing egress traffic, worst case. Best case only opening up FQDN based whitelists on specific ports to CloudFlare’s network to allow the tunnel to negotiate. In essence, only allowing specific outbound connections needed to support the applications.
An interesting secondary use case for this is self-hosting of your web application. Years ago if you wanted to self-host something at your home, you would have to either ask your ISP for a static IP or use a Dynamic DNS provider that would constantly update your DNS with your IP. With CloudFlare Tunnels, once configured, the tunnel will come up regardless of your location or IP address. This is great for self-hosting at home (when you can’t afford a cloud provider and want to reuse some equipment) or even having a local lab that you want to share out to friends for testing.
Technical Setup
There are other articles that walk through the setup and it really depends on your implementation but I will share a few links of what I did to setup a Kubernetes lab up with CloudFlare Tunnels to expose my local lab running podman + kind + Kubernetes with a custom app I wrote onto the Internet.
Have a working Kubernetes cluster. For a quick lab, I highly recommend kind+podman but many use minikube.
Have a local cloudflared that you can run to setup the tunnel and access token
One of the tweaks I had to make though is that the cloudflared manifest is a bit dated. As of the time of this writing I made the following changes
#Image was set to 2022.3.0 which did not even start
image: cloudflare/cloudflared:2024.3.0
# Reduce replicas - this was a lab with a single node!
replicas: 1
# Update the ingress section.
# This maps the CloudFlare proxied address to a kubernetes service address.
# Since cloudflared runs int the cluster it will use K8 DNS to resolve
- hostname: k8s-fcos-macos.woohoosvcs.com
service: http://tools-service:80
Don’t forget to import the secret from the CloudFlare instructions!
If setup properly you’ll see success!
More Than Tunnels
This is just the beginning. This is just a piece of the full Zero Trust Offering by Cloud Flare. It is a bit out of scope for this article but the nice part about CloudFlare is a lot of it is set it and forget it and let them manage once its configured properly.
Conclusion
Whether you are a large enterprise needing full Zero Trust or just a startup hosting a few servers out of your garage off your home internet, CloudFlare has tiers and offerings that can meet your budget. Its a great tool that I have used for this site and my https://tools.woohoosvcs.com/ for a number of years.
It seem every week we see a new article of some sort of IT security related incident. While many of these larger companies tend to have security tools to help combat them, many smaller companies do not know where to start. An eye opening experience would be to run an internal vulnerability scan on your corporate network to see what types of vulnerabilities you have.
These scans results may then drive you to more promptly patch and mitigate vulnerabilities. Other times it can help give data to management to ask for resources like security tools and people to manage them.
What is This Article?
This article is a quick and dirty install guide for installing Greenbone Vulnerability Management on Kali Linux. Both have been around for quite some time and are free to install. You can attempt to install Greenbone on any Linux distrubution but Kali tends to be the easier and more stable platform since its very commonly used for vulnerability scanning and management.
A Server (Physical or VM) to install that has 2GB RAM, 1 Core and 20GB HDD space
Basic understanding of installing Linux
Installing Kali Linux
We won’t get too much into the details of this but if you’re a first time installer, select the Graphical Install and you can’t go too wrong with most of the defaults.
Kali Linux – Install
You can install a Desktop but for the purpose of this tutorial, I’ll be using command line so I unselected the Desktops. It saves space and a little compute.
Kali – Desktop Environment
Prepping for Greenbone Vulnerability Management
I always like to start out with a freshly updated operating system. Since Kali is based off Debian we’ll be using apt-get. The first step is to configure network access.
# This will tell us the interface name, most likely eth0
ifconfig -a
# This will allow us to edit the interfaces file
sudo nano /etc/network/interfaces
We can then populate it with eth0 information for DHCP
sudo nano /etc/network/interfaces
The new lines are the “auto eth0” and “iface eth0 inet dhcp”.
Control X to save and then a “sudo systemctl restart networking” and your ifconfig -a should show an ip address for eth0.
From here we can update the system. Its always best to update before the install to ensure you’re running the latest fixes.
# We're going to switch to root since the next few commands will need to be under that context
sudo su - root
# This command updates the package metadata
apt-get update
# This command performs the actual update
apt-get upgrade
# Reboot when done to start fresh (optional but should be done at some point)
reboot
Depending on your internet connection, this could take a few minutes.
Installing and GVM
Installing is the simplest part.
sudo apt-get install gvm
And wait a few minutes after answering “Y” to download and install.
Next we’ll run “sudo gvm-setup” which aside from running through the configuration will start pulling down the various feeds. This will take a good 30-40 minutes. It does an rsync on community feeds for CVEs, Vulnerabilities and other scanner options.
Once it has completed this process, we do need to modify it to listen on 0.0.0.0 instead of 127.0.0.1 so that it is network accessible. Before that though it will output the admin username and password which we need to capture before proceeding. It is randomized for every install and since this install will get blown away after this lab, I’ll share it unfiltered.
Kali -GVM – Password
We can do that by running the following to edit the systemd startup file
From here a “sudo gvm-start” is all that is needed.
If all went well you should be able to https:// to the IP of the server on port 9392
With any luck aside from a certificate error the following screen should show up.
gsa – login
Configuring a Scan
Now that we have access to the tool, we need to configure a scan. This starts with configuring a target list. Under Configuration / Targets. Then create a new target
gsa – target – newgsa – new -target
This requires just a few fields entered. The name is fairly self explanatory and is just a name for the targets to be scanned. For the list of hosts, you can list subnets and/or IPs. In this example I picked the scanner itself.
For the PortList, The default can be used but when possible I like to scan All TCP and Nmap top 100 UDP ports as many times applications run on non standard ports.
If you feel comfortable providing your scanner credentials it can login and perform authenticated vulnerability checks as some may not be able to be detected anonymously.
Under Scans / Tasks we want to create a new Scan Task
GSA – Scan Task
Once that has been created and saved a scan can be kicked off.
GSA – Run Scan
When running a scan it can take some time and that is determined by the remote endpoint but it is not uncommon for it to take 30 minutes per IP address depending on how quickly the endpoint can be scanned and what it finds. By default it does have quite a bit of concurrency and in order to fully utilize that you may have to tune your CPU and RAM configurations but that is out of scope for this document.
Once a scan is complete you have a report. Unfortunately this scan did not turn up much due to it being already fairly secure but this is what you can expect to see!
gsa – report
Final Words
That is it! You now have a vulnerability scanner you can use to scan your network for vulnerabilities. If you choose to use this for your vulnerability management needs, tweaks will need to be applied to port ranges, hosts and other settings but in a nutshell this is the nuts and bolts of what you need.
My first real exposure to auditd has been deploying Rapid7 InsightIDR. Its been a great tool but I did not understand why they require auditd to be disabled. Is it not more secure having an audit daemon running? After a server had rebooted to completely disable this, it ran into a ton of performance issues and my path lead me down better understanding auditd.
What is Auditd?
At a high level it is a piece of software that allows you to view and audit actions being performed on the operating system. These actions can be directory listing, program execution, audit policy changes.
How is this Facilitated?
There are two pieces to the puzzle. There is a kernel based kauditd which queues up audit events for consumption. Various syscalls and other events cause an audit event to trigger.
These events are consumed via a userland auditd process. This process enables the auditing (via auditctl) and registers its PID and starts consuming events pushed through a PIPE. by default these events are simply logged to /var/log/audit/audit.log.
In the event that the auditd can’t consume these properly there is an audisp process that handles the overflow. Perhaps the auditd crashes but audit events are still pumped to the PIPE. Audisp will generically pump these to syslog which may push to /var/log/messages instead.
Auditctl
You can use the auditctl command to view the status or add rules. These rules would allow you to monitor extra resources or ignore certain ones.
auditctl -s
Why Does Rapid7 Want This Disabled?
The Rapid7 ir_agent has its own consumer process that scans the auditd events. Unfortunately (unless compatibility mode is enabled), only one process can consume these and Rapid7 wants its agent to be the consumer. It does so in an interesting way though. kauditd knows events can’t always be consumed in realtime so there are provisions for a backlog buffer which Rapid7 increases. It does this so a background job can run periodically to pull these events from the queue instead of listening in realtime. I’m not sure of the benefit of this method but it seems to work.
Without auditd disabled and stopped though, no others can listen, including Rapid7.
Here you can see, it is currently disabled and no pid is registered. Importantly though you can see the high backlog_limit (buffer). It is normally under 300 because auditd is running constantly.
So Why Did Our Server Blow Up?
Well, in our case its a server that generates a ton of audit logs because it kicks off tens of processes per second. It was easy to dump those to a audit.log file but a security tool actually parsing those just couldn’t keep up. We will either need to filter some of those auditd events or disable the agent.
Summary
If you ever need to use auditd, hopefully this gives you a basic insight into it.
Recently a client had a need for putting a web application on the internet that end users could access. They wanted to lock it down so that not everyone on the internet could access. Whitelisting IP Address was not an option because they were remote users with dynamic IPs and the overhead of maintaining this whitelist would be problematic.
The use case was a password recovery tool that their remote users could use to reset and recover passwords. Simple authentication would not suffice. For starters if the users’ passwords expired they wouldn’t be able to easily log into the site. Along with that it would be a high profile target for brute forcing.
Why Not IP Whitelisting?
IP whitelisting used to be and still us for some organizations the de-facto method of filtering traffic. It can be very problematic though. Users today are on the go, working remotely or using their mobile device on cellular data as well as home internet. Other times it involves sales staff at client sites. Keeping up with these IP whitelists can be a chore. Updating this whitelist can be time sensitive to avoid halting productivity. When not maintained, there is a chance someone unexpected could gain access due to simply having an IP previously whitelisted.
A workaround for this is VPN but that requires a bit of support overhead in user training and support. This can be clunky for users that are not used to to using VPN.
Why Certificates
Many larger organizations already have internal Certificate Authorities in place. For Microsoft Active Directory deployments, when CA has been installed, end users are likely auto enrolling in user certificates. Domain joined workstations already have these and trust it the internal Root CA.
Certificates also have a built in expiration. In an auto enrollment environment, this expiration could be lowered substantially to below 1 year.
TLS Handshake
Once of the nice features of TLS is that it does include a mechanism for this. Below is an example of a TLS handshake where the server requests a certificate and the client provides it.
TLS Handshake – Certificate Authentication
In Frame 19, the client makes the TLS request with a Client Hello. Frame 23 the Server response with a Server Hello. This is where they set parameters and negotiate things like TLS versions and encryption algorithms.
Frame 26 is part of the Server Hello but it was large and split up. Boxed in red is the “Certificate Request” where the server is requesting a certificate to authenticate.
Frame 33 is where the client actually provides it.
From here you can see this happens before the application level (HTTP) protocol communicates starting in frame 43. What this means is that before the user reaches the web application for authentication, the device requiring TLS Certificate Authentication is filtering the requests. Many times this is a reverse proxy or load balancer is not vulnerable to the same exploits as the web servers.
Browsers
When used properly and the client has a certificate, the browser will prompt users for a certificate to use such as pictured below.
Browser Certificate Authentication Prompt
Other Applications
A really neat application for this when you have a legacy plain text protocol in play but you want to open it up over the internet and secure similarly. Perhaps you have a legacy application that uses raw text and is not SSL/TLS capable. You can still put this on the internet through a reverse proxy like F5 LTM or stunnel.
Traditionally this type of traffic would be protected via IPSEC tunnel that is encrypted or a dedicated circuit such as MPLS. That does require specific hardware and/or monthly circuit costs to accommodate.
stunnel is extremely useful in this scenario as you can install it on the local machine that has the legacy application and configure it to connect to localhost on a random port and proxy information out over TLS and configure it to use the certificate based authentication.
Here is a graphical example of what that may look like with an stunnel server broken out. stunnel could be installed on the end user’s workstation though.
Legacy App Secured with TLS 1.2 or higher & Certificate Based Authentication
stunnel could be put on the local end user workstation to minimize that unencrypted leg. Typically on the server side the reverse proxy has a leg directly on the same VLAN/subnet as the application which minimizes exposure over that but this does help secure the application traffic over the untrusted internet.
Final Words
In this article we learned a little on Certificate Based Authentication. We also learned how it may help your organization better secure your applications and possibly avoid more costly solutions.
A few years ago Comodo CA was spun off from Comodo’s offering and rebranded as Sectigo. You can read more about it from the horse’s mouth here.
During this transition Sectigo went through rehoming their intermediaries. This was to show the Sectigo brand. Their Root CAs were due to expire in 2020.
Sectigo’s Documentation
Sectigo has a very nice document on this which does make a lot of sense. It does however seem to have some pieces that did not originally make sense. I was not quite left with enough warm fuzzies to leave it alone. You can read about it here. Their article lays a great foundation.
Cool Troubleshooting Tools
Not everyone is comfortable with using OpenSSL and inspecting certs manually. Here are a few of the cool tools I found along the way.
Certificate Decoder – Just plug in your PEM file contents and it will decode and give you the OpenSSL command to do so
crt.sh – Cool web portal to look up certificates based on thumbprint and other identifiers
SSL Labs – Server Test – If you want to see how your cert chain is trusted, this is one of the many things this site can do.
AddTrust External CA Root has been around since 2000 and well trusted. What happens when this expires?
Digging In
Running through SSL Labs is an easy way to see the cert paths that are trusted. One good hint at this is the cert chain that the server sends. It is why it is important to include the intermediaries on whatever device is terminating the certificate.
Provided Cert Chain
So far this looks normal but you can see that the “Valid until” on #3 is 30 May 2020.
Trusted Cert Chain(s)
Here you can see there are two trusted paths. Path #2 is in line with the cert chain we are providing with the early expiration.
Path #1 appears short circuited. One may think the same “USERTrust RSA Certification Authority” may be trusted. Upon further inspection, they have a different fingerprint.
It appears that Sectigo is signing the certificates with an Intermediary chained to a Root that expires in 2020. Due to an intentional name collision, it also matches another Root that expires in 2038.
This is the part that seems to be omitted in most documentation is that there are two “USERTrust RSA Certification Authority” CAs. One that expires in 2020 and one that expires in 2038. At the expiration of 2020, that path should no longer be valid. It is likely browsers and operating systems are already picking the shorter cert path if they trust it.
Final Words
Per Sectigo’s article I linked to we see SSL Labs do exactly what was expected. As always you should test, particularly on systems that are older and do not automatically update their Root CAs.
Trust Chain Path A: AddTrust External CA Root [Root] USERTrust RSA Certification Authority (Intermediate) [Intermediate 2] Sectigo RSA DV/OV/EV Secure Server CA [Intermediate 1] End Entity [Leaf Certificate]
Trust Chain Path B: USERTrust RSA Certification Authority (Root CA) [Root] Sectigo RSA DV/OV/EV Secure Server CA [Intermediate 1] End Entity [Leaf Certificate]
The interesting tidbit on the Cross Signed Intermediary is
This intermediate certificate is signed with SHA384 hash algorithm, but the root certificate it depends on – AddTrust External CA Root – is signed in SHA1. This historical chain presents a high compatibility rate with old systems or browsers that cannot be updated. If you work with strict clients or systems that only accept full SHA256 (or more) certification chain, you can install the following chain on your server. It has the same name but it signed in SHA284: USERTrust RSA Certification Authority. Then the chain will be shortened and won’t include a SHA1-signed certificate anymore.
In fully disclosure, at least at the time of this writing, this blog uses CloudFlare but I am not compensated for mentioning it. I am really a fan of the product. In today’s world, sites and servers exposed to the internet are constantly scanned for vulnerabilities and exploits. I happen to look at such logs on a daily basis and see them constantly in a wide variety of systems.
Exploited and attacked systems can have effects that range from a site or network being brought down to sensitive data being stolen and sold to anywhere in between.
Firewalls are great but traditionally they do not inspect and potentially block traffic. Some do and are great, such as Checkpoint and Palo Alto but many times they have a high barrier to entry and require a traditional infrastructure that allows a physical or virtual appliance to exist.
Firewalls at the edge of your network are not great at dealing with Distributed Denial of Service (DDoS) attacks because everything is funneling to your firewall. If the DDoS saturates your internet connection, their goal is achieved and legitimate traffic gets dropped too.
Also with new encryption, specifically most TLS connections using Diffie Hellman – it is not enough to load the TLS key on to an intermediary device to decrypt. It must actually terminate to the device, whether that’s CloudFlare, F5, CheckPoint, etc.
Why CloudFlare?
Web Security
Appliances and services like CloudFlare are great because they are specialized to understand HTTP transactions and content and with something like CloudFlare that sees a major chunk of the internet traffic their heuristics are fairly good.
This blog for example is just a web site exposed to the internet, so I will use it as an example for setup and benefits.
Pricing and Tiers
CloudFlare has a few different tiers, ranging from free ($0/month), professional ($20/month), business ($200/month) and enterprise($much more/month). Sometimes its difficult to be knowledgeable of which features exist in each addition until you try to implement them and realize you need the next tier up. That is really my only major gripe with it but it does have a free tier so can one really complain?
Distributed Architecture
Their environment is highly distributed so that local denial or distributed denial of service attacks are typically limited to the region they originate. In a truly distributed attack, the nodes closest to the source of the DDoS tend to not get as overloaded because they catch it closer to the source.
This distributed nature combined with their build in caching also greatly increases performance as static content on your site is cached close to where requestors are requesting it. This helps your site scale and mitigates/minimizes the need to spin up more servers closer to the consumers of your web content.
In a fairly static site like this blog, it helps keep hosting costs lower! This page has some good “marketing” documentation on it – https://www.cloudflare.com/cdn/
Beginning Onboarding
Configuration is fairly straight forward. You can sign up online, indicate the domain name. It will then try to pull down your existing DNS records from the existing provider as you will ideally want CloudFlare to host your DNS. This allows it to use AnyCast to provide responses as close to the destination as possible. For those that are a bit skeptical of hosting your DNS with CloudFlare, at the Business level (currently $200/month) you can do a CNAME setup for just domains and subdomains.
Before you point your NS records to CloudFlare, export your records from the current hosting provider and make sure what CloudFlare has matches up.
All of these entries would normally be public but for proxied entries, CloudFlare will actually point it at one of its termination points and forward to this entry. Its a good idea to keep these private so potential attackers do not know the source of the content and attempt to bypass CloudFlare.
Any records that do not need to go through CloudFlare, click on the “Proxied” status and it will change to DNS only.
Once you point your DNS servers at CloudFlare’s and check, you are most of the way there!
Enabling SSL/TLS
SSL has actually be deprecated and replaced by TLS but it has been around that people still call it TLS. You will see it used interchangeably everhwere. This allows CloudFlare to terminate TLS for you. In the earlier days, all static content was plain text/unecrypted via http/80. These days though browsers start to mark that content as insecure, search engines rank those sites lower and people generally look for the lock in their browser that indicates the site is secure. This is whether the content really needs it. For this reason it is important to enable TLS so that users have a better browsing experience and any potential sensitive data is encrypted. Some examples of that are usernames and passwords when logging into a site.
TLS – Full
TLS – Full is the best compromise of all. CloudFlare will issue a certificate to its endpoint, unless you have a custom one you would like to upload. The Business plan is required for custom certificates, otherwise you will get a shared certificate with other random customers of CloudFlare.
Full also encrypts between CloudFlare and your web server/service. This allows end to end encryption. By default CloudFlare will issue a free origin certificate but unless you are in Full (strict) the origin certificate is not validated so it can be a self signed or expired certificate.
Enabling Web Application Firewall
The Web Application Firewall (WAF) is the heart of the protection of CloudFlare. It has a list of protections and vulnerabilities that are enabled based on your needs to better protect your site. In order to help prevent false positives though, it is best to only enable what you need.
You will note that it does require the Professional plan which at the time of this writing is about $20/month.
If you opt for Pro or higher, you can enable the WAF via the following option and then enable the individual managed rules that apply to your site.
The list goes on and on for a bit so this is not all inclusive.
Securing Your Origin
Once you are completely comfortable with CloudFlare, do not forget to secure your origin. By this I mean setup ACLs to restrict connections to only allow CloudFlare to connect to it. This way malicious parties do not simply bypass CloudFlare. This list is always kept up to date – https://www.cloudflare.com/ips/
I have been going through a CheckPoint R77.30 to R80.20 upgrade. I was lucky enough to have a “lab” instance to run this through as we plan for production.
In going through this upgrade, I learned a few things being fairly new to CheckPoint.
#1 – Newer Management servers can manage much older Security Gateway. I was concerned that upgrading the management server and leaving it as is for a while which would likely be the case for production would become a major issue but it is well supported by CheckPoint. It appeared that the R80.20 Management server could manage as old as R65 SGs.
#2 – When you have an R80.20 Management server pushing IPS updates to an R77.30 instances, the R80 instance translates the IPS rules since there were major changes. This was a concern because R77 is past End of Support so I wanted to ensure IPS rules could still be downloaded and supported.
#3 – When you actually upgrade the Security Gateway, some of the IPS inspection rules change or act differently. One in particular is the “Non Compliant HTTP” which appears to no longer support HTTP 0.9.
For #3 – What this means is that GET requests without a version will may get blocked by default with the reason “illegal header format detected: Malformed HTTP protocol name in request”
Check_MK (https://checkmk.com) when setup for distributed monitoring (remote sites) also uses an http “like” protocol that triggers this.
Options are either to add exclusions in the IPS Inspection Setting to bypass the Non Complaint for these specific cases or in the case of F5, create an HTTP 1.0 or higher compliant HTTP check.
GET / HTTP/1.1
UPDATE: 2019-11-07 – I decided to kick a ticket around with CheckPoint Support on this one but have not heard back. I imagine since HTTP 1.0 has been around circa 1996 they decided to require it. In doing so they likely forgot many out of the box software is backward compatible to HTTP 0.9
UPDATE: 2019-11-11 – CheckPoint provided me with sk163481. The dates of this are after my ticket so my inquiry most likely triggered this.
