Tuesday, February 22, 2005

Centralizing Syslogs

Simple methods to setup a basic syslog server and start sending logs to it.

Tested with RedHat 7/8/9, Fedora Core 2 and Core 3


Set Up a Syslog Server

Unfortunately the /etc/sysconfig/syslog parameters don't work as I've tested, so manual editing of the /etc/rc.d/init.d/syslog is necessary. Add the "-r" option to the daemon line of the start() function.

/etc/rc.d/init.d/syslog excerpt

[...]
start() {
echo -n $"Starting system logger: "
daemon syslogd -h -r $SYSLOGD_OPTIONS
RETVAL=$?
echo
echo -n $"Starting kernel logger: "
daemon klogd $KLOGD_OPTIONS
echo
$RETVAL -eq 0 && touch /var/lock/subsys/syslog
return $RETVAL
}
[...]

Once edited, save and restart the syslog daemon.

service syslog restart

Check to see if it is listening on UDP port 514.

netstat -an | grep 514

SENDING LINUX CLIENT SYSLOGs TO THE SYSLOG SERVER

Edit the /etc/syslog.conf file to direct the syslog output with the "@" directive. In the example below, note that this syslog is recording both locally and to a remote syslog server. This ensures that the event is recorded locally at the very least if there is a network disruption that prevents communication with the central Syslog server.

/etc/syslog.conf excerpt


[...]

 # Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
*.info;mail.none;authpriv.none;cron.none @10.x.x.x
 # The authpriv file has restricted access.
authpriv.* /var/log/secure
authpriv.* @10.x.x.x

[...]


Once edited, save and restart the syslog daemon.

  service syslog restart 

SENDING WINDOWS CLIENT EVENT LOGS TO THE SYSLOG SERVER

Get NTSyslog from the sourceforge website. http://ntsyslog.sourceforge.net/. Install it, run the GUI control 'NTSyslogCtrl.exe' and direct the machine to the central syslog server.

AUTOMATING DEPLOYMENT

Create a folder called 'ntsyslog'. Extract the ntsyslog-1.13.zip [1] file inside that folder, creating a folder 'ntsyslog-1.13'. Create the following batch and registry files in the 'ntsyslog' folder.

NtSyslogReg

Nt Syslog Reg

REGEDIT4

HKEY_LOCAL_MACHINE\SOFTWARE\SaberNet?
"Syslog"="your.server.here"
"syslog1"="your.other.server.here"

HKEY_LOCAL_MACHINE\SOFTWARE\SaberNet\Syslog\Application?
"Information"=dword:00000000
"Information Priority"=dword:00000009
"Warning"=dword:00000001
"Warning Priority"=dword:00000009
"Error"=dword:00000001
"Error Priority"=dword:00000009
"Audit Success"=dword:00000000
"Audit Success Priority"=dword:00000009
"Audit Failure"=dword:00000001
"Audit Failure Priority"=dword:00000009

HKEY_LOCAL_MACHINE\SOFTWARE\SaberNet\Syslog\System?
"Information"=dword:00000000
"Information Priority"=dword:00000009
"Warning"=dword:00000001
"Warning Priority"=dword:00000009
"Error"=dword:00000001
"Error Priority"=dword:00000009
"Audit Success"=dword:00000000
"Audit Success Priority"=dword:00000009
"Audit Failure"=dword:00000001
"Audit Failure Priority"=dword:00000009

HKEY_LOCAL_MACHINE\SOFTWARE\SaberNet\Syslog\Security?
"Information"=dword:00000000
"Information Priority"=dword:00000009
"Warning"=dword:00000001
"Warning Priority"=dword:00000009
"Error"=dword:00000001
"Error Priority"=dword:00000009
"Audit Success"=dword:00000000
"Audit Success Priority"=dword:00000009
"Audit Failure"=dword:00000001
"Audit Failure Priority"=dword:00000009

NtSyslogBatch

Nt Syslog Batch

@echo off
cmd /c xcopy \\\\ntsyslog-1.13\* c:\ntsyslog\ /Y /S
cmd /c c:\ntsyslog\ntsyslog.exe -install
cmd /c regedit /s \\\\ntsyslog.reg
echo Syslogger will be installed at next reboot.

Resulting tree:

 ntsyslog (shared as \\server\ntsyslog)
|
|-------ntsyslog.reg
|-------install_ntsyslog.bat
|-------nysyslog-1.3
|
|------(NT Syslog files...)

** NOTE FOR WINXP SP2 **
Be sure to enable the NTSYSLOG application in the firewall. Otherwise the log server will receive error messages every second until it is filled (~ 20GB/day).

AUTOMATING DEPLOYMENT FOR WINDOWS 98

