tag:blogger.com,1999:blog-72761115518968867352024-03-13T20:51:48.547+02:00linuxconnecta repository for all sorts of technical stuffAnonymoushttp://www.blogger.com/profile/07621494388922534829noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-7276111551896886735.post-75354235378125521372012-04-10T19:12:00.000+03:002012-04-27T11:04:57.012+03:00Forcing public key and password in OpenSSHUsing OpenSSH with public key authentication is quite secure. In fact, if the private key is password protected, you get 2-factor authentication -- something you know (the password) and something you have (the private key).<br />
<br />
<h1>
The Problem</h1>
However, the SSH architecture does not allow the server to force a password on the private key - The whole point, and indeed the fundamental principle in public key authentication is that the private key is unknown to the server and is managed totally by the client. There simply is no way to enforce a password! This leaves open the possibility of users deleting their private key passwords, and regressing to 1-factor authentication. The password-less private key is equivalent to a login password which is in some file in plain text on the users machine. Its not too bad since the private key is a long and strong login password, but it is written in plain-text!<br />
<br />
A simple solution for this problem is to add another authentication step on the server, independent of the public key authentication. Sadly, in OpenSSH, only one authentication step is allowed, you can tell the OpenSSH server which authentication methods you allow, but once one of them succeeds, the user is considered authenticated.<br />
<br />
<h1>
The Solution</h1>
By utilizing another one of the OpenSSH's server options, we can add another authentication step. OpenSSH has the option to force a command AFTER authentication. This can be either done per public key in each users' authorized_keys2 file, or as a general option in the OpenSSH's sshd_config file, where is can also be selectively applied by using the Match directive.<br />
<br />
So, armed with this knowledge, we'll force another authentication step. But which one? I would go for <a href="http://linux-pam.org/">PAM</a>. PAM is standard on most (if not all) GNU/Linux distributions, and has modules for a lot of authentication schemes, including OTP and of course UNIX passwords. We now need a command which will authenticate with PAM. I found this <a href="http://linux-pam.org/Linux-PAM-html/adg-example.html">PAM example application</a> a small, very readable application written in c so it needs very little resources. It only depends on PAM and the c stdlib, so should be pretty OS agnostic. It's simple, so it's easy to audit -- nothing shady going on!<br />
<br />
As is, the pam application is not entirely suitable since it requires a user-name in the command line. To work around this, I put the pam binary in <code>/usr/local/bin/</code> and wrap it in small shell script to pass the current user (remember that the OpenSSH server uses the user's shell to run the command)<br />
<code><br />
#!/bin/sh -f<br />
/usr/local/bin/pam "$USER" || exit 0<br />
</code><br />
Save this script to <code>/usr/local/bin/auth_res.sh</code>, and remember to make it executable!<br />
Add all of your 2-factor required users to the aptly named group <code>twofactor</code>, and then add the <code>Match</code> block below to the end of the <code>sshd_config</code> file:<br />
<code><br />
Match Group twofactor<br />
ForceCommand "/usr/local/bin/auth_res.sh"<br />
RSAAuthentication no<br />
PasswordAuthentication no<br />
PubkeyAuthentication yes<br />
</code><br />
<br />
Voilla! Now the users in the twofactor group will always need a private key <b>AND</b> to authenticate to PAM!<br />
<br />
<h1>P.S.</h1>
Another advantage of these scheme is that the password resides on the server -- With password protected private keys, if someone get's a user's private key he can now try to bruteforce it at his leasure. In the proposed scheme, it will be harder to brute force the password since the server has limits on tiem between logins etc ...Anonymoushttp://www.blogger.com/profile/07621494388922534829noreply@blogger.com0tag:blogger.com,1999:blog-7276111551896886735.post-11567994554034046282010-04-16T11:32:00.004+03:002010-05-03T22:25:18.290+03:00HOWTO connect Nokia VPN to GNU/Linux<h2>Overview</h2>This HOWTO describes how to setup a GNU/Linux box as an IPSec gateway and a Nokia VPN client as a road-warrior so that they can talk to each other. The protocol used is IPSec with RSA authentication.<br />
While most of the procedures described here are documented somewhere or other, I could not find them summarized under one roof, so I decided to do it myself.<br />
<br />
To get this setup going, you will have to setup a certificate authority (CA) to issue certificates, hack the racoon IKE daemon to account for a problematic nat-t negotiation protocol by the Nokia VPN client, and configure both the racoon daemon and the Nokia vpn client so that they will be able to talk to each other and recognize the certificates.<br />
<br />
This HOWTO assumes intermediate knowledge of GNU/Linux. You are assumed to know your shell, and have no problems in compiling packages from source. I do not assume any specific GNU/Linux distribution, just a 2.6.x kernel.<br />
<br />
<h2>Prerequisites</h2><h3>GNU/Linux</h3><ul><li>openssl</li>
<li>ipsec-tools modified for Nokia (see <a href="http://linuxconnect.blogspot.com/2010/04/ipsec-tools-fix-for-nokia-vpn-nat-t.html">this post</a>)</li>
<li>possibly open the firewall to the IPsec packets (see <a href="http://linuxconnect.blogspot.com/2010/04/iptable-rule-for-allowing-ipsec-traffic.html">this post</a>)<br />
<li> 2.6 kernel</li><br />
<br />
<br />
</ul><h3>Nokia</h3>(get it from <a href="http://europe.nokia.com/support/download-software/nokia-mobile-vpn/compatibility-and-download">Nokia</a>) <ul><li>Mobile VPN Client version >= 3.1</li>
<li>A compatible phone</li>
</ul><h2>Setting up a certificate infrastructure</h2><h3>Generating CA certificate</h3>First we need to setup a certificate authority (CA) to sign all the certificates used for authenticating the gateway and clients. <pre># set certificate_dir to the directory you wish to keep all the certificates in:
mkdir ${certificate_dir} && cd ${certificate_dir}
# generate 2 2048 bit rsa key for the CA
openssl genrsa 2048 > ca.key
# generate the CA bookkeeping files
mkdir -p demoCA/newcerts
touch demoCA/index.txt
echo "00" > demoCA/serial
echo "00" > demoCA/crlnumber
# generate the CA certificate and make link a hash to it
openssl req -days 1825 -x509 -new -key ca.key > ca.crt
ln -s ca.crt `openssl x509 -noout -hash -in ca.crt`.0
# generate the certificate revocation list (CRL) and hash
openssl ca -gencrl -cert ca.crt -keyfile ca.key -out crl.pem
ln -s crl.pem `openssl crl -noout -hash < crl.pem`.r0
</pre>At this stage we setup a CA which has enough function to support all of our IPSec needs. <h3>Creating the gateway certificates</h3>We now create the certificates for our gateway: we create a 2048 bit key, make a request and get it signed by our CA <pre>cd ${certificate_dir}
openssl genrsa 2048 > vpngw.key
openssl req -new -key vpngw.key > vpngw.csr
openssl ca -keyfile ca.key -cert ca.crt -in vpngw.csr -out vpngw.crt
</pre><h3>Creating certificates for Nokia clients</h3>For each client (or group of clients), we need to create a private key and certificate in a format that Symbian will recognize: <pre>cd ${certificate_dir}
mkdir -p Nokia/vpn
# key and certificate as for the client
openssl genrsa 2048 > client.key
openssl req -new -key client.key > client.csr
openssl ca -keyfile ca.key -cert ca.crt -in client.csr -out client.crt
# convert them into Nokia compatible format:
openssl x509 -outform der -in client.crt -out Nokia/vpn/client.cer
## MUST enter an encryption passwd! ##
openssl pkcs8 -outform DER -v2 des-ede3-cbc -topk8 -in client.key -out Nokia/vpn/client.key
# convert the CA certificate into Nokia compatible format:
openssl x509 -outform der -in ca.crt -out Nokia/vpn/ca.crt
</pre><b>Note: you must supply an encryption password for the client key!</b> <h2>Setting up IKE on GNU/Linux</h2>Use the following raccon.conf file as a template: <pre>#path to the certificate -- use the above defined certificate_dir
path certificate "/etc/racoon/certs";
## uncommend to get a lot of debug output
#log debug;
#option of controlling racoon by racoonctl tool is disabled
# substituted the network address of the relevant (external) interface here
listen {
adminsock disabled;
isakmp 192.168.10.1 [500];
isakmp_natt 192.168.10.1 [4500];
}
#remote section – anonymous address of road-warrior client
#any change in this section should be reflected in the Nokia vpn policy file
remote anonymous {
exchange_mode main;
certificate_type x509 "vpngw.crt" "vpngw.key";
ca_type x509 "ca.crt";
verify_cert on;
proposal_check claim;
generate_policy on;
nat_traversal on;
dpd_delay 20;
ike_frag on;
passive on;
verify_identifier on;
my_identifier asn1dn;
peers_identifier asn1dn;
#agreement proposal in IKE first phase
proposal {
encryption_algorithm aes 256;
hash_algorithm sha1;
authentication_method rsasig;
dh_group modp1024;
}
}
#SA information for IKE second phase
#any change in this section should be reflected in the Nokia vpn policy file
sainfo anonymous {
pfs_group modp1024;
lifetime time 1 hour;
encryption_algorithm aes;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
#############################################################
## local network information
## change the settings in this section to suit your own network setup
mode_cfg {
#starting address of the IP address pool
network4 192.168.10.20;
#maximum number of clients
pool_size 20;
#network mask
netmask4 255.255.255.0;
#authentication source – user database on the system
auth_source system;
#configuration source – from data given in this section
conf_source local;
#DNS and WINS servers IP addresses
dns4 192.168.10.1;
wins4 192.168.10.1;
#banner file – welcome message
banner "/etc/racoon/motd";
}
</pre><b>Things to remember</b> <ul><li>At the top of the file, set "path certificate" to the path of your CA and vpngw certificates</li>
<li>You would mostly need to change the things in the mode_cfg section to suit you own network. Other sections should be good as-is.</li>
<li>The "remote" and "sainfo" sections are especially tailored to fit the nokia vpn profile, so changing them will induce a change in the nokia vpn policy.</li>
</ul><h2>Setting up the Nokia VPN policy</h2>The Nokia VPN policy file is really a zip archive containing two configuration files (.pol & ..pin), the client key and certificate and the CA certificate. We will construct this archive in the <i>${certificate_dir}/Nokia/vpn</i> directory. The contents of the directory: <ul><li>my-vpn.pin: policy information</li>
<li>my-vpn.pol: policy configuration</li>
<li>ca.crt: CA certificate. See above for info on how to create</li>
<li>client.cer: client certificate. See above for info on how to create</li>
<li>client.key: client key. See above for info on how to create</li>
</ul>The policy information file contains information to be shown about the policy in the phone: <pre>[POLICYNAME]
My First VPN Policy
[POLICYVERSION]
1.0
[POLICYDESCRIPTION]
This is my first policy. Lets see if it works
[ISSUERNAME]
Me LTD.
[CONTACTINFO]
me@me.org, +44-11111111
</pre>The policy configuration file contains all the config info. The following file is compatible with the racoon config given above: <pre>SECURITY_FILE_VERSION: 1
[INFO]
My First VPN
[POLICY]
sa my-vpn = {
esp
## AES-256
encrypt_alg 12
max_encrypt_bits 256
## SHA-1
auth_alg 3
identity_remote 0.0.0.0/0
src_specific
hard_lifetime_bytes 0
hard_lifetime_addtime 3600
hard_lifetime_usetime 3600
soft_lifetime_bytes 0
soft_lifetime_addtime 3600
soft_lifetime_usetime 3600
replay_win_len 0
## prefect forward secracy (see also IKE section)
pfs
}
remote 0.0.0.0 0.0.0.0 = { my-vpn(**GATEWAY_IP**) }
inbound = { }
outbound = { }
[IKE]
ADDR: **GATEWAY_IP** 255.255.255.255
IKE_VERSION: 1
MODE: Main
ID_TYPE: 9
REPLAY_STATUS: FALSE
USE_MODE_CFG: TRUE
IPSEC_EXPIRE: TRUE
USE_XAUTH: FALSE
USE_COMMIT: FALSE
ESP_UDP_PORT: 0
SEND_NOTIFICATION: TRUE
INITIAL_CONTACT: TRUE
USE_INTERNAL_ADDR: TRUE
DPD_HEARTBEAT: 90
NAT_KEEPALIVE: 60
REKEYING_THRESHOLD: 90
GROUP_DESCRIPTION_II: MODP_1024
### Proposal
PROPOSALS: 1
ENC_ALG: AES256-CBC
AUTH_METHOD: RSA_SIGNATURES
HASH_ALG: SHA1
GROUP_DESCRIPTION: MODP_1024
GROUP_TYPE: DEFAULT
LIFETIME_KBYTES: 0
LIFETIME_SECONDS: 86400
PRF: NONE
### CA
CAs: 1
FORMAT: BIN
DATA: ca.crt
### CLient credentials
OWN_CERT_TYPE: USER
OWN_CERTS:
FORMAT: BIN
DATA: client.cer
PRIVATE_KEY_FORMAT: BIN
PRIVATE_KEY_DATA: client.key
</pre>Notes: <ul><li>Replace the 2 occurences of **GATEWAY_IP** with you actual gateway's IP</li>
<li>Set USE_XAUTH=TRUE for another password verification before connection</li>
<li>Set OWN_CERT_TYPE: DEVICE to allow for password-less access to the client key</li>
</ul>Zip the above 5 files into my-vpn.vpn: <pre>zip my-vpn.vpn bioc-vpn.pin bioc-vpn.pol ca.crt client.cer client.key</pre>copy the <i>my-vpn.vpn</i> to the phone and install it. There should be no errors reported. <br />
<br />
Enjoy the VPNAnonymoushttp://www.blogger.com/profile/07621494388922534829noreply@blogger.com44tag:blogger.com,1999:blog-7276111551896886735.post-41154272033894231092010-04-15T18:14:00.009+03:002010-04-15T18:45:49.106+03:00iptable rule for allowing IPsec trafficFirst, we need to open the firewall to the ESP protocol and open the IKE ports (UDP 500 and 4500). Assuming eth1 is the external interface of the firewall:<br />
<pre>iptables --append INPUT --protocol ESP --in-interface eth1 --jump ACCEPT
iptables --append INPUT --protocol UDP --source-port 500 --destination-port 500 --in-interface eth1 --jump ACCEPT
iptables --append INPUT --protocol UDP --source-port 4500 --destination-port 4500 --in-interface eth1 --jump ACCEPT</pre><br />
A way to identify traffic originating from a valid IPsec session (presumably to allow it inside your network) is to use the policy module, which matches the policy used by IPsec for handling a packet.<br />
A good catchall rule is:<br />
<pre>iptables \
--append INPUT \
--in-interface eth1 \
--match policy \
--pol ipsec \
--dir in \
--jump LOG \
--log-level debug \
--log-prefix "IPSec "</pre>This rule will log all packets coming from a IPsec connected peer with the message "IPSec ".Anonymoushttp://www.blogger.com/profile/07621494388922534829noreply@blogger.com0tag:blogger.com,1999:blog-7276111551896886735.post-37429914853924753892010-04-04T14:12:00.006+03:002011-03-29T12:03:21.222+02:00ipsec-tools fix for Nokia VPN NAT-TNokia NAT-T is not compatible with the linux ipsec-tools. More info can be found in <a href="https://trac.ipsec-tools.net/ticket/318">this ticket</a> in the ipsec bug tracker. <br />
An ugly hack which fixes this problem is provided at <a href="http://www.spenneberg.com/7750.html">Nokia VPN (N97) -> raccon -> Nat-T</a>. Since this is the only fix available, we'll go with ugly ...<br />
<br />
Basically, the racoon daemon has to be complied without RFC nat-t support and one source line has to be changed.<br />
<br />
I will spell out the procedures outlined above:<br />
<br />
<h2>Using actual "raw" sources</h2>To compile from source, get the ipsec-tools tarball from the <a href="http://ipsec-tools.sourceforge.net/">ipsec-tools project page</a>.<br />
<br />
for compilation I used the following configure options:<br />
<pre>./configure \
--enable-hybrid \
--enable-frag \
--enable-gssapi \
--enable-stats \
--enable-dpd \
--enable-fastquit \
--disable-ipv6 \
--enable-natt \
--enable-natt-versions=0,1,2,3,4,5,6,7,8 \
--enable-security-context=kernel
</pre>note the "--enable-natt-versions=0,1,2,3,4,5,6,7,8" switch<br />
<br />
before compiling change one line in the file ipsec-tools-0.7.1/src/racoon/nattraversal.c:<br />
<pre>--- ipsec-tools-0.7.1/src/racoon/nattraversal.c 2009-12-15 08:01:36.000000000 +0100
+++ ipsec-tools-0.7.1.patched/src/racoon/nattraversal.c 2009-10-11 13:39:36.000000000 +0200
@@ -314,7 +314,7 @@
return;
}
- if (iph1->natt_options->version < vid_numeric)
+ if (iph1->natt_options->version == 0)
if (natt_fill_options (iph1->natt_options, vid_numeric) == 0)
iph1->natt_flags |= NAT_ANNOUNCED;
}
</pre><br />
You can now compile and install. The resulting racoon daemon will now accept nat-t connections from a Nokia VPN client<br />
<br />
<h2>Using Debian sources</h2><pre>apt-get install devscripts build-essential fakeroot
apt-get build-dep racoon
apt-get source racoon
cd ipsec-tools*
dch -l local nokia</pre><ul><li>edit <i>debian/rules</i> and add the <i>--enable-natt-versions=0,1,2,3,4,5,6,7,8</i> option to configure</li>
<li>patch <i>src/racoon/nattraversal.c</i> as per above</li>
</ul><pre>debuild -us -uc
dpkg -i ../*.deb</pre>Anonymoushttp://www.blogger.com/profile/07621494388922534829noreply@blogger.com0tag:blogger.com,1999:blog-7276111551896886735.post-51394743024908618002010-03-21T23:15:00.001+02:002010-04-16T11:36:53.686+03:00Usefull apps for symbianI have a Nokia E51 phone which runs symbian 3rd edition. This is a list of apps which I have installed <ul><li>cCalc: Superior to the built in calculatro in both function and ease of use</li>
<li>cClock: Great screensaver - see the time, missed calss etc.. in a large font</li>
<li>s60SpotOn: use your phone as a light </li>
<li>KeePassJ2ME: Share passwords with the desktop application KeePass</li>
<li>Putty: I use it mainly as a port-forwarder for the Nokia built-in mail client, but if you have a device with a real keyboard, it can be used as a terminal</li>
<li>MetrO</li>
<li>Gmail</li>
<li>Google Maps </li>
</ul>Anonymoushttp://www.blogger.com/profile/07621494388922534829noreply@blogger.com0tag:blogger.com,1999:blog-7276111551896886735.post-15635481366978700252009-04-14T17:26:00.007+03:002009-04-21T19:17:35.354+03:00getting mach64 dri to work on debianNowadays kernels don't come with a mach64 drm module. It seems there used to be some security problems with the mach64 drm module, but this has long been fixed as claimed in in the <a href="http://dri.freedesktop.org/wiki/ATIMach64?highlight=%28CategoryHardwareChipset%29">Mach 64 DRI page</a>.
Anyway, to get it working for your current kernel, download the latest version from the <a href="http://cgit.freedesktop.org/mesa/drm/">freedesktop git</a> untar it and cd into the distribution directory. after that: <pre>cd libdrm-X.X.X/linux-core
make</pre>
Now, before installing, remove the previous modules (that came with the kernel): In debian they are usually in the <pre>/lib/modules/`uname -r`/kernel/drivers/gpu/drm</pre> directory. remove this directory (perhaps move it somewhere for backup) and then, back in the <pre>libdrm-X.X.X/linux-core</pre> directory, do <pre>sudo make install</pre>
To see if it works, exit X, remove all the old modules:<pre>sudo rmmod drm agpgart</pre> and try reloading them:<pre>sudo insmod agpgart; sudo insmod drm; sudo insmod mach64</pre>start X and test: <pre>glxinfo | grep render</pre>You should have "direct rendering: Yes". If you still have "Software Rasterizer" for OpenGL, try looking through the Xorg log file at <pre>/var/log/Xorg.0.log</pre>. It's sometimes a memory problem. In this case, try reducing display depth.
If this doesn't work, try rebooting before you give up -- sometimes the old modules just won't go away until reboot.Anonymoushttp://www.blogger.com/profile/07621494388922534829noreply@blogger.com0tag:blogger.com,1999:blog-7276111551896886735.post-72263384952065328382009-04-14T08:09:00.017+03:002009-04-14T16:43:17.954+03:00tuxonice for debianDebian provides the <a href="http://packages.debian.org/search?keywords=tuxonice&searchon=names">linux-patch-tuxonice</a> package which is in the form of a kernel patch. To use it, we must compile the kernel after applying the patch. I outline the "debian way" of doing it, which will build deb packages of the patched kernel:
Make a directory for all of this kernel stuff:
<pre>mkdir kernel && cd kernel</pre>Download the kernel source, tuxonice patch and building helpers:
<pre>sudo apt-get install linux-source-2.6 linux-tuxonice-patch build-essential fakeroot</pre>
make sure you have all the necessary dependencies for building
<pre>sudo apt-get build-dep linux-2.6</pre>Unpack the kernel source. Use the appropriate version as installed by the above apt-get command (I will use 2.6.29 here)
<pre>tar xjvf /usr/src/linux-source-2.6.29.tar.bz2
cd linux-source-2.6.29
</pre>Build the whole thing, including patch.
Note: you might have to answer some kernel configuration questions. Choose the default values unless you have a good reason not to.
<pre>fakeroot make-kpkg --added_patches tuxonice --initrd --revision=+tuxonice.1 buildpackage</pre> You should now have the full kernel .deb files in the parent dir.
Before installation, add the resume argument to the kernel command line. First find out what is the swap partition:
<pre>grep swap /etc/fstab</pre>Now edit the /boot/grub/menu.lst file to add this to all kernels:
<pre>sudoedit /boot/grub/menu.lst</pre>Find the line beginning with "# defoptions" and append the argument <pre>resume=swap:/dev/hXX</pre> where /dev/hXX is the partition from the grep command above. My line looks like this:
<pre># defoptions=quiet resume=swap:/dev/hda5</pre>save the file.
Now install the new kernel packages:
<pre>cd ../
sudo dpkg -i linux-*-2.6.29*.deb</pre> install the hibernate package
<pre>sudo apt-get install hibernate</pre> after rebooting with the new kernel, use hibernate:
<pre>sudo hibernate</pre>Anonymoushttp://www.blogger.com/profile/07621494388922534829noreply@blogger.com0tag:blogger.com,1999:blog-7276111551896886735.post-24872590867259363972009-04-13T20:11:00.000+03:002009-04-13T21:01:42.037+03:00First rule of effective backupBackup is important -- everyone knows it, but for backup to be really effective, it must be done regularly. While doing repetitive tasks can be very hard and error prone for us humans, computers simply excel at this, so the first rule of effective backup is:
<div style="text-align: center;"><div style="text-align: left;"><span style="font-weight: bold;">Backups should be automatic, with as little human intervention as possible.</span>
Corollary: Unless you have a tape changer,<span style="font-weight: bold;"> don't use tape for backup</span> because you'll need a human to change the tapes (and they'll forget to do it)
I'll post several solutions I use which follow this rule
</div></div>Anonymoushttp://www.blogger.com/profile/07621494388922534829noreply@blogger.com0