FAQ.
SRATOR addresses many security concerns. When used under the right conditions and with appropriate adherence to security behavior, it can be a powerful and secure tool.
|
How Does It Work?
TOR, or the "onion network" protects both the device being managed by making it hard to find, and the management site by anonymizing the source of the management session. Accessing remote server or device with SSH over TOR hidden service, the 16-character (alphanumeric) ".onion" address is hard to guess. If you protect the hidden service address, attackers have a hard time finding it. If they can't find it, they can't hack it. The device is location and network agnostic.
Only Configured Services Are Accessible
Full function operating systems have many default services running (for convenience) that are available unless they are specifically disabled. The TOR hidden services are defined one at a time, on a specific port, and all other services running on the device are not reachable via TOR.
What Software Is Used?
TOR hidden services provide anonymized location and network independence.
See item below "What Do I Need To Access The Remote Site?" Secure Shell (SSH) protocol version 2 is the command line shell software. It is mature and supports port forwarding among other features. 2 Factor Authentication (or MFA - multifactor authentication) can be supported with DUO security. What Hardware Do I Need?
If your remote device is a server already running Linux, you can probably just run it from that platform. If your remote server is a cloud server, you can also run the software: install TOR, configure the hidden service, set up the level of authentication you want/need. You're in! The remote gateway could be an inexpensive Raspberry Pi.
No Inbound Ports Needed
Because the hidden service is accessed through TOR, the access from a remote site to public internet does not have to allow any "inbound" access on the conventional IPv4 or IPv6 network connections. Only outbound access to the onion network is needed.
All Communications Encrypted
SSH (secure shell) Protocol Version 2 is a mature, well understood, thoroughly tested. Any access to other protocols will be encrypted; for example web page access will be encrypted with HTTPS and a self-signed server certificate.
Use Cases
Use Case 1: Remote access to your home or small business desktop, use RDP tunneled through SSH (port forwarding).
Use Case 2: Secure administrative access (command line or web GUI) to high-value IoT (Internet of Things) platforms, say automobiles or expensive medical equipment. What Do I Need To Access The Remote Site?
Operating System Ideally start with a standard Linux installation. I recommend VirtualBox (from Oracle, it's free), with a supported version of Ubuntu or similar operating system.
TOR The onion router software can be installed on Debian or Ubuntu with the command " sudo apt install tor ". Observe status of your connection with " sudo /etc/init.d/tor status ". torsocks A command line TOR "wrapper" that will "torify" your application; for example " torsocks ssh -2 [email protected]:22122 ". Install by " sudo apt install torsocks " (only makes sense after installing tor). arm A command line TOR traffic monitoring application, to see the bytes sent to and from your connection to TOR. Install using " sudo apt install tor-arm ". What Are Some Considerations?
1. If you use the port forwarding mechanism recommended here under SSH (Secure Shell), only TCP ports will be forwarded. So none of these will work: SNMP, ICMP Ping and Traceroute, or other non-TCP protocols.
2. If you are attacked (someone leaked your ".onion" address), you cannot determine where the attacker is coming from. This is already an issue on conventional network access. It is, however, relatively straightforward to create a new hidden service ".onion" address. 3. Stakeholders must "get comfortable" with the idea of using TOR as a valid business tool; sometimes it is difficult to think of the "dark web" as a legitimate business platform. https://torproject.org describes many legal and legitimate use cases for TOR. How Does SRATOR Work With Zero Trust Networks?Zero Trust Networks approaches security and connectivity by enforcing a secure control plane that enforces encrypted connections. Read the first chapter of the book for free. The idea of remote access to a secure gateway under a high level control plane is entirely aligned with SRATOR's implementation.
Conventional Security Perimeters (the old way)
|
Can Enterprise Security Use This For Device Management And Block General User Access To TOR?
Some company policies might prefer not allowing everyone in their network to have unrestricted access to TOR. This can be enforced by restricting authorized accounts on a jumpserver in a firewalled DMZ. That jumpserver can utilize an internal TOR bridge to access the TOR relays. The enterprise can monitor and filter traffic through the internal TOR bridge for audit compliance (who did what when and where did they go).
What Is Your Support Model?
All of the capabilities in a SRATOR implementation are possible with open source and free software. Depending on your degree of technical experience you can roll your own installation, or purchase a fully configured and working setup, and SRATOR will support it, troubleshoot and fix any problems, perform ongoing upgrades and (security) patching. Or, ideally an in-person hands-on session where you learn what to do to create your own SRATOR from scratch, basically teaches you how to fish for yourself. All combinations are open and available. SRATOR is one component of the "Zero Trust Network" idea described elsewhere in the FAQ: a secure "Control Plane" is necessary to consolidate "who has what access to which devices" at a group/team, department, or enterprise (company wide) level.
Temporary Vendor Support
Temporary vendor or consultant access can be configured through a hidden service at a different port. If a vNF or vServer in a virtualized environment can configure its own TOR access and shut down after the need is over. The real "production *.onion" service can also be replaced at any time with a new hidden service address.
What About UDP Protocols?
Many currently used "management" tools rely on SNMPv2c (simple network management protocol version 2c), which have two problems: 1) it is unencrypted, and 2) it runs on UDP. SRATOR with port forwarding protects the contents of the SNMP transmission, and can be switched to TCP so it can be port forwarded over the initial SSH connection. Tools do have to be reconfigured to use both port forwarding and change to TCP, but the change appears to have no specific technical roadblocks to getting it done. SYSLOG, TACACS, and many protocols that typically run over UDP, can be configured to run over TCP. Note: actually, it SNMP and other legacy management tools can be replaced with alternate approach; for example, using SDN control plane approach to separate "reporting" vs "admin" functions, would give everyone a chance to retire a 30-year-old legacy technology.
Can I Do This Myself?Absolutely ! If you do and learn something, let me know so we can all benefit from your experience. Detailed instructions for one way to do this are being prepared.
Resolving The "Sniper" Problem
One of the key issues that make security professionals indigestion is what I will refer to below as the "sniper problem". Basically it is, if A can see B in their sights, B can also shoot back at A along the same "line of sight". In network terms, if an internal system (with an internal IP address) has a routed network connection to an external device (on an external IP address), the external device also has a path back to the internal device: the internal IP address is known to the external site and every router through which that traffic passes. Administrators of private corporate networks typically prohibit such access because it reveals the internal IP address and potentially internal network structure /design, unless high capacity, high speed proxy servers hide the internal addresses.
An expensive way to resolve the sniper problem is to never allow the "inside" (secure, private) network to access the "outside" (untrusted, public internet) network other than through a DMZ. All network connections either start or stop in the DMZ, so only DMZ addresses protected by firewalls, IDS/IPS, and other security mechanisms ever exit to the public networks. SRATOR can address this because TOR anonymizes the IP address and location of both the source (user) and destination (device under management). When an administrator initiates a "TORified" SSH session to the hidden service at the managed device, neither of the conventional IPv4 addresses of the endpoints are revealed; in fact every new session randomizes these IPv4 addresses. There is no way the bullet can find its way back from B to A through TOR. ? How can Quantum computingA. This is the most important tech contest since the space race, and America is losing
https://wapo.st/2Iea47K If your resource is not visible it's harder for an attacker to break in to your system. ?A.
|