UnixDude

My UNIX journeys..

  • About Me…
  • Disclaimer

Logcheck — check logs for unusual activity and emails

Posted by phatdee on May 14, 2012
Posted in: Linux, Logs, Security. Tagged: logs, monitoring, security. Leave a Comment

#!/bin/sh
#
# $Id: logcheck.sh,v 1.5 2002/10/11 18:52:33 tcole Exp $
#
# logcheck.sh: Log file checker
# Written by Craig Rowland
#
# This file needs the program logtail.c to run
#
# This script checks logs for unusual activity and blatant
# attempts at hacking. All items are mailed to administrators
# for review. This script and the logtail.c program are based upon
# the frequentcheck.sh script idea from the Gauntlet(tm) Firewall
# (c)Trusted Information Systems Inc. The original authors are
# Marcus J. Ranum and Fred Avolio.
#
# Default search files are tuned towards the TIS Firewall toolkit
# the TCP Wrapper program. Custom daemons and reporting facilites
# can be accounted for as well…read the rest of the script for
# details.
#
# Version Information
#
# 1.0 9/29/96 — Initial Release
# 1.01 11/01/96 — Added working /tmp directory for symlink protection
# (Thanks Richard Bullington (rbulling@obscure.org)
# 1.1 1/03/97 — Made this script more portable for Sun’s.
# 1/03/97 — Made this script work on HPUX
# 5/14/97 — Added Digital OSF/1 logging support. Big thanks
# to Jay Vassos-Libove for
# his changes.

# CONFIGURATION SECTION

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/local/bin

# Logcheck is pre-configured to work on most BSD like systems, however it
# is a rather dumb program and may need some help to work on other
# systems. Please check the following command paths to ensure they are
# correct.

# Person to send log activity to.
SYSADMIN=user@example.com

# Full path to logtail program.
# This program is required to run this script and comes with the package.

LOGTAIL=/export/logsentry/bin/logtail

# Full path to SECURED (non public writable) /tmp directory.
# Prevents Race condition and potential symlink problems. I highly
# recommend you do NOT make this a publically writable/readable directory.
# You would also be well advised to make sure all your system/cron scripts
# use this directory for their “scratch” area.

TMPDIR=/export/logsentry/tmp

# The ‘grep’ command. This command MUST support the
# ‘-i’ ‘-v’ and ‘-f’ flags!! The GNU grep does this by default (that’s
# good GNUs for you Linux/FreeBSD/BSDI people :) ). The Sun grep I’m told
# does not support these switches, but the ‘egrep’ command does (Thanks
# Jason ). Since grep and egrep are usually the GNU
# variety on most systems (well most Linux, FreeBSD, BSDI, etc) and just
# hard links to each other we’ll just specify egrep here. Change this if
# you get errors.

# Linux, FreeBSD, BSDI, Sun, HPUX, etc.
GREP=egrep

# The ‘mail’ command. Most systems this should be OK to leave as is.
# If your default mail command does not support the ‘-s’ (subject) command
# line switch you will need to change this command one one that does.
# The only system I’ve seen this to be a problem on are HPUX boxes.
# Naturally, the HPUX is so superior to the rest of UNIX OS’s that they
# feel they need to do everything differently to remind the rest that
# they are the best ;).

# Linux, FreeBSD, BSDI, Sun, etc.
#MAIL=mail
# Solaris
MAIL=mailx
# HPUX 10.x and others(?)
#MAIL=mailx
# Digital OSF/1, Irix
#MAIL=Mail

# File of known active hacking attack messages to look for.
# Only put messages in here if you are sure they won’t cause
# false alarms. This is a rather generic way of checking for
# malicious activity and can be inaccurate unless you know
# what past hacking activity looks like. The default is to
# look for generic ISS probes (who the hell else looks for
# “WIZ” besides ISS?), and obvious sendmail attacks/probes.

HACKING_FILE=/export/logsentry/etc/logcheck.hacking

# File of security violation patterns to specifically look for.
# This file should contain keywords of information administrators should
# probably be aware of. May or may not cause false alarms sometimes.
# Generally, anything that is “negative” is put in this file. It may miss
# some items, but these will be caught by the next check. Move suspicious
# items into this file to have them reported regularly.

VIOLATIONS_FILE=/export/logsentry/etc/logcheck.violations

# File that contains more complete sentences that have keywords from
# the violations file. These keywords are normal and are not cause for
# concern but could cause a false alarm. An example of this is the word
# “refused” which is often reported by sendmail if a message cannot be
# delivered or can be a more serious security violation of a system
# attaching to illegal ports. Obviously you would put the sendmail
# warning as part of this file. Use your judgement before putting words
# in here or you can miss really important events. The default is to leave
# this file with only a couple entries. DO NOT LEAVE THE FILE EMPTY. Some
# grep’s will assume that an EMPTY file means a wildcard and will ignore
# everything! The basic configuration allows for the more frequent sendmail
# error.
#
# Again, be careful what you put in here and DO NOT LEAVE IT EMPTY!

VIOLATIONS_IGNORE_FILE=/export/logsentry/etc/logcheck.violations.ignore