Same as above, only use this modified batch script.

NtSyslogBatch98

Nt Syslog Batch 98

@echo off
command /c xcopy \\\\ntsyslog-1.13\* c:\ntsyslog /Y /S
command /c c:\ntsyslog\ntsyslog.exe -install
command /c regedit /s \\\\ntsyslog.reg
echo Syslogger will be installed at next reboot.

Monday, February 21, 2005

Snort Documentation for Creating a Distributed Intusion Detection System on Fedora

Tested on Fedora Core 2 and Core 3.

Central Console Setup

MySQL Database

Based on Patrick Harper's guide to Snort/Acid installation (http://www.snort.org/docs/Snort_SSL_FC2.pdf)


DATABASE INSTALLATION

If necessary, install the database package and start the service.

 yum install mysql
service mysqld start

Download the latest SNORT package (http://www.snort.org/dl/snort-2.3.0.tar.gz) and version 2.2.0 (http://www.snort.org/dl/snort-2.2.0.tar.gz). Both will be needed to get the extra features of the database loaded.

 cd /usr/local/src
wget http://www.snort.org/dl/snort-2.3.0.tar.gz
wget http://www.snort.org/dl/snort-2.2.0.tar.gz
tar xvfz snort-2.3.0.tar.gz
tar xvfz snort-2.2.0.tar.gz

Time to make the database. If this is your first installation of MySQL, be sure to set the root password. Create a database 'snort', a user for it, and grant the appropriate permissions. **NOTE: This is lifted almost verabtim from Patrick's doc at http://www.snort.org/docs/Snort_SSL_FC2.pdf. I've modified some of the content slightly to fit this example.


 mysql
mysql> SET PASSWORD FOR root@localhost=PASSWORD('password');
>Query OK, 0 rows affected (0.25 sec)
mysql> create database snort;
>Query OK, 1 row affected (0.01 sec)
mysql> grant INSERT,SELECT on root.* to snort@localhost;
>Query OK, 0 rows affected (0.02 sec)
mysql> SET PASSWORD FOR snort@localhost=PASSWORD('password_from_snort.conf');
>Query OK, 0 rows affected (0.25 sec)
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@localhost;
>Query OK, 0 rows affected (0.02 sec)
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort;
>Query OK, 0 rows affected (0.02 sec)
mysql> exit
>Bye

Execute the following commands to create the tables

 mysql -u root -p < /usr/local/src/snort-2.3.0/contrib/create_mysql snort
Enter password: the mysql root password

Then install the extra DB tables using the following command

 zcat /usr/local/src/snort-2.2.0/contrib/snortdb-extra.gz |mysql -p snort
Enter password: the mysql root password

Now you need to check and make sure that the Snort DB was created correctly

 mysql -p
>Enter password:
mysql> SHOW DATABASES;

(You should see the following)

+------------+
| Database
+------------+
| mysql
| Snort
| test
+------------+
3 rows in set (0.00 sec)

 mysql> use Snort
>Database changed mysql> SHOW TABLES;

+------------------+
| Tables_in_Snort
+------------------+
| data
| detail
| encoding
| event
| flags
| icmphdr
| iphdr
| opt
| protocols
| reference
| reference_system
| schema
| sensor
| services
| sig_class
| sig_reference
| signature
| tcphdr
| udphdr
+------------------+
19 rows in set (0.00 sec)

 mysql> exit 

BASE Analytics

Based on Patrick Harper's guide to Snort/Acid installation (http://www.snort.org/docs/Snort_SSL_FC2.pdf)


BASE INSTALLATION

If necessary, install the web server package and start the service.

 yum install httpd
service httpd start

Download the latest JPGraph (http://www.aditus.nu/jpgraph/jpdownload.php) and ADODB (http://phplens.com/lens/dl/adodb453.tgz) packages. Unpack and install them. This example assumes a default web root at /var/www/html.

 cd /usr/local/src
wget http://phplens.com/lens/dl/adodb453.tgz
wget http://members.chello.se/jpgraph/jpgdownloads/jpgraph-1.17.tar.gz
tar xvfz adodb453.tgz
tar xvfz jpgraph-1.17.tar.gz
mv adodb /var/www/
mv jpgraph-1.17 /var/www/
ln -s /var/www/jpgraph-1.17 /var/www/jpgraph

Download BASE (http://www.snort.org/dl/contrib/data_analysis/BASE/) from the snort website and unpack it.

 wget http://www.snort.org/dl/contrib/data_analysis/BASE/base-1.0.tar.gz
tar xvfz base-1.0.tar.gz
mv base /var/www/html/

Create the BASE configuration file and define the variables.

 cd /var/www/html/base
cp base_conf.php.dist base_conf.php
vi base_conf.php
Set $BASE_urlpath to the web path used to access BASE
$BASE_urlpath = "http:///base";
set $DBlib_path to the ADODB path
$DBlib_path = "/var/www/adodb";
set $DBtype to the MySQL
$DBtype = "mysql";
set the alert and archive databases to their requisite database and access settings.
set $ChartLib_path to the JPGraph path
$ChartLib_path = "/var/www/jpgraph/src";
Save and exit

Open a browser and navigate to your site. On first access, BASE will ask to install the requisite tables and alert data into the database. Press the Setup button. On successive accesses, this will already exist and BASE will go straight to the analytics page.

 http:///base 

Centralized Rule & Configuration Distribution

CREATE A CENTRALIZED DISTRIBUTION WEB SERVER

This is a very insecure setup and is not intended for a public-facing server. Only use this for an internal server. Please use appropriate security precautions.

These examples assume a default webroot installation at /var/www/html.

If necessary, install the web package and start the service.

 yum install httpd
service httpd start

Create a 'snort' directory and subdirectories.

 cd /var/www/html
mkdir -p snort/rules
mkdir -p snort/bleedingedge
mkdir -p snort/oinkmaster
mkdir -p snort/rpm
mkdir -p snort/config
cd snort

Get the basic packages needed to create a drone. This snort_mirror.sh sample script will pull mirrors of the relavent rule files from snort.org and bleedingsnort.org.

 /usr/local/bin/snort_mirror.sh 

Schedule the mirror script to be run with cron.

 crontab -e
0 5 * * * /usr/local/bin/snort_mirror.sh;

Fill in the config and rpm directories. These are the master files. Use the RPMS from the SensorInstallation process.

 cd /var/www/html/snort/rpm
cp /usr/src/redhat/RPMS/i386/snort-2.3.0-0.fdr.1.i386.rpm .
cp /usr/src/redhat/RPMS/i386/snort-debuginfo-2.3.0-0.fdr.1.i386.rpm .
cp /usr/src/redhat/RPMS/i386/snort-mysql-2.3.0-0.fdr.1.i386.rpm .
cd ../config
cp /etc/oinkmaster.conf .

Change oinkmaster.conf to point to http:///snort/rules/snort-snapshot-2_3.tar.gz.

***Note, this file contains passwords that grant access to the snort database. Perhaps an encrypted transport would be better.

 cp /etc/snort/snort.conf . 

Populate oinkmaster for distribution. Use the oinkmaster files from the OinkmasterRuleUpdates process.

 cd /var/www/html/snort/oinkmaster
cp /usr/local/src/oinkmaster/oinkmaster.pl .
cp /usr/local/bin/oinkmaster.sh .

Change the oinkmaster.sh file to point to http:///snort/bleedingedge/bleeding.rules.tar.gz.

USING THE CENTRAL SERVER

From the sensor machine, get the files needed to install the snort drone and install. Or just run this drone_install.sh script for all of the below steps.

 cd /usr/local/src
wget http:///snort/rpm/snort-2.3.0-0.fdr.1.i386.rpm
wget http:///snort/rpm/snort-debuginfo-2.3.0-0.fdr.1.i386.rpm
wget http:///snort/rpm/snort-mysql-2.3.0-0.fdr.1.i386.rpm
rpm -ivh snort-2.3.0-0.fdr.1.i386.rpm snort-mysql-2.3.0-0.fdr.1.i386.rpm snort-debuginfo-2.3.0-0.fdr.1.i386.rpm

On the drone, set up oinkmaster.

 cd /etc
wget http:///snort/config/oinkmaster.conf
cd /usr/local/bin
wget http:///snort/oinkmaster/oinkmaster.pl
wget http:///snort/oinkmaster/oinkmaster.sh

Set up the snort files.

 cd /etc/rc.d/init.d
wget http:///snort/config/snortd
cd /etc/snort
wget http:///snort/config/snort.conf
cd /etc/sysconfig
wget http:///snort/config/snort

Set it up for boot and run it.

 chkconfig snortd on
service snortd start

Check the log for errors.

 cat /var/log/messages | grep snort 

UPDATING THE DRONES

A cron job will need to be set up to automatically update the configuration files, rules, and restart snort. The job will need to retrieve oinkmaster and snort configuration changes and update the rules. It will then need to restart snort for the changes to take effect. A cron job like this drone_update.sh script should do the trick. This will be run as root because of the service restart at the end, which needs root privileges. Only make changes to the master server if you've thoroughly tested the effect in a comparably configured test drone or you'll run the risk of killing all of the sensors!

 crontab -e
15 2 * * * /usr/local/bin/drone_update.sh

Sensor Installation

SENSOR INSTALLATION

Install these packages to satisfy dependancies.

 yum install mysql
yum install mysql-devel
yum install pcre
yum install pcre-devel

Download the latest PCRE package from http://www.pcre.org. This will provide the libpcre.h file required for the RPM build. Current version tested with is version 5.0.

 cd /usr/local/src
wget http:///sourceforge/pcre/pcre-5.0.tar.gz

Untar, build and install.

 tar xvfz /usr/local/src/pcre-5.0.tar.gz
cd pcre-5.0
./configure
make
make check
make install

Download the snort source from http://www.snort.org. Current version tested with is version 2.3.0.

 wget http://www.snort.org/dl/snort-2.3.0.tar.gz 

Untar the archive and enter the directory.

 tar xvfz /usr/local/src/snort-2.3.0.tar.gz
cd snort-2.3.0

Configure and make the source files.

 ./configure
make
make check

Change to the 'rpm' directory. Create the RPMS for install.

 cd rpm
rpmbuild --with fedora --with mysql -ta /usr/local/src/snort-2.3.0.tar.gz

Install the RPMS.

 rpm -ivh /usr/src/redhat/RPMS/i386/snort-2.3.0-0.fdr.1.i386.rpm /usr/src/redhat/RPMS/i386/snort-debuginfo-2.3.0-0.fdr.1.i386.rpm /usr/src/redhat/RPMS/i386/snort-mysql-2.3.0-0.fdr.1.i386.rpm 

The RedHat-compliant setup makes some assumptions that need to be fixed. Edit the daemon startup script in /etc/rc.d/init.d and remove the $ALERTMODE variable from each start line.

 cd /etc/rc.d/init.d
vi snortd
Remove $ALERTMODE from the start() function calls and save.

Edit the snort configuration file. Add an output for the database.

 cd /etc/snort
vi snort.conf
Change the HOME_NET variable to your public IP address
Add the line "output database: log, mysql, user=snort password= dbname=snort host=" to section 3.
  **OPTIONAL: DSHIELD**
You may want to add "output alert_syslog: LOG_AUTH LOG_ALERT" for use with DShield parsing scripts.
Save and exit.

Test snort.

 snort -T -c /etc/snort/snort.conf 

If all is well, change the ownership to the snort user. This will make life easier later.

 chown -R snort:snort /var/log/snort /etc/snort 

Add snort to the startup regimen and start the service.

 chkconfig snortd add
service snortd start

Final check: check syslog for successful startup messages.

 cat /var/log/messages | grep snort 

Oinkmaster Rule Updates

OINKMASTER INSTALLATION

Get the latest script from the snort website (http://www.snort.org/dl/contrib/rule_management/oinkmaster/). Untar it.

 cd /usr/local/src
wget http://www.snort.org/dl/contrib/rule_management/oinkmaster/oinkmaster-1.1.tar.gz
tar xvfz oinkmaster-1.1.tar.gz
ln -s oinkmaster-1.1 oinkmaster
cd oinkmaster

Install the script into one of the local binary directories. I prefer /usr/local/bin.

 cp oinkmaster.pl /usr/local/bin 

Modify and install the configuration file.

 vi oinkmaster.conf
Set url to the path of your snort version
url = http://www.snort.org/dl/rules/snortrules-snapshot-2_3.tar.gz
Save and exit.
cp oinkmaster.conf /etc/

To add some additional functionality to oinkmaster, you might want to write a script. This would allow for updates from multiple sites (say Bleeding Edge and Snort.org), mail notification, logging and so forth. Here's my sample oinkmaster.sh script.

 wget http://www.hunt-family.net/oinkmaster.sh
vi oinkmaster.sh
Change the email address to your own.
Save and exit.
cp oinkmaster.sh /usr/local/bin

Schedule the script to run at a time of your choosing with cron, preferably as the 'snort' user.

 crontab -e -u snort
07 01 * * * /usr/local/bin/oinkmaster.sh
Save and exit.

D-Shield Integration

Integrating Snort with DShield for Automated Reporting of Violators to ISPs.

OVERVIEW

DShield is an organization dedicated to monitoring Internet threats from the same folks that update the Internet Storm Center (http://isc.sans.org). In fact, much of the data presented on the Internet Storm Center is from the DShield collaborative. For more information or reasons why you should contribute to DShield, visit thier site at http://dshield.org.

GET THE SCRIPTS

Navigate to http://www.dshield.org/howto.php and download the client of choice. For this example, I've used the "Linux 2.4x iptables," "Snort 1.8," and "Snort Portscan" clients.

 cd /usr/local/src
wget http://www.dshield.org/clients/framework/iptables.tar.gz
wget http://www.dshield.org/clients/framework/snort_portscan.tar.gz
wget http://www.dshield.org/clients/framework/snort_18_syslog.tar.gz

REGISTER ON THE SITE

Click the "Signup" link on the home page. This allows you to receive a nicely formatted daily report on the attacks/scans you have submitted. Registration for the Fightback program is optional, but recommended. This gives the DShield organization permission to submit abuse complaints to ISPs on your behalf.

CONFIGURE AND TEST

Untar the archives.

 tar xvfz iptables.tar.gz
tar xfvz snort_18_syslog.tar.gz
tar xvfz snort_portscan.tar.gz

Enter the iptables directory and edit the test.cnf file to fit your environment. Change the "whereto=" line to "whereto=./output.txt". To test the mail delivery of the output, uncomment and enter your email address and local sendmail command. The default is usually sufficient. NOTE: An MTA must be running on the host running the script. Run the test wrapper and review the results in output.txt and debug.txt.

 cd iptables
vi test.cnf
Change 'whereto=' to a local output file.
Change the email information and enable the sendmail command.
Save and exit.
./test_wrapper.sh

The script should run and deliver output to the local 'output.txt' file. Check it to see if the iptables denials were dumped correctly. To see how the process worked, look at the debug.txt file as well.

 cat output.txt
cat debug.txt

If satisfactory, repeat for the snort and snort portscan scripts. Each of these should read from the /var/log/messages file for different lines. Check your email to see if the email messages delivered properly.

SETTING UP A COMMON CONFIGURATION SET FOR MULTIPLE SCRIPTS

Create a configuration directory under /etc. Populate it with the source and target exclude files. Also copy the production configuration file.

 cd /usr/local/src/iptables
mkdir /etc/dshield
cp *.lst dshield.cnf /etc/dshield/

Now modify the exclude files. The source-exclude file should include your private network ranges and any testing Internet servers you may use. The other exclude files are typically fine as they are.

 cd /etc/dshield
mv dshield.cnf dshield_iptables.cnf
vi dshield-source-exclude.lst
I added GRC Shields Up! scanner to my exclude list since I use it to do most of my Internet-based port scanning.
Save and exit.

Edit the configuration file for production script use. Enter your email and the user id you received when you registered at the DShield site. Leave the 'to=' field as it is. If you would like to receive a copy of what the script submits, add your email to the 'cc=' line. Set 'whereto=' to 'whereto=MAIL'. Change the path in the 'source_exclude=', 'source_port_exclude', 'target_exclude' and 'target_port_exclude' variables to /etc/dshield/(filename). Make sure 'obfus=N' to use the Fightback service. Set 'verbose=N', but change 'debug=Y' for use as a transcript file later in a later step.

 cp dshield.cnf dshield_iptables.cnf
vi dshield_iptables.cnf
Edit the variables as described above:
from=
userid=
to=report@dshield.org
log=/var/log/messages
sendmail=/usr/sbin/sendmail -oi -t
whereto=MAIL
source_exclude=/etc/dshield/dshield-source-exclude.lst
target_exclude=/etc/dshield/dshield-target-exclude.lst
source_port_exclude=/etc/dshield/dshield-source-port-exclude.lst
target_port_exclude=/etc/dshield/dshield-target-port-exclude.lst
obfus=N
linecnt=/tmp/dshield.cnt
verbose=N
debug=Y
rotate=N
Save and exit.

Copy the snort and snort portscan config files into the /etc/dshield directory as dshield_snort.cnf and dshield_snort_portscan.cnf files. Perform the same procedure on them, only use dshield_snort.cnt or dshield_portscan.cnt for the linecnt variable. When complete, the /etc/dshield directory should contain the following:

   root@www bin# ls -1 /etc/dshield
dshield_iptables.cnf
dshield_snort.cnf
dshield-source-exclude.lst
dshield-source-port-exclude.lst
dshield-target-exclude.lst
dshield-target-port-exclude.lst
dshield_snort_portscan.cnf

CREATING THE PRODUCTION SCRIPTS

Install the perl scripts into the /usr/bin directory.

   cd /usr/local/src
cp iptables/iptables.pl /usr/bin
cp snort_18_syslog/snort_18_syslog.pl /usr/bin
cp snort_portscan/snort_portscan.pl /usr/bin

Once you have test scripts that work when executed manually, copy the launching scripts into the /usr/local/bin folder.

   cd /usr/local/src
cp iptables/test_wrapper.sh /usr/local/bin/dshield_iptables
cp snort_portscan/test_wrapper.sh /usr/local/bin/dshield_snort_portscan
cp snort_18_iptables/test_wrapper.sh /usr/local/bin/dshield_snort

When done, the folder should look similar to this:

   root@www bin# ls
dshield_iptables dshield_snort dshield_snort_portscan

Create a script to launch all of the others at /usr/local/bin/dshield.

   root@www bin# cat /usr/local/bin/dshield
#!/bin/bash
/usr/local/bin/dshield_iptables
/usr/local/bin/dshield_snort_portscan
/usr/local/bin/dshield_snort

Create the /var/log directory for dshield.

   mkdir /var/log/dshield 

Edit the scripts for production use.

   cd /usr/local/bin
vi dshield_iptables
Comment out the "echo "20021201000000" > dshield.cnt" line.
Change the executable line to read "/usr/bin/iptables.pl -config=/etc/dshield/dshield_iptables.cnf > /var/log/dshield/iptables_debug.txt"
Save and exit.
   vi dshield_snort
Comment out the "echo "20021201000000" > dshield.cnt" line.
Change the executable line to read "/usr/bin/snort_18_syslog.pl -config=/etc/dshield/dshield_snort.cnf > /var/log/dshield/snort_syslog_debug.txt"
Save and exit.
   vi dshield_snort_portscan
Comment out the "echo "20021201000000" > dshield.cnt" line.
Change the executable line to read "/usr/bin/snort_portscan.pl -config=/etc/dshield/dshield_snort_portscan.cnf > /var/log/dshield/snort_portscan_debug.txt"
Save and exit.

AUTOMATING SUBMISSIONS

Edit the root crontab file to execute the scripts.

   crontab -e
Add a line with "20 * * * * /usr/local/bin/dshield". This will execute the script on the :20 minute every hour.
Save and exit.

FINAL TESTING

Execute the dshield script manually to test it. Make sure the three submission emails are received.

   /usr/local/bin/dshield 

WRAPPING UP

Once running well, the submission emails can be curtailed by editing the /etc/dshield/*.cnf files and blanking out the "cc=" email addresses.

Cygwin Documentation for Installing OpenSSH on Windows 2003

Tested on Windows 2003.


If you have trouble, this is also a good resource

http://www.cs.bham.ac.uk/~smp/projects/ssh-windows/


Cygwin Installation Instructions - Optimized for SSH

Purpose
Provide method of secure file transport. This allows for new files to be updated on the servers and for backups between servers to take place securely.

Pre-Installation
See the SSH Installation document for account setup steps that must occur prior to installing Cygwin.

Installation
1) Launch the Setup program.

2) When the setup program starts, click "Next."

3) Select "Install from Local Directory" if you already have the install files downloaded. Otherwise select "Install from Internet." Click next. See below.

4) Enter the desired root directory for Cygwin. This will be the '\' directory in the shell. Install Cygwin "For All Users," otherwise you will have problems with permissions. Pick a text file type (recommend Unix).

5) Set the local package directory if you are installing from local directory. Otherwise select your download site.

6) On the next screen, make sure to have the Cygwin base files and OPENSSH packages installed. I recommend installing OPENSSL as well.

7) The program sets off installing Cygwin packages. This may take a few minutes. When it does get to the next screen, select install Start Menu shortcuts. Click Next.

8) See Install SSH with PKA document for further instruction on setting up SSH services.

Setting up Secure Shell with Public Key Authentication Capability on Cygwin

Pre-Installation
Before installing Cygwin on the server, follow these steps as the administrator account:

1) Open the User/Group manager and create group "grsshd" and user "sshd".

2) Make "sshd" a member of group "grsshd".

3) Install Cygwin as detailed in the Install Cygwin For SSH document.

Installation
Do this after installing Cygwin. Log into the SSH server machine as the system administrator.

1) Execute the following commands from the Cygwin shell:

 $ ssh-host-config -y
$ touch /var/log/sshd.log
$ chown sshd:grsshd /var/empty /var/log/sshd.log /etc/ssh*

2) Open the Services Manager. Open the properties for "Cygwin sshd" service. Navigate to the "Log On" tab. Set the service to use the ".sshd" account and enter the password for the account. Press OK.

3) Open the Local Security Policy manager. Navigate to Local Policies -> User Rights Management. Change the following settings to include the account "sshd":

  • Act as part of operating system
  • Replace process level token
  • Adjust memory quotas for a process
  • Login as service

Close the Policy Manager.

4) Run "cygrunsrv -S sshd". If no errors, run "cygrunsrv -Q sshd" for status of the service. The SSHD service is now established. Proceed to the next section if your account will be pursuing Public Key Authentication.

Establishing Public Key Authentication
These instructions assume you are logged into the client machine and are using OpenSSH (Cygwin) to connect to the SSH server. If you are using another client product, such as Putty, the commands will be slightly modified, but the process is the same. Modify commands as per the requirements of your software.

Cygwin has some limitations with regard to PKA. PKA on the server can only be set up on the account under which the SSHD daemon (service) is run. That means for PKA logins, the connection will always log in as the "sshd" account on the remote server. If you desire access to your own account, you will have to run "ssh " and enter a password, assuming you have previously established your account on that server.

To establish PKA to the "sshd" account, perform the following steps:

1) Generate the DSA keys for SSH protocol 2 authentication. Open a Cygwin shell and execute "ssh-keygen -t dsa". Answer all questions with blanks.

2) Generate the RSA keys for SSH protocol 2 authentication. Execute "ssh-keygen -t rsa". Again, answer blank to all questions.

3) Run "ssh -l sshd ". Enter the password for the "sshd" account you set up while establishing the SSH process on the server. You should now have a prompt at the remote server under the account "sshd".

4) Run "ssh localhost" to generate a .ssh/known_hosts file. This gets the directory established with the proper permissions if it does not yet exist. Enter the password for "sshd" again.

5) Type "exit" and "exit" again. You should have a prompt at your local machine under your normal user account.

6) Move to your own keys directory. Run "cd .ssh".

7) Prepare your public keys for transport to the server. Create a directory to hold your public keys with "mkdir pub". Copy your keys into this new folder with "cp *.pub pub". Adjust the ownership with command "chown -R sshd:grsshd pub".

8) Transfer the keys to the remote SSH server. "scp -r pub sshd@:~/.ssh" You will be prompted for a password. Enter the password for the "sshd" account on the remote server. Watch the status as the files transfer.

9) When done, initiate a shell to the remote server to prepare the keys for use. Run "ssh -l sshd " and enter the "sshd" password. You should now have a prompt indicating you are on the remote SSH server as the "sshd" account.

10) Navigate to your keys with "cd .ssh/pub".

11) Add your keys to the authorized keys file. This will perform the actual authentication the next time you log in. "cat *.pub >> ../authorized_keys".

12) Leave the remote server. Type "exit". You should now be at your local machine as your normal account.

13) Test the public key authenticator. Run "ssh -l sshd ". You should receive no password prompt and should be immediately logged in as the "sshd" account on the remote SSH server.

14) Type "exit" to leave the server. Your account is now set up for automatic Public Key Authentication to the SSH server.

OpenSSHD service / Windows XP startup / crashing / instability problem *and* solution

Dr. Daniel Schmidt
April 02, 2005
from SSH-L listservice (ssh@erdelynet.com)


Hi all,

I recently discovered something interesting and wanted to share it with the list, in the event that someone else will avoid frustrations similar to my own.

I installed OpenSSH for Windows 3.8.1p1 on an XP Pro (SP2) server machine I administer in our research group. Setup was easy and it ran quietly and effectively (once I told the Windows firewall to let it do so via port 22, of course), but I noticed that I had to log in and manually start the OpenSSH service every time the server rebooted (XP is set on autoupdate, so this does indeed happen from time to time). That was a bit annoying, so I enabled automatic startup via Administrative Tools --> Services.

Then, the fun began. After a reboot, I got a BSOD / immediate reboot two or three times in a row before it finally was able to get into Windows, and when it did so, I was getting all *kinds* of errors. Very, very ugly. I tested a bunch of different things related to what else was starting up, tried replacing the Windows firewall with ZoneAlarm, altered some of the other Services starting, but all to no avail - It would make it into Windows maybe half the time, and even when it did, it was not at all stable or behaving properly.

I noted recently that others have had problems with OpenSSHD for Windows with respect to the fact that, when the Service is set to start automatically, it apparently tries to do so before it "should", making the system as a whole very, very unhappy. I'd suspected something similar on our server, and from this article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q193888

...modified the OpenSSHD Service's registry entry a bit. I noted that the TCIP/IP service was already listed in the "DependOnService" list, so I figured it was probably some other network-related service, maybe the firewall or the antivirus package we're running (Symantec Antivirus Corporate Edition 9). What I decided to do, instead of trying to guess which of the hundred services I needed to have it depend on, was to look here, for the list of Service Groups (I suggest RegEdt32 so that the list doesn’t look like total crap):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder

The Service Groups are listed here in the order Windows starts them. I noted that "Network Provider" was near the bottom of the list, and it certainly seemed reasonable that I would need to be finished starting before OpenSSHD tried to do anything, so I added "Network Provider" to my "DependOnGroup" entry, found here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OpenSSHD

...and it worked fine after that. When in doubt, I would say, just choose the absolute last thing on the Services Groups list and put that in OpenSSHD's "DependOnGroup" entry; this will ensure that it waits until everything else is done before it attempts to start.

Our server survives now rebooting with no problems, and OpenSSHD always starts as it should, with no user intervation (hooray!). To be fair, I'm not the first to try something like this - One can find mention of something like this in an obsolete readme file, here:

http://www.networksimplicity.com/openssh/source/readme.txt

See Troubleshooting (8). Things must've changed since then, however, as this file indicates that "The OpenSSHd service depends on the Computer Browser service so that it starts in the correct order," which is not what I found in my registry.

On my Win2K box at home, on the other hand, and the aforementioned Service Group "Network Provider" does not exist on it; clearly I would have to do something different here than on the aforementioned XP Pro server. It's therefore quite difficult to decide on an appropriate and general dependency for this service, since it's clear that things change quite a bit between various versions of Windows (all to the benefit of the consumer, no doubt) - For the moment it looks like this fix has to be applied on a case by case basis. One further warning, the XP SP2 update renames / changes the default startup values for some services, so we can’t assume that any two MS OS installs with the same name will be "the same" when it comes to such things.

Hope this helps,

Dr. Daniel Schmidt

SSHWindows installation resolution


Original Message----- From: ssh-owner@erdelynet.com mailto:ssh-owner@erdelynet.com On Behalf Of Robert Jacobson Sent: Wednesday, May 18, 2005 7:43 AM To: ssh@erdelynet.com Subject: Re: Automatic Start of opensshd service

At 4:59 PM +0200 5/18/05, M. Franco max-lists-at-ycom.ch |ssh_erdelynet| wrote: >Hi, > >I also have this problem since a reboot after the installation of the >OpenSSHd service. > >I noticed that if I manually start it after a reboot, the service works >well, but not if it's started automatically. > >Note: I use the local system account for this service. > >Anybody got an idea about this ?

This is a now-classic problem with the sshwindows distribution from sourceforge. It is *broken*, and hasn't been updated in about 10 months now.

If you want a working openssh for windows, you will have to first UNINSTALL sshwindows. Make sure you remove the registry keys under HKLM and HKCU for "Software\Cygnus Solutions". (the uninstaller may do this already...

Then install Cygwin (www.cygwin.com). During setup, install the packages:

 cygrunsrv
openssh

rebase

(in addition to the default packages)

After cygwin is installed, start cygwin and run the command:

 ssh-host-config -y

After that, things *should* work -- but maybe not. I've had several problems with permissions and such.

-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Robert Jacobson sohorob@pobox.com BS, Aeronautical Engineering Univ. of Md., College Park Flight Ops. Team - SOlar Heliospheric Observatory (SOHO) -

Cleanup the Cygwin Registry on Removal

REGEDIT4

[-HKEY_LOCAL_MACHINE\Software\Cygnus Solutions]

[-HKEY_CURRENT_USER\Software\Cygnus Solutions]

[-HKEY_USERS\.DEFAULT\Software\Cygnus Solutions]

Saturday, February 19, 2005

Persistent Netcat Listeners for Honeypots

This ISC article was so good, I had to reprint it for posterity if they ever decided to archive it.

from SANS Institute Internet Storm Center
by Ed Skoudis
http://isc.sans.org/diary.php?date=2005-02-18

The other day, we asked readers to set up honeypot listeners using Netcat to capture some of the malicious code trying to hit TCP port 41523. Now, one of the problems with the most popular Linux/UNIX implementation of Netcat (that is, Hobbit's original) is that it does not create a persistent listener. Unlike the Windows version of Netcat (with its -L option for "Listen Harder"), the original UNIX/Linux version doesn't do this. Once one client connects and drops, the listener dies.

There are many ways to get around this problem, such as using a different version of Netcat. However, one of my favorite simple ways to deal with this is to set up the Netcat listener in a while loop as follows:

 $ while [ 1 ]; do echo "Started"; nc -l -p 41523 >> capture.txt; done 

This will listen on TCP 41523, append whatever it receives to capture.txt, and then start listening again.

If you'd like to go further and actually log out while keeping this thing running, you can simply dump this while line in a file, called honeypot.sh. Then, chmod it so that it is executable (chmod 555 honeypot.sh). Finally, invoke it as follows:

 $ nohup ./honeypot.sh & 

Then, logout and go watch some TV. Take a nap. Run naked through the park. Do whatever it is that you do...

Come back, and your little Netcat buddy will be running with its results stored in capture.txt. To kill it, you could simply kill the pid of the nc listener itself. Thanks to Don Smith for the nohup idea. Note that Don did NOT suggest the park idea.