red letting are command that you need to issue as root

1. click on Computer > More Applications > YaST

2. Put in root password for YaST

3. Scroll down until you see Software Management and single click on it

4. Check for the following software. If you don’t have it installed, install it

   1. kernel-source

   2. gcc

   3. gcc-c++

   4. make (This is most likely already installed, but just to double check)

5. Once you have installed that software, lets head over to the command line. Right click on the desktop and select “open terminal”

6. Once you get into the terminal, you want to log in as a super user or root. You can do this by using the su command

   clmowers@linux-box:~> SUPassword:linux-box:/home/clmowers #

7. Next you want to run the following command. This will check for the needed software and it will also show you the kernel modules that are installed. You MUST have the same kernel numbers though out, or you will have issues later down the road

   rpm -qa kernel* gcc* make

   It will look like this when the command is run

   linux-box:/home/clmowers # rpm -qa kernel* gcc* make gcc-c++-4.2-24make-3.81-66kernel-source-2.6.22.17-0.1 gcc42-c++-4.2.1_20070724-17 kernel-default-2.6.22.17-0.1 gcc-4.2-24 gcc42-4.2.1_20070724-17

   Notice that both of the kernels are the same. If these numbers are diffent then you need to run the online updates to get the lastest ones and to make sure everything matches. ***Just remember that these numbers change, This was the latest kernel when I wrote this, yours might be different from mine.

8. OK, lets move on. Next we want to change the directory to /usr/scr/linux. We can do that by this command

   linux-box:/home/clmowers # cd /usr/src/linux

9. next we want to issue these commands. Don’t worry, we are almost done in the command line for the time being.

   linux-box:/home/clmowers # make mrproper; make cloneconfig; make modules_prepareYou will notice that it is done when you get back to this linelinux-box:/home/clmowers #

10. YEA!!! The moment we all have been waiting for, installing vmware server. But we are not done yet. Once vmware server is installed we will need to configure it. Then you can start adding all the VM that your heart desires.

11. Next you want to go to where you have downloaded the file and right click and select install software

12. Once the windows closes we are ready to configure it. I know I know, but we are almost done. Just 2 more minutes.

13. open up a new terminal window (or open the one you already had) and issue this command

    linux-box:/home/clmowers # cd /usr/binlinux-box:/usr/bin #

14. This will bring you to the /usr/bin directory. Next we want to run the pl script the vmware was so kind of to provide us. This will let us configure the server

    linux-box:/usr/bin # vmware-config.pl

15. We will start out by reading the EULA. Hit space or enter to go through the agreement. Once you are done reading hit Q and then type yes. Now what I did was just accept all the defaults. This will give you a very good install of vmware. My only suggestion would be to create a folder under your /home/username/ directory called vms. When you get to the question asking you where you want to have your virutual machine saved, type in that location.

16. You will be ask for your license key, so make sure that you have one. Type it in and press eneter.

Introduction

Are you using SSH in the best way possible? Have you configured it to be as limited and secure as possible? The goal of this document is to kick in the new year with some best practices for SSH: why you should use them, how to set them up, and how to verify that they are in place.

All of the examples below assume that you are using EnGarde Secure Linux but any modern Linux distribution will do just fine since, as far as I know, everybody ships OpenSSH.

SSHv2 vs. SSHv1

There are numerous benefits to using the latest version of the SSH protocol, version 2, over it’s older counterpart, version 1 and I’m not going into a lot of details on those benefits here – if you’re interested, see the URL in the reference below or Google around. That being said if you don’t have an explicit reason to use the older version 1, you should always be using version 2.

To use SSHv2 by default but permit SSHv1, locate the “Protocol” line in your sshd_config file and change it to:

Protocol 2,1

When doing 2,1 please note that the protocol selection is left up to the client. Most clients will default to v2 and “fall back” to v1, while legacy clients may continue to use v1. To force everybody to use SSHv2, change it to:

Protocol 2

When you make this change don’t forget to generate the appropriate HostKey’s as well! SSHv2 requires the following keys:

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

While SSHv1 requires:

# HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key

Once your changes are made, restart the SSH daemon:

# /etc/init.d/sshd restart

[ SUCCESSFUL ] Secure Shell Daemon
[ SUCCESSFUL ] Secure Shell Daemon

