Hamilton Vera

Enabling serial port in iMX27ADS

diff –exclude CVS –exclude .git -uNr linux-2.6.22/arch/arm/mach-mx27/board-mx27ads.h linux-2.6.22.modified/arch/arm/mach-mx27/board-mx27ads.h
— linux-2.6.22/arch/arm/mach-mx27/board-mx27ads.h     2009-10-23 19:03:32.000000000 -0200
+++ linux-2.6.22.modified/arch/arm/mach-mx27/board-mx27ads.h    2009-10-23 19:03:00.000000000 -0200
@@ -73,7 +73,7 @@
#define UART2_ENABLED           1
/* UART 3 configuration */
#define UART3_MODE              MODE_DCE
-#define UART3_IR                IRDA
+#define UART3_IR                NO_IRDA
#define UART3_ENABLED           1
/* UART 4 configuration */
#define UART4_MODE              MODE_DTE

October 23, 2009 Posted by hvera1981 | Uncategorized | | No Comments Yet

Fighting Back PHP Reverse Shell

To avoid PHP reverse shell, just disable some functions in your php.ini:

disable_functions =system,passthru,escapeshellcmd,proc_open,apache_child_terminate,apache_get_modules,apache_get_version,

apache_getenv,apache_lookup_uri,apache_note,apache_request_headers,apache_reset_timeout,ap

This can handle this threat

October 1, 2009 Posted by hvera1981 | Apache | | No Comments Yet

Installing Python Setuptools

Using Python 2.6.x

wget http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c9-py2.6.egg#md5=ca37b1ff16fa2ede6e19383e7b59245a

sh setuptools-0.6c9-py2.6.egg

September 17, 2009 Posted by hvera1981 | Uncategorized | | No Comments Yet

Compile Kernel in Slackware64

cd /usr/src

wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.tar.bz2

tar xvfj linux-2.6.31.tar.bz2

cd /var/adm/packages

removepkg *kernel*

cd /usr/src

ln -s linux-2.6.31 linux

cd /usr/include

rm -R scsi
ln -s /usr/src/linux/arch/ia64/include/asm

ln -s /usr/src/linux/include/asm-generic

ln -s /usr/src/linux/include/linux

ln -s /usr/src/linux/include/mtd

ln -s /usr/src/linux/include/rdma

ln -s /usr/src/linux/include/scsi

ln -s /usr/src/linux/include/sound

ln -s /usr/src/linux/include/video

cd /usr/src/linux

make mrproper

make menuconfig

->Configure your kernel

make

make install

September 17, 2009 Posted by hvera1981 | Uncategorized | | No Comments Yet

Nome de alguns objetos em inglês

Just to poke fun at my friend Alan , I will take over the world!

É estranho como o nome de objetos que em português que são formados por palavras compostas (formado por duas/mais palavras distintas) são completamente diferentes em inglês. Este novo post conterá palavras que em inglês não são traducões obvias das mesmas em portugues.

abaixo-assinado – petition
algodão-doce – candyfloss
alto-astral – in a very good mood
alto-falante – speaker
alto-forno – blast furnace
ano bissexto – leap year , intercalary year
arco-íris – rainbow
arranha-céu – skyscraper
asa-delta – hang glide

B:
banho-maria – double boiler ou bain-marie
batata-doce – sweet potato (tradução direta)
bate-boca – argument
bem-sucedido – successful
bem-vindo – welcome
borracha – eraser

C:
cabeça-dura – stubborn ou difficult
caneta tinteiro – fountain pen
casa decimal – decimal place
cofre-forte – vault
copo descartável – paper cup
corrente de emails (induzir alguem a repassar email) – chain letters

D:
dedo-duro – snitch
diapasão – tuning fork (este mereceu entrar na lista, pois o nome em ingles e’ uma palavra composta)

F:
feira-livre – street market

G:
guarda-chuva – umbrella (este quase todo mudo sabe)
guarda-costas – bodyguard
guarda-roupa – wardrobe

M:
máquina de datilografar – typewriter
maria-vai-com-as-outras – follow like sheep
matéria-prima – raw material
mochila – schoolbag
motor de quatro-tempos – four-stroke engine

R:
recém-casado – just married
recém-nascido – newborn
roda-gigante – Ferris wheel ou observation wheel

S:
saca-rolhas – bottle openers

September 16, 2009 Posted by hvera1981 | Uncategorized | | No Comments Yet

Apache SSL with Virtual Hosts Using SNI

