kali-anonstealth: ParrotSec's RAM wipe and TOR routing, packaged for Kali

Two tools in one package, and why they are grouped

kali-anonstealth is a port of ParrotSec's stealth and anonsurf modules to Kali Linux, and the README explains the arrangement in one line: this repo contains the sources of both the anonsurf and pandora packages from ParrotSec combined into one.

The two do completely different things, and grouping them is about lifecycle rather than about function.

Pandora overwrites the RAM when the system is shutting down, and it can also be run manually:

pandora bomb

The README is direct about what that means. This will clear the entire system cache, including active SSH tunnels or sessions. So pandora is a memory hygiene tool, aimed at the case where a machine has handled sensitive material and the RAM contents should not survive a reboot.

Anonsurf is the traffic side. It will anonymize the entire system under TOR using IPTables, and it will also allow you to start and stop i2p as well. So anonsurf rewrites the system firewall so all outbound traffic goes through the TOR daemon, and it can bring up an i2p router alongside.

The grouping makes sense in use. A paranoid workflow on a live system is: enable anonsurf to route everything through TOR while you work, then run pandora before you shut the machine down so the RAM does not retain what you did. Both are about leaving no trace, and both are operations on the whole system rather than on one application.

The primary language is Shell, the licence is GPL-3.0, and the repository is not archived with the last push on 2026-06-16. The recent releases are v1.4.0.0 on 2026-06-16, v1.3.0.0 on 2025-02-17 and v1.2.7.0 on 2025-01-14, and the version naming with four components follows the Kali package convention.

The anonsurf command set, and the warning about how to run it

The usage block is the reference for what the tool does, and the commands divide into two groups.

Usage:
 anonsurf {start|stop|restart|change|status}

 start - Start system-wide anonymous
          tunneling under TOR proxy through iptables
 stop - Reset original iptables settings
          and return to clear navigation
 restart - Combines "stop" and "start" options
 change - Changes identity restarting TOR 
 status - Check if AnonSurf is working properly
----[ I2P related features ]----
 starti2p - Start i2p services
 stopi2p - Stop i2p services

The stop command is worth reading carefully, because it tells you how the tool works. Stopping resets the original iptables settings and returns to clear navigation. So anonsurf is not a proxy setting in a browser or an application configuration, it is a rewrite of the system firewall rules, and stopping means restoring what was there before. That also explains why the tool is all system wide, since the rules it writes are not scoped to a process.

The change command is the one that does something the others do not. Changes identity by restarting TOR, which is the operation you want when a single exit node is not enough and you want a new circuit or a new IP without tearing down your connections.

And then the note that is the most operationally important line in the README. DO NOT run this as service anonsurf $COMMAND. Run this as anonsurf $COMMAND.

That is a specific failure mode. The start and stop operations manipulate the system firewall, and running them through the service wrapper means the script is not running in the environment it expects, which for a script that saves and restores iptables state can mean the restore does not happen and the machine is left with a broken network configuration. The README says it plainly and it is the kind of instruction worth following exactly rather than approximately.

The status command checks if AnonSurf is working properly, which given the firewall rewriting is the command you want before and after any change, and the i2p commands are separate from the main set, so starti2p and stopi2p are their own lifecycle rather than part of start and stop.

What the port actually changed, and the platform caveat

The modifications made in the port are listed explicitly, and they are the part of the README that tells you this is not a straight copy.

Modifications have been made to use the DNS servers of Private Internet Access, instead of FrozenDNS, and fixes for users who don't use the resolvconf application. Some functionality has been removed, such as the gui and iceweasel in ram.

Each of those three changes solves a different problem.

The DNS change is the one that matters most for a system level anonymisation tool. The original pointed at a DNS resolver that was part of the ParrotSec arrangement, and PIA resolvers are used instead, which means the tool does not depend on an external service that the user may not have. For a tool whose whole job is to control name resolution so that traffic does not leak a destination query to the local resolver, the choice of resolver is part of the security property rather than a convenience.

The resolvconf fix is about the other side of the same problem. resolvconf is the Debian and Ubuntu mechanism for managing the nameserver configuration, and a tool that rewrites DNS settings has to integrate with it or work around it. A system without resolvconf is common enough that the workaround is worth having, and the phrase in the README that this has been fixed for users who don't use the resolvconf application suggests the failure mode was a broken resolver configuration after anonsurf ran.

The removals are about trimming the surface. The gui component and iceweasel in ram were ParrotSec features that do not apply in the same form on Kali, and the port drops them rather than carrying them half working.

The platform caveat is stated in a note and it is precise. This may work with any debian/ubuntu system, but this has only been tested to work on a kali-rolling amd64 system.

So the honest scope is: a Kali rolling system on amd64, with the author's statement that it is likely to work elsewhere. The combination of kali-rolling and amd64 matters, because rolling means the underlying Debian base changes under you, and a tool that edits iptables and DNS configuration is sensitive to that in a way that an ordinary application is not.

The installer reflects that this is a packaged thing rather than a set of scripts to copy. The README says this repo can be compiled into a deb package to correctly install it on a Kali system, and the easiest way to get this working is to just run the installer.

Why the RAM wipe and the firewall rewrite belong in the same package

Putting pandora and anonsurf together is not a packaging convenience, and understanding why makes the tool easier to use correctly.

The two operations address different leak paths, and they are complementary rather than alternatives.

Anonsurf is about what leaves the machine while it is running. It rewrites the system firewall so outbound traffic goes through TOR, and it can bring up i2p alongside. The exposure it addresses is network level: an application on the machine, or the machine itself, making a connection that identifies you.

Pandora is about what is left behind afterwards. The RAM wipe is aimed at the case where the memory contents survive, and where a cold boot or a swap read would expose what was in there. The README's warning that it clears the entire system cache including active SSH tunnels or sessions is the whole risk in one line, because in an environment where you are connected over SSH to do your work, running the wipe terminates your own connection.

So the intended sequence is the one anonsurf does not automate: enable the anonymised routing, do the work, then wipe the memory before the machine goes down or before it is handed to someone else. A machine used for sensitive work and then returned to a pool of shared machines is the case where both halves matter, and the case where running pandora on a live SSH session is the mistake.

The i2p side of anonsurf is worth a moment too. The starti2p and stopi2p commands are separate from the main start and stop, so the two networks are independent lifecycles. That means you can run the i2p router while the iptables rewriting is not active, or the reverse, and the tool does not force a particular combination.

There is a practical reason the commands are split this way rather than bundled. The start operation is the one that changes the machine's networking, and it is the one that has a matching stop that restores the previous state. Bundling i2p into it would mean the stop operation had to restore two things at once, and the failure mode of a partially restored firewall is a machine that appears to be online but is not routing the way the operator expects.

The installer, the packaging tree, and what the repository actually contains

The installation is one command:

./installer.sh

And once the installer is complete, you will be able to use both the anonsurf and pandora modules. There is no package manager invocation and no configuration step described, so the installer is doing the whole job: fetching the sources, building the .deb and installing it.

The repository listing is very small, and that is itself informative. There are .github/, LICENSE, README.md, installer.sh and a single directory, kali-anonsurf-deb-src/. So the packaging tree is a directory rather than a set of loose scripts, which is what you would expect from a project whose output is a Debian package.

The .github/ directory indicates that there is CI configuration, and the presence of a release script and workflow is consistent with a project that publishes .deb packages rather than with one that expects users to clone and run things. The releases in the repository metadata are named in the Kali convention, kali-anonsurf-1.4.0.0, with a Debian version and a Kali package version, so the package versioning and the upstream ParrotSec versioning are tracked separately.

The licensing is GPL-3.0, which is the right choice for a port of ParrotSec software since the original is copyleft, and the LICENSE file is at the repository root.

There is one practical gap worth naming. The README describes the installer as making things extremely easy, and it may well do exactly that, but it does not say what it actually does: whether it builds from source, downloads a prebuilt .deb, or fetches and compiles the ParrotSec sources it is a port of. For a script that ends up running as root on a machine and modifying firewall rules, knowing that before you run it is reasonable diligence, and the installer.sh file is right there in the repository to read.

The upstream relationship is also worth being clear about. This is not a fork of Kali's own packages and not a from scratch implementation, it is ParrotSec's anonsurf and pandora adapted to Kali's packaging and conventions, with the DNS, resolvconf and trimming changes listed above. Anyone who knows the ParrotSec tools will find the behaviour familiar, and the differences are the three modifications the README enumerates.

Editorial conclusion

kali-anonsurf fits a Kali user who wants the ParrotSec anonymisation workflow on their own machine, and who understands that pandora is destructive and that anonsurf manipulates the system firewall. It is the wrong tool if you need a VPN, since anonsurf is a TOR and i2p transport rather than a commercial VPN, and it is the wrong choice for a production server, because the routing is all system wide and a misfire takes the machine's networking with it. Before installing, read the usage notes carefully, in particular the instruction not to run it as service anonsurf but as anonsurf, and note the caveat that it has only been tested on a kali-rolling amd64 system.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Und3rf10w/kali-anonsurf on GitHub