Linux | n0on3.net

Posts Tagged ‘Linux’

Reverse shell with ssh

May 3rd, 2011
Write comment

Sometimes you need to access a machine which is behind a firewall or a NAT, such as your box at home. If you have access to another machine with a public address, here is a simple way to do that with just ssh. The following configuration is assumed:

The machine you want to access is running ssh daemon, listening on port 2200
The address of such machine is irrelevant since it is unreachable.
The machine you have access to is also running ssh daemon, e.g., listening on port 2201
Such machine has instead a reachable address, such as 6.6.6.6

Now, of course the first thing you have to do is reach the machine with public address from the machine behind the firewall or NAT and establish a connection to be used eventually as channel to forward the ssh connection. The following command does that via ssh, and tells the machine to forward any connection incoming on its port 2202 to localhost:2200 from the command issuer point of view.

ssh -p 2201 -NR 2202:localhost:2200 user@6.6.6.6

At this point you probably got it, you can access your home box by ssh’ing into 6.6.6.6 and then running the following command to access the other machine.

ssh -p 2202 user@localhost

It might also be nice to filter port 2202 from all sources except localhost, just in case your private box is not hardened as much as your public machines

CVE-2010-3081

September 20th, 2010
Write comment

Sometimes you just have to spread alerts such this one.
If you are running 64-bit Linux machines, then you should take care of this vulnerability, because there is also a public exploit that is being used to attack affected production systems. If your distribution has already provided a patch, you just have to update your system kernel. Otherwise, you should patch it yourself. A couple of links about that:

Ksplice developers also wrote a tool to check if your systems have been compromised by that exploit by looking for the backdoors it installs. You can find it here. In order to do the check, just download this source code file, compile it, and run it. You should see something like this:

$ gcc -o diagnose-2010-3081 diagnose-2010-3081.c
$ ./diagnose-2010-3081
Diagnostic tool for public CVE-2010-3081 exploit -- Ksplice, Inc.
(see http://www.ksplice.com/uptrack/cve-2010-3081)
 
$$$ Kernel release: 2.6.26-XX-XXX-XXX
$$$ Backdoor in LSM (1/3): not available.
$$$ Backdoor in timer_list_fops (2/3): not available.
$$$ Backdoor in IDT (3/3): checking...not present.
 
Your system is free from the backdoors that would be left in memory
by the published exploit for CVE-2010-3081.

Otherwise, your system is already compromised.
Patch this vulnerability and consider also running some analysis, because while this is a publicly known exploit, there are probably many bad guys with their own one.

Detach process from parent shell

August 17th, 2010
Write comment

When using UNIX or similar systems via CLI, you typically log in a shell as a single running process, spawned by another process such as any ssh-daemon if you are connecting remotely or by the gnome-terminal process if you are in a gnome-desktop environment, and so on ( by the way, you can check what is your shell spawned from with the pstree utility ). Anyway, from this shell you will probably provide commands, that wil launch programs, that will be put into concrete form by the OS spawning new processes ( actually, forking the current process and calling something like execve ).
While you can play with the launched processes with some jobs control techniques, sometimes you just want to start some programs that should be completed independently from the fate of your shell (e.g. you want to log out, or just to close your terminal emulator, or just your shell somehow dies). That means, in other words, that you may want to run something and then log out letting the machine do the job while you can go performing more pleasant tasks

.
This is also often seen as " turning a process into a daemon " , even if it’s not strictly correct.
This can be easily achieved with the nohup POSIX command that will instruct your process to ignore the SIGHUP signal if your shell dies (e.g. when you log out). To use it, you can just append the command you want to provide after the nohup invocation such as:

nohup ./my_time_consuming_script.sh and its args

By the way, if you use the bash shell, you can get the same result using the disown builtin command, that can remove jobs from the job table, or to mark jobs so that SIGHUP is not sent to them if the parent shell receives it. The syntax is:

disown [-ar] [-h] [jobspec ...]

with options meaning:

-h do not remove from job table
-a apply to all jobs
-r apply to running jobs only

That’s it, let the machine do the jobs and go sunbathing

SSH login without password

August 3rd, 2010
Write comment

Ok, this can be found pretty everywhere on the internet, but on the n-th time someone asked me how to use management scripts that do stuffs via SSH without have to enter one or more password, I need to write it here so that next time I’ll have no remorse in saying “go read it online, on my website”.

Well, here’s the story: you can connect via ssh to other hosts without entering your password as long as you can prove that you are authorized to login with that identity. This is achieved by placing a public key on the host you want to connect to, so that when you try to login an authentication handshake is prompted to your machine that is then supposed to own the corresponding private key and thus to be able to complete the handshake.

This is what happend behind, you won’t see anything of this during your ssh login. But in order to make this mechanism work, you have to place that public key on the host you want to connect to. Probably for this purpose you may want to use your public RSA key generated to use ssh, that you can find in ~/.ssh/id_rsa.pub where ‘~’ is your home folder ( please be careful not mismatching this with ~/.ssh/id_rsa that is your private key: instead take care of this file by setting proper permissions and/or encryption because this file represent your identity and if leaked, anyone can access any machine where your public key is placed to consider you an “authorized” user ).

The place where ssh daemon looks for authorized keys when someone try to connect to the system as the given user is, with very small imagination, the ~user/.ssh/authorized_keys file, where ~user is the home of the user you are trying to login as e.g. with ssh user@whaterver-host.com. So basically what you have to do is append your own ~/.ssh/id_rsa.pub to the remote ~user/.ssh/authorized_keys. Here is a command you can use ( you will have to prompt the password two last times ).

ssh user@whaterver-host.com 'if [ ! -d ~/.ssh ];then mkdir ~/.ssh; fi'; 
cat ~/.ssh/id_rsa.pub | \
  ssh user@whaterver-host.com 'cat >> ~/.ssh/authorized_keys'

Now you will be able to login to whaterver-host.com just with ‘ ssh user@whaterver-host.com ‘ without being prompted for any password, even from many machines if you keep your id_rsa pair with you across them.( But remember, keep it safe! )
Cheers!

Advanced Shell Scripting

May 21st, 2010
Write comment

Yesterday I delivered a lesson for the advanced Linux course arranged by LUG Roma3 at Roma Tre University on voluntary base. Here are the slides I sketched out for this occasion.

It’s not really “advanced” stuff, but sounds just better than “basics +1″

Change keyboard layout in Linux

April 28th, 2010
Write comment

Keybord gth There are several ways to change the keyboard layout in linux.
First, you can load a given keyboard translation tables with :

loadkeys <tablecode>

Alternatively, if you are in a X11 env, you can set the keyboard map using the X Keyboard Extension with:

setxkbmap <kbmapcode>

But if you want to permanently change the console keyboard layout, e.g. in Debian, you can reconfigure console-data and use the wizard to select the desired layout with: