Overblog Suivre ce blog
Administration Créer mon blog
16 octobre 2013 3 16 /10 /octobre /2013 20:40

We'll be seeing here how to setup a the PPTP Server and Client to use PKI certificates.
See previous part for how-to create certificates.

Some patching is involved, to have PPTP-EAPTLS support. Using non-official binaries brings many security issues. More, bugs and glitches arise all along the way. It is certainly a result of PPTP being slowly deprecated by the Linux community.
For all this reasons, this post is mostly for the sake of the PPTP geeks curiosity, only for fun. This shouldn't be used in a production environment.

This tutorial assumes the PPTP Server and PPTP Client are already set-up, like in this tutorial : Linux PPTP Server and Client with IPv4+IPv6 Support

We'll just be adding EAP-TLS Support here

 

1. Server Patching

We first need to patch the server pppd binary to support EAP-TLS :
We first check our pppd version :
sudo /usr/sbin/pppd --version

We then download the ppp sources and the ppp-eaptls patch :
sudo wget ftp://ftp.samba.org/pub/ppp/ppp-2.4.5.tar.gz
sudo wget http://www.nikhef.nl/~janjust/ppp/ppp-2.4.5-eaptls-mppe-0.997.patch

( make sure you download the version that match your /usr/sbin/pppd --version output )

We get openssl and libssl-dev :

sudo apt-get install openssl

sudo apt-get install libssl-dev


We apply patch and compile :

sudo tar -zxf ppp*.tar.gz

cd ppp*

 

sudo patch -p1 < /home/fjord/ppp-2.4.5-eaptls-mppe-0.997.patch

sudo ./configure

sudo make

sudo make install

sudo make install-etcppp

 

cd pppd

sudo cp pppd /usr/sbin/pppd


Server patching is done !

for other sources and patch versions, see here :

ftp://ftp.samba.org/pub/ppp/
http://www.nikhef.nl/~janjust/ppp/download.html

 

2. Client Patching

We will next need to patch the client pppd binary to support EAP-TLS.