SSL with Virtual Hosts Using SNI

Summary

Using name-based virtual hosts with SSL adds another layer of complication. Without the SNI extension, it’s not generally possible (though a subset of virtual host might work). With SNI, it’s necessary to consider the configuration carefully to ensure security is maintained.

(Note: this page is just about support that comes with the Apache web server. Alternatives such as mod_gnutls are another topic.)

The Problem

The problem with using named virtual hosts over SSL is that named virtual hosts rely on knowing what hostname is being requested, and the request can’t be read until the SSL connection is established. The ordinary behavior, then, is that the SSL connection is set up using the configuration in the default virtual host for the address where the connection was received.

While Apache can renegotiate the SSL connection later after seeing the hostname in the request (and does), that’s too late to pick the right server certificate to use to match the request hostname during the initial handshake, resulting in browser warnings/errors about certificates having the wrong hostname in them.

And while it’s possible to put multiple hostnames in a modern certificate and just use that one certificate in the default vhost, there are many hosting providers who are hosting far too many sites on a single address for that to be practical for them.

Server Name Indication

The solution is an extension to the SSL protocol called Server Name Indication ( RFC 4366), which allows the client to include the requested hostname in the first message of its SSL handshake (connection setup). This allows the server to determine the correct named virtual host for the request and set the connection up accordingly from the start.

With SNI, you can have many virtual hosts sharing the same IP address and port, and each one can have its own unique certificate (and the rest of the configuration).

Prerequisites to use SNI

Use OpenSSL 0.9.8f or later
Build OpenSSL with the TLS Extensions option enabled (option enable-tlsext; OpenSSL 0.9.9 might have this enabled by default).
Apache must have been built with that OpenSSL (./configure –with-ssl=/path/to/your/openssl). In that case, mod_ssl will automatically detect the availability of the TLS extensions and support SNI.
Apache must use that OpenSSL at run-time, which might require setting LD_LIBRARY_PATH or equivalent to point to that OpenSSL, maybe in bin/envvars. (You’ll get unresolved symbol errors at Apache startup if Apache was built with SNI but isn’t finding the right openssl libraries at run-time.)

How can you tell if your Apache build supports SNI? If you configure multiple name-based virtual hosts for an address where SSL is configured, and SNI isn’t built into your Apache, then upon Apache startup a message like “You should not use name-based virtual hosts in conjunction with SSL!!” will occur in the error log. If SNI is built in, then the error log will show “[warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)”.

The client browser must also support SNI. Here are some browsers that do:

Mozilla Firefox 2.0 or later
Opera 8.0 or later (with TLS 1.1 enabled)
Internet Explorer 7.0 or later (on Vista, not XP)
Google Chrome
Safari 3.2.1 on Mac OS X 10.5.6

(per Wikipedia)

Changes in configuration to use SNI

There is one new directive related to using SNI with name-based virtual hosts, SSLStrictSNIVHostCheck, which controls whether to allow non SNI clients to access a name-based virtual host. (Link to Apache doc for that directive)

The first (default) vhost for SSL name-based virtual hosts must include TLSv1 as a permitted protocol, otherwise Apache will not accept the SNI information from the client and it will be as if the client did not support SNI at all.

Since the first (default) vhost will be used for any request where the provided server name doesn’t match another vhost, it is important that the first vhost have the most restrictive access control, otherwise clients can access restricted resources by sending a request for any unknown hostname. (This isn’t actually any different from using virtual hosts without SSL.)

Environment variables

When Apache supports SNI and the client provided the hostname using SNI, the new environment variable SSL_TLS_SNI will be set to the hostname that the client provided.

Scenarios

SNI/Request hostname mismatch, or SNI provides hostname and request doesn’t.

This is a browser bug. Apache will reject the request with a 400-type error.

Client doesn’t support SNI.

If Apache has SNI support, and a request without the SNI hostname is received for a name-based virtual host over SSL, and SSLStrictSNIVHostCheck is on, it will be rejected (403) and this message logged:

[error] No hostname was provided via SNI for a name based virtual host

If SSLStrictSNIVHostCheck is off, then the request will be handled as if the server did not have SNI support; see above.

Examples

Server configuration

# Ensure that Apache listens on port 443
Listen 443

# Listen for virtual host requests on all IP addresses
NameVirtualHost *:443

# Go ahead and accept connections for these vhosts
# from non-SNI clients
SSLStrictSNIVHostCheck off

