Enabling connections multiplexing is actually just a matter of 2 options to set. I find it practical and easy to set them globally by editing my ~/.ssh/config and adding the following lines :

1
2
3

Host *
	ControlMaster auto
	ControlPath ~/.ssh/sockets/ssh-socket-%r-%h-%p

These settings apply for any hosts, but you could enable it selectively if needed. “ControlMaster auto” will start a master connection and create the control socket if none exist yet. The control socket will be created in the path specified by the ControlPath directive. This socket is used by the ssh client to create a new SSH connection over an already existing master connection.

It is recommended that the socket name contains the hostname (%h), the port (%p) and the remote username (%r), to avoid using an inappropriate control socket when establishing a new connection.

The path where the control sockets are created are to be correctly protected (the directory permissions should be something like 0700 and the sockets themselves 0600) because if the sockets are accessible, they can be used to establish connection as the user who created the master connection.

SSH : Multiplexing connections is a post from: Tech@Sakana - A sysadmin's blog

To make rsync both secure and automated (i.e : non-interactive), you can use SSH as the transport and set up a key pair. This is what will be discussed in this post, along with a few improvements.

Basic rsync + ssh

Let’s first ensure that rsync works correctly over ssh :

spaghetti% rsync -avz -e ssh --delete Documents prodigy:/tmp
Password: 
building file list ... done
Documents/
Documents/Letters/
Documents/Letters/Santa.odt
[...]
spaghetti% 

As for the options : -avz is for the verbose archive gzip compressed mode. This transfers your files and directories recursively, preserving most of their attributes (date, owner, group, and so on). –delete will make rsync to delete the files in the target directory if they don’t exist anymore in the source directory. All in all, you should end up with the target and source directories synchronized.

As we are specifying -e ssh, all the data are transfered over a secured ciphered SSH session.

Notice that it did ask for the password which is unsuitable for automation/scripting purposes. Let’s take care of that.

Setting up an SSH key pair

First let’s create the key pair :

spaghetti% ssh-keygen -t rsa          
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kattoo/.ssh/id_rsa): testRsync
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in testRsync.
Your public key has been saved in testRsync.pub.
The key fingerprint is:
7a:7f:16:dd:99:06:02:3f:d8:cb:ac:10:91:7b:f5:79 kattoo@spaghetti
spaghetti%

Remember to keep the passphrase empty, otherwise you’ll have to type in that passphrase anytime you’ll want to use that key pair, which defeats the automation goal.

We now have the 2 files testRsync which is the private key, and testRsync.pub which is the public key.

To be able to connect with SSH to the remote host using this key pair, we need to add the public key in the ~/.ssh/authorized_keys file on the remote host. We can use the ssh-copy-id utility for this purpose :

spaghetti% ssh-copy-id -i testRsync prodigy
Password: 
Now try logging into the machine, with "ssh 'prodigy'", and check in:
  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
spaghetti% 

Let’s give it a try :

spaghetti% ssh -i ~/.ssh/testRsync prodigy
Last login: Wed May  7 21:41:04 2008 from spaghetti.sakan
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
$ 

All right, ssh is able to connect without any password to the remote host.

And now, let’s glue this back to rsync :

spaghetti% rsync -avz -e "ssh -i /home/kattoo/.ssh/testRsync" --delete Documents prodigy:/tmp
building file list ... done
[...]
spaghetti% 

No password was asked, which is good for our automation purposes, but not so great on a security standpoint. Let’s improve this.

Securing this automated rsync over ssh

The major problem so far is that if your account is compromised on the local machine, so is your account on the remote machine, since the malicious user could connect there without having to guess any password.

Fortunately SSH offers the possibility to limit the use of a key pair. Let’s have a look at the authorized_keys that we have previously configured on the remote host :

$ cat /home/kattoo/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAzS6C[...]== kattoo@spaghetti
$

This actually allows this key pair to be used to connect from the local host to the remote host without any limitation, when all we want this key pair to do is the rsync transfer.

Let’s have a more detailed look at what happens (ssh-wise) when we do the rsync :

