Thursday, April 06, 2006
Generating SSL Key
# 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
Monday, June 06, 2005
Activating simultaneous login limit on Freeradius
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
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.
Wednesday, March 30, 2005
compiling kernel the Debian way
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!
Saturday, March 26, 2005
Linux lags Windows in new security report
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
Sunday, March 20, 2005
old PROM SPARC32 problem during Debian Woody installation
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.