<VirtualHost *:443>
  # Because this virtual host is defined first, it will
  # be used as the default if the hostname is not received
  # in the SSL handshake, e.g. if the browser doesn't support
  # SNI.
  DocumentRoot /www/example1
  ServerName www.example.com

  # Other directives here

</VirtualHost>

<VirtualHost *:443>
  DocumentRoot /www/example2
  ServerName www.example2.org

  # Other directives here

</VirtualHost>

Source http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

September 2, 2009 Posted by hvera1981 | Apache | | No Comments Yet

Installing Slackware on encrypted volumes

=========================================

Introduction

————

Increasingly desired in any modern Linux distribution is the ability to

install onto an encrypted partition (or drive, or volume). Especially for

people with a laptop who are traveling a lot, it adds a lot to the security

of your data if access to that data is denied to the potential thief of

your computer.

Slackware 12.0 has improved support for LVM built into the installer.

With a little more effort, the installer offers the opportunity to use

transparent encryption on the partitions/volumes/disks where you install

Slackware. You can combine the use of LVM and encryption to minimize the

number of times you need to enter an unlock passphrase.

If you want to know more about setting up and using LVM during the

installation, read the file ‘README_LVM.TXT’.

Slackware uses device-mapper and cryptsetup to achieve transparent

encryption of your data partitions and your swap. Cryptsetup uses a

concept called LUKS (Linux Unified Key Setup) which enables you to change

your unlock password for the encrypted volume without having to re-encrypt

all of your data. You can even assign multiple passphrases to an encrypted

volume, so that other people besides you are able to unlock the encryption

without the need to know _your_ passphrase.

When preparing a partition for transparent encryption with cryptsetup,

the program will ask you for a password. This password is used to encrypt

another randomly generated password and this particular password is used

to actually encrypt the data inside the mapped volume. Cryptsetup will

create a mapped device and make this block device available under the

‘/dev/mapper’ directory. Any data read from or written to this mapped device

will automatically be decrypted from / encrypted to the actual partition.

A big NOTE finally. When you encrypt your root filesystem, you will have

to make sure that there will be at least one (small) partition which is left

unencrypted. This partition will contain your kernel(s) to boot from,

the initrd that is needed with encrypted volumes, and you need to install

LILO either to the MBR – or if that is not possible, into the root sector

of this small unencrypted partition. You will probably guess why we can

not use an encrypted partition for this…

Using cryptsetup during Slackware installation

———————————————-

We are going to encrypt our partitions/volumes before installing

Slackware onto them.

After the computer boots up from the install CD/DVD (or USB flash disk,

or PXE) and you find yourself at the ‘#’ prompt, the first thing to do is

use ‘fdisk’ to create any partitions you need for your Slackware. Next, use

‘cryptsetup’ to prepare the partitions you intend to be encrypted. Note:

this section of the README concerns itself with setting up encrypted *data*

partitions. If you want to know how to configure an encrypted *swap*

partition, skip to the section called “Encrypted swap”.

Suppose, you want to encrypt the partition called ‘/dev/sda2′ and use it

as your ‘/home’ filesystem. If your actual partition is called differently,

PLEASE use that partition name in the next series of examples. Several

of the commands shown below will irrevocably destroy any data that you

currently have on the partition.

* To begin with, we are going to fill the partition with random data. This

will make it a lot harder for any forensics expert to determine where your

encrypted data resides on that partition after we’re finished installing

Slackware onto it. The process will take a long time – depending on the

size of your partition it may take hours or more. if you’re not _too_

concerned with the possibility of an FBI agent confiscating your computer,

you can skip this command:

# dd if=/dev/urandom of=/dev/sda2

* Prepare the partition for encryption. You will be asked twice to enter

a passphrase. Note that a passphrase is not limited to a single word. The

passphrase may contain spaces. We will use a key size of 256 bits. The

default cipher is ‘aes’, with mode ‘cbc-essiv:sha256′ which is safe enough.

# cryptsetup -s 256 -y luksFormat /dev/sda2

You can dump information about the encrypted partition to your console by

running the following command:

# cryptsetup luksDump /dev/sda2

* Now we will open the encrypted partition and let the devicemapper create

a mapped block device. We will use the mapped device which behaves just

like an ordinary disk partition when we get to the TARGET selection in

’setup’. The mapped device nodes will be made available in the directory

‘/dev/mapper’. The command will ask you for the passphrase which you entered

during the “luksFormat” operation. The last argument that the command takes