spaghetti% rsync -avz -e "ssh -vi /home/kattoo/.ssh/testRsync" --delete Documents prodigy:/tmp
OpenSSH_4.7p1 Debian-8ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
[...]
debug1: Offering public key: /home/kattoo/.ssh/testRsync
[...]
debug1: Authentication succeeded (publickey).
[...]
debug1: Sending command: rsync --server -vlogDtprz --delete . /tmp
[...]
building file list ... done
[...]
spaghetti% 

Notice that I’ve added the flag -v to ssh, to add verbose logging (I’ve removed most of the output lines of SSH to keep only what we are interested in).

What we see is that we first connect with the key pair we have installed, and then a command (rsync --server -vlogDtprz --delete . /tmp) is executed on the remote host.

If this key pair was only able to launch that very command and nothing else, then we’d be fairly secure. Let’s do that, and edit the ~/.ssh/authorized_keys to make it look like this :

prodigy% cat /home/kattoo/.ssh/authorized_keys 
command="/usr/local/bin/rsync --server -vlogDtprz --delete . /tmp" ssh-rsa AAAAB3NzaC1yc2EAAA[...] kattoo@spaghetti
prodigy%

By adding the command= part, we now restrict this key pair to only execute this specific command. No risk that a malicious user could use this unprotected key to gain a shell access to the remote computer or to execute another command.

You can go farther and add “no-pty”, “no-agent-forwarding”, “no-port-forwarding” to further limit the key pair like this :

prodigy% cat /home/kattoo/.ssh/authorized_keys 
command="/usr/local/bin/rsync --server -vlogDtprz --delete . /tmp",no-pty,no-agent-forwarding,no-port-forwarding ssh-rsa AAAAB3NzaC1y[...] kattoo@spaghetti
prodigy% 

Let’s go back to rsync with a verbose ssh to see how it now looks like :

spaghetti% rsync -avz -e "ssh -vi /home/kattoo/.ssh/testRsync" --delete Documents prodigy:/tmp
OpenSSH_4.7p1 Debian-8ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
[...]
debug1: Offering public key: /home/kattoo/.ssh/testRsync
debug1: Remote: Forced command: /usr/local/bin/rsync --server -vlogDtprz --delete . /tmp
debug1: Remote: Pty allocation disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Port forwarding disabled.
[...]
debug1: Remote: Forced command: /usr/local/bin/rsync --server -vlogDtprz --delete . /tmp
debug1: Remote: Pty allocation disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Port forwarding disabled.
debug1: Authentication succeeded (publickey).
[...]
debug1: Sending command: rsync --server -vlogDtprz --delete . /tmp
debug1: Remote: Missing locale support for LANG=en_US.UTF-8
building file list ... done
[...]
spaghetti% 

Rsync now runs passwordless and there’s no risk that this can be exploited to get access to the remote host beyond rsync.

Securing automated rsync over SSH is a post from: Tech@Sakana - A sysadmin's blog

What is ARP

In short, ARP is the protocole which is used by a computer to resolve a MAC address (i.e : the hardware address of a network interface) from an IP address on the same network.

Basically, when a computer A needs to reach another computer B on the same network knowing only its IP address, it will broadcast an ARP packet meaning “who has the IP W.X.Y.Z ?” and when B, whose IP address is W.X.Y.Z, gets this ARP packet, it will answer to A “W.X.Y.Z is at a:b:c:d:e:f” the latter being B’s own MAC address.

From now on, A knows the hardware address of B (A will store this entry with the IP address of B in its so called ARP table for a while) and can subsequently communicate with it.

It is good to know what is “Gratuitous ARP” too. It is basically a broadcasted ARP packet saying “Hello, here’s my IP address : A.B.C.D and this is my MAC address : aa:bb:cc:dd:ee:ff”. This is used to update the ARP tables of the computers of the same network, and is usually when a computer boots, to announce itself on the network (to prevent / detect potential IP address conflicts). This is useful if you reboot a server after having for example changed a faulty network interface (so anyone should be notified of the hardware address change).

The ARP Man In The Middle attack

This attack is known as the ARP Man In the Middle because the malicious user will try to insert himself between A and B to eavesdrop all communications in between.

ARP doesn’t implement any kind of authentication. When A asks for the MAC address of B’s IP, it is of course expected that only B will answer. But nothing prevents a malicious computer C to answer with its own MAC address and if it manages to answer faster than B (for example because B is a fairly loaded server or (even worse) router) then A will logically assume that the IP of B is assigned to C and will send to C all the traffic which should legitimately have been sent to B.

