Web-Performance Blog
In my access logs, I found excessive requests from IP address 65.108.99.119. During a regular review, I also found this IP is listed on AbuseIPDB, which indicated it has a lower reputation or may even be malicious.
The reverse PTR was also not very valuable.
crawl1-135.oi.tb.007ac9.net.
During a review of access logs, I recently came across this user agent string. It was by far the highest in request count. As it turns out, this is a SEO tool called Sistrix.
Mozilla/5.0 (compatible; Optimizer)
The reverse PTR for real asterisk calls should always be:
*.crawler.sistrix.net
If you are using Azure Front Door, the need for a WAF policy that rate limits or blocks access to certain IP addresses might arise. Using the correct parameters in the WAF policy is crucial to implement an effective block that cannot be bypassed.
When selecting the property RemoteAddr in your WAF rules, a custom X-Forwarded-for header can be used to “hide” the real IP address or even to masquerade as a different IP address and therefore pass through an IP restriction.
Between July 14-17, police and cybersecurity agencies from multiple countries worked together to go after NoName057(16), a pro-Russian cybercrime network. The operation, called “Eastwood,” was coordinated by Europol and Eurojust. Authorities from 12 countries took action at the same time, targeting both the group’s members and their computer infrastructure. The main participating countries included the US, Germany, France, Italy, and several others across Europe. Eight additional countries provided support for the investigation, including Ukraine, Canada, and some Baltic nations. Two private cybersecurity organizations, ShadowServer and abuse.ch, also helped with the technical aspects.
The joint action represents the kind of international cooperation that’s become more common when dealing with cybercrime groups, particularly those with political ties. Law enforcement agencies have been increasingly working across borders to tackle these networks that operate internationally.
It was visible that on witha.name, after July 18th, 2025, at 01:05, there was a lengthy and unusual gap in the updates of the configurations. As a result, the group’s operations were noticeably disrupted.
I stumbled across this prompt refinement tool. I do not have much experience with it, but it looks interesting to help with building prompts.
A recent change in the SqlServer PowerShell module has given me a headache this week. I’m running the module with Azure DevOps in a pipeline that is triggering an Azure deployment script within a network-integrated container instance.
System.IO.FileNotFoundException: Could not load file or assemblyThe problem this error.
A blog post was today published outlining the risk (CVE-2025-34509) of Sitecore having a default user Sitecore\ServicesAPI and a password of b. The user usually has no default roles, however, it is already one step inside the system.
Probably setting a secure and strong password could be sufficient. I didn’t yet see an official statement from Sitecore yet.
Read all details of the disclosure here: Is b For Backdoor? Pre-Auth RCE Chain In Sitecore Experience Platform
Vulnerable databases are found in 10.1, 10.2, 10.3, and 10.4. 9.3 and 10.0 did not yet have this password for the user as per the setup script analysis. labs.watchtower.com
Recently I saw intermittent failures of a Python script. However, in my Azure DevOps pipeline, I don’t really knowingly use Python. After today, it just kept consistently failing, which led me to research this issue with the Azure CLI.
/opt/az/lib/python3.12/site-packages/azure/multiapi/storagev2/fileshare/__init__.py:1: UserWarning:
pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html.
The pkg_resources package is slated for removal as early as 2025-11-30.
Refrain from using this package or pin to Setuptools<81.
I ran into this issue, and after not too long searching, I could already find an open case on GitHub. The root cause of the issue seems to be the latest Azure CLI 2.74.0, which is no longer working as intended.
I started seeing a new issue on June 10th, 2025 that my Azure App Service staging slot was created with the name “staging”, but it became “stagingd5a1” in the domain name.
So four seemingly random characters were added to my azure app service deployment slot name. This became a problem as my pipeline is running health checks on the deployment. These checks, however, are not run on the assigned name but on the expected name which suddenly was no longer correct. It would be possible to obtain the name and use it, but there are also other issues that can emerge from it. The website might not know what portal to return on a random hostname, CORS errors could occur on an unexpected domain.
Microsoft is generally pushing for more secure, randomly generated hostnames.
However, this is not the feature I ran into in this case.
While I’m aware those models aren’t limited or bound to Ollama, is Ollama still the way I interface and use them? Here I try to keep notes on how I use certain models and what I like or dislike about them.