We first need to downgrade libssl, because of a bug.
( See : http://openssl.6102.n7.nabble.com/libssl-1-0-1-breaking-program-td45714.html )
( It seems necessary to downgrade for at least one peer. I tested it downgrading the client )

sudo wget http://ftp.us.debian.org/debian/pool/main/o/openssl/libssl-dev_0.9.8o-4squeeze14_i386.deb instead

sudo wget http://ftp.us.debian.org/debian/pool/main/o/openssl/libssl0.9.8_0.9.8o-4squeeze14_i386.deb

 

sudo apt-get remove libssl-dev

suod apt-get remove libssl-doc

sudo dpkg -i libssl0.9.8_0.9.8o-4squeeze14_i386.deb

sudo dpkg -i libssl-dev_0.9.8o-4squeeze14_i386.deb

 


We then proceed with the same patching procedure :

We first check our pppd version :
sudo /usr/sbin/pppd --version

We then download the ppp sources and the ppp-eaptls patch :
sudo wget ftp://ftp.samba.org/pub/ppp/ppp-2.4.5.tar.gz
sudo wget http://www.nikhef.nl/~janjust/ppp/ppp-2.4.5-eaptls-mppe-0.997.patch

( make sure you download the version that match your /usr/sbin/pppd --version output )

We get openssl and libssl-dev :

sudo apt-get install openssl

sudo apt-get install libssl-dev


We apply patch and compile :

sudo tar -zxf ppp*.tar.gz

cd ppp*

 

sudo patch -p1 < /home/fjord/ppp-2.4.5-eaptls-mppe-0.997.patch

sudo ./configure

sudo make

sudo make install

sudo make install-etcppp

 

cd pppd

sudo cp pppd /usr/sbin/pppd


Server patching is done !

for other sources and patch versions, see here :

ftp://ftp.samba.org/pub/ppp/
http://www.nikhef.nl/~janjust/ppp/download.html

 

3. PPTP Server setup

sudo mkdir /etc/ppp/keys

We copy here the files ca.crt, dh1024.pem, server.crt and server.key :
 

we edit pptpd.conf

sudo leafpad /etc/pptpd.conf
--------------------------------------------------------------------------------------------------
ppp /usr/local/sbin/pppd

option /etc/ppp/options-pptpd-eaptls

localip 10.0.0.1

remoteip 10.0.0.10-20

--------------------------------------------------------------------------------------------------

We create a options-pptp-eaptls file :

sudo cp pptpd-options options-pptpd-eaptls


We edit it to this settings ( most important listed only ) :
--------------------------------------------------------------------------------------------------------
name server
#auth ## not used here, to try
refuse-pap

refuse-chap

refuse-mschap-v2
require-eap
require-mppe-128
ms-dns 208.67.222.222

ms-dns 208.67.220.220

proxyarp


nodefaultroute


#debug

#logfile /tmp/pppd.log

lock


nobsdcomp

--------------------------------------------------------------------------------------------------------

 


We finally edit /etc/ppp/eaptls-server to register the certificates, using [TAB] as a delimiter :
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
*<TAB>server<TAB>-<TAB>/etc/ppp/keys/server.crt<TAB>/etc/ppp/keys/ca.crt<TAB>/etc/ppp/keys/server.key<TAB>*
-------------------------------------------------------------------------------------------------------------------------------------------------------------------


We restart to apply :

sudo service pptpd restart

 

4. PPTP Client setup

We create the keys directory :
sudo mkdir /etc/ppp/keys

we copy in the needed client keys : client_kevin.crt, client_kevin.key and ca.crt in

sudo cp ca.crt /etc/ppp/keys/

sudo cp client_kevin.crt /etc/ppp/keys/
sudo cp client_kevin.key /etc/ppp/keys/


We create a options-pptp-eaptls file :

sudo cp options.pptp options-pptp-eaptls


We edit it to this settings :
----------------------------------------------------------------------------------------------------------------------------------------

name client_john                                   ## the CN= part of the client certificate

remotename server                               ## the CN= part of the server certificate

 

# Lock the port

lock

 

# Authentication

# We don't need the tunnel server to authenticate itself

noauth

 

#ipcp-accept-local

#ipcp-accept-remote

#noipdefault

nobsdcomp

nodeflate

#nopredictor1

#nopcomp

#noaccomp

 

refuse-pap

refuse-chap

refuse-mschap

refuse-mschap-v2

 

require-mppe-128

need-peer-eap # the server must authenticate using eap

 

#password 1234 # if private key is password encrypted. doesn't work yet

 

debug

logfile /tmp/pppd.log

----------------------------------------------------------------------------------------------------------------------------------------------

 

We edit a /etc/ppp/eaptls-client file to register the certificates, using [TAB] as a delimiter :
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
*<TAB>server<TAB>/etc/ppp/keys/client_kevin.crt<TAB>-<TAB>/etc/ppp/keya/ca.crt<TAB>/etc/ppp/keys/client_kevin.key


We finally create or edit a peer file :
sudo leafpad /etc/ppp/peers/MYVPN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
pty "pptp 192.168.0.40 --nolaunchpppd"

file /etc/ppp/options-pptp-eaptls

name client_kevin
remotename server

#require-mppe-128

#require-mschap-v2

usepeerdns

noauth

ipparam MYVPN

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

 


5. PPTP Connection

The Network-manager GUI seems broken with PPTP EAP-TLS, I never managed to make it work.
Using the command line, the usual commands do work :

tunnel up :
sudo pon MYVPN

tunnel down :
sudo poff MYVPN

debug launch :
sudo pon MYVPN debug dump logfd 2 nodetach


6. Password protected keys

Although it is theorically very simple, only requiring to add 'password 1234' to the file /etc/ppp/options-pptp-eaptls, the debug list shows the password as being noticed in the debug log, but the EAP authentication fails in the end :
Adding 'password 1234' to the file /etc/ppp/peer/MYVPN shows the same result.


Trying using the GUI network-manager doesn't help either.

Maybe downgrading libssl-dev brought this issue. Downgrading the server library too may solve this.
The only small protection possible is to chmod +600 the key files ( only the owner can read or write ).

 

Repost 0
Published by computer outlines - dans VPN PPTP
commenter cet article
14 octobre 2013 1 14 /10 /octobre /2013 21:08

We'll be seeing here how to setup a Public Key Infrastructure, using Debian, with some explanations about the different terms and options used.


1. PKI quick reminder
We'll be creating :

a master Certificate Authority (CA) certificate and private key,
a certificate and private key pair for the Server and each Client.

It is good practice to generate a distinct client key per user, and name them as to identify the user or computer it will be installed in, in case of leave or loss.
Extra care should be taken while transfering private keys : encrypted channel, or USB drive.

Note : certificate are also named public keys.

 

2. Easy-RSA tools install

sudo apt-get install openvpn
sudo mkdir vpn
cd vpn
sudo cp -a /usr/share/doc/openvpn/examples/easy-rsa/2.0/* .


3. Variables setup

We'll setup the variables accordingly to our situation
sudo leafpad vars

here are the most important fields explained :

export KEY_SIZE=1024                                        Key strength, use 2048 for extra-strength

export KEY_COUNTRY="US"                               Organization Location : Country

export KEY_PROVINCE="VA"                                                                    Region
export KEY_CITY="Norfolk"                                                                       City

export KEY_ORG="FunStudios"                                            Organization Name
export KEY_EMAIL="contact@FunStudios.org"                     Organization contact email

export KEY_OU="Creation"                                                    OU ( ie department )

 


4. Keys Creation

sudo -i
. ./vars
./clean-all
./build-ca

[ ENTER ] will leave the default settings entered in vars. The only exception will be the CN :
Check you're using a unique CN.
If default is used, 'FunStudios CA' is proposed

./build-key-server server

( no challenge password )

[ ENTER ] will leave the default settings entered in vars.
CN : if default is used, 'server' is proposed

No options / two 'Yes' answer for confirmations

./build-key client_kevin
[ ENTER ] will leave the default settings entered in vars.
CN : if default is used, 'client_kevin' is proposed

No options / two 'Yes' answer for confirmations

( no challenge password )
(./build-key client_john )

[ ENTER ] will leave the default settings entered in vars.
CN : if default is used, 'client_john' is proposed

No options / two 'Yes' answer for confirmations


We generate the Diffie Hellman parameters
./build-dh ( nb : dot/build-dh
( creates the dh1024.pem file )

 

Once again, do note that all your CNs have to be differents


Some Explainations

The Challenge password:
The Challenge password is used internally, for various uses : key revocation, …. It is not to be confused with an encrypted key passphrase, which protects the key, and is needed at each key usage by a software to unlock the key.

To create passphrase encrypted keys :
To create passphrase encrypted keys , we use ./build-key-pass client_kevin
( instead of ./build-key client_kevin )

To create Windows-friendly keys :
To create Windows-friendly keys ( PKCS #12 format), we use :
./build-key-pkcs12 client_kevin
( instead of ./build-key client_kevin )


5. Keys management and Usage

the keys are in the /keys subfolder. There are :

for the server :

ca.crt Root                                      CA certificate
server.key                                       Server Key
server.crt                                        Server Certificate
dh1024.pem                                   Diffie Hellman parameters

for the clients :

ca.crt Root                                        CA certificate
client_kevin.crt                                 client_kevin certificate
client_kevin.key                                client_kevin key
client_john.crt                                   client_john certificate
client_john.key                                  client_john key


Let's sum up the different keys, their role, and their secrecy requirements :

 

VPN 12 : Setting up a Debian Public Key Infrastructure

Source : copied from chart on openvpn.net

 

Other files found in the /key subfolder :
server.csr, client_kevin.csr, client_john.csr
They are Certificate Signing Request files


Only .key files should be kept confidential, .csr and .crt files can be sent over insecure channels ( unencrypted ).
Normally, each computer will have its own certificate/key pair.

Source : openvpn.net


6. Adding clients later

. ./vars

./build-key-pass client_tom


( we don't clean the directory with ./clean-all ).
( ./build-key-pass allows to create a password-protected key )

 

Repost 0
Published by computer outlines - dans VPN PPTP OPENVPN
commenter cet article
12 octobre 2013 6 12 /10 /octobre /2013 22:25

We'll see here how to upgrade a SSH server security by using Public-Keys.

Raspbian and Debian OS are used here. Ubuntu will function the same too.

 

VPN 11 : SSH with Public-Key Authentication

SSH Server OS : Raspbian June 2014

SSH Client OS : Debian 7.5

 

Last edited July 28 2014

 

1. Security benefits of SSH with Public-keys Authentication

Beside the basic features of SSH ( Encryption, Communication Integrity Protection), using SSH with Public-Keys authentication brings many extra security benefits :

. Extra-strong key you don't have to re-enter each time

. Impossible to brute-force key because of the keylength ( 1024, 2048, ... bits )

. Better Man in the Middle protection.

. Possibility to disable password-authentication making most automated attacks useless

. Password protection ( a compromised ssh Server can't steal your certificate )

. Policy enforcement ( Perfect control of user password policy )

. Certificate revocation possibility

 

note on MITM protection : While password-based authentication is providing a MITM protection by verifying the SSH Server public-key, the Public-keys Authentication method is better designed, making MITM attacks almost impracticable and impossible ( IF you accept a wrong Server Public-Key, the attacker may do some damages still, even with Public-Keys Authentication ).

 

2. SSH with Public-keys Authentication setup


On the Client :

ssh-keygen
[Enter] = default location = /home/[user]/.ssh/
[Enter] = no passphrase
[Enter]

Your identification has been saved in /home/[user]/.ssh/id_rsa.
Your public key has been saved in /home/[user]/.ssh/id_rsa.pub.

On the Server :

mkdir /home/[user]/.ssh
cd .ssh

We copy the public key here. Ex, using scp on the client :
scp id_rsa.pub [user]@[ip]:/home/[user]/.ssh


On the Server, we add the key to authorized_keys :

cat id_rsa.pub >> authorized_keys


Next login will be automatic

 

3. SSH with Public-Keys Authentication Enhanced security

Two extra steps are needed to enhance the security level

. Protecting the private key

. Disabling password login and root login

 

Protecting the private key


During the key creation, we can choose a passphrase. It is a good security practice, as it prevents the key from being lost/stolen.

we finally make the private key only accessable by the owner : chmod 600

Notes on adding a passphrase :
It strengthens the key, as a key may get compromised.
It is distinct from the regular ssh login password

By default, after 3 failed logins, a regular user/password login is still possible, unless password login is disabled.

 

disabling password login :
we disable it on the server :
sudo nano /etc/ssh/sshd_config

----------------------------------------------------

ChallengeResponseAuthentication no
PasswordAuthentication no
usePAM no

----------------------------------------------------

nb : there should still be :

------------------------------------------------------
RSAAuthentication yes
PublickeyAuthentication yes

-------------------------------------------------------

disabling root login :

we disable it on the server :
sudo nano /etc/ssh/sshd_config

---------------------------------------------------------

PermitRootLogin no

---------------------------------------------------------


4. Using a private port / Fail2Ban

Finally, you may want to consider these extra-measures :

. Setting your router or server listening port to a private port ( TCP 49152-65535 ).

. Using Fail2Ban if using a private port is not possible.

 

5. Adding a Banner that will be displayed before authentication

Adding a banner may be usefull, for information display, or warning / legal displays.

we set it on the server :
sudo nano /etc/ssh/sshd_config

we uncomment this line :

--------------------------------------------------------------

Banner /etc/issue.net

--------------------------------------------------------------

We then edit /etc/issue.net as we wish.

 

Repost 0
Published by computer outlines - dans VPN
commenter cet article
12 octobre 2013 6 12 /10 /octobre /2013 20:46

We'll see here explained simply the essence of Public-key cryptography, and its use for encryption, authentication, certificates and PKIs.

 

VPN technologies requiring a lot of security, one mean to provide it is through the simple, usual passwords. The other way, more evolved and secure, is through certificates. We'll be seeing here the theory and the functioning of Public-key cryptography.

 

Last edited July 27 2014

 

1. Symetric-key encryption

The most basic form of cryptography is symetric cryptography. It is a basic system, where a message is encrypted using a secret key K. Then, the encrypted message can be unencrypted using the same secret key K.
An historical exemple is the Ceasar code, which is a simple letter shift of +n, where n is the key :
message : HELLO                               ------------------> encrypted message = KHOOR
key : +3

The un-encryption is performed using the same key, in a minus way.


The obvious problem of symetric crypto is the key, which has to stay secret at all costs. Historically, 2 seperate messengers where sent by horse on two seperate path : one with the encrypted message, one with the key. So that the the message wouldn't be found with its un-encryption key.
This key exchange / integrity problem is obviously furthermore crutial in an IT context : How to send the secret key on the internet in a safe way ?

Modern symetric keys algorithms are : RC4, 3DES, Twofish, Blowfish, Serpent, AES (Rijndael), CAST5, and IDEA.

Symetric-key encryption is also named secret-key, single-key, shared-key, one-key, and private-key encryption ( the last term leads to ambuguity with assymetric encryption )

 

2. Assymetric-key encryption

Assymetric cryptography slowly emerged through the 20th century. It relies on a particularity of asymetric keys algorithms :
A key pair is generated : Key1 and Key2.
If a message is encrypted with Key1, it can only be unencrypted by Key2.
this message CANNOT be unencrypted by Key1, and Key2 can't be guessed from Key1.

samely :
If a message is encrypted with Key2, it can only be unencrypted by Key1.
this message CANNOT be unencrypted by Key2, and Key1 can't be guessed from Key2.


Modern asymetric keys algorithms are : Diffie–Hellman key exchange protocol, RSA encryption algorithm (PKCS#1), Various elliptic curve techniques.

Assymetric-key encryption is also named public-key cryptography.

 

3. Assymetric-key encryption usages
The main usages of assymetric cryptography are Public-key encryption and Digital signatures ( ie certificates ). Let's see these


1. Public-key encryption
Let's imagine Bob and Alice want to communicate over an open ( ie insecure ) channel, like a WEP Wifi network.
Bob creates an assymetric-encryption keypair. He keeps one of the keys ( the private key ) secret and makes the other key ( the public key ) available to anyone.
Alice gets the public-key, chooses a secret password : abcd , and encrypts the following message with Bob public key :
" I'm Alice. My password is abcd. OK ? "
The message is then sent to Bob over the insecure channel.


Nobody but Bob can decrypt this message, as Bob's secret private key is needed. Now Bob and Alice have securely exchanged a secret key : abcd. The basic problem of key-exchange has been solved.


Now they'll continue the conversation, using symetric-encryption, using abcd as the secret key ( Because Assymetric-encryption is too CPU-intensive and time-consuming to keep on using it past the abcd key exchange )


This is Public-key encryption. An example of use if HTTPS, where Bob is the HTTPS server, and Alice si a Client Browser. Another example is SSH, where Bob is the SSH server and Alice the SSH client.

 

2. Digital signatures
Now let's imagine Bob wants to send a message to Alice, so that Alice can be sure the message really is from Bob ( Authenticity ) and hasn't been altered ( integrity ).

This is how we can do this :

Bob first computes a Hash ( MD5 ) of the message. ( A Hash is like a fingerprint ).
Bob then encrypts the message's Hash with his private key : The result is the Digital Signature.
The message is then sent by Bob to Alice appended with the Digital Signature.

Alice now unencrypts the Digital Signature with Bob's public key, computes the MD5 Hash of the received message, and compares these two values : If they are equal, it means that :
1. The message hasn't been altered ( Integrity )
2. The message is really from Bob ( Authenticity )
3. Bob isn't able to refute that message ( Non-Repudiation )

 

4. Practical example : SSH server

How SSH works

When the SSH server is installed, it generates a private/public key-pair.

When a client wants to connect, he receives the server public-key. The client creates a symetric-key, encrypts it with the SSH-server public-key, and sends this result to the SSH-server.

The SSH server unencrypts the received message with its private-key. Now a private, symetric-key has been securely exchanged between the SSH server and the client.

All following communication will be encrypted with that symetric key.

The client is now able to authenticate securely using that encrypted channel.

This is ( simplified ) how SSH works

One note : When receiving the SSH Server's public-key, the Client will raise a warning if this public-key is not already known ( present on /home/[user]/.ssh/known_hosts file ). If the user accepts the key, it is added to the known_hosts file, and no more warning will be raised. This is a basic way for the client to check who it is connecting to ( Althought not 100% spoof-proof ).

SSH with Public Key authentication

Once the secure encrypted channel has been created, the client has different options to authenticate. One is simple password authentication, using a login name + password. Another one is using a Public-key. Let's see how this authentication works.

This is how we do it :

1. We generate an assymetric-encryption key-pair : a private key and a public key
2. We place the private key in the client and have the SSH server register the public key

Now, once the secure encrypted channel has been created, the client will authenticate by proving it can un-encrypt a challenge encrypted by the SSH server with the client's public-key.

This is ( simplified ) how SSH with Public Key authentication works.

 

note: for some extra security, we can have the client 's private-key password-encrypted on the client's HDD.

See next Blogpost ( VPN 11 : SSH with Public-Key Authentication ) for a Debian tutorial

 

5. Practical example : PPTP server with EAP-TLS
This next practical example is to secure a PPTP server with a Public Key Infrastructure
This is how we do it :


1. We create a personnal Certificate Authority ( CA ) with its own Public-key/Private-key pair
2. We have this CA Sign Public-key/Private-key pairs for the PPTP Server and any PPTP client
3. We place the CA certificate + the Server's key-pair in the Server
4. We place in each Client the CA certificate + the Client's keypair

Do note that the CA have the Server and Client certificates signed using its Private-key, which will remain secret. The CA will only make publicly available its Public-key.

 

Here is how the Server-Client exchange works :


1. Each peer ( the Server and the Client ) will verify that the other peer's certificate has been rightfully signed by the CA.
2. If the certificate is authenticated ( ie. Authenticated and Unaltered ), each peer now checks the Certificate headers, for informations like :
. Common Name ( CN ) : It's the name written on the certificate
. Certificate type : Client or Server ( if Server, nsCertType=server )

The Server can now verify if a Client certificate has been rightfully signed by the CA.
We don't need to maintain a Client's list at the Server's level. We just issue ( sign ) certificates for the clients.
If wished, a client's certificate can be revoked at the CA's level : This is the Certificate Revocation List ( CRL ).
We just have to be sure the Server checks the CA's CRL.


See VPN 12/13 for a tutorial on Debian PPTP Server with EAP-TLS

notes : nsCertType si a deprecated Netscape Certificate Type Exttention. This is a multi-valued extensions which consists of a list of flags to be included. It was used to indicate the purposes for which a certificate could be used. The basicConstraints, keyUsage and extended key usage extensions are now used instead.
Acceptable values for nsCertType are: client, server, email, objsign, reserved, sslCA, emailCA, objCA.
( source : x509v3 / https://www.openssl.org/docs/apps/x509v3_config.html )

 

Repost 0
Published by computer outlines - dans VPN
commenter cet article
10 octobre 2013 4 10 /10 /octobre /2013 20:58

This study is about the practical usability of PPTP using public wifi-hotspots ( Libraries, cafes, ..) and consumers networks ( Friends networks, ... )

It is widely known that the GRE's use of PPTP makes it less reliable than pure TCP/UDP protocols like OpenVPN, as firewalls and ISPs handle GRE in a quite peculiar way.

But how does that actually shape in real life ? This survey is aimed at building a statistical chart, so to have a clear view of PPTP real-life possibilities.

VPN 8 : A PPTP wifi-hotspots usability survey

[ Tests Ongoing ]

Repost 0
Published by computer outlines - dans VPN PPTP
commenter cet article
9 octobre 2013 3 09 /10 /octobre /2013 20:40

We'll see here how to protect our PPTP server with Fail2BAN, to suppress brute-forcing attacks. The OS used is RASPBIAN, but this should work with any Ubuntu or Debian variants.

VPN 7 : PPTP server protection with Fail2ban

Fail2ban monitors the system logs for failed login attemps, and dynamically builds iptables rules to block individual IPs.

Do note that using Fail2ban with pptpd is kind of a hack, due to the fanciful way pptpd performs logging.

Tested using Raspbian June 2014 / Last edited July 28 2014

 

1. Fail2Ban installation

We do the usual updates :

sudo apt-get update
sudo apt-get upgrade

We install fail2ban :

sudo apt-get install fail2ban

We create a fail2ban jail.local file to add pptp :

sudo nano /etc/fail2ban/jail.local
we create a pptp entry :
------------------------------------------------------------------------------------------------------------------
[pptp]

enabled = true
port = 1723
protocol = tcp
filter = pptp
logpath = /var/log/syslog
bantime=60
findtime=600
maxretry = 2

------------------------------------------------------------------------------------------------------------------

The last three lines are the most important, to shape your protection :

bantime : time an IP is banned, in seconds. Negative number for a permanent ban.
maxretry : number of match before an IP is banned
findtime : time, in seconds, before an IP match counter is reset to 0

 

We create the pptp failed connection detection filter, using regex :
sudo nano /etc/fail2ban/filter.d/pptp.conf :
-------------------------------------------------------------------------------------------------------
[Definition]
failregex = CTRL: Client <HOST> control connection finished
ignoreregex =
--------------------------------------------------------------------------------------------------------

We restart the fail2ban service :
sudo service fail2ban restart

Note : You may need pptp debugging, for this trick to work, if /var/log/syslog doesn't log IP addresses :
sudo nano /etc/ppp/options
and uncomment debug:
----------------------------------------------------------------------------------------------------------------
debug
----------------------------------------------------------------------------------------------------------------

This is kind of a hack, because there is no way for fail2ban to distinguish a failed login from a reguler PPTP connection termination, due to pptpd fanciful logging format. Thus, regular logins will be counted as failed-ones, and the IP will eventually get banned. ( You will need to lift the ban manually using SSH, or just cleverly design the bantime/findtime/maxretry values so to allow regular usage while preventing brute-forcing at the same time )

 

2. Fail2Ban use

Actives ban/unbans can be checked using :
cat /var/log/fail2ban.log

Another way to check active bans are with iptables :

sudo iptables -L

 

Likewise, unbanning an IP can be performed using IPtables.

 


To debug your regex expressions match :
sudo fail2ban-regex /var/log/syslog /etc/fail2ban/filter.d/pptp.conf

If you're using the ignoreregex value too, use :

sudo fail2ban-regex /var/log/syslog /etc/fail2ban/filter.d/pptp.conf /etc/fail2ban/filter.d/pptp.conf

 

nb : Here we are using a jail.local file instead of editing the jail.conf file. jail.local is loaded at startup and appended to jail.conf.

 

Repost 0
Published by computer outlines - dans VPN PPTP
commenter cet article
8 octobre 2013 2 08 /10 /octobre /2013 03:10

I'll briefly detail here the iptables config for both the PPTP Server and the PPTP Client, and will outline the GRE protocol functioning and needs.

VPN 6 : iptables for your PPTP server and PPTP client

Tested using :

PPTP Server : Raspbian June 2014

PPTP Client : Debian 7.5 LXDE

Last Edited July 27 2014

 

1. The GRE negociation explained

After the TCP control channel has exchanged some informations, the peers start using the GRE layer ( IP protocol 47 ) : Each peer will send a Configure-Request, and wait for a Configure-Ack. If no Ack is received, the peer will reissue another Configure-Request.

If a Configure-Reject or a Configure-Nack is received, the peer will reissue a different Configure-Request.

To be noted is that the two peers issue their Configure-Request Simultaneously, there is no turn. A typical, successful sequence will look like this :

Peer 1 : Configure-Request ------------------->

<------------------- Peer 2 : Configure-Request

<------------------- Peer 2 : Configure-Ack

Peer 1 : Configure-Ack -------------------------->

 

 

2. Server Iptables configuration

 

Here is a basic PPTP Server Iptables config ( with 192.168.1.40 as the PPTP server IP ) :

------------------------------------------------------------------------------------------------------------
#!/bin/bash

# Set defaults.
iptables -F
iptables -X
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT

# Accept established sessions
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow Pings.
iptables -A INPUT -p icmp -j ACCEPT

# Allow SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow PPTP Control connection
iptables -A INPUT -p tcp --dport 1723 -j ACCEPT

# Allow GRE
iptables -A INPUT -p gre -j ACCEPT

# NAT for PPTP clients connectivity
iptables -t nat -A POSTROUTING -j SNAT --to-source 192.168.1.40

------------------------------------------------------------------------------------------------------------

 

3. Client Iptables Configuration

The PPTP Client is nothing special. We just uncomment the last line and set the port if we're using a custom PPTP TCP port :

------------------------------------------------------------------------------------------------------------------
#!/bin/bash

# Set defaults.
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

# Accept established sessions
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow Pings.
iptables -A INPUT -p icmp -j ACCEPT

# Your Hidden PPTP port
# sudo iptables -t nat -I OUTPUT -p tcp --dport 1723 -j DNAT --to-destination :57594

------------------------------------------------------------------------------------------------------------------

 

4. Iptables Boot-time Autoload

I'll briefly remind to ways to have iptables automatically loaded :

a. clear iptables file

sudo touch /etc/init.d/firewall
sudo chmod 755 /etc/init.d/firewall
sudo update-rc.d firewall defaults

sudo leafpad /etc/init.d/firewall
--------------------------------------------------------------------------------
#!/bin/bash

# Set defaults.
iptables -F
iptables -X
iptables -P INPUT DROP

etc .. ...

-----------------------------------------------------------------------------------

 

b. consolidated iptables file

sudo touch /etc/firewall.sh
sudo chmod 755 /etc/firewall.sh

 

sudo leafpad /etc/firewall.sh
--------------------------------------------------------------------------------
#!/bin/bash

# Set defaults.
iptables -F
iptables -X
iptables -P INPUT DROP

etc .. ...

-----------------------------------------------------------------------------------

 

sudo sh /etc/firewall.sh

sudo iptables-save

sudo bash -c "iptables-save > /etc/iptables.conf"

 

sudo touch /etc/init.d/firewall
sudo chmod 755 /etc/init.d/firewall
sudo update-rc.d firewall defaults

sudo leafpad /etc/init.d/firewall
--------------------------------------------------------------------------------
#!/bin/bash

iptables-restore < /etc/iptables.conf

-----------------------------------------------------------------------------------

 

Repost 0
Published by computer outlines - dans VPN PPTP
commenter cet article
4 octobre 2013 5 04 /10 /octobre /2013 21:07

I'll briefly explain an easy tip to change the default TCP 1723 port of a PPTP server.

Port TCP 1723 being an easy target for network scanners, it may prove usefull to change the PPTP server listening port to a private-range port, well hidden in the dark.

Linux OS will be used for the PPTP client, as it allows for easy networking-ports manipulations, using iptables.

I'm using a Raspberry PI as the PPTP server here, but any OS will work.

I'll use the TCP 57594 port throughout this post as an exemple, do choose your own, private-range port ( 49152 to 65535 )

PPTP client used : Debian 7.5 LXDE

Edited July 8 2014

VPN 5 : PPTP server hiding - change the default port

1. PPTP Server Setup

The PPTP server setup is quite simple : As it most likely lies just before an upstream router, we will just use the port-forwarding options of the upstream router to do the tweak :

we'll forward port TCP 57594 to the PPTP server port TCP 1723.

VPN 5 : PPTP server hiding - change the default port

2. PPTP Client Setup

 

The PPTP client tweak is very easy : we'll just create an iptables rule, that uses the nat table to change the outgoing port :

sudo iptables -t nat -I OUTPUT -p tcp --dport 1723 -j DNAT --to-destination :57594

 

( this is not persistent. a script is needed to automate it )

 

VPN 5 : PPTP server hiding - change the default port

3. Global Picture, and Additional Considerations

Here is the global picture :

 

VPN 5 : PPTP server hiding - change the default port

Like always with PPTP, the heart of the matter will remain :

the Internet Gateway 1 / ISP 1/ ISP2 / Internet Gateway 2 path

 

and the way they'll treat/handle the GRE protocol. Wireshark is of great help to troubleshoot eventual problems.

 

Part 4 : PPTP server port translation

Just out of clarity, here is how to have the port translation directly performed by the PPTP server :

 

VPN 5 : PPTP server hiding - change the default port

The iptables tweak on the server-side will be :

sudo iptables -t nat -I PREROUTING -p tcp --dport 57594 -j REDIRECT --to-ports 1723

( again, this is not persistent. a script is needed to automate it )

Repost 0
Published by computer outlines - dans VPN PPTP
commenter cet article
3 octobre 2013 4 03 /10 /octobre /2013 02:18

This post will explain how to setup a PPTP server that is able to transport both IPv4 and IPv6, using Raspbian as the server, and how to setup a Debian or Windows 8 client.

( The setup is the same for Debian or Ubuntu as the server ).

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6

The tunnel will use the 10.0.0.0/8 IPv4 private address range and the 2001:db8:0:10::/64 IPv6 global unicast address range.

 

Tested using :

PPTP Server : RASPBIAN version June 2014

PPTP Client : Debian 7.5 and Windows 8

 

Last Edited July 1 2014

 

1. PPTP Server setup

The main difficulty is about the radvd service : We need radvd, for IPv6 default gateway advertising to the client. But if the radvd service is running before the tunnel is up, it will spill false router-advertisements to other interfaces, misleading other network clients. ( Is this a radvd bug ?! ).

The solution is to have the radvd service removed from autostart, and activated once the tunnel is up. Likewise, it is stopped when the tunnel is down.

The solution presented here is simple, but only support one IPv6 connection. See Part 4 for solutions that support multiple simultaneous clients.

 

We first update our server :

sudo apt-get update

sudo apt-get upgrade

 

We make sure the pptp server is set with static IPs. We'll be using here :

192.168.1.40 for IPv4

2001:db8:0:1::40 for IPv6

 

We reboot the OS :

sudo reboot

 

We install the pptp server :

sudo apt-get install pptpd

 

We edit the pptp server configuration :

sudo nano /etc/pptpd.conf
We uncomment the localip and remoteip lines and change them to :

-------------------------------------------------------------------------------------
localip 10.0.0.1
remoteip 10.0.0.10-14
-------------------------------------------------------------------------------------

 

We setup the pptp server options :

sudo nano /etc/ppp/pptpd-options

We uncomment the ms-dns lines and change them our DNS choice :
---------------------------------------------------------------------------------------
ms-dns 208.67.222.222
ms-dns 208.67.220.220
---------------------------------------------------------------------------------------
In this example, we use OpenDNS’s servers.

We enable IPv6 by adding to the end :
---------------------------------------------------------------------------------------
ipv6 ::1,::2
----------------
-----------------------------------------------------------------------

 

 

We create users and passwords , using this syntax :

user<tab>*<tab>password<tab>*

sudo nano /etc/ppp/chap-secrets

--------------------------------------------------------------------------------------
john    *    secret1      *

tom     *    secret2      *
--------------------------------------------------------------------------------------

 

We adjust the ipv4 MTU :

sudo nano /etc/ppp/ip-up

( We add this line to the end of the file ) :
----------------------------------------------------------------------------------------
ifconfig $1 mtu 1400
----------------------------------------------------------------------------------------

 

We enable IPv4 and IPv6 forwarding :

sudo nano /etc/sysctl.conf

( we uncomment IPv4 and IPv6 forwarding ) :
-----------------------------------------------------------------------------------------
net.ipv4.ip_forward=1

net.ipv6.conf.all.forwarding=1

-----------------------------------------------------------------------------------------
 

we apply the networking changes :

sudo sysctl -p

 

we finally create IPv4 NAT, to allow IPv4 clients full connectivity :

sudo iptables -t nat -A POSTROUTING -j SNAT --to-source 192.168.1.40
sudo iptables-save

 

We create a NAT boot-time script :

sudo bash -c "iptables-save > /etc/iptables.conf"
sudo nano /etc/network/if-pre-up.d/iptables
-------------------------------------------------------------------------------------------
#!/bin/sh
iptables-restore < /etc/iptables.conf
-------------------------------------------------------------------------------------------

sudo chmod +x /etc/network/if-pre-up.d/iptables

 


IPv6 Specifics

 

We install radvd :

sudo apt-get install radvd

 

We edit radvd.conf :

sudo nano /etc/radvd.conf
---------------------------------------------------------------------------------------------

interface ppp0 {
AdvSendAdvert on;
AdvDefaultPreference high;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2001:db8:0:10::/64 {
AdvOnLink on;
AdvAutonomous on;
};
RDNSS 2620:0:ccc::2 2620:0:ccd::2 {
};
};

 

---------------------------------------------------------------------------------------------

( We'll be using OpenDNS IPv6 addresses. You may use Google Public DNS, Comodo Secure DNS, ... )

we stop radvd, and remove it from boot-time autostart :

sudo service radvd stop

sudo update-rc.d -f radvd remove

 

We create the PPTP server tunnel up / tunnel down IPv6 RADVD scripts :

sudo nano /etc/ppp/ipv6-up.d/radvd
---------------------------------------------------------------------------------------------
#!/bin/bash
sudo ip -6 addr add 2001:db8:0:10::1/64 dev ppp0
sudo service radvd start
exit 0
---------------------------------------------------------------------------------------------
sudo chmod 755 /etc/ppp/ipv6-up.d/radvd

sudo nano /etc/ppp/ipv6-down.d/radvd
---------------------------------------------------------------------------------------------
#!/bin/bash
sudo pkill radvd
exit 0
----------------------------------------------------------------------------------------------
sudo chmod 755 /etc/ppp/ipv6-down.d/radvd

 


 we restart the pptp server :

/etc/init.d/pptpd restart

 

Local network IPv6 routing / Internet Gateway setup

Whereas IPv4 is using NAT, and thus doesn't need any special routing care, IPv6 does need some static IPv6 routes on the local network of the PPTP Server, for the 2001:db8:0:10::/64 network to be reachable.

Likewise, some port forwarding is needed on the Internet Gateway to allow Wan access of the PPTP server.

See Part 5 : Network IPv6 Routing, for the required IPv6 static routes for different network topologies, and a port forwarding exemple.

 

 

2. PPTP Client Setup

Windows 8

The Windows 8 PPTP client supports PPTP transport of IPv4 and IPv6 natively. Nothing special to setup here.

The VPN IPv4 DNS addresses get setup OK. The only glitch is the lack of Windows support for RDNSS, thus no VPN IPv6 DNS addresses set. Static IPv6 DNS needed here.

 

Debian 7.5

 

As the network manager doesn't allow to setup PPTP transport of IPv6, we will have to setup and up/down the tunnel manually. It is actually very simple.

 

We update the Debian client, and install the pptp-linux package :

sudo apt-get update

sudo apt-get upgrade

sudo apt-get install pptp-linux

 

we install the rdnss listener, needed as we're not using the network manager :

sudo apt-get install rdnssd

 

We set our user and password :

We create users and passwords , using this syntax :

user<tab>*<tab>password<tab>*

sudo leafpad /etc/ppp/chap-secrets

--------------------------------------------------------------------------------------
john    *    secret1      *

--------------------------------------------------------------------------------------

 

We create a config file for the tunnel, that we'll name MYVPN :

sudo leafpad /etc/ppp/peers/MYVPN

--------------------------------------------------------------------------------------

pty "pptp 192.168.1.40 --nolaunchpppd"
name john
remotename PPTP
require-mppe-128
require-mschap-v2
usepeerdns
noauth
file /etc/ppp/options.pptp
ipparam MYVPN

---------------------------------------------------------------------------------------

 

We enable IPv6 in the pptp client options by adding to the end :

sudo leafpad /etc/ppp/options.pptp

---------------------------------------------------------------------------------------
+ipv6
ipv6cp-accept-local
ipv6cp-use-ipaddr

---------------------------------------------------------------------------------------

 

 

We create a script for client to have the default route replaced when teh tunnel is up :
sudo leafpad /etc/ppp/ip-up.d/MYVPN
----------------------------------------------------------------------------------------------
#!/bin/sh

sudo ip route change default via 10.0.0.1 dev ppp0

----------------------------------------------------------------------------------------------
sudo chmod +x /etc/ppp/ip-up.d/MYVPN

 

We create a script for client to replace default route when the tunnel is down.

( replace eth1 with your interface name ) :
sudo leafpad /etc/ppp/ip-down.d/MYVPN
----------------------------------------------------------------------------------------------
#!/bin/sh

#sudo ip route del default
sudo ip route add default via 192.168.1.1 dev eth1
----------------------------------------------------------------------------------------------
sudo chmod +x /etc/ppp/ip-down.d/MYVPN

 

You may have to use scripts for the IPv6 tunnel up/down too. As an example, althrough my tunnel RAs ( Router Advertisements ) have a priority set to high, they get unpreferred because of a strange metric 1 route to the default gateway ( under investigation ... ).

So I use this to get rid of it :

sudo leafpad /etc/ppp/ipv6-up.d/MYVPN

---------------------------------------------------------------------------------------------------------------

#!/bin/sh

sudo ip route del default via fe80::8cde:48ff:fe00:0080 dev eth1  proto static  metric 1

sudo service rdnssd restart

---------------------------------------------------------------------------------------------------------------

sudo chmod +x /etc/ppp/ipv6-up.d/MYVPN

 

So do the debugging of your personal situation, using :

ip -6 route show

 

Tunnel start/stop

The tunnel is up'ed and down'ed using these commands :

to create the tunnel :

sudo pon MYVPN

to delete the tunnel :

sudo poff MYVPN

To troubleshoot tunnel creation problems, use this debug syntax :

sudo pon MYVPN debug dump logfd 2 nodetach

 

4. Multiple simultaneous clients with IPv6 support

The problem with multiple clients comes from the fact that each client creates a distinct ppp interface ( ppp0, ppp1, ppp2 ). Thus, the server script that starts radvd must be aware of the ppp interface used, requiring some scripting.

source 1

source 2

 

5. Network IPv6 Routing

Let's quickly check the IPv6 extra network routing needs, depending on the topology, for some different scenarios. Remember to adapt your client Scripts, depending on the topology.

 

Case 1 : client on the same LAN as the PPTP Server

This is the simplest case. I detail it to outline the need for Internet Gateway to have a static route to the 2001:db8:0:10::/64 network ( the tunnel IPv6 network ) via 2001:db8:0:1::40 ( the PPTP server ) :

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6
VPN 4 : Debian PPTP Server w/ IPv4 and IPV6

Case 2 : client goes LAN-WAN through a local router

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6

Nothing more to do, as the client only has and IPv4 connection with the PPTP server. It remains the need for a route for the Internet Gateway :

2001:db8:0:10::/64 through 2001:db8:0:1::40

 

 

Case 3 : Client goes Wan-Lan through a local Router

 

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6

Here we have three IPv6 static routes needed :

Internet Gateway                                    2001:db8:0:10::/64 through 2001:db8:0:1::40

                                                               2001:db8:0:2::/64 through 2001:db8:0:1::40

 

DIR 626-L                                               2001:db8:0:10::/64 through 2001:db8:0:2::40

 

Case 4 : Client uses Wan Access

 

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6

Nothing complicated here. We need a static route :

Internet Gateway 2001:db8:0:10::/64 through 2001:db8:0:1::40

and a port forwarding :

Internet Gateway TCP 1723 forwarded to 182.168.1.40 port 1723

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6
Repost 0
Published by computer outlines - dans vpn ipv6
commenter cet article
1 octobre 2013 2 01 /10 /octobre /2013 02:02

We'll see here how to setup PPTP for real use, covering issues like Wan access, port forwarding, and PPTP passthrough. We'll use a Cisco Small Business RV110W as a VPN server, Debian 7.5 LXDE as VPN client, and a DLink DIR-626L to test PPTP Passthrough.

 

[ Last Edited June 21 2014 ]

 

1. Debian PPTP Client Setup

We first install the required packages :

sudo apt-get update
sudo apt-get upgrade

sudo apt-get install pptp-linux
sudo apt-get install network-manager-pptp
sudo apt-get install network-manager-pptp-gnome

 

( If you're not using LXDE or gnome, the network-manager packages might be different )

 

2. Simple Lan PPTP Setup

We'll first see the simplest topology, a local Lan Access :

 

VPN 3 : PPTP setup

We setup the RV 110-W for PPTP :

Menu Tab : VPN Client TAB

. Allow the PPTP Server

. Choose VPN Server IP and leased IP range if needed

. Allow MPPE encryption

. Create client with password

[ reminder : use a real 128 bits entropy password, ie 20 characters long using numbers, lower-case letters, higher-case letters, special characters ]

VPN 3 : PPTP setup

We then setup the VPN tunnel in Debian by left-clicking on the network-manager :

VPN 3 : PPTP setup

We fill-in the gateway, user/password, and enable MPPE in advanced options.

IPv4 settings can be left on automatic ( VPN ) :

VPN 3 : PPTP setup

Here we have our VPN tunnel set :

VPN 3 : PPTP setup

3. Simple Lan PPTP Setup with exit router

Here we have a little more complexe situation, where PC1 ( Client ) has to exit through a first router ( DIR 626 L ) before reaching the VPN Server :

 

VPN 3 : PPTP setup

There is nothing new to actually setup here, as the DIR 626-L handles the situation quite brilliantly. No firewall-opening needed, neither the need to tick the DIR 626-L PPTP Pass-through.

The DIR 626-L PPTP Pass-through option will only be needed if multiple concurrent PPTP sessions are initiated from the DIR 626-L Lan.

 

4. Lan PPTP Setup with entry Router

Here we have to pass-in a first router ( DIR 626-L ) before reaching the PPTP server :

 

 

VPN 3 : PPTP setup

Things get a little more complicated here, but still quite easy : we just need the DIR 626-L to forward TCP port 1723 to the VPN Server :

VPN 3 : PPTP setup

5. PPTP Server reachable from Wan

The last topology will allow access from Wan :

 

VPN 3 : PPTP setup

We need our Internet Gateway to handle-in the PPTP protocol ( ie TCP port 1723 and GRE protocol ). We have three options here :

1. The Internet Gateway is PPTP friendly

We just have to forward port 1723 ( and protocol GRE = IP protocol 47 eventually ).

2. The Internet gateway can be bridged

If the Internet Gateway can be bridged ( ie its router can be deactivated, so that it performs like a bridge ), any protocol / port will freely flow-by

3. We put the PPTP Server in a DMZ

We setup our Internet gateway so that the PPTP Server IP is in DMZ

Repost 0
Published by computer outlines - dans VPN
commenter cet article

Présentation

  • : Computer Outlines Blog
  • : Blog mainly focused over IPv6, Windows Server, and Networking in general.
  • Contact

Recherche

Liens