TuxTraining

Irssi is a popular IRC client. Its a very popular client for small window managers like fluxbox. This short howto will walk you though the steps for setting up a jail that only has a few commands in it and will help create a much safer IRC enviroment for you. There are a couple things you will need to have installed before we get started. First you need irssi, next you will need jail. First step is to install jail and irssi, so that irssi will work from your regular linux or unix install.

(more…)

Sick of all those fancy CD-burning apps not working for you? You need something that just gets the work done? Welcome to BashBurn – It just works!

BashBurn is a collection of scripts for CD burning in a Linux console (BashBurn might very well work in *BSD, Solaris etc. but it is developed and tested only under Gentoo Linux). BashBurn was previously named Magma. It’s not the best looking CD-burning application out there, but it does what you want it to do (And if not then probably didn’t want to do it anyway).

(more…)

pam_abl provides auto blacklisting of hosts and users responsible for repeated failed authentication attempts. Generally configured so that blacklisted users still see normal login prompts but are guaranteed to fail to authenticate.

Brute force password discovery attacks involve repeated attempts to authenticate against a service using a dictionary of common passwords. While it is desirable to enforce strong passwords for users this is not always possible and in cases where a weak password has been used brute force attacks can be effective.

The pam_abl module monitors failed authentication attempts and automatically blacklists those hosts (and accounts) that are responsible for large numbers of failed attempts. Once a host is blacklisted it is guaranteed to fail authentication even if the correct credentials are provided.

Blacklisting is triggered when the number of failed authentication attempts in a particular period of time exceeds a predefined limit. Hosts which stop attempting to authenticate will, after a period of time, be un-blacklisted.

Download: Here

Normally we will set the hostname of a system during the installation process. Many peoples don’t care about this, and don’t change the hostname even if for example this was set to something really stupid by the datacenter that installed the system (most likely they will set this to “debian” on any debian installation, etc). For me, it is important to see on each one of the ssh screens I will have open at any time a different hostname that is relevant and will give me quickly the information on what system I am logged in.

(more…)

It is assumed that you already know how to configure and use BIND (the Berkeley Internet Name Domain). If not. It is also assumed that you have a basic familiarity with compiling and installing software on your UNIX-like system.

This document describes some extra security precautions that you can take when you install BIND. It explains how to configure BIND so that it resides in a “chroot jail,” meaning that it cannot see or access files outside its own little directory tree. We shall also configure it to run as a non-root user.

The idea behind chroot is fairly simple. When you run BIND (or any other process) in a chroot jail, the process is simply unable to see any part of the filesystem outside the jail. For example, in this document, we’ll set BIND up to run chrooted to the directory chroot/named. Well, to BIND, the contents of this directory will appear to be/ the root directory. Nothing outside this directory will be accessible to it. You’ve probably encounted a chroot jail before, if you’ve ever used ftp to log into a public system.

Because the chroot process is much simpler with BIND 9, I have started to expand this document slightly, to include more general tips about securing a BIND installation. Nevertheless, this document is not (and is not intended to be) a complete reference for securing BIND. If you do only what is outlined in this document, you’re not finished securing your nameserver!
The idea behind running BIND in a chroot jail is to limit the amount of access any malicious individual could gain by exploiting vulnerabilities in BIND. It is for the same reason that we run BIND as a non-root user.
This should be considered as a supplement to the normal security precautions (running the latest version, using access control, etc.), certainly not as a replacement for them.

(more…)