# This is the name of a file that contains patterns that we should
# ignore if found in a log file. If you have repeated false alarms
# or want specific errors ignored, you should put them in here.
# Once again, be as specific as possible, and go easy on the wildcards

IGNORE_FILE=/export/logsentry/etc/logcheck.ignore

# The files are reported in the order of hacking, security
# violations, and unusual system events. Notice that this
# script uses the principle of “That which is not explicitely
# ignored is reported” in that the script will report all items
# that you do not tell it to ignore specificially. Be careful
# how you use wildcards in the logcheck.ignore file or you
# may miss important entries.

# Make sure we really did clean up from the last run.
# Also this ensures that people aren’t trying to trick us into
# overwriting files that we aren’t supposed to. This is still a race
# condition, but if you are in a temp directory that does not have
# generic luser access it is not a problem. Do not allow this program
# to write to a generic /tmp directory where others can watch and/or
# create files!!

# Shouldn’t need to touch these…
HOSTNAME=`hostname`
DATE=`date +%m/%d/%y:%H.%M`

umask 077
rm -f $TMPDIR/check.$$ $TMPDIR/checkoutput.$$ $TMPDIR/checkreport.$$
if [ -f $TMPDIR/check.$$ -o -f $TMPDIR/checkoutput.$$ -o -f $TMPDIR/checkreport.$$ ]; then
echo “Log files exist in $TMPDIR directory that cannot be removed. This
may be an attempt to spoof the log checker.” \
| $MAIL -s “$HOSTNAME $DATE ACTIVE SYSTEM ATTACK!” $SYSADMIN
exit 1
fi

# LOG FILE CONFIGURATION SECTION
# You might have to customize these entries depending on how
# you have syslogd configured. Be sure you check all relevant logs.
# The logtail utility is required to read and mark log files.
# See INSTALL for more information. Again, using one log file
# is preferred and is easier to manage. Be sure you know what the
# > and >> operators do before you change them. LOG FILES SHOULD
# ALWAYS BE chmod 600 OWNER root!!

# Find out what OS we are running on
OS=`uname -s`

# Generic and Linux Slackware 3.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$

# Linux Red Hat Version 3.x, 4.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$
#$LOGTAIL /var/log/secure >> $TMPDIR/check.$$
#$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$

# Linux Debian 2.2 and 3.0
if [ $OS = "Linux" ]; then
$LOGTAIL /var/log/messages > $TMPDIR/check.$$
$LOGTAIL /var/log/syslog >> $TMPDIR/check.$$
$LOGTAIL /var/log/auth.log >> $TMPDIR/check.$$
$LOGTAIL /var/log/mail.log >> $TMPDIR/check.$$
$LOGTAIL /var/log/daemon.log >> $TMPDIR/check.$$
fi

# FreeBSD 2.x
if [ $OS = "FreeBSD" ]; then
$LOGTAIL /var/log/messages > $TMPDIR/check.$$
$LOGTAIL /var/log/auth.log > $TMPDIR/check.$$
# I guess we don’t have that right now.
#$LOGTAIL /var/log/daemon.log > $TMPDIR/check.$$
# Lets not even look at the mail log since we probably don’t care.
#$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
fi

# BSDI 2.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$
#$LOGTAIL /var/log/secure >> $TMPDIR/check.$$
#$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
#$LOGTAIL /var/log/ftp.log >> $TMPDIR/check.$$
# Un-comment out the line below if you are using BSDI 2.1
#$LOGTAIL /var/log/daemon.log >> $TMPDIR/check.$$

# SunOS, Sun Solaris 2.5
if [ $OS = "SunOS" ]; then
$LOGTAIL /var/log/syslog > $TMPDIR/check.$$
$LOGTAIL /var/adm/messages >> $TMPDIR/check.$$
$LOGTAIL /var/log/auth.log >> $TMPDIR/check.$$
$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
fi

# HPUX 10.x and others(?)
#$LOGTAIL /var/adm/syslog/syslog.log > $TMPDIR/check.$$

# Digital OSF/1
# OSF/1 – uses rotating log directory with date & time in name
# LOGDIRS=`find /var/adm/syslog.dated/* -type d -prune -print`
# LOGDIR=`ls -dtr1 $LOGDIRS | tail -1`
# if [ ! -d "$LOGDIR" ]
# then
# echo “Can’t identify current log directory.” >> $TMPDIR/checkrepo$
# else
# $LOGTAIL $LOGDIR/auth.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/daemon.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/kern.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/lpr.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/mail.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/syslog.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/user.log >> $TMPDIR/check.$$
# fi
#

# END CONFIGURATION SECTION. YOU SHOULDN’T HAVE TO EDIT ANYTHING
# BELOW THIS LINE.

# Set the flag variables
FOUND=0
ATTACK=0

# See if the tmp file exists and actually has data to check,
# if it doesn’t we should erase it and exit as our job is done.

if [ ! -s $TMPDIR/check.$$ ]; then
rm -f $TMPDIR/check.$$
exit 0
fi

# Perform Searches

