I was looking for a well-known CMS (Content Management System) that I could easily run in a Docker container as a target for information security reconnaissance tools, such as WhatWeb.
As in the previous post, I had created a simple web app using Python Flask to use as a teaching tool. The purpose was to demonstrate SQL injection and XSS (cross-site scripting) vulnerabilities and how to remediate them.
In this case, the remediation step for XSS (escaping output) tripped me up. I tried this:
return '<p>You searched for: ' + escape(user_input) + '</p>'
I expected it to escape only the
user_input variable, but instead it escaped all the HTML, returning this:
<p>You searched for: <script>alert(1)</script></p>
I recently developed a teaching tool using the Python Flask framework to demonstrate SQL injection and XSS (cross-site scripting) vulnerabilities and how to remediate them.
The remediation step for SQL injection tripped me up though when I received the following error message:
sqlite3.ProgrammingError: Incorrect number of bindings supplied. The current statement uses 1, and there are 4 supplied.
My web logs are filled with requests for
/xmlrpc.php, even on sites that aren’t running WordPress. Every one of these attempts is from a scanner trying to find, and possibly exploit, WordPress sites.
Why not put those scanners in a fail2ban jail and block them from further communication with your web server?
Continue reading Blocking WordPress scanners with fail2ban
Problem: I have a host that has 2 active network interfaces. One is used as a management port (
eth0), one is used as an FTP dropbox (
Both can route to the Internet, but all connections other than FTP on eth1 are blocked via iptables. The default route uses the interface for the FTP dropbox, but I have a static route configured for the subnet that includes my management and monitoring hosts so that I can SSH to the host and check on host availability, disk space, mail queue, etc.
However, the static route means that I cannot monitor the FTP dropbox, since FTP connection attempts coming in on one interface and IP address are then routed out via the management interface and IP address.
Solution: Use policy-based routing to direct the system to consult a different routing table for connections coming in on the FTP interface.
It sounds easy enough.
Continue reading Linux policy based routing
I had always been under the impressions that when moving a file from one Linux filesystem to another (i.e. a new inode is created), that
mv is essentially a
cp command followed by an
That’s not quite correct. It is essentially a
cp --archive command followed by an
Continue reading cp, mv, ownership and attributes
In my previous post I mentioned that I am learning about Podman, a tool for running containers that does not require a daemon process (like the Docker daemon) or root privileges.
In this post I would like to demonstrate why running containers with root privileges could be dangerous.
Continue reading Using Docker to get root access
I have recently been learning about podman, a tool for running containers that has a command syntax that matches Docker, but that does not require a Docker daemon and which does not require root privileges.
I ran into some unexpected problems publishing ports with Podman, which had to do with my default DROP policy on the iptables FORWARD chain. Below I will demonstrate some of the differences between Docker and Podman in terms of iptables changes, and provide a workaround for Podman.
Continue reading Docker versus Podman and iptables
I’ve played with Docker containers but haven’t really done anything, useful or otherwise, with them. I decided to create a Docker image that includes a web-based chatbot. You can find the Git repository for this (including the finished
Dockerfile) at https://github.com/cherdt/docker-nltk-chatbot
I’d previously been using the Docker driver with Kitchen CI and kitchen-ansible to test my Ansible playbooks. I really like using Kitchen CI. Test-driven infrastructure development! Regression testing! It’s great.
There were several reasons I decided to switch from the Docker driver to Vagrant. My target hosts are all either VMs or bare metal servers, so Vagrant VMs more closely resemble that environment. In particular, there are a couple areas where Docker containers don’t perform well for this purpose:
- Configuring and testing SELinux settings
- Configuring and testing systemd services