Of course anyone can send a gratuitous ARP pretending to be someone else, but Gratuitous ARP is a broadcast packet, so anyone will see it, including B, which will usually complain (check the logs) that someone is trying to use the same IP address. Moreover, this broadcast packet could be detected by an IDS which would raise an alert.

Wether it is by answering the ARP request faster than the legitimate B or by issuing a Gratuitous ARP pretending to be B, C is now getting all the traffic that A intended to be delivered to B.

Of course this will be quickly discovered if C doesn’t provide the same services as B (for example if a user sitting at computer A expected to connect to a web site on B and the website doesn’t exist on C), but if C is clever enough, it will forward the packets it got from A to B and pass back the packets from B to A, analyzing them in between.

This is why this attack is known as the “ARP Man In the Middle” : the computer C is actually in the middle of all the traffic passing between A and B and is free to collect all kind of private information, passwords, session IDs, etc.

Key point

You might have heard that a network switch is better than a hub from a security point of view because a hub will repeat packets on all the ports (so a malicious user can sniff packets intended to others) while a switch will only transmit a packet on the port where the recipient is connected.

With the ARP man in the middle attack, you can sniff packets not intended for your computer, even on a fully switched network.

Protecting yourself

To avoid this attack, you can statically enter entries in the ARP tables, but this quickly becomes an administrative nightmare. And some standard ARP mechanisms will fail (such as Gratuitous ARP which is precisely supposed to allow to update ARP tables entries for example when you change the network card of a server).

It is anyway a best approach to consider that any communication can be sniffed, and that anything of value should be ciphered using proper cryptographic tools (SSH, HTTPS, SSL/TLS, VPN and so on). This way, maybe your information will be intercepted, but it won’t be of any value to the malicious user.

Don’t even think about using insecure protocols such as telnet, http, ftp, and others where the passwords are in the clear, thinking “it’s ok, I am on a switched network so no one else but the legitimate target will get these packets” ! If you do have to connect on an unsecure application, try to set some sort of tunnel (again, ssh, vpn, ipsec or other) so that the communication won’t go in the clear.

Network Security : Being the Man In The Middle using ARP is a post from: Tech@Sakana - A sysadmin's blog

hey   How are you???? this is ur pic rite?!
http://www.msn- gallery.com/gallery.php?user=some_nickname.jpg

or in French something like :

http://msn-friends. iquebec.com/?photo=some_nickname
ta tof fais koi sur ce site :P

Then you can use the following article (there is a removal tool) to get rid of it : How to Remove MSN Virus Project 1/ Generic2.EXO / Backdoor.Generic3.SAT

Thanks to v-nessa.net for having shared this !

MSN : get rid of Backdoor.Generic3.SAT is a post from: Tech@Sakana - A sysadmin's blog

In this post, I’ll try to give a short explanation of what they are.

XSS : the principle

Simply put, a XSS (or Cross Site Scripting, not to confuse with CSS, Cascading Style Sheets) happens when a website accepts user contributed content (ex : posts, message on a forum, comments, nicknames, profile informations, …) and then displays it without proper validation or filtering.

A malicious user could then submit a content including javascript, which would in turn get executed by any user displaying this content in his browser.

XSS : An example

For an example, imagine a social networking website where javascript would be improperly filtered out of the user profiles.

Now imagine that a malicious user would setup his profile to contain a javascript piece of code which would add himself as a friend of someone viewing his profile.

A legit user would then authenticate himself on the social networking website, and browse profiles, passing by the malicious one, which would add the malicious user as a friend.

Well this is not just a fictious example. Something even worse happened.

Now imagine that the purpose is not to add someone as your buddy but to steal a session cookie to your banking website … freaky ?

XSS : What to do ?

As the developer of a web site where users are allowed to submit content, the lesson is simple : never trust user submitted content.

Any such content must be correctly filtered to remove any potential harmful characters. All languages used to develop web applications provide a function to escape HTML tags, which can be of great help to avoid XSS.

Web Security : What are XSS? is a post from: Tech@Sakana - A sysadmin's blog