# Check for blatant hacking attempts
if [ -f "$HACKING_FILE" ]; then
if $GREP -i -f $HACKING_FILE $TMPDIR/check.$$ > $TMPDIR/checkoutput.$$; then
echo >> $TMPDIR/checkreport.$$
echo “Active System Attack Alerts” >> $TMPDIR/checkreport.$$
echo “=-=-=-=-=-=-=-=-=-=-=-=-=-=” >> $TMPDIR/checkreport.$$
cat $TMPDIR/checkoutput.$$ >> $TMPDIR/checkreport.$$
FOUND=1
ATTACK=1
fi
fi

# Check for security violations
if [ -f "$VIOLATIONS_FILE" ]; then
if $GREP -i -f $VIOLATIONS_FILE $TMPDIR/check.$$ |
$GREP -v -f $VIOLATIONS_IGNORE_FILE > $TMPDIR/checkoutput.$$; then
echo >> $TMPDIR/checkreport.$$
echo “Security Violations” >> $TMPDIR/checkreport.$$
echo “=-=-=-=-=-=-=-=-=-=” >> $TMPDIR/checkreport.$$
cat $TMPDIR/checkoutput.$$ >> $TMPDIR/checkreport.$$
FOUND=1
fi
fi

# Do reverse grep on patterns we want to ignore
if [ -f "$IGNORE_FILE" ]; then
if $GREP -v -f $IGNORE_FILE $TMPDIR/check.$$ > $TMPDIR/checkoutput.$$; then
echo >> $TMPDIR/checkreport.$$
echo “Unusual System Events” >> $TMPDIR/checkreport.$$
echo “=-=-=-=-=-=-=-=-=-=-=” >> $TMPDIR/checkreport.$$
cat $TMPDIR/checkoutput.$$ >> $TMPDIR/checkreport.$$
FOUND=1
fi
fi

# If there are results, mail them to sysadmin

if [ "$ATTACK" -eq 1 ]; then
cat $TMPDIR/checkreport.$$ | $MAIL -s “$HOSTNAME $DATE ACTIVE SYSTEM ATTACK!” $SYSADMIN
elif [ "$FOUND" -eq 1 ]; then
cat $TMPDIR/checkreport.$$ | $MAIL -s “Systems Check: $HOSTNAME $DATE” $SYSADMIN
fi

# Clean Up
rm -f $TMPDIR/check.$$ $TMPDIR/checkoutput.$$ $TMPDIR/checkreport.$$

Git cheatsheet

Posted by phatdee on May 13, 2012
Posted in: Git, Linux. Tagged: cheatsheet, git. Leave a Comment

Various GIT cheatsheets

Posted by phatdee on May 13, 2012
Posted in: Git. Tagged: cheatsheet, git. Leave a Comment

A practical git guide

Notes extracted from git screencast at http://www.peepcode.com.

Configuration

identify yourself to git: email and your name

git config –global user.name “David Beckwith”

git config –global user.email “dbitsolutions@gmail.com”

To view all options:

git config –list

OR

cat .git/config

Set up aliases

git config –global alias.co checkout

View your configuration

cat .gitconfig

To ignore whitespace (Ruby is whitespace insensitive)

git config –global apply.whitespace nowarn

Some nice aliases:

gb = git branch
gba = git branch -a
gc = git commit -v
gd = git diff | mate
gl = git pull
gp = git push
gst = git status

Start using git

git init

Ignoring files

Add a file in the root directory called .gitignore and add some files to it: (comments begin with hash)

*.log db/schema.rb db/schema.sql
Git automatically ignores empty directories. If you want to have a log/ directory, but want to ignore all the files in it, add the following lines to the root .gitignore: (lines beginning with ‘!’ are exceptions)

