OpEn iNfiDel

Generating SSL Key

2006-04-06T02:54:00.000-07:00

Step one - create the key and request:

# openssl req -new > new.cert.csr

Step two - remove the passphrase from the key (optional):

# openssl rsa -in privkey.pem -out new.cert.key

Step three - convert request into signed cert:

# openssl x509 -in new.cert.csr -out new.cert.cert -req -signkey
new.cert.key -days 365

The Apache-SSL directives that you need to use the resulting cert are:

SSLCertificateFile /path/to/certs/new.cert.cert
SSLCertificateKeyFile /path/to/certs/new.cert.key

Activating simultaneous login limit on Freeradius

2005-06-06T01:26:00.000-07:00

For those who are too lazy to read the Simultaneous-Use document in
Freeradius 1.0.1, here's how to do it, but I opted to use SNMP_Session
and BER modules:

1. Download SNMP_Session and BER from

http://www.switch.ch/misc/leinen/snmp/perl/

2. Extract and

#cd SNMP_Session-1.07/
#perl Makefile.PL
#make test
#make install

3. Edit /etc/raddb/users file and insert the following lines:

DEFAULT Simultaneous-Use := 1
Fall-Through = 1

(It may differ if you want to define it under a group, but it should
be one instance)

4. Edit /etc/raddb/nasspaswd and add:

<ip address of NAS> SNMP community

5. Restart radius

You're done!

Installing PERL modules in Unix/Linux

2005-06-06T00:44:00.000-07:00

There are 3 normal ways to install a Perl module on a Unix machine.
Which one you use will depend on a number of factors, the most important
one being whether you have root privileges on the machine.

1. Compile

The standard way to install a Perl module on Unix is to change into the
directory that was created when you unpacked the .tar.gz file, and then
type the following sequence of commands:

perl Makefile.PL
make
make test
make install

This will create a makefile for you, then compile the module, test it,
and put it in the correct location for you. This requires that you are
logged in as root, so that you can copy files to the Perl library
directory, and various other places on your system where the
installation will put files.

If you do not have root permissions on the machine where you want to
install the module, such as if you wish to install a module in your home
directory, just change one of those commands. Instead of

perl Makefile.PL

type

perl Makefile.PL PREFIX=/path/to/where/you/want/it

That will put all the files in that directory. In order to use modules
that are stored in that location, you will need to add the following
like to your Perl programs:

use lib /path/to/where/you/want/it

2. CPAN.pm

Perl comes with a very handy module called CPAN.pm that automates the
process of downloading and installing a Perl module. There are some
modules that are really helpful to have installed before you use
CPAN.pm. They are not absolutely required, but they make life a lot
easier. These modules are:

Digest::MD5
HTML::Parser
MIME::Base64
URI
libnet
libwww

You can download and install those modules as described in the section
above. Then you can load the CPAN.pm shell with the following command:

perl -MCPAN -e shell

This also requires that you are root.

The first time that you run the CPAN shell, you will need to make some
configurations. It's usually OK to select all the defaults. When you
come to the section about choosing a CPAN mirror, try to choose one that
is located near to you.

Once you have typed the above command, you will be at an interactive
prompt with a huge number of options to make your life easier. The only
ones that I will talk about here are the search feature, and the
installation feature.

To find a particular module, use the i command, followed by an
expression that you want to search for:

cpan> i /Time/

CPAN.pm will go out to the CPAN mirrror that you selected, download the
list of modules, and tell you which ones match the search word.

To install a module, just type:

cpan> install Time::CTime

CPAN.pm takes care of the whole process. It downloads the compressed
file, unpacks it, builds it, and installs it all for you, unless there
is a problem with the installation process. If there are other modules
on which this module relies, it will also download and install those.

3. Manually placing files

Occasionally, you will not be able to use any of the methods above to
install modules. This may be the case if you are a particularly under-
privileged user - perhaps you are renting web space on a server, where
you are not given rights to do anything.

It is possible, for some modules, to install the module without
compiling anything, and so you can just drop the file in place and have
it work. Without going into a lot of the detail, some Perl modules
contain a portion written in some other language (such as C or C++) and
some are written in just in Perl. It is the latter type that this method
will work for. How will you know? Well, if there are no files called
something.c and something.h in the package, chances are that it is a
module that contains only Perl code.

In these cases, you can just unpack the file, and then copy just the
*.pm files to a directory from which you will run the modules. Two
examples of this should suffice to illustrate how this is done.

IniConf.pm is a wonderful little module that allows you to read
configuration information out of a .ini-style config file. IniConf.pm is
written only in Perl, and has no C portion. When you unpack the .tar.gz
file that you got from CPAN, you will find several files in there, and
one of them is called IniConf.pm. This is the only file that you are
actually interested in. Copy that file to the directory where you have
the Perl programs that will be using this module. You can then use the
module as you would if it was installed ``correctly,'' with just the
line:

use IniConf;

Time::CTime is another very handy module that lets you print times in
any format that strikes your fancy. It is written just in Perl, without
a C component. You will install it just the same way as you did with
IniConf, except that the file, called CTime.pm, must be placed in a
subdirectory called Time. The colons, as well as indicating an
organization of modules, also indicates a directory structure on your
file system.

compiling kernel the Debian way

2005-03-30T23:04:00.000-08:00

