Beyond Security

1. Beyond Security Presentation on Noam Rathaus CTO Sunday, July 11, 2004

2. Paradigm • A perfectly secure system does not permit any external connections to itSuch a computer, though protected, is impractical: • Nobody can connect, regardless of their trust level • This essentially describes a computer that is not networked • These systems are not a lot of fun...

3. Extension to Paradigm • Trusted user sees “a live host” • Permits connections from user to server • Untrusted user sees “a dead host” • Connections to server are blocked How do we discriminate between trusted and untrusted users? Today this is done by Firewalls/VPN's

4. Limitations • Firewalls authorize access by IP address. Problems: • Dynamic addresses • Roaming users • VPN's authorize by authentication. Problems: • Needs complicated software (VPN client) • VPN is per-network and not per-service Port knocking to the rescue!

5. Introduction 1/4 • This illustration shows a server which is running four services and which has no Firewall • All ports are open • Remote computers will successfully connect to four ports: ftp/21, smtp/25, http/80 and pop/110

6. Introduction 2/4 • Firewalled Server listens on port ssh/22 • Connections to the server are seamlessly blocked to all users • However, once a user completes a port knocking sequence, connections are allowed

7. Introduction 3/4 • Port knocking is a method of establishing a connection to a networked computer that has no open ports • Before a connection is established, ports are opened using a port knock sequence, which is a series of connection attempts to closed ports • A remote host generates and sends an authentic knock sequence in order to manipulate the server's firewall rules to open one or more specific ports

8. Introduction 4/4 • These manipulations are mediated by a port knock daemon, running on the server, which monitors the firewall log file for connection attempts which can be translated into authentic knock sequences • Once the desired ports are opened, the remote host can establish a connection and begin a session. Another knock sequence may used to trigger the closing of the port

9. What is it good for? • Port knocking is best for hosts that provide services to authorized users who require continual access to services and data from any location • Port knocking is not suitable for hosts running public services, such as SMTP or HTTP • Port knocking is used to keep all ports closed to public traffic while flexibly opening and closing ports to traffic from users who have authenticated themselves with a knock sequence

10. What else? • This on-demand IP-based filtering which is triggered by a remote user can offers the advantages of IP-based filtering without the limitation usually associated with maintaining IP rules

11. What isn’t it? • Port knocking cannot be used to protect public services - such protection cannot be effective if the knock sequence, or a method to generate it, is made public

12. Why is it so exciting? • Port knocking is not a listening service – it is not exposed to network attacks • There is no way to detect a port-knocking server (unlike a firewall that can be detected) • The port seems closed – because they are closed! • In security, simple mechanism = less probability for weaknesses

13. Why not just a Firewall? • Firewalls define and limit the communication possible within a network • System administrators tend to be paranoid (good!) and need to enforce limits to help monitoring and troubleshooting • Unless you are very familiar with your operating system, you may not be aware of all the services running on your computer

14. Summarize • Port knocking can be used whenever there is a need to transfer information across closed ports • The port knock daemon can be implemented to respond in any suitable way to an authentic port knock • The knock may be used to communicate the knock information silently and/or to trigger an action. This is a form of IP over closed ports

15. Simple Implementation • The simplest implementation of port knocking uses a log file to interface with the firewall software • This simple approach makes port knocking highly accessible for home users • The protected services do not require any modification • This form of port knocking is relatively easy to set up

16. Best Practice • Port knocking is ideally suitable for remote administration provided by a latent, on-demand SSH service. In other cases port knocking may not be the right answer

17. Some History • cd00r / SAdoor • cd00r.c and SAdoor are working proof-of-concept codes for a not listening remote shell on UN*X systems • A listener in non-promiscuous mode looking for a specific sequence of packets before actually opening any kind of listener. • This sequence can be any kind of IP traffic for obscurity • Used primarily as stealth backdoors

18. What is needed? • knockclient • a port knocking client responsible for sending knocks to remote firewall where a knockdaemon is listening • knockdaemon • a port knocking server responsible for monitoring and responding to incoming knocks generated by knockclient

19. Port Knocking Client “Flavors” • There are port knocking implementations in Perl, C/C++, Java, python and even BASH • The easiest to implement is Python, Perl and BASH • The implementation use the logs generated by IPTABLES to discover when someone knocked on the Firewall in the right way

20. What’s next? 1/3 • Suppose you have a networked system and you need to connect using ssh • To close all other ports, use: ipchains -p tcp -s 0/0 -d FIREWALL/32 -p 0:1023 -j DENY -l ipchains -p tcp -s 0/0 -d FIREWALL/32 -p 1024:49151 -j DENY • Each connection attempt will be logged: Feb 12 00:13:26 ... input DENY ... CLIENT:64137 FIREWALL:102 ... Feb 12 00:13:27 ... input DENY ... CLIENT:64138 FIREWALL:100 ... Feb 12 00:13:27 ... input DENY ... CLIENT:64139 FIREWALL:100 ... Feb 12 00:13:28 ... input DENY ... CLIENT:64140 FIREWALL:103 ...

21. What’s next? 2/3 • A daemon monitoring the log file can detect these connection attempts to ports 102, 100, 100, 103 from the same IP address • This particular port sequence could trigger the daemon to open port ssh/22 • The daemon would execute the following command ipchains -I input -p tcp -s CLIENT/32 -d FIREWALL/32 22 -j ACCEPT

22. What’s next 3/3 • Another sequence can be used to close the port • For example, 103, 100, 100, 102 could be used to trigger the deletion of the rule that was dynamically created to allow CLIENT to connect ipchains -D input -p tcp -s CLIENT/32 -d FIREWALL/32 22 -j ACCEPT • In this example, a remote user has opened port ssh/22 to IP address CLIENT by making TCP connections to ports 102, 100, 100, 103 and subsequently closed the ssh/22 port to their IP by knocking on ports 103, 100, 100, 102

23. Enhancements • Encrypted Port Knocks • The 4-port knocks in the previous example provided limited protection against packet sniffing, since the knock was independent of the connecting IP address • Anyone on the network looking at packets could reconstruct the sequence and use it to gain access to the ssh/22 port • In order to reduce the risk of the knock being deconstructed and gainfully executed by a third-party, it should contain the client IP address and be encrypted

24. noamr@beyondsecurity.com Questions?