From another machine, try SSH’ing in. You can use the -v option to see which protocol is being used, and the ‘-oProtocol=’ option to force one or the other – for example, “ssh -v -oProtocol=2 ” would force protocol version 2.

Binding to a Specific Address or Non-Standard Port

If you’re running SSH on an internal, firewalled, workstation then you can probably skip this section, but if you’re running SSH on a firewall or on a machine with two network interfaces, this section is for you.

Out of the box OpenSSH will bind to every available network address; while convenient and suitable for most installations, this is far from optimal. If your machine has two or more interfaces then the odds are that one is “trusted” and the other is “untrusted.” If this is the case, and you don’t need nor want SSH access coming in on the untrusted interface, then you should configure OpenSSH to listen on a specific interface.

To have OpenSSH only bind to your internal interface, 192.168.0.1 in the example below, locate the following line in your sshd_config file:

ListenAddress 0.0.0.0

and change the 0.0.0.0 to 192.168.0.1:

ListenAddress 192.168.0.1

To verify that this change took, restart OpenSSH and look at netstat:

# /etc/init.d/sshd restart

[ SUCCESSFUL ] Secure Shell Daemon
[ SUCCESSFUL ] Secure Shell Daemon

# netstat -anp | grep sshd

tcp 0 0 192.168.0.1:22 0.0.0.0:* LISTEN 7868/sshd

As you can see, the sshd daemon is now only listening on 192.168.0.1. SSH requests coming in any other interface will be ignored.

Similarly, you may want to change the port that the SSH daemon binds to. Sometimes there is a functional need for this (ie, your employer blocks outbound 22/tcp) but there is also security-through-obscurity value in this as well. While not providing any real security benefit against a determined attacker, moving the SSH daemon off of port 22 protects you against automated attacks which assume that the daemon is running on port 22.

To have OpenSSH bind to a port other than port 22, 31337 in the example below, locate the following line in your sshd_config file:

Port 22

and change the 22 to 31337:

Port 31337

To verify that this change took, restart OpenSSH and, again, look at netstat:

# netstat -anp | grep sshd

tcp 0 0 192.168.0.1:31337 0.0.0.0:* LISTEN 330/sshd

Finally, to SSH into a host whose SSH daemon is listening on a non-standard port, use the -p option:

ssh -p 31337 user@192.168.0.1

Using TCP Wrappers

TCP Wrappers are used to limit access to TCP services on your machine. If you haven’t heard of TCP Wrappers you’ve probably heard of /etc/hosts.allow and /etc/hosts.deny: these are the two configuration files for TCP Wrappers. In the context of SSH, TCP Wrappers allow you to decide what specific addresses or networks have access to the SSH service.

To use TCP Wrappers with SSH you need to make sure that OpenSSH was built with the -with-tcp-wrappers. This is the case on any modern distribution.

As I indicated earlier, TCP Wrappers are configured by editing the /etc/hosts.deny and /etc/hosts.allow files. Typically you tell hosts.deny to deny everything, then add entries to hosts.allow to permit specific hosts access to specific services.

An example:

#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
ALL: ALL
#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
sshd: 207.46.236. 198.133.219.25

In the example above, access to SSH is limited to the network 207.46.236.0/24 and the address 198.133.219.25. Requests to any other service from any other address are denied by the “ALL: ALL” in hosts.deny. If you try to SSH into a machine and TCP Wrappers denies your access, you’ll see something like this:

ssh_exchange_identification: Connection closed by remote host

This simple configuration change significantly hardens your installation since, with it in place, packets from hostile clients are dropped very early in the TCP session — and before they can do any real damage to a potentially vulnerable daemon.

Public Key Authentication

The last item I will cover is public key authentication. One of the best things you can do to tighten the security of your SSH installation is to disable password authentication and to use public key authentication instead. Password authentication is suboptimal for many reasons, but mostly because people choose bad passwords and attackers routinely try to brute-force passwords. If the systems administrator has chosen a bad password and he’s permitting root logins… game over.

Public key authentication is no silver bullet – similarly, people generate passphrase-less keys or leave ssh-agents running when they shouldn’t – but, in my opinion, it’s a much better bet.

Just about every distribution ships with public key authentication enabled, but begin by making sure it is:

