I’ve been deploying and maintaining Suricata on Windows environments, and I wanted to log an issue regarding cross-platform compatibility with suricata-update.
While suricata-update is an exceptional utility for Linux and POSIX-compliant systems, running it natively on Windows consistently triggers file-locking exceptions (specifically [Errno 13] Permission denied during temporary file operations and archive extraction/moving phases).
The Root Cause
Unlike Unix-based operating systems—which allow files and directories to be moved or deleted while an open handle exists—Windows NT enforces strict exclusive file and directory locking. When Python’s tempfile module or internal file-copy routines in suricata-update attempt to manipulate the downloaded tarball or extraction directories before handles are fully released, Windows blocks the operation outright.
Impact on Windows Users
Because of this behavior, Windows administrators are forced to build custom native PowerShell wrappers (using utilities like tar.exe to bypass Python file locking entirely) just to automate baseline rule updates.
Suggested Improvements / Feature Request
Windows-Native Handle Management: Implement explicit handle closing and robust exception handling (or retry loops with backoff) around temporary directory operations for Windows environments.
Alternative Extraction Path: Provide a fallback mechanism on Windows that utilizes native OS utilities (tar.exe or Expand-Archive) rather than relying purely on Python’s strict file-system wrappers.
Official Windows Guidance: Expand documentation regarding Windows file-locking quirks or officially acknowledge the limitation so users aren’t left troubleshooting upstream Python exceptions.
Thank you for your continued work on Suricata and for making such a powerful IDS accessible across platforms. Any improvements to native Windows rule management would be immensely appreciated by the community!
This issue appears to have been unaddressed by the development team for years. It seems both Suricata and Snort are gradually losing traction for general end users. While Snort was booming 15 years ago and Suricata generated similar excitement when it launched, community interest in both has dropped significantly. Having worked in this space since 2003, it feels like open-source NIDS/NIPS development is coming to an end for everyday users, outside of specialized enterprise environments.
One of the reasons why Suricata-Update is not well supported on Windows is that it is written in Python, there are a variety of Python distributions for Windows, and there is a lack of Windows expertise on this team. We track some issues here: https://redmine.openinfosecfoundation.org/issues/3965.
To your general concern, I somewhat agree - at least with hobbyist users. Fewer people seem to be setting up Linux or BSD firewalls, routers, IDS systems than 10 or 20 years ago, opting instead for OPNsense, or Ubiquiti gear.
It gets frustrating at times, especially since running this project has become purely a hobby for me now. Years ago, I sold pre-built console packages targeting environments that required a Windows-only architecture, and they did quite well. But getting Windows-focused support has always felt like pulling teeth—even with the Snort team, where getting simple upgrades took forever and a 64-bit build took years. While they’ve claimed Snort 3.x is being ported to Windows, after several years with no progress, it seems unlikely at this point.
On the Suricata side, running suricata-update directly alongside the installation works fine, but trying to bundle or migrate that into a standalone update utility on Windows has proven futile. It’s the same core issue that has plagued Windows builds for years. While I do have a working utility that can download and update the ruleset, its major limitation is that it enables every single rule across the board.
I haven’t had a chance to explore PulledPork for Suricata yet, as free time is scarce. I definitely appreciate your perspective on the Python distribution challenges on Windows—and it’s encouraging to hear about your Rust project for first-class Windows rule management! You’re also spot-on about the shift toward appliance OSs like OPNsense and Ubiquiti; fewer folks are building custom bare-metal setups these days, which makes maintaining native Windows IDS packages feel like a niche endeavor.