1 / 14

Limitations of Port Knocking

Limitations of Port Knocking. Software Project Presentation Paper Study – Part III Group Member: Liew Jiun Hau (20086034) Lee Shirly (20095815) Ong Ivy (20095040). Agenda. Out-of-Order Delivery Network Address Translation (NAT) Authentication-Connection Association.

lavender
Download Presentation

Limitations of Port Knocking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Limitations of Port Knocking Software Project Presentation Paper Study – Part III Group Member: LiewJiunHau (20086034) Lee Shirly (20095815) Ong Ivy (20095040)

  2. Agenda • Out-of-Order Delivery • Network Address Translation (NAT) • Authentication-Connection Association

  3. Out-of-Order Delivery • Problem • Attackers can perform DoS on a client: • Send one packet per second to a random port of server • Spoofing the client IP as the source IP • Knock sequence broken  authentication fail • Solution • Divide the bits representing port number into data bits and sequence number bits • Server will be able to reorder packets correctly before decoding the knock sequence • Use SPA mechanism – only a single packet is sent

  4. About Network Address Translation • A method to solve the IPv4 address space problem • Internet was growing fast back in late 1990s • There was not enough (public) IP address to be assigned to all hosts • NAT can map a large group of private IP addresses into a single public IP address • Each host will be translated into same public IP address • This slows down the consumption of public IP addresses • However NAT causes some hidden issue for port knocking

  5. NAT – Issues • So what if a port knock client is behind NAT? • Who is actually authorized at the end of the port knocking process? • One client successfully port-knock the server • But everyone with the same public IP now has access • This defeats the purpose of port knocking!

  6. NAT – Issues (cont) • In SPA, IP address information is hashed together with Timestamp, ID and Password • How do a client know about its public IP address? • Can it know in a secure way?

  7. NAT – Possible Solutions • Set up a simple server machine at the boundary of the private network • Client can securely discover its public IP address by querying the boundary server machine • Using some external service • www.whatismyip.com • Use by fwknop (one of the SPA implementation)

  8. NAT – Possible Solutions (cont) • The other alternative will be a three-pass mutual authentication • Originally proposed by RenniedeGraaf, John Aycock and Michael Jacobson Jr • The notations used are as follow • A = Client • B = Server • NX = Nonce of X • PIDX = Public IP of X • MAC = Message Authentication Code (e.g. HMAC-SHA-1) • K = Pre-shared key between client and server • The steps are as follow: • 1: A  B req, NA,MACK(req, NA) • 2: B  A PIDA, NB, MACK(NA, PIDA, PIDB) • 3: A  B MACK (NB, PIDA, PIDB) • This approach is more secure but make port knocking less “stealthy”

  9. NAT – Possible Solutions • We can also add some configurations to further mitigate risk • Set a short timeout • Close the port after timeout • Close the port immediately after a connection is made • This leave only a small window during which the client can connect • This also avoid a problem where adversaries could eavesdrop • They can wait for the port to be opened and try to make connection after the authentic client did • There might still exist a race condition • Adversaries can send request faster than client • So how can we solve this issue?

  10. Authentication-Connection Association • A successfully opened port can still be hijacked by an attacker • Attacker will be able to impersonating the client • This is the unsolved issue in previous slide • To counter this, we can wrap post-authentication connections within an encrypted session • Use a pre-shared key that only known by the client and server • Attacker has no way of crafting valid packets without the key • Invalid packets will be dropped at server side • This however increase the load on server

  11. Authentication-Connection Association (cont) • The other possible solution would be to generate TCP Sequence Numbers (SN) in a randomized & authentication-dependent manner • Server can verify the TCP sequence number based on previous authentication • But this require client to have heightened privileges to manipulate the TCP / IP packet fields • Powerful adversaries who can perform MITM is not affected

  12. Next Presentation • Continue to study and analyze other known problems and their possible solutions/improvements in details • Present and discuss in next session • Questions?

  13. References • Jeanquier S (2006) An Analysis of Port Knocking and Single Packet Authorization. M.Sc. Thesis. Royal Holloway, University of London. Sept 2006. • deGraaf R, Aycock C, and Jacobson M. ‘Improved Port Knocking with Strong Authentication’. ACSAC 2005, pp. 409-418. • Rash M. ‘Single Packet Authorization with Fwknop’. The USENIX Magazine. Feb 2006, Vol. 31, No. 1, pp 63-69. • William Stallings. Cryptography and Network Security: Principles and Practices (3rd Edition). Pearson Education. 2003. • James. F. Kurose, Keith W. Ross. Computer Networking: A Top-Down Approach Featuring the Internet (3rd Edition). Addison Wesley. May 23, 2004.

  14. Thank you

More Related