RSAAuthentication yes
PubkeyAuthentication yes

Both of these options default to “yes” and the “RSAAuthentication” option is for SSHv1 and the “PubkeyAuthentication” option is for SSHv2. If you plan on using this authentication method exclusively, while you’re there, you may want to disable password authentication:

PasswordAuthentication no

Before you proceed, make sure you have a terminal open on your target machine. Once you restart the SSH daemon you will no longer be able to log in without a key… which we haven’t generated yet!

Once you’re sure, restart the SSH daemon:

# /etc/init.d/sshd restart

[ SUCCESSFUL ] Secure Shell Daemon
[ SUCCESSFUL ] Secure Shell Daemon

Now, from your desktop, try to SSH in to your target machine:

$ ssh rwm@brainy

Permission denied (publickey,keyboard-interactive).

We’re locked out! This is a good thing. The next step, on your desktop, is to generate a key:

$ ssh-keygen -t dsa -C “Ryan’s SSHv2 DSA Key (Jan 2008)”

Generating public/private dsa key pair.
Enter file in which to save the key (/home/rwm/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): **********
Enter same passphrase again: **********
Your identification has been saved in /home/rwm/.ssh/id_dsa.
Your public key has been saved in /home/rwm/.ssh/id_dsa.pub.
The key fingerprint is:
98:4d:50:ba:ee:8b:79:be:b3:36:75:8a:c2:4a:44:4b Ryan’s SSHv2 DSA Key (Jan 2008)

A few notes on this:

• You can generate a DSA (-t dsa), RSA (-t rsa), or SSHv1 (-t rsa1) key. In the example above I’m using dsa.
• I like to put the date I generated the key in the comment (-C) field, that way I can change it out every so often.
• You’re entering a passphrase, not a password. Use a long string with spaces and punctuation. The longer and more complicated the better!

The command you just ran generated two files – id_dsa, your private key and id_dsa.pub, your public key. It is critical that you keep your private key private, but you can distribute your public key to any machines you would like to access.

Now that you have generated your keys we need to get the public key into the ~/.ssh/authorized_keys file on the target machine. The best way to do this is to copy-and-paste it – begin by concatenating the public key file:

$ cat .ssh/id_dsa.pub

ssh-dss AAAAB3NzaC1kc3MAAACBAL7p6bsg5kK4ES9BWLPCNABl20iQQB3R0ymaPMHK…
… ds= Ryan’s SSHv2 DSA Key (Jan 2008)

This is a very long string. Make sure you copy all of it and that you do NOT copy the newline character at the end. In other words, copy from the “ssh” to the “2008)”, but not past that.

The next step is to append this key to the end of the ~/.ssh/authorized_keys file on your target machine. Remember that terminal I told you to keep open a few steps ago? Type the following command into it, pasting the key you’ve just copied into the area noted KEY:

echo “KEY” >> ~/.ssh/authorized_keys

For example:

echo “ssh-dss AAAA5kS9BWLPCN…s= Ryan’s SSHv2 DSA Key (Jan 2008)” >> ~/.ssh/authorized_keys

Now, try to SSH in again. If you did this procedure correctly then instead of being denied access, you’ll be prompted for your passphrase:

$ ssh rwm@brainy

Enter passphrase for key ‘/home/rwm/.ssh/id_dsa’:
Last login: Thu Jan 10 14:37:14 2008 from papa.engardelinux.org
[rwm@brainy ~]$

Viola! You’re now logged in using public key authentication instead of password authentication.

In Summary…