is the name of the mapped device. We will call our mapped device ‘crypthome’

- it will be available for use as the block device ‘/dev/mapper/crypthome’.

# cryptsetup luksOpen /dev/sda2 crypthome

We’ve now finished our preparations, and it is time to start the ’setup’

program and install Slackware. This setup does not differ at all from the

setup you have become used to. The only notable difference lies in the

names of the devices you will select for your target partitions. Be sure

to read until the end of the story though, because we will have to do some

postprocessing in order to make your encrypted partitions available after

reboot (setup can not yet do all of this automatically).

In setup, under “SWAP”, proceed as usual and configure a normal

unencrypted swap partition, even if you want to have your swap encrypted. We

will take care of swap encryption after the installation of Slackware

finishes.

In setup, when you choose “TARGET” in the main menu, you will notice that

the mapped device is available in the ‘Linux partition’ selection as

“/dev/mapper/crypthome”. Select the partition you designated for your

root (‘/’) filesystem, and next select “/dev/mapper/crypthome” for your

‘/home’ filesystem. Create any filesystem you like on them. My favorite

fstype still is ext3, but you can choose xfs or jfs for stability and speed.

NOTE: The underlying partition will *also* be visible in the target selection

menu. Be very careful NOT to select this device (‘/dev/sda2′ in our

example) for any other filesystem you wish to create, or you will

destroy the data on the encrypted partition.

At the end of the Slackware installation when you select “Exit”, don’t

reboot just yet. We are going to create a configuration file for

the cryptsetup program, called ‘/etc/crypttab’. This file contains the

information cryptsetup needs for unlocking your encrypted volume and mapping

it to the correct device name. The file ‘/etc/crypttab’ contains lines of the

format: “mappedname devicename password options”. Since we are still inside

the installer, the root filesystem of our fresh Slackware installation is

still mounted under ‘/mnt’. For our example where we encrypted ‘/dev/sda2′

and mapped the unlocked device to ‘/dev/mapper/crypthome’, we need this

single line in ‘/etc/crypttab’:

crypthome /dev/sda2

So, we need to run the command:

# echo “crypthome /dev/sda2″ > /mnt/etc/crypttab

in order to create the file with the required content. You can of course

also just start the ‘vi’ editor and add the above line. When the password

is not listed in the crypttab file (potentially very unsafe of course)

cryptsetup will ask you for the password when your computer boots.

Encrypted swap

==============

Now, remember we have configured the swap partition as usual during the

installation of Slackware, which means we have not yet configured it as an

encrypted swap. We are going to take care of that omission right now. it

really is very simple and straight-forward. It is also independent of

whether or not you are using encryption for any other (data) partition. Add

the following line to the ‘crypttab’ file on your fresh installation

of Slackware – for the sake of this example I am assuming that the swap

partition you chose is ‘/dev/sda3′:

cryptswap /dev/sda3 none swap

You can use the ‘vi’ editor to add this line to ‘/mnt/etc/crypttab’.

You can also choose to run the following command which adds that line to

the end of the file:

# echo “cryptswap /dev/sda3 none swap” >> /mnt/etc/crypttab

We need to edit the ‘fstab’ file of your Slackware installation so that

the correct device will be used for the swap after your computer reboots

(the device ‘/dev/sda3′ will no longer be useful, but ‘/dev/mapper/cryptswap

will’). The line in ‘/mnt/etc/fstab’ for your swap will look like this at

first:

/dev/sda3 swap swap defaults 0 0

and you will have to change it so that it becomes like this:

/dev/mapper/cryptswap swap swap defaults 0 0

These two edits are sufficient. The Slackware boot-up process will take

care of the rest. At shutdown of your Slackware, the encrypted swap partition

will be reformatted as a normal unencrypted swap, so that any other OSs

you might be running in a multi-boot configuration will have no problems in

using this swap partition as well.

NOTE: the swap partition is encrypted with a new randomly generated key every

time your computer boots.

There is no need to ever enter a passphrase!

Encrypted root filesystem

=========================

You can go one step further than merely encrypting your ‘/home’

filesystem’s partition. You can choose to encrypt _all_ of your Slackware

partitions, including the root partition. In this case you will have to

perform some additional post-install configuration before you reboot your

Slackware box.

* Be sure to create a small partition which you leave *unencrypted*. Tell

the installer to mount it under ‘/boot’. The kernel and the initrd (with

the cryptsetup and additional required kernel modules) will go there,

and LILO will have to be installed to the root sector of that partition