No, I'm not avid fan of Debian, but I use it in work and I like it's speed and simplicity. For a note, here's how to compile kernel with Debian (Woody) in a flash.

First login to your Debian machine on the command line as root. Install the prerequisites that we need to compile the new kernel:

#apt-get install kernel-package ncurses-dev fakeroot wget bzip2

Then go to /usr/src:

#cd /usr/src

Then get the latest Linux kernel source (or the kernel source you need) from http://www.kernel.org/pub/linux/kernel/v2.4/:

#wget http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.23.tar.bz2

Unpack the kernel sources:

#tar xjf linux-2.4.23.tar.bz2

#cd linux-2.4.23/

It is normally a good idea to take the configuration of your existing (working!) kernel as a starting point for the configuration of your new kernel. Usually the current kernel configuration is saved in a file under /boot, e.g. /boot/config-2.4.18-bf2.4. We will load this configuration and then do the changes we desire (e.g. add quota support, iptables support, etc.).

make menuconfig

Then run the following commands:

make dep
make-kpkg clean
fakeroot make-kpkg –revision=custom.1.0 kernel_image

If the compilation stops with an error, run

make clean

and then re-run the previous commands starting with

make menuconfig

Change the kernel configuration where the error occurs (e.g., the compilation often gives back errors for some WAN modules, so leave them out if you do not need them). If no error occurs you will find the new kernel as a Debian package called kernel-image-2.4.23_custom.1.0_i386.deb under /usr/src.

cd ../

Now you can install the new kernel by doing the following:

dpkg -i kernel-image-2.4.23_custom.1.0_i386.deb

We are almost finished now. Reboot your machine:

shutdown -r now

and if everything is ok your machine should come up with the new kernel. You can run

uname -a

to verify that.

Good luck!

Linux lags Windows in new security report

2005-03-26T23:13:00.000-08:00

A report released today (by Security Innovations) indicates Windows Server 2003 may actually be more secure than its most popular Linux competitor when it comes to vulnerabilities
and the time it takes to patch them. Paper is at,

http://www.securityinnovation.com/resources/linux_windows.shtml

Another Microsoft funded research..according to Thompson:
“We’ve gotten funding from Microsoft ..”

The study is limited:

“This study appears to be more concerned with vulnerability counts and patch-release cycles than in actual security or securability.”

here’s the method:

In the Security Innovation report, the trio took requirements for three typical enterprise Web server environments and scrutinized known vulnerabilities and subsequent patches. The Windows Server 2003 platform included ASP.NET for scripting, a SQL Server 2000 database server and Microsoft Internet Information Services 6.0 Web server. Any function was accepted by default during installation (assuming many admins just keep clicking the Next button during the process). On the Linux side, the team used two different configurations for Red Hat Enterprise Linux 3.0. Both ran PHP for scripting, a MySQL database server and an Apache Web server. But one version included high modularity, where essentially the researchers installed whatever Red Hat had available; the other was minimally configured to include only core components.

the problem is..

“Most of us in the Linux security community have been saying for years that the average Linux distribution — Red Hat, SuSE, etc. — isn’t terribly secure ‘by default.’ Good security comes from careful configuration, not by running an installer,”

and RedHat data doesn’t seem to follow the study:

The Red Hat Security Response Team publish the data allowing anyone to run these metrics for themselves, see http://people.redhat.com/mjc/

some comments from the community:

Todays Security advice from Secunia for Mandrake 10.1 is that all known vulnerabilities are patched see http://secunia.com/product/4198/ Todays Security advice from Secunia for Windows Server 2003 has 13% of known vulnerabilities not patched see http://secunia.com/product/1173/ and 4 of these problems date back to 2003! So the maximum time MS takes to patch vulnerabilities in Server 2003 is 2 years and still counting - where is that mentioned in this “research”?

from:

http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1069985,00.html?track=NL-105&ad=509123

old PROM SPARC32 problem during Debian Woody installation

2005-03-20T19:58:00.000-08:00

Got an ancient Ultra Sparc II (sun4m) whose task before is a firewall running on Solaris 2.6, it's got 448MB RAM and 10Mpbs Quad Ethernet port. I decided to install Debian on it as it's the only distro that supports sun4m, AFAIK. I had a hard time looking for Gentoo support but it was my first choice. I initially installed Debian3 Woody for SPARC. But I went into problems during the reboot to continue my installation for the base packages, because of the old PROM that does not support more than one 1GB under the /boot partition, the error was:

SILO buggy old PROMs don't allow reading past 1GB from start of the disk..
Read error on block 327684
Cannot find /etc/silo.conf (Attempt to read block from filesystem resulted in short read)
Couldn't load /etc/silo.conf

To solve this, I need to boot from my Debian CD installer on rescue mode, and mount / and /boot partition.
Then do the following steps:

ln -s . /boot/etc
ln -s . /boot/boot
mv /etc/silo.conf /boot
ln -s /boot/silo.conf /etc/silo.conf

path may vary as "target" may be appended before the directories for the mount point.

Then, edit /etc/kernel-img.conf, and add
link_in_boot = Yes

There was no vi editor installed yet, so I need to use nano-tiny.

Reboot my system and installation continued successfully.

I'd like to thank Ben Collins and Nathan Norman of debian-sparc mailing list for the help.

welcome to my linux notes

2005-03-13T11:15:00.000-08:00