SSH is a wonderful tool and is every systems administrators second best friend (Perl, of course, being the first . It allows you to read your email from anywhere, provided you still use a terminal-based mail reader. It allows you to tunnel an xterm or X11 application from your home server to your desktop at work. It provides you a far superior alternative to FTP in SFTP and SCP.

SSH is great but just like any tool, it’s only as good as you use it. I hope that you found value in some of my best practices and if you have any of your own, leave them in the comments!

Before I go, here are some additional resources on SSH:

• The OpenSSH Project
• SSH, The Secure Shell: The Definitive Guide
• Introduction to SSH Versions 1 and 2
• Knock, Knock, Knockin’ on EnGarde’s Door (with FWKNOP)

Setting up Subversion

For detailed information on this, including alternate setups, have a look at Version Control with Subversion.

1. Install the required packages.

   sudo aptitude install enscript libapache2-mod-python python-docutils trac db4.3-util libapache2-svn subversion-tools

2. Create a virtual host directory for SVN. We’ll use /var/local/svn instead of /var/www so that Subversion instances don’t clog up the directory of web root directories.

   sudo mkdir -p /var/local/svn/svn.example.com

3. Create a development group, and add the web user to it.

   sudo addgroup example; sudo adduser www-data example

4. Add users to the development group. These are persons that need access to the repository.

   1. sudo adduser username1 example
   2. sudo adduser username2 example
   3. sudo adduser username3 example

5. Set the proper permissions.

   sudo chmod 2770 /var/local/svn/svn.example.com

6. Set up the repository.

   sudo svnadmin create /var/local/svn/svn.example.com

7. Clear the current password file. By default it’s for the svnserve protocol, but we’ll be using HTTPS (or just HTTP). We’ll be adding users to this file later in the process.

   sudo rm /var/local/svn/svn.example.com/conf/passwd
   sudo touch /var/local/svn/svn.example.com/conf/passwd

8. Allow the group to write to the repository.

   sudo chmod -R g+w /var/local/svn/svn.example.com

9. Set proper file ownership.

   sudo chown -R www-data:example /var/local/svn/svn.example.com

10. Set the repository access permissions. Information on how to do this can be found in the Path-Based Authorization section of Version Control with Subversion.

    sudo vi /var/local/svn/svn.example.com/conf/authz

11. Create a directory for the log files.

    sudo mkdir /var/log/apache2/svn.example.com

12. Add the site to the log rotation list.

    sudo vi /etc/logrotate.d/apache2

13. Configure the virtual host…

    sudo vi /etc/apache2/sites-available/svn.example.com

    …with the following data. If you don’t care about SSL, you can ignore the SSL options and run this on port 80.

    <VirtualHost [server's IP address]:443>
      ServerName svn.example.com
      <Location />
        DAV svn
        AuthType Basic
        AuthName "svn.example.com"
        AuthUserFile /var/local/svn/svn.example.com/conf/passwd
        AuthzSVNAccessFile /var/local/svn/svn.example.com/conf/authz
        SVNPath /var/local/svn/svn.example.com
        Require valid-user
      </Location>
      CustomLog /var/log/apache2/svn.example.com/access.log combined
      ErrorLog /var/log/apache2/svn.example.com/error.log
      SSLEngine on
      SSLCertificateFile /etc/apache2/ssl/apache.pem
    # Add this once there is a real (non self-signed) certificate.
    #  SSLCertificateKeyFile /etc/apache2/ssl/server.key
    </VirtualHost>
    <VirtualHost [server's IP address]:80>
      ServerName svn.example.com
      Redirect / https://svn.example.com/
    </VirtualHost>

    Reference:

    /etc/apache2/mods-enabled/dav_svn.conf

14. Enable the subversion virtual host.

    sudo a2ensite svn.example.com

15. Create user/password combinations.

    htpasswd /var/local/svn/svn.example.com/conf/passwd username

16. Restart the web server.

    sudo /etc/init.d/apache2 restart

17. If you’re going to have users working locally, set up svnwrap. (See the man page for details.)

    sudo ln -s /usr/bin/svnwrap /usr/local/bin/svn

Setting up Trac

1. Create the web directory. We’ll use /var/local/trac instead of /var/www so as not to clog up the directory of webroots.

   sudo mkdir /var/local/trac/trac.example.com

2. Set the proper permissions.

   sudo chmod 2770 /var/local/trac/trac.example.com

3. Create a Trac instance.

   sudo trac-admin /var/local/trac/trac.example.com initenv

4. Set proper ownership on the web directory.

   sudo chown -R www-data:example /var/local/trac/trac.example.com

5. Allow the group to write to the repository.

   sudo chmod -R g+w /var/local/trac/trac.example.com

6. Configure it.

   sudo vi /var/local/trac/trac.example.com/conf/trac.ini

7. Create a directory for the log files.

   sudo mkdir /var/log/apache2/trac.example.com

8. Add the site to the log rotation list.

   sudo vi /etc/logrotate.d/apache2

9. Configure the virtual host…

   sudo vi /etc/apache2/sites-available/trac.example.com

   …with the following data. If you don’t care about SSL, you can skip the SSL options and run this on port 80.

   # Trac Configuration
   <VirtualHost [server's IP address]:80>
     ServerName trac.example.com
     Redirect / https://trac.example.com/
   </VirtualHost>
   <VirtualHost [server's IP address]:443>
     ServerName trac.example.com
     DocumentRoot /var/local/trac/trac.example.com/
     Alias /trac/ /usr/share/trac/htdocs
     <Directory "/usr/share/trac/htdocs/">
         Options Indexes MultiViews
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>
     <Location />
         SetHandler mod_python
         PythonHandler trac.web.modpython_frontend
         PythonInterpreter main_interpreter
         PythonOption TracEnv /var/local/trac/trac.example.com/
         PythonOption TracUriRoot /
         AuthType Basic
         AuthName "trac.example.com"
         # Use the SVN password file.
         AuthUserFile /var/local/svn/svn.example.com/conf/passwd
         Require valid-user
     </Location>
     CustomLog /var/log/apache2/trac.example.com/access.log combined
     ErrorLog /var/log/apache2/trac.example.com/error.log
     SSLEngine on
     SSLCertificateFile /etc/apache2/ssl/apache.pem
   # Add this once there is a real (non self-signed) certificate.
   #  SSLCertificateKeyFile /etc/apache2/ssl/server.key
   </VirtualHost>

   Reference:

   http://trac.edgewall.org/wiki/TracOnUbuntu

10. Enable the Trac virtual host.

    sudo a2ensite trac.example.com

11. Restart the web server.

    sudo /etc/init.d/apache2 restart

The last thing to do is add the subdomains “svn” and “trac” to the DNS configuration for your domain. Once this is done, Subversion and Trac will be integrated into your server environment, and will be accessible from the web.

This how to uses Ubuntu 7.10 Server install. I am sure that this could be done with a much smaller install base, rather than server – I might have used the Alternative CD, or maybe even some other distribution like DSL, or Puppy Linux (if you needed GUI [graphical user interface] ). But for proof of concept this worked fine. I used an Old Dell GX100 Optiplex with 256 MB of RAM (I don’t think I need any more that 128 [maybe even 64MB], but this is what was in the box when I pulled it out of the pile). It has a small form factor, and runs pretty quiet. My steps are geared toward English & US, so you may want to change those if your using something else =).

Read more…

Install Debian. I used the basic barebones install option. I did
some things that were done because of preference, and not necessary. I
have marked them approriately. I encourage contributions from anyone
who would like to add or correct something in this HowTo to contact me
so I can fix it. I have installed this setup twice following these
instructions and used Avantfax 2.3.0. Thanks to all the resources who
helped me figure this out. Especially Razametal, who submitted a
fantastic Spanish language walkthrough on ecualug.org.

Read more…

There are already tons of written Snort rules, but there just might
be a time where you need to write one yourself. You can think of
writing Snort rules as writing a program. They can include variables,
keywords and functions. Why do we need to write rules? The reason is,
without rules Snort will never detect someone trying to hack your
machine. This HOWTO will give you confidence to write your own rules.

Read more…

It’s very simple to masquerade (internet connection sharing in
Windows language ) on Linux with a few lines of iptables and ip_forward
commands.

Read more…

This document describes how to set up Hyperic HQ on Fedora 8. The
resulting system provides an awesome, web-based “System
ManagementSoftware”. It’s the next stage of classical monitoring and
able to manage all kinds of operating systems, web servers, application
servers and database servers.

Read more…

DRBD is an abbreviation of Distributed Replicated Block Device.
DRBD is a block device which is designed to build high-availability
clusters. This is done by mirroring a whole block device via (a
dedicated) network. You could see it as a network RAID1.

Read more…

This document describes how to set up, configure and use Timevault
on Ubuntu 7.10. The resulting system provides a powerful backup system
for desktop usage. TimeVault is a simple front-end for making snapshots
of a set of directories. Snapshots are a copy of a directory structure
or file at a certain point in time. Restore functionality is integrated
into Nautilus – previous versions of a file or directory that has a
snapshot can be accessed by examining the properties and selecting the
‘Previous Versions’ tab.

Read more…