in case you are not able to use the MBR.

* Perform a Slackware install just like I described above, creating

additional encrypted partitions and mapping them to appropriate names -

for this example I assume that you map the encrypted root partition

‘/dev/sda1′ to ‘cryptroot’. When the LILO configuration pops up, tell lilo

that your root partition is ‘/dev/mapper/cryptroot’. Lilo will try to install

and fail, and will tell you so. It will however have written a ‘lilo.conf’

file which we can edit in a follow-up action. Proceed with the installation

and at the end, exit the setup program but do _not_ reboot just yet.

* After the return to the command prompt, perform a ‘chroot’ into the new

installation. All the filesystems are still mounted, so we can run the

following commands:

# mount -o bind /proc /mnt/proc

# mount -o bind /sys /mnt/sys

# chroot /mnt

* Next, now that we are in the chroot, create the initrd with LVM and

CRYPT support – or else your Slackware computer will not be able to

proceed past the initial stage of booting the kernel. The initial ramdisk

(initrd) contains a small filesystem with the tools needed to unlock the

root filesystem, so that the kernel can start the init program. In the

example command line below which creates the ‘initrd.gz’ image I assume

that the root filesystem is ‘ext3′, we used the mapped device ‘cryptroot’

for the root filesystem on the real partition ‘/dev/sda1′, and are running

the Slackware 12.0 default SMP kernel ‘2.6.21.5-smp’:

# mkinitrd -c -k 2.6.21.5-smp -m ext3 -f ext3 -r cryptroot -C /dev/sda1 -L

The resulting initrd image will be written to the file ‘/boot/initrd.gz’

by default. We still need to tell lilo about this initrd, so open the

configuration file ‘/etc/lilo.conf’ in an editor such as vi or pico – it

should already have been generated by the ‘liloconfig’ part of setup. Look

for the “Linux bootable partition config” and add a line for the initrd -

it should end up looking somewhat like this:

image = /boot/vmlinuz

initrd = /boot/initrd.gz

root = /dev/mapper/cryptroot

label = linux

read-only

* We have one additional change to make, and that is almost at the top

of the file. Look up the line that says “boot = /dev/mapper/cryptroot”

and which was the reason for lilo to fail installing itself. Change the

boot device to name of the small *unencrypted* partition you’ve created

and which is mounted under ‘/boot’. Assuming the name of that partition is

‘/dev/sda4′, the “boot =” line must become like this:

boot = /dev/sda4

We are done. Write the changes, exit the editor and run the command ‘lilo’.

Lilo will issue a couple of warnings concerning a difference in what

‘/proc/partitions’ reports and what lilo thinks are the available partitions,

but it is safe to ignore these.

Reboot now, and you will be presented with a “Enter passphrase: “

prompt. After entering the passphrase which unlocks your root filesystem,

the system will boot into Slackware. If there are other encrypted partitions,

you will be prompted for their respective passphrases, too.

Additional passphrases, keyfiles

================================

The cryptsetup program assigns 7 ‘key slots’ to any partition or volume

it encrypts. Each of those seven slots can contain a key to unlock the

partition’s data. The key can be a passphrase, but the content of a

*keyfile* is another option. You can then pass the name of a file as a

parameter to cryptsetup in order to unlock an encrypted volume so that

you won’t have to type a passphrase. This creates the possibility to

use a keyfile on a removable USB flash disk for unlocking your Slackware

computer. Slackware has partial support for keyfiles: if the file can be

found, it will be used and you won’t have to type a passphrase. A file on a

USB stick will *not* be found on boot because the stick’s filesystem is not

mounted. Future versions of Slackware will support USB sticks as unlocking

mechanism. For now, if you encrypt your root filesystem, you will have to

enter a passphrase to boot into it. After the root filesystem is unlocked

and mounted, it is completely safe to have a keyfile for _additional_

encrypted filesystems stored in for instance the ‘/root’ directory. That

way, you have only one passphrase to type. Alternatively, you can setup

LVM, encrypt the underlying physical device, and create logical volumes

on the mapped device. Once that encrypted physical device is unlocked all

the logical volumes you’ve created and which contain your filesystems are

accessible without having to enter additional passphrases.

Good luck with your Slackware with encrypted partition(s)!

=============================================================================

Author:

Eric Hameleers <alien@slackware.com> 26-jun-2007

Wiki URLs:

http://www.slackware.com/~alien/dokuwiki/doku.php?id=slackware:setup