After learning of the SFP subdomain issue I wanted to create a simple tool that could help identify the problem and generate example records that could be added to close the gap.
This project is a work in progress and not public just yet.
After seeing DNS used for Command and Control in the wild I was curious to know how easy of difficult it would be to implement. This project is exactly that, a benign implementation of a bot that’s behavior can be controlled by DNS records.
This project is an ongoing contribution to the Ansible modules for interfacing to Infoblox systems.
With the update for my site to use “chips” to link to related pages its very easy for me tag a post with a tag that doesn’t have the supporting “tagged” page and resulting in a broken link. With the number of chips and tags I have across this site manually verifying each one manually is far to inefficient. Using LinkChecker makes this process quick and easy.
Infoblox is a popular tool that enables teams to centrally manage DNS, DHCP, and IP addresses (DDI) efficiently. One way to automate Infoblox is through the use of Ansible with the use of the Infoblox Ansible collection.
However, when using the Infoblox Ansible collection I quickly encountered some missing functionality…
- Define a member as a Grid Master Candidate
- Assign members to a network
- Define a DHCP range
In this blog post, I will discuss some of the changes I have proposed to fix these issues that exists in v1.4.1.
I have been using the http.server Python module for some time but recently, it's been more handy than ever. Whether it's testing network controls, Load Balancer configurations or simply copying a file from one location to another. Whichever the reason, the Python http.server module is so simple to use you can't afford not to know.