log/*
!.gitignore

Then add an empty .gitignore in the empty directory:

touch log/.gitignore

Scheduling the addition of all files to the next commit

git add .

Checking the status of your repository

git status

Committing files

git commit -m “First import”

Seeing what files have been committed

git ls-files

Scheduling deletion of a file

git rm [file name]

Committing all changes in a repository

git commit -a

Scheduling the addition of an individual file to the next commit

git add [file name]

Viewing the difference as you commit

git commit -v

Commit and type the message on the command line

git commit -m “This is the message describing the commit”

Commit and automatically get any other changes

git commit -a

A “normal” commit command

git commit -a -v

Viewing a log of your commits

git log

Viewing a log of your commits with a graph to show the changes

git log –stat

Viewing a log with pagination

git log -v

Visualizing git changes

gitk –all

Creating a new tag and pushing it to the remote branch

git tag “v1.3″
git push –tags

Creating a new branch

git branch [name of your new branch]

Pushing the branch to a remote repository

git push origin [new-remote]

Pulling a new branch from a remote repository

git fetch origin [remote-branch]:[new-local-branch]

Viewing branches

git branch

Viewing a list of all existing branches

git branch -a

Switching to another branch

The state of your file system will change after executing this command.

git checkout [name of the branch you want to switch to]

OR

git co [name of the branch you want to switch to]

Making sure changes on master appear in your branch

git rebase master

Merging a branch back into the master branch

First, switch back to the master branch:

git co master

Check to see what changes you’re about to merge together, compare the two branches:

git diff master xyz

If you’re in a branch that’s not the xyz branch and want to merge the xyz branch into it:

git merge xyz

Reverting changes to before said merge

git reset –hard ORIG_HEAD

Resolving conflicts

Remove the markings, add the file, then commit.

Creating a branch (and switching to the new branch) in one line

git checkout -b [name of new branch]

Creating a stash (like a clipboard) of changes to allow you to switch branches without committing

git stash save “Put a message here to remind you of what you’re saving to the clipboard”

Switching from the current branch to another

git co [branch you want to switch to]

Do whatever
Then switch back to the stashed branch

git co [the stashed branch]

Viewing a list of stashes

git stash list

Loading back the stash

git stash apply

Now you can continue to work where you were previously.

Deleting a branch (that has been merged back at some point)

git branch -d [name of branch you want to delete]

Deleting an unmerged branch

git branch -D [name of branch you want to delete]

Deleting a stash

git stash clear

Setting up a repository for use on a remote server

Copy up your repository. e.g.:

scp -r my_project deploy@yourbox.com:my_project

Move your files on the remote server to /var/git/my_project
For security make the owner of this project git
On the repository server:

sudo chown -R git:git my_project

Then (for security) restrict the “deploy” user to doing git-related things in /etc/passwd with a git-shell.

Checking out a git repository from a remote to your local storage

git clone git@yourbox.com:/var/git/my_project

Viewing extra info about a remote repository

cat .git/config

By virtue of having cloned the remote repository, your local repository becomes the slave and will track and synchronize with the remote master branch.

Updating a local branch from the remote server

git pull

Downloading a copy of an entire repository (e.g. laptop) without merging into your local branch

git fetch laptop

Merging two local branches (ie. your local xyz branch with your local master branch) USE MERGE

git merge laptop/xyz

This merged the (already copied laptop repository’s xyz branch) with the current branch you’re sitting in.

Viewing metadata about a remote repository

git remote show laptop

Pushing a committed local change from one local branch to another remote branch

git push laptop xyz

Creating a tracking branch (i.e. to link a local branch to a remote branch)

git branch –track local_branch remote_branch

You do not need to specify the local branch if you are already sitting in it.

git pull

Note: You can track(link) different local branches to different remote machines. For example, you can track your friend’s “upgrade” branch with your “bobs_upgrade” branch, and simultaneously you can track the origin’s “master” branch (of your main webserver) with your local “master” branch.

By convention, ‘origin’ is the local name given to the remote centralized server which is the way SVN is usually set up on a remote server.

Seeing which local branches are tracking a remote branch

git remote show origin

Working with a remote Subversion repository (but with git locally)

git-svn clone [http location of an svn repository]

Now you can work with the checked out directory as though it was a git repository. (cuz it is)

Pushing (committing) changes to a remote Subversion repository

git-svn dcommit

Updating a local git repository from a remote Subversion repository

git-svn rebase

NOTE: make sure you have your perl bindings to your local svn installation.

I screwed up, how do I reset my checkout?

git checkout -f

Install and configure DHCP

Posted by phatdee on May 3, 2012
Posted in: Configurations, Linux. Tagged: dhcpd, OpenSuse. Leave a Comment

(Copied from http://sellingfreesoftwareforaliving.blogspot.com/2011/11/install-and-configure-dhcp-server.html)
Install and configure DHCP server
This blog entry describes how you would install and configure the dhcpd (DHCP) server for the purpose of assigning an IP address to machines booting up via the network and pointing these machines to the PXE boot environment.

The PXE boot environment (TFTP server) is documented in another blog entry Install and configure tftp server for PXE boot environment and the main entry discussion on Network Installation of openSUSE.

1) Install DHCP Server (dhcpd)

Command-line (as root): zypper in dhcp-server yast2-dhcp-server

2) Configure DHCP

Make a backup of the dhcpd.conf file to start afresh: mv /etc/dhcpd.conf /etc/dhcpd.org.conf

Create a new dhcpd.conf file, using your favourite text editor as root, from scratch with the following content:

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
option domain-name “example.org”;
option routers 192.168.11.1;
max-lease-time 7200;

ddns-updates off;

ddns-update-style none;

log-facility local7;
default-lease-time 600;

# define rules to identify DHCP Requests from PXE and Etherboot clients.
class “pxe” {
match if substring (option vendor-class-identifier, 0, 9) = “PXEClient”;
}
class “etherboot” {
match if substring (option vendor-class-identifier, 0, 9) = “Etherboot”;
}

subnet 192.168.11.0 netmask 255.255.255.0 {
range 192.168.11.51 192.168.11.60;
default-lease-time 14400;
max-lease-time 172800;
server-name “192.168.11.200″;
next-server 192.168.11.200;
filename “pxelinux.0″;
# allow members of “pxe”;
}

Using the sample dhcpd.conf above, you can see that
My router IP is 192.168.11.1

DHCP daemon is giving out IP address starting from 192.168.11.51 to 192.168.11.60. You can adjust this setting to provide more IP addresses. The important part is to assign IP addresses outside the range of any other existing DHCP server (either in the router or in another environment where you do not have access to the official DHCP server).

server-name and next-server points to the IP address of the network installation server (ie pointing back to the openSUSE server that is running DHCP server, TFTP server, Apache2 server with binaries)

Alternatively, if you would like a GUI interface, you may try yast2 dhcp-server. Below are screenshots of the 4 step wizard.

3) Starting and Stopping the DHCP Server

Its best to manually start and stop the DHCP Server as required… as most LANs already have some DHCP service running… doubly so if your machine is portable (ie Laptop), you wouldn’t want your Laptop to start dishing out IP addresses on boot.

To start the DHCP server, command-line (as root): rcdhcpd start

To stop the DHCP server, command-line (as root): rcdhcpd stop

Network Installation of SLES/SLED/Suse

Posted by phatdee on May 3, 2012
Posted in: Linux, SLES/Suse. Tagged: autoyast, installation, OpenSuse, sles. Leave a Comment

(copied from http://sellingfreesoftwareforaliving.blogspot.com/2011/11/network-installation-of-opensuse.html)
Network Installation of openSUSE
This will be my main blog entry discussing the best practices (mine anyway) on setting up a network installation server.

What is the Motivation for this setup?

1) Local Area Networks (LANs) are ubiquitous… even in homes where, chances are, you have a modem to the Internet and next to it is a wireless/ethernet router for multiple wifi and ethernet capable devices (PCs, Laptops, Smartphones, Tablets etc) to connect and surf the web.

2) If you are a Linux/OSS enthusiast, you would be constantly downloading the latest ISOs from the web, burning them onto a DVDs and installing them on physical/virtual machines. This is time/resource intensive… time to download, time to burn a DVD, time/money spent on blank DVDs etc. Of course, if you install openSUSE on virtual machines, you avoid the DVD part of the process but you would still have lots of ISOs on your filesystem… if you have a classroom of 20 machines… well, you get the idea.

3) Almost all PCs and Laptops these days have an ethernet port and are capable of booting up from the network (ie PXE-boot). This means you physically power them on, tell it to go into PXE-boot mode and it will go onto the network and seek out an installation server to download and install the openSUSE binaries.

4) This is an efficient way to install openSUSE onto both physical and virtual machines in a LAN environment where there is only one central place for your software binaries.

Pre-requisites:

i) You have a LAN environment connecting a few machines via the network cable. Although booting from wifi is possible but it is out of the scope of this discussion.

ii) You have a physical machine (preferably*) with openSUSE installed and this will be the designated network installation server.
*It is possible to set this up on a virtual machine but you need to ensure it is connected to the physical LAN in a Bridge networking mode and not the usual NAT networking mode for typical virtual machines.

3 Simple^ Steps to Success:
^Simple – it will become more simple as you do this more frequently.

Step 1: Install and configure Apache2 webserver to host and distribute openSUSE binaries.
Please refer to my other blog entry on this subject – Using Apache2 to deploy & maintain SUSE

Step 2: Install and configure tftpboot server to enable initial boot of target machines over the network.
Please refer to my other blog entry on this subject – Install and configure TFTP server for PXE boot environment

Step 3: Install and configure dhcpd server to provide an IP address for target machines and redirect them to the tftpboot server.
Please refer to my other blog entry on this subject – Install and configure DHCP server

Step 4: On the target physical machines, on boot and depending on the BIOS, activate the boot from LAN option and watch it get an IP address from the Installation Server (via Step 3), followed by connecting to the TFTP server and presenting an installation menu (via Step 2). Enter the choice of OS to install and your installation will commence over the LAN (via Step 1).

Additional points of note:

a) Everything discussed here applies to SLES, SLED and openSUSE. The steps documented are based on openSUSE 11.x and should work on older versions and even the enterprise editions of SUSE.

b) Software installation (apache2, tftpboot, syslinux, dhcpd etc) assumes your SLE or openSUSE server have access to their respective binaries, either in DVD (also ISO) or software repository on the web.

References:
openSUSE.org – SDB:PXE boot installation

Novell Cool Solutions – Setting Up a SUSE PXE Installation Server in an Existing NetWare Environment

Novell Article – Setting up a PXE Boot Server

tar directory + hidden files like home directories

Posted by phatdee on April 16, 2012
Posted in: Bash, File Systems, Shell. Tagged: tar. Leave a Comment

find . -name .\* | tar cvf ../filename.tar -T -

Swat — Setting up stunnel

Posted by phatdee on April 15, 2012
Posted in: Linux, Logs, Security, Uncategorized. Tagged: stunnel, swat. Leave a Comment

Modifications to the SWAT setup are as follows:

Install OpenSSL.

Generate certificate and private key.

root# /usr/bin/openssl req -new -x509 -days 365 -nodes -config \
/usr/share/doc/packages/stunnel/stunnel.cnf \
-out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem

Remove SWAT entry from [x]inetd.

Start stunnel.

root# stunnel -p /etc/stunnel/stunnel.pem -d 901 \
-l /usr/local/samba/bin/swat swat

Afterward, simply connect to SWAT by using the URL https://myhost:901, accept the certificate, and the SSL connection is up.

Novell ZLM 7.3.x SSL cert expiration.

Posted by phatdee on April 5, 2012
Posted in: SLES/Suse, ZLM 7.3.x. Tagged: novell, SSL, ZLM. Leave a Comment

By default the SSL certs are only valid for 2 years.  The interesting part is that no where in the startup scripts for ZLM does it state ..hey your SSL certs are expired.  It just says, everything is started..however when you try to access  your ZLM server, it will error out with unable to connect to port 10636 make sure ndsd is started.

10389 eDirectory LDAP

10636 eDirectory secure LDAP.  if you run netstat -ntlu or p  you will not see port 10636. The screwed up part was that I didn’t realize it was just a simple SSL cert at first, I honestly thought ndsd was having bigger issues.  It wasn’t until much latter in the troubleshooting that I happened to find a hidden log somewhere that I just happened to notice the SSL cert expired due to the date.  Really obscure place..oh well next time I will know.

 

Do the follow to get your secure ldap port back up.

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

# ldapconfig set ‘Require TLS for Simple Binds with Password=no’ -a admin.system

Password: 	<provide the ZLM Administrator password > 

LDAP Server Configuration:
LDAP Server: CN=LDAP Server - blx-zlm002.O=system
LDAP Group: CN=LDAP Group - blx-zlm002.O=system
Require TLS for Simple Binds with Password set to no
LDAP Server refreshed with the new configuration.

Now we delete the eDirectory certificate authority using ldap tools and recreate it afterwards with the ndsconfig command. Take care that you need to insert the name of the ZLM management zone into the ldapdelete command. You used that during the ZLM installation in step 2 and can get it from the backup of the zlm.conf file:

# ldapdelete -H ldap://localhost:10389 -D cn=admin,o=system -W -Z -x ‘cn=<ZLM management zone name > -TREE CA,cn=Security’
Password: <provide the ZLM Administrator password >

sample:

# ldapdelete -H ldap://localhost:10389 -D cn=admin,o=system -W -Z -x ‘cn=BLX_ZLM002-TREE CA,cn=Security’

Now we use ndsconfig to recreate the certificate authority and that also recreates all the server certificates:

# ndsconfig upgrade

[1] Instance at /etc/nds.conf:  blx-zlm002.O=system.BLX_ZLM002-TREE 

Migrating the eDirectory configuration file "/etc/nds.conf" to the new configuration file  location "/etc/opt/novell/eDirectory/conf/nds.conf"... 

Upgrading Novell eDirectory server with the following parameters, Please wait...
  Tree Name		: BLX_ZLM002-TREE
  Server DN		: blx-zlm002.O=system 

  Configuration File	: /etc/opt/novell/eDirectory/conf/nds.conf
  Instance Location	: /var/nds/data
  DIB Location		: /var/nds/dib 

Checking if server is ready to service requests... 				Done
Enter admin name with context[admin.org]:	admin.system
Enter the password for admin.system: 	<provide the ZLM Administrator password > 

Performing eDirectory health check... 					Done
For more details view health check logfile: /var/nds/log/ndscheck.log 

Extending schema... 								Done
For more details view schema extension logfile: /var/nds/log/schema.log 

Configuring HTTP service... 							Done
Configuring LDAP service... 							Done
Configuring SNMP service... 							Done
Configuring SAS service... 							Done
Associating certificate with the NCP server object...
INFO: Server is already associated with a certificate. 			Done
Configuring NMAS service... 							Done
Configuring SecretStore...
INFO: SecretStore extensions have already been added to the server.	Done
Configuring LDAP Server with default SSL CertificateDNS certificate... 	Done
Triggering the 'External Reference Check' process... 			Done 

The instance at /etc/opt/novell/eDirectory/conf/nds.conf is successfully configured.

Now we need to migrate the eDirectory configuration file back to the original location:

# mv /etc/opt/novell/eDirectory/conf/nds.conf /etc

and delete the line “/etc/opt/novell/eDirectory/conf/nds.conf”from the file /etc/opt/novell/eDirectory/conf/.edir/instances.0. There must be only one line in containing “/etc/nds.conf”.

# rcndsd restart

Now check if the steps above worked and eDirectory is now listening on the secure ldap port:

# netstat -tanpu | grep 10636

tcp        0      0 0.0.0.0:10636           0.0.0.0:*               LISTEN      12562/ndsd

Now we switch back the TLS requirement as the port 10636 is now open:

# ldapconfig set ‘Require TLS for Simple Binds with Password=yes’ -a admin.system

NLDAP server configuration utility for Novell eDirectory 8.8 SP3 v20216.73 

[1] Instance at /etc/nds.conf:  blx-zlm002.O=system.BLX_ZLM002-TREE
Password: 	<provide the ZLM Administrator password > 

LDAP Server Configuration:
LDAP Server: CN=LDAP Server - blx-zlm002.O=system
LDAP Group: CN=LDAP Group - blx-zlm002.O=system
Require TLS for Simple Binds with Password set to yes
LDAP Server refreshed with the new configuration.

As the certificate authority now has changed, we need to export the new public key of it and add it to the java key store ZLM uses for the secure ldap connection to the edirectory:

First grab the password for the java keystore we need to create from your running ZLM server, not the old config file ! Therefor check the file server.xml of the ZLM tomcat instance for it:

# cat /etc/opt/novell/zenworks/tomcat/base/server.xml | grep keystorePass
keystorePass=”6629e7bf19a845c1a8ee81cb2da50b89”

Then grab the public key of the edirectory certificate authority and copy it to a file eg. called ca.b64:

# openssl s_client -connect localhost:10636 -showcerts -keyform DER

CONNECTED(00000003)
depth=1 /OU=Organizational CA/O=BLX_ZLM002-TREE
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/O=BLX_ZLM002-TREE/CN=blx-zlm002.brunold.at
   i:/OU=Organizational CA/O=BLX_ZLM002-TREE
-----BEGIN CERTIFICATE----- ...
-----END CERTIFICATE-----
 1 s:/OU=Organizational CA/O=BLX_ZLM002-TREE 
   i:/OU=Organizational CA/O=BLX_ZLM002-TREE
-----BEGIN CERTIFICATE----- MIIFOzCCBCOgAwIBAgIkAhwU4T7E9RD9k7RX/68pr64twzvO+ApIlj/Xgd5kAgIM DTQnMA0GCSqGSIb3DQEBBQUAMDYxGjAYBgNVBAsTEU9yZ2FuaXphdGlvbmFsIENB MRgwFgYDVQQKFA9CTFhfWkxNMDAyLVRSRUUwHhcNMTAwMjI2MTEyMDA0WhcNMjAw MjI2MTEyMDA0WjA2MRowGAYDVQQLExFPcmdhbml6YXRpb25hbCBDQTEYMBYGA1UE ChQPQkxYX1pMTTAwMi1UUkVFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA4yDkpyO/ck67GKDioJHl3LXI623pPAORuAHLJRJcaBziQowZO984snooe7/I yjQ6EqY7KFtJ4xoqCWcTf9MGolb0+Kw1PNHWdp00PIfMoTgh/kLZuBKzCzkpuvhG eOw+Cf3eGRkIS9SMEESTmmurbDWLLMcvttsnqGshm6mdMEF5qklEf4MBp9F15JHi UDfu0g1UQm8g1O2EUltlTfbnGWRAd8Mk6q2mpoiJRr29gyIMGBNeh965X8YVirei kXM9+RkeItcUISPFLKMloaIeU1y7fsMhkzKJE+1U1Xyb5oI+Tl79rHclJJ2jj7RE luGn3V+Yt7dSyxUATcCcSz8iTwIDAQABo4ICLzCCAiswHQYDVR0OBBYEFLmWcUAJ cuaeddzABSVzXafh6IoVMB8GA1UdIwQYMBaAFLmWcUAJcuaeddzABSVzXafh6IoV MAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMIIBzAYLYIZIAYb4NwEJBAEEggG7 MIIBtwQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRw Oi8vZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2Nl cnRhdHRyc192MTAuaHRtMIIBSKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmh GgEBADAIMAYCAQECAQAwCDAGAgEBAgEAAgEAogYCARgBAf+jggEEoFgCAQICAgD/ AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh//////////wEB AAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IoVgCAQICAgD/AgEAAw0A QAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAwGDAQAgEAAgh//////////wEBAAIEFOE+ xDAYMBACAQACCH//////////AQEAAgQU4T7Eok4wTAIBAgICAP8CAQADDQCA//// //////////8DCQCA/////////zASMBACAQACCH//////////AQH/MBIwEAIBAAII f/////////8BAf8wDQYJKoZIhvcNAQEFBQADggEBAFIUh1l8IpbIxhK5bni8ZQFa GBtMzqB6LtmN0cSgSMXKgHMUiH3tVcS/xFKQzjLdM7Nhe+ZCGsWsHDAezlcTi/94 zOwNj8L8SnGWkfAjPSSIlXd31pvvxaUXY+u1YOLlP59USe1joX2/lWEPKyjUH62x AulOP6JFoVyrHEmaft4pa4l01mxIsM8dw1FLbJnlVQIcIE4WYYAUUAQ+5/TbwQGR 1Iza0vw1YuiCxiE3uLIa6E5FwyaDgkFqqdO366TFWUieCgOciFYfkQUdQBeKe20F ApDmLGq5VPEYg1DUsH6ISndQgjOn++KJaId2ExlF3RbiAN/oy05pQx6Hd4lVVrg= -----END CERTIFICATE----- 
---
Server certificate
subject=/O=BLX_ZLM002-TREE/CN=blx-zlm002.brunold.at
issuer=/OU=Organizational CA/O=BLX_ZLM002-TREE

Take care that you copy the second certificate in the list (1 s:/OU=Organizational CA/O=BLX_ZLM002-TREE) starting with “—–BEGIN CERTIFICATE—–” till “—–END CERTIFICATE—–” into the ca.b64 file.

Now create the new java keystore and copy it to the appropriate location:

# /opt/novell/eDirectory/lib64/nds-modules/embox/jre/bin/keytool -import -file ca.b64 -alias

127.0.0.1 -keystore ldap-certs
Enter keystore password:  <provide the keystore password here >
Owner: O=BLX_ZLM002-TREE, OU=Organizational CA
Issuer: O=BLX_ZLM002-TREE, OU=Organizational CA
Serial number: 21c14e13ec4f510fd93b457ffaf29afae2dc33bcef80a48963fd781de6402020c0d3427
Valid from: Fri Feb 26 12:20:04 CET 2010 until: Wed Feb 26 12:20:04 CET 2020
Certificate fingerprints:
	 MD5:  9A:C6:F7:95:E3:1B:00:38:74:D6:AC:35:50:7E:9C:6F
	 SHA1: 5B:8D:8B:7E:FE:27:89:C1:3B:26:90:42:F4:43:72:29:1A:C3:C1:17
Trust this certificate? [no]:  yes
Certificate was added to keystore

# cp ldap-certs /opt/novell/zenworks/datamodel/share/ldap-certs

Djbdns — Different programs

Posted by phatdee on March 13, 2012
Posted in: djbDNS, TinyDNS djbdns. Tagged: djbdns, dnscache, tinydns. Leave a Comment
ServiceDescription
DnscacheDnscache is a local DNS cache that accepts recursive DNS queries from local clients and collects responses from other DNS servers.
TinyDNSTinyDNS is responsible for making DNS information available to the Internet. TinyDNS handles load balancing and client differentiation, or directing clients to specific servers.
WalldnsWalldns hides local host information from requested reverse and forward records.
RbldnsRbldns is an IP address-listing DNS service. It can be used to publish a list of IP addresses that provide a specific service.
DnsfilterDnsfilter is an IP-address-to-hostname conversion utility.
dnsip, dnsipq, dnsname, dnstxt, dnsmxThese are command line tools used to manage the DNS services.
dnsq, dnsqr, dnstraceThese are DNS debugging utilities.

Wodim — Device Names

Posted by deeman on February 28, 2012
Posted in: File Systems. Tagged: file systems. Leave a Comment

Don’t know your CDROM device name? 

$ wodim –device
You do now..

Listing A to Z and 1 to 10

Posted by phatdee on February 21, 2012
Posted in: Shell, Useful Commands. Tagged: useful commands. Leave a Comment

seq -s : 1 10
1:2:3:4:5:6:7:8:9:10

seq -s / 1 10
1/2/3/4/5/6/7/8/9/10

seq -s // 1 10
1//2//3//4//5//6//7//8//9//10

echo {a..z}
a b c d e f g h i j k l m n o p q r s t u v w x y z

Removing blank lines from file using vi

Posted by phatdee on February 17, 2012
Posted in: Useful Commands, VIM. Tagged: vi. Leave a Comment

In the past I’ve always removed empty lines using

:g/^$/d

However, just found an easier way..

:v/./d

Posts navigation

← Older Entries
  • Subscribe

    Enter your email to subscribe to future updates
  • Categories

  •  

    May 2012
    M T W T F S S
    « Apr    
     123456
    78910111213
    14151617181920
    21222324252627
    28293031  
  • RSS DistroWatch.com: News

    • Development Release: LuninuX OS 12.00 Beta 2
    • Distribution Release: Dream Studio 12.04
    • Distribution Release: ExTiX 10
    • Development Release: Zorin OS 6 RC
    • Development Release: Linux Mint 13 RC
    • Distribution Release: Hybryde Linux 1
    • Distribution Release: Parted Magic 2012_05_14
    • Development Release: siduction 12.1 RC
    • Distribution Release: Ophcrack LiveCD 3.4.0
    • Distribution Release: Chakra GNU/Linux 2012.05
  • RSS LinuxSecurity.com – Security Advisories

    • Ubuntu: 1445-1: Linux kernel vulnerabilities
    • Ubuntu: 1445-1: Linux kernel vulnerabilities
    • Debian: 2475-1: openssl: integer underflow
    • Ubuntu: 1444-1: BackupPC vulnerability
    • Ubuntu: 1443-1: Update Manager vulnerabilities
    • Mandriva: 2012:078: imagemagick
    • Mandriva: 2012:077: imagemagick
    • Debian: 2474-1: ikiwiki: cross-site scripting
    • Debian: 2473-1: openoffice.org: buffer overflow
    • Ubuntu: 1442-1: Sudo vulnerability
  • Recent Posts

    • Logcheck — check logs for unusual activity and emails
    • Git cheatsheet
    • Various GIT cheatsheets
    • Install and configure DHCP
    • Network Installation of SLES/SLED/Suse
    • tar directory + hidden files like home directories
    • Swat — Setting up stunnel
    • Novell ZLM 7.3.x SSL cert expiration.
    • Djbdns — Different programs
    • Wodim — Device Names
  • Meta

    • Log in
    • Entries RSS
    • Comments RSS
    • WordPress.org
Proudly powered by WordPress Theme: Parament by Automattic.