Virtual Private Network and Security
Michael Tsai
2015/05/15
But, first, a bit about
Transport Layer + Port No.
Multiplexing & Demultiplexing
Transport Layer FTP
Network & Lower Layers
Pkt Pkt
Pkt Pkt Pkt
Pkt Pkt
海一樣的封包. 有進有出.
個是誰的?
Firefox"
(HTTP) LINE Skype
Your Network Device
Transport Layer
Network & Lower Layers
Web Server Web Server
(Apache) Socket:
port 80
Socket: port 37981
Well-Known Port Number
Service/
Application Port Number Service/
Application Port Number FTP 20 (data) /
21 (command) HTTP 80 / 8080
SSH 22 HTTPS 443
Telnet 23 POP3 (mail client
-> server) 110 SMTP (mail
server->server) 25 IMAP (mail client
-> server) 143
DNS 53 NFS 2049
DHCP 67/68 PPTP (VPN) 1723
UDP: Connection-less Transport
•
Simplest design
•
Header has only 4 fields:
•
Source and destination port numbers
•
Length
•
Checksum
•
Why do we need checksum for end-to-end connections?
•
Possible: no bottom layer protocol does it
• IP only has header checksum (no data checksum)
• Layer 2 CAN have NO error detection scheme (though most do)
•
Could be caused by relaying hosts (router / switch)
(e.g., memory corruption)
TCP: Reliable Transport
•
Why?
•
IP is not reliable
• Lost packets, errornous packets
• No idea about latency - varying over time
•
Basic ingredients:
•
Error detection: verify checksum
•
ACK or NACK:
notify the other side whether a packet is correctly received
•
Re-transmission: if not, do it again
•
Sequence number: check for missing or redundant packets
•
Time-out: estimate the latency. If not received within a time period, then do it again.
• Need an accurate estimation of round-trip time (RTT). What if it is too short or too long?
TCP: Pipelined Transmissions
Sender Receiver
Transmission time
=L/R
Round Trip Time
Sender Transmission time Receiver
=L/R
Round Trip Time
• 最多可以丟N個”未被ack”的封包進”pipeline”."
• 收到ack代表前面的都收到了
TCP Designs
•
Round-trip Time Estimation
•
EstimatedRTT=0.875 * EstimatedRTT + 0.125 * SampleRTT
•
DevRTT=0.75*DevRTT+0.25* |SampleRTT – EstimatedRTT|
•
TimeoutInterval=EstimatedRTT+4*DevRTT
•
Flow Control
•
Make sure the buffer at the receiver is not filled up (the top layer is too slow)
•
Receiver will provide the information of the remaining size of the buffer receive window
•
Transmitter makes sure that the transmitted data will not
exceed the size of the receive window
TCP Designs
•
Connection Management
•
Establish: SYN (Client initial sequence number) SYN-ACK
ACK
•
End: FINACK
"
•
Congestion Control
•
因為”一次送多個未ack的封包”而造成的網路更塞車
•
封包掉 塞車了 減少傳送速度
•
收到ACK 通順的網路 增加傳送速度
•
Slow start: 從1開始, 緩慢地增加(2x)一次可以傳送未ack封包個數
NAT (Network Address Translation) Revisited
門 : 140.112.91.208
馬撒起 菜瓜布
凱莉
小小郭
內部用: 192.168.0.2
內部用: 192.168.0.3
內部用: 192.168.0.4
內部用: 192.168.0.5
內部用門
:192.168.0.254 Src: 192.168.0.2"
Dest: 8.8.8.8
Src: 140.112.91.208"
Dest: 8.8.8.8 對照表:"
• 菜瓜布有連到8.8.8.8"
• 要找助教請轉到192.168.0.4
Src: 8.8.8.8"
Dest: 140.112.91.208 Src: 8.8.8.8"
Dest: 192.168.0.2
NAT (Network Address Translation) Revisited
eth0 (public IP):
140.112.91.208 馬撒起
菜瓜布
凱莉
小小郭
eth0: 192.168.0.2
eth0: 192.168.0.3
eth0: 192.168.0.4 port 80: listening (httpd)
eth0: 192.168.0.5
eth1 (private IP):
192.168.0.254 Src: 192.168.0.2 port
18442"
Dest: 8.8.8.8 port 53
Src: 140.112.91.208 port 28473"
Dest: 8.8.8.8 port 53 對照表:"
• 菜瓜布有連到8.8.8.8
(192.168.0.2 port 18442 —> 140.112.91.208 port 28473 —> 8.8.8.8 port 53)"
• 要找助教請轉到192.168.0.4
(140.112.91.208 port 80 redirects to 192.168.0.4 port 8080)
Src: 8.8.8.8 port 53 "
Dest: 140.112.91.208 port 28473
Src: 8.8.8.8 53 Dest: 192.168.0.2
18442
Check all the connections
•
netstat:
print network connections, routing tables, and interface statistics
•
Example:
netstat -na --inet
(list connections on all interfaces, using numerical addresses, listing only IP connections)
netstat -s (print the statistics)
netstat -i (list interface statistics)
VPN (Virtual Private Network)
馬撒起 菜瓜布
凱莉
小小郭
門 : 140.112.91.208 內部用: 192.168.0.2
內部用: 192.168.0.3
內部用: 192.168.0.4
內部用: 192.168.0.5
內部用門 : 192.168.0.254
姜姜
內部用: 192.168.0.6 門 : 140.113.x.x
• 透過網路連線,把通往內部的封包都先送到
140.112.91.208,然後再解開轉送到真正的目的地
Src: 192.168.0.6 Dest: 192.168.0.5 Src: 140.113.x.x"
Dest: 140.112.91.208
Src: 192.168.0.6 Dest: 192.168.0.5
Common Types of VPN: IPSec, SSL VPN, PPTP/L2TP
Crypto 101: encryption
• Symmetric algorithms (shared key)
• Both parties have the same shared key, and use the same key for encryption and decryption
• Asymmetric algorithms (public key and private key)
• Each party has a public key and a private key - public key is used for encryption and private key is used for decryption
Encryption ( )
Two basic types of encryption:
• Symmetric (or secret-key) algorithms
• Both parties share the same secret key
• The same key is used for encryption and decryption
• Asymmetric (or public-key) algorithms
• Each party has a public key and a private key
• Public key is used for encryption and private key is used for decryption
16
Encryption ( )
Plaintext ( ) Key ( ) Ciphertext ( )
Hello,
Here is your health
check result
GVfsQanXp Sa88w4A0I FMwnVRIf2 2cTZNamxi Wij0T6HMy
Content from Prof. Hsu-Chun Hsiao’s “Cryptography and Network Security” slides
Symmetric encryption ( )
• Alice wants to send message m to Bob in secret
• Assume a secure channel to first distribute shared key KAB
• Channel: can be Internet, wireless network, phone, etc.
• Secure channel: msgs cannot be overheard or manipulated
• Alice encrypts m using KAB; Bob decrypts c using KAB too
• Alice & Bob keep KAB in secret, so only Alice and Bob know m
10
Encryption ( ) m
KAB
c = EKAB(m) Insecure
channel Decryption ( )
KAB
m = DKAB(c) c
Secure channel
Asymmetric encryption ( )
• Alice wants to send message m to Bob in secret
• Bob has a public/private key pair KB/KB-1
• Assume Alice learns Bob’s public key KB via an authenticated channel
• Authenticated channel: msgs can’t be manipulated but may be overheard
• Alice encrypts m using KB; Bob decrypts c using KB-1
• Bob keeps his own private key KB-1 in secret, so only Bob can decrypt c, and only Alice and Bob know m
11
Encryption ( )
Decryption ( ) m
KB KB-1
m = DKB-1(c)
Insecure c channel
c = EKB(m)
a.k.a. public-key encryption ( )
Authenticated channel
Symmetric encryption
Asymmetric encryption
Properties
• Encryption is reversible with corresponding decryption key
• It is computational infeasible to
• recover ciphertext without knowing the key
• find a private key from its public key
• Longer key provides better security
Computational Infeasible
•
~2^33 devices in the world
•
~2^30 symmetric cryptographic operations per device per second
•
~2^25 seconds per year
•
~2^128 operations to brute force AES-128 encryption
•
(128-25-30-33=40)
~2^40 years to brute force AES-128 encryption
•
~2^33 years since the beginning of the universe XD
Comparison
Symmetric Asymmetric
Secret key is only known to the communicating parties
Public key is known to everyone Private key only known to owner For secure comm., key should be
secret and authentic
For secure comm., private key is secret and public key is authentic
112 bit key for high security (2015) 2048 bit key (RSA) for high security (2015)
~1,000,000 ops/s on 1 GHz CPU
~100 signatures/s,
~1000 verifies/s (RSA) on 1 GHz
CPU
TLS & SSL
•
Nescape’s Secure Sockets Layer (SSL) 2.0 —> 3.0 (proprietary)
—> Transport Layer Security (TLS) 1.0 (non proprietary) by IETF as an effort to secure HTTP
•
Sitting on top of TCP (there are versions to work with UDP too)
•
Provide:
• Encryption: (you already know)
• Authentication:
Verify you are really who you claim to be
• Integrity:
Detect message tampering (modification) and forgery (entire thing is put together by the attacker)
•
Most “secure protocols” work similarly
Common Workflow
• Verify each other’s public key (man-in-the-middle attack)
• Certificate (signed by a trusted third party)
• Check against a database
(e.g., SSH’s ~/.ssh/known_hosts)
• DNS (example: SSHFP)
• Use public-private key to establish a shared key
SSH
• SSH: the secure shell
• As secure replacement for rlogin, rcp, and telnet
• Crypto is used to confirm a user’s identity / encrypt all communications
• Can use public crypto to establish the user’s identity
• Can use personal password to establish the user’s
identity (vulnerable to brute-force / dictionary attack)
SSH
• SCP/SFTP: securely copy/transfer files from remote hosts
• Example:
scp hsinmu@linux1.csie.ntu.edu.tw:~/tmp/* ./
Poor man’s VPN: SSH tunnel
ptg
SSH: the secure shell 929
Security
also pass -o "VerifyHostKeyDNS yes" on the ssh command line when first ac- cessing a new system.
SSH has a couple of ancillary functions that are useful for system administrators.
One of these is the ability to tunnel TCP connections securely through an en-
crypted SSH channel, thereby allowing connectivity to insecure or firewalled ser- vices at remote sites. This functionality is ubiquitous among SSH clients and is simple to configure. Exhibit A shows a typical use of an SSH tunnel and should help clarify how it works.
Exhibit A An SSH tunnel for RDP
In this scenario, a remote user wants to establish an RDP (remote desktop) con- nection to a Windows system on the enterprise network. Access to that host or to port 3389 is blocked by the firewall, but since the user has SSH access, he can
route his connection through the SSH server.
To set this up, the user logs in to the remote SSH server with ssh. On the ssh
command line, he specifies an arbitrary (but specific; in this case, 9989) local port that ssh should forward through the secure tunnel to the remote Windows ma- chine’s port 3389. (For the standard OpenSSH implementation, the option to re- quest this behavior is simply -L localport:remotehost:remoteport.) All source ports in this example are marked as random since programs choose an arbitrary port from which they initiate connections.
To access the Windows machine’s desktop, the user then opens the remote desk- top client (here, rdesktop) and enters localhost:9989 as the address of the server to connect to. The local ssh receives the connection on port 9989 and tunnels the traffic over the existing connection to the remote sshd. In turn, sshd forwards the connection to the Windows host.
Of course, tunnels such as these can be intentional or unintentional back doors as well. System administrators should use tunnels with caution and should also
watch for unauthorized misuse of this facility by users.
FIREWALL
External system
ssh rdesktop
random port
random port
port 9989
port 22
port 3389 random port
SSH server
sshd
Windows system
RDP server
Enterprise Internet side
side
VPN’s downsides
• VPN: only a secure tunnel between endpoints
• Nothing about the security of the endpoints
• Example:
give access to VPN users to your “private network”
• VPN connections should probably be given less
privileges (treat them as external users)
Today’s In-Class Homework
•
2選1:•
Connect to CSIE VPN from your Ubuntu VM https://esystem.csie.ntu.edu.tw/nalab/vpn (no instruction for Linux yet! Try it yourself!)•
Use SSH Tunnel to create a tunnel from your machine’s 10080 to linux[1-10] (and then to www.csie.ntu.edu.tw’s 80 port)—> Use your browser to test it (http://localhost:10080)