Monday 16 October 2017

Locales cosmetics. Kali on Raspberry Pi

After installation of the Kali Linux on a Raspberry Pi platform (at least in the Kali GNU/Linux Rolling) I noticed that the Xfce login screen shows in the upper right corner the full list of local keyboards installed (the locales). I don't like it! :) I don't need other than C and US keyboard and more than that, you can save some precious space on the Raspberry Pi storage.

The following post is purely cosmetic. There is no problem with the default installation despite the huge and not necessary keyboard list.

So, let's free some space!

1. First, after login (shell or X), run in console:
locale -a (Display a list of all available locales)
or
locale -a -v (As above but the -v option causes the LC_IDENTIFICATION metadata about each locale to be included in the output)


2. Make sure the file /etc/default/locale exists (if not, create it) and has proper content, such as:
LANG="en_US"
LANGUAGE="en_US:en"
or only
LANG=C.UTF-8

3. Delete all (but C.UTF-8 and en_US.utf8) generated locale data:
rm -rfv /usr/lib/locale/*

Generate again the new locales:
locale-gen

4. Restart the Pi or stop/start the X service:
service lightdm stop
service lightdm start


Of course, if you need more keyboards (or something different than US) you can in the step 3.

Thursday 28 September 2017

SSH over proxy or over multiple hosts

Well, sometimes an evil sysadmin won't let us to live in peace and close all the ports that you need (of course, except the ssh).

Presuming that you already have a host with ssh and Internet access (host1 in the following example) you can use it as a "jump" platform or as SOCKS proxy server to reach a target host (host2 here).

+-----------+<--port 22-->+---------+<--port 2222-->+----------+
|   mybox   |-------------|  host1  |---------------|   host2  |
+-----------+             +---------+               +----------+
localhost:8080            "jump" host                  target


Using as proxy server:
(in this example we have two steps, but you can join those steps in one. Hint:  use && as in command1 && command2 and -f ssh parameter).

mybox:~$ ssh -D 8080 -N -p 22 user@host1
user@host1's password:

Type the password and let this terminal open and open another one.

mybox:~$ ssh -X -p 2222 user2@host2 -o ProxyCommand="/usr/bin/connect -5 -S localhost:8080 %h %p"

Jumping over ssh:
mybox:~$ ssh -t -X -p 22 user@host1 ssh -X -p 2222 user@host2

You may ask yourself "Why not using the second example all the time because is simple and more convenient???". 
Well, the simple answer is that you can not use X11 forwarding (-X parameter) if the host1 had not implemented the X11 forwarding rule in the sshd_config. So, no X11 forwarding in this case.
The first example (proxy), because is a SOCKS tunnel, have no importance if the host1 have or not have the X11 forwarding rule active. As a tunnel, it pass the packets between the two ends of it.

Wednesday 13 September 2017

WordPress - Administration Over SSL

There are at least two ways to redirect over a SSL connection the WordPress administration.

The most usual (and recommended ways) are:

1. In the wp-config.php file

Insert into the wp-config.php file the following line:

define('FORCE_SSL_ADMIN', true);

It must be inserted somewhere above wp-settings.php location.

2. Modify the Apache virtual host settings (or .htaccess file or the main httpd.conf)


# Force SSL for wp-admin folder and wp-login.php file
    RewriteEngine On
    RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
    RewriteCond %{HTTPS} !=on [NC]
    RewriteRule ^/?(wp-admin/|wp-login\.php) https://your-site.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]

# End Force SSL...


Notice!
For both ways, of course, you must also already have SSL configured on the server and a (virtual) host configured for the secure server before your site will work properly with these constants set to true.

A more comprehensive reference here:
https://codex.wordpress.org/Administration_Over_SSL

rc.local issue and init.d scripts


Well, the only issue with rc.local file is that this file does not exist in modern Debian flavors.
For the old fashion guys like me that is an issue, at least for ten minutes. :)

So, what can we do about? We have at least two options:
To forgot about rc.local and start your task using init.d scripts, or
To enable the rc.local script.

Both ways have pluses and minuses and is up to you what way you will choose. For myself, I prefer the first way. Yes, it's a little bit strange to make a script for each task you will run at boot but you have a better granularity and control over the process.

Nevertheless, one way or another, following the next steps you will have a script that run on boot (or in rcS.d, or in rcX.d) :)

The first option:


Making init.d scripts, copy and paste this code and do the modifications in the start, stop sections. Save it to /etc/init.d/ folder and set the executions rights (chmod +x /etc/init.d/your-script-name).

#! /bin/sh
### BEGIN INIT INFO
# Provides:          your-script-name
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

# Some scripts that run always (it is not mandatory...)
touch /var/lock/your_script

# Carry out specific functions when asked to by the system
case "$1" in
 start)
    echo "Starting script your-script-name"
    echo "Some info about..."
    /usr/local/bin/your-script #of course, this is an example
    ;;
 stop)
    echo "Stopping script your-script-name"
    echo "Some info about..."
    killall -9 your-script #of course, this is an example
    ;;
 restart)
    $0 stop
    $0 start
    ;;
 *)
    echo "Usage: /etc/init.d/your-script-name {start|stop|restart}"
    exit 1
    ;;
esac

exit 0

##################### End script

# Adding the init.d script to default targets (in this case to level 2,3,4, and 5, see the script headers)
root@linuxhorizon:~# update-rc.d your-script-name defaults

# Removing
root@linuxhoriozn:/etc/rc2.d# update-rc.d -f your-script-name remove



The second option:


Making the rc.local script

root@linuxhorizon:~# cat > /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/put/your/script/here

exit 0
############### End rc.local

root@linuxhorizon:~# chmod +x /etc/rc.local
root@linuxhorizon:~# systemctl start rc-local
root@linuxhorizon:~# systemctl status rc-local



Now it's a good time for a coffee! :) By the way, do you know how it look the caffeine molecule? Probably you don't, so here it is, click to enlarge!

Tuesday 12 September 2017

The magic of REISUB

When everything goes wrong and you graphic interface (X) will stop responding (dead, hung, freeze etc.) there is a magic word who can save you from a disastrous reboot by powering down your computer

First, type "R" (the letter) while holding down Alt and SysRq (PrintScrn). This shortcut can give you the contorl over the keyboard letting you to switch to console mode (Ctrl-Alt-Fx, while x is is your terminal as F1, F2 etc.). If this is not working you can try the next step:

Type the phrase “REISUB” while holding down Alt and SysRq (PrintScrn) with about 1 second between each letter. Your system will reboot. 

For a shutdown, REISUO will do the trick. :)

But what are those letters do?

r – Puts the keyboard into raw mode, taking control of it away from the X server.
e – Sends the terminate signal to all processes, asking them to end gracefully.
i – Sends the kill signal to all processes, forcing them to end immediately.
s – Flushes data from your cache to disk.
u – Remounts all file systems read-only.
b – Reboots your computer.
o - Shutdown your computer.

You can try step by step one the letters, maybe you are lucky enough to gain control over your computer without rebooting (the letter B).

An Ubuntu cheat sheet could be found here: https://files.fosswire.com/2008/04/ubunturef.pdf

Friday 1 September 2017

The rkhunter (1.4.2) update issue

I found that the rkhunter v1.4.2 (Debian distro, I don't know about other flavors or versions) had a strange problem. Installed for the first time, I can not update it: 
host:/root# rkhunter --update
Invalid WEB_CMD configuration option: Relative pathname: "/bin/false"
Fixing this in config file (/etc/rkhunter.conf) by removeing /bin/false between quotes I had another error:
ns3:/etc# rkhunter --update
[ Rootkit Hunter version 1.4.2 ]

Checking rkhunter data files...
Checking file mirrors.dat                            [ Skipped ]
Checking file programs_bad.dat                       [ Update failed ]
Checking file backdoorports.dat                      [ Update failed ]
Checking file suspscan.dat                           [ Update failed ]
Checking file i18n versions                          [ Update failed ]
So, digging a little bit I found the following solution. All you need is to replace the followings in the /etc/rkhunter.conf file:
From UPDATE_MIRRORS=0     to UPDATE_MIRRORS=1
From MIRRORS_MODE=1       to MIRRORS_MODE=0
From WEB_CMD="/bin/false" to WEB_CMD=""
The funny thing is that in the rkhunter.conf comments, the recommended values are good. :)

Friday 30 June 2017

GoldenEye? No! Tuesday! And is much worse!

Tuesday's massive outbreak of malware that shut down computers around the world has been almost universally blamed on ransomware, which by definition seeks to make money by unlocking data held hostage only if victims pay a hefty fee. Now, some researchers are drawing an even bleaker assessment—that the malware was a wiper with the objective of permanently destroying data.

Full story here: https://arstechnica.com/security/2017/06/petya-outbreak-was-a-chaos-sowing-wiper-not-profit-seeking-ransomware/