Block Inbound Traffic from Anonymity Networks
Block connections from anonymous networks to keep the organisation's network secure.
Plain language
This control is about blocking traffic from networks that let users hide their identity, such as those used for anonymous browsing. If these are not blocked, people with bad intentions could bypass security measures and access sensitive parts of your network, potentially leading to data theft or the spread of malware.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Aug 2023
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for networkingSection
Network design and configurationOfficial control statement
Inbound network connections from anonymity networks are blocked.
Why it matters
If inbound traffic from Tor and other anonymity networks isn’t blocked, attackers can probe and access services while hiding attribution, increasing breach risk.
Operational notes
Maintain deny rules for known Tor exit nodes and similar networks using refreshed threat intel lists, and alert on repeated blocked connection attempts.
Implementation tips
- IT team: Identify anonymity networks that you need to block. Use network monitoring tools to compile a list of known anonymity networks like Tor or I2P that should be restricted.
- IT team: Set up firewall rules to block identified anonymity networks. Adjust your firewall settings so that any traffic coming from these sources is automatically rejected and cannot enter your network.
- System owner: Work with the IT team to understand the implications of blocking anonymity networks. Communicate to staff why these networks are blocked and provide alternative ways to access allowed content if necessary.
- IT team: Regularly update the list of blocked networks. Stay informed about new anonymity networks or changes in existing ones, and update your firewall rules accordingly to ensure ongoing protection.
- Manager: Schedule annual reviews of the blocking strategy with IT and security personnel. Base these reviews on reports of any incidents involving anonymity networks and adjust strategies as needed to enhance security.
Audit / evidence tips
-
Askthe list of blocked anonymity networks: Request the documentation that outlines which networks are restricted from accessing the organisation's systems
Goodis a comprehensive list that is current and includes the last update date
-
Askfirewall configuration documentation: Request to see the current settings on the organisation’s firewall. Look to see if rules match the list of identified anonymity networks. Good evidence would be clear settings that align with the blocked lists and dates of last modification
-
Asknetwork traffic logs: Request samples of recent logs that show blocked traffic attempts
Goodwould be logs showing successful blocking actions with timestamps and network details
-
Askabout staff education records: Request records of staff discussions or training regarding the impact of anonymity network blocking
Goodshows regular staff engagement activities explaining the reasoning behind these controls
-
Askincident reports involving anonymity networks: Request documentation of any security incidents where anonymity networks were involved
Cross-framework mappings
How ISM-1627 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| extension Depends on (1) expand_less | ||
| Annex A 8.9 | ISM-1627 requires inbound network connections from anonymity networks to be blocked | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.