Car Webcam Surveillance System

Main Idea: LINUX-based Web Cam Recorder

The idea is to have an on-board laptop with web server to snap pics with the webcam every few seconds and record the data to the hard drive. A wireless connection at the house and server will provide for syncronization of the data when the car returns into the range of the base AP.

1. Acquire an old laptop with a hard drive and USB port.
2. Get a USB web camera. Mount it to the back of the car by the center brake light. Run the cable to the trunk. Get a USB extension cable if nec.
3. Get a wireless card that is compatible with LINUX. Recommended, any Prism-based 802.11 card or Orinoco Gold. Prism 802.11g chips are supported in LINUX, but the driver setup can be involved. Do some research and be prepared.
4. Get a DC/AC power converter. Run the DC power connect from the lighter or other car outlet back to the trunk of the vehicle.
5. If the battery of the laptop is not operable, a small UPS may be desirable for use. Disable the alarms through the console setup, if available. APC brand recommended. Make sure it has "smart" firmware.
6. Load LINUX to the laptop. Use a journaling file system, like xfs or reiserfs as the machine will probably experience frequent power loss. Software required: apache, cron, scp, webcam image capture software or scripts, wireless drivers/scripts.
7. Setup the wireless connection. It can be configured in any way, so long as you can connect to it from another machine and view the apache dir with the webcam captures.
8. Setup LINUX power management for no power alert alarms. Preferably, it will have no GUI (init:3) and no sound drivers as it can get distracting. Set the power management software to shut the system down at 5% on-board battery power. If using a UPS in lieu of an on-board battery, use NUT or APCUPSD and set for shutdown at 3% power. Or you can use both. :)
9. Setup webcam capture script/app to collect the image every few seconds. Save it to a local directory in the web hierarchy.

---

Option: Wireless Sync to a base server

1. Ensure the wireless settings do not allow the card to "roam" to any other APs or ad-hoc networks. It should only connect to the base AP.
2. The base server in the house requires SSH. Create an account for the laptop to dump files to. Generate keys on the laptop and perform the exchange so that the laptop can connect to it's account on the server automatically with SCP.
3. Create a script that will scp all files in the webcam directory to the base server, then delete them if successful.
4. Schedule scp script to execute every minute in cron. Throw output to /dev/null.

• An ftp client could be used for this exercise, but is not recommended as it is not encrypted.

---

Alternate Setup: Bootable LINUX CD

This configuration maximizes the HD space available for recording. Follow the above with the following modifications:

1. Acquire an old laptop with hard drive, CD drive and USB port.
2. Get a USB pen drive (flash drive, thumb drive). Recommend 1GB space.
3. Burn a copy of a bootable linux CD. Knoppix, Debian, etc.
4. Modify the BIOS of the laptop. set CDROM as the boot device. set power settings to power it ON in the event of a power failure. Save and exit.
5. Boot to the LINUX CD. Establish the settings you want and save to the USB drive.

• You will have to run some rc scripts from the usb drive at bootup to ensure that the web server, sync scripts, and wireless card are running when the machine powers up.

Clustered Intruson Detection System

Ideas for creating a scalable architecture for very large enterprises.

• Create a LINUX-based IDS appliance with clustering enabled.
• After establishment of first node, additional nodes can be dropped in and configured directly into the cluster.
• Added nodes will pull configurations from existing nodes and self-configure after initial node config.
• Once finalized, nodes will form cluster and share CPU, memory, and application space. This provides drop-in scalability merely by adding more appliance units and configuring.
• Incoming spanned traffic will have to be load balanced among promiscuous NICs.

Securing Wireless: Presentation Notes

Course 1 - Implementing Wireless Security

Agenda

1. Standards Overview
2. Considerations for Your Enterprise
   1. Regulations Compliance
   2. Data Value
   3. Public Perception
3. Implementing Security
   1. WEP
   2. WPA
   3. WPA2/802.11i
   4. TKIP/LEAP/PEAP
   5. MAC filtering
   6. 802.1x
   7. Bluetooth
4. Detecting Problems
   1. Rogue AP
   2. Rogue Client
   3. Attacks
   4. Failures
5. Links
6. Contact

---

Course 2 - Auditing Wireless Security

Agenda

1. Auditing Wireless Security
2. Discovery
   1. Kismet
   2. Netstumbler
   3. GPS Mapping
3. Types of Attack
   1. WEP
   2. WPA
   3. LEAP
   4. Deauthentication
   5. Bluetooth
4. Links
5. Contact

---

Kismet

Netstumbler

Void11 DOS

WEP Cracking

WPA Cracking

Bluetooth Snarfing

Auditing Tutorials

LEAP Hack

Wireless Overview Notes

Agenda

1. Overview
2. Defining Wireless
3. COTS Products
4. Considerations for 802.11b/g
   1. Frequency Interference
   2. Range/Coverage
   3. Speed
5. Configuration Example
   1. Linksys WRT54G
6. COTS Security
   1. Levels of Security
   2. Need v. Complexity
   3. Linksys Example
7. Links
8. Contact

---

Wireless Alphabet Soup

Ubiquitous Municipal Coverage Initiatives

Password Rules for Kids

A decent password policy for kids and, frankly, most users.

from KidzOnline

---

Password Creation

Chapter 1

1. Passwords are crucial in keeping your personal information confidential and your computer system secure.

2. Sharing your passwords:

    * can allow people access to your email and other sensitive files
   * can cause you to lose access to saved files and private information

3. To be TRULY secure, every password needs to be different.

4. Use different passwords for different levels of security:

    * Level 1 – routine downloads and product registrations
   * Level 2 – e-mail accounts and operating systems
   * Level 3 – bank accounts, online auctions, administrative logins

Chapter 2

5. To ensure your password remains secret:

    * memorize your password
   * if you have to write it down, keep it on you
   * don’t leave your password where its easy to find it

6. Password basics:

    * do not share your passwords with anyone
   * make them impossible to guess
   * create different passwords
   * try to memorize your password
   * do not write them down

Creating a Vericept Instance in VMWare

Here's the generic host creation VM documentation with the promiscuous NIC setup and drive conversion sections. Here's a better structure below:

• Determine customer platform (Vmware version: ESX v?, workstation, gsx, etc) and total space dedicated for this VM.

• Create the VM in workstation with the total space defined as the MAXIMUM. Allow for auto-expansion of the disk to maximum. This will yield about a 6 GB partition. This was done correctly the first time.

• Compress this final disk image with a file utility appropriate to the receiving host machine. Windows = winzip or windows compress utility. ESX, Linux = Tar/Gzip.

• Burn to disk and ship. Be ready to have this available via FTP should the disk be damaged in transit. Include a document with step-by-step installation instructions from disc to image, through conversion, into VM setup and promiscuous port settings.

On the receiving end (ESX ONLY):

• copy the compressed file from DVD and uncompress/untar it to the /vmfs directory of an ESX box (handles large files well).

• Run the disk conversion process.

vmkfstools –i vmhba:X:X:X:X:.vmdk

  Make sure the customer has MAX DISK SPACE _plus_ the 6GB overhead of the original disk file.  When done, delete the old 6GB file.

• Create a new VM, define for Linux, name, RAM, etc., and attach the new ("existing") disk you just converted.

• You previously wired the NICs, defined the virtual switches and such so you have a _separate_ production and sensing network connections and virtual switches, right? Add one virtual NIC for this VM connected to the production network's virtual switch. Add one v-NIC connected to the "sensor" v-switch (don't worry about the terminology, it works). The production network can be shared amoung the VMs. The "sensor" network can only be used by Vericept VM and needs a dedicated NIC bound to a dedicated virtual switch within VM.

• Set the "sensor" NIC into promiscuous mode.

echo "PromiscuousAllowed yes" > /proc/vmware/net/vmnicX/config

• Run the VM.

• Test test test

• *optional* Log into Paypal.com and send $10 to Drew Hunt (pinowudi@yahoo.com) for his efforts.

Take Care of Your Laptop

Look at what happens when you don't take data security seriously.

from BlogSpot
http://blastradius.blogspot.com/2005/04/follow-up-professor-exaggerator.html

Linksys BEFW11S4

I've been using this unit since May 2000 and it's still going strong. There was a brief time in 2003 that the wireless failed to work (just failed to transmit), but it seems to have miraculously healed itself after a couple of resets and a while on the shelf. It is currently used as my "public" AP for granting limited access to guests and passerby to dissuade them from knocking on my "private" AP.

Product Page

http://www.linksys.com/support/support.asp?spid=68

Public Wireless Diversion

Many people talk of wireless security in terms of the strength of encryption. However, many access attempts into wireless resources are simply users looking for a free Internet connection. In this model of access aquisition, the intruder will often forgo even weakly secured networks for lower hanging fruit. This article explores the pursuit of wireless security by offering a more enticing target to the prospective rogue client.

Even though unsecured wireless access is highly available in populated areas, it is still pretty sparse in my corner of the States. So, to remove the temptation from the locals looking for a free ride on my production data network, I've set up a public access point for them. The following document offers my tips for a successful diversionary AP and how to ensure you aren't providing a casual hacker a backdoor into your network.

Intent

This is intended for a home setup or maybe a small business that doesn't pass sensitive data on their wireless network, but doesn't want prying eyes watching their traffic or using their AP as a SPAM relay. This is security through appeasement. To make it work, the freely available network must be more attractive than the protected wireless network. Larger businesses or those handling sensitive data should implement more robust protection for their wireless networks.

Public Access Network

AP Selection

To ensure the public network is the most succulent plum, you may want to invest in an AP that is compatible with external antennae. This would allow you to extend the coverage of the public network through the use of high-gain antennaes now available at consumer electronics stores. Having a greater coverage area, the would-be freeloader will strike the public network possibly before they are even aware of your data network. However, for this simple example, any consumer-grade access point will do.

Infrastructure Setup

The public access infrastructure will require an AP and another routing control device (read "firewall"). If you have a spare box with three NICs, look at Smoothwall (http://www.smoothwall.org) for an easy out-of-the-box solution. Some modifications to the /etc/rc.d/rc.firewallup script will be necessary to grant the outgoing access to the ORANGE ("Public access" or "DMZ") interface.

The goal here is to allow the most common forms of access without presenting major exposure. This setup will allow common web and email client access, but not email relaying, so a spammer would not be able to abuse the net and get you into trouble. This is not to say that a user wouldn't do something illegal over an approved protocol, like posting kiddie porn to a website using your network. If you are worried about these things, look at an in-line transparent proxy, like SQUID (http://www.squid-cache.org/), that can let you review where users are going and possibly limit activity you deem inappropriate.

The firewall should limit the egress (outgoing) access of the public network to only necessary protocols. Most users want some basic access to the web, their email and maybe some other apps, like instant messaging. For this example, users of the public net will be limited to web functions (HTTP - TCP 80, HTTPS - TCP 443), email (POP - TCP 110), necessities to make these two work (DNS - UDP 53), and one infrastructure service to get the correct time (NTP - UDP 123). No ingress (incoming) access should be allowed except for the requisite DNS and NTP access as they come in over UDP. Most firewalls can take care of the incoming traffic automatically as it is very common.

Connect the public AP and open the configuration interface. This is commonly a web page on the device. Set the DNS servers to those provided by your ISP. Set the DHCP service on the AP to accept a reasonable number of connections. I allow for 50 users. Set the WAN to a static IP address to the same IP subnet as your firewall interface. Set the firewall interface as the gateway. Save the settings and backup the configuration if possible. Reboot the AP. Test connecting to the AP and make sure the DNS and gateways are set correctly. Try browsing some web pages.

In this example, I've also added a "public" hub between the AP and the firewall so I can easily connect a spare box for traffic analysis with Snort (http://www.snort.org), data capture of interesting packets (tcpdump), and putting up a honeypot to see if the public net is being abused (Honeyd, LaBrea Tarpit, netcat, or whatever). These allow me to monitor and determine if the public network is being abused and may need to be taken down for a time or improvements made. This 100Mb/s half-duplex hub won't impact performance as wireless is a half-duplex communication technology that's theoretical maximum throughput (802.11g = 54Mb/s) is about half of the hub's.

Packet Snooping and Legality

Is it legal to snoop your public access network? Well, you are providing the network with no guarantees of privacy or security. Users of the network have an implicit agreement to whatever terms you impose since they did not seek prior agreement to use the net. How do you know who is using your network or what they did should your ISP accuse you of something?

This can be a very tricky subject, so snoop at your own risk. You may also want to add an in-line transparent proxy that displays a disclaimer notice on the user's first web access.

SSID & Frequency Selection

802.11b/g only has three non-overlaping channels: 1,6, and 11. The higher channels have higher frequencies, which are more susceptible to interference and attenuation with common household objects. To make your public access net attractive, you want it to have the maximum covage available so users can see it before your protected wireless net. Set the public AP to channel 1.

To ensure scanning users searching for a network understand the intent of this AP, set the SSID to "PUBLIC". This sends a clear message to passerby that this network is provided for their use and further searching/hacking is unnecessary.

Protected Data Network

AP Selection

For the private side, use an AP that provides security features appropriate for the sensitivity of the data. Linksys wireless routers provide a good mix of consumer standard protection (old WEP, WPA, WPA-PSK) as well as an outsourced RADIUS authentication scheme for more demanding environments.

Infrastructure Setup

This is up to you. You may want to monitor the network for intrusions to make sure the security scheme in place is working. However, for a home environment this is probably overkill. Just make sure that every node (computer) using the wireless network has a firewall installed and operating. See the CentralSyslog project for more on how to centrally collect logs to monitor firewall and login intrusions. Also see the SnortDocumentation project to set up a freely-available intrusion detection system for your network.

SSID & Frequency Selection

As noted for the public AP, lower frequencies carry farther than higher frequencies. This network should be size-limited to just the coverage area needed. It should also use a channel that will not interfere with the public network in such close proxmity. Since 802.11b/g networks only offer three non-overlapping channels (1,6,11) and public is using channel 1, the data network should use either channel 11 or 6. I recommend channel 11 as it has the weakest area penetration, but I've also found it is more susceptible to microwave oven interference. If your environment is susceptible to these types of interference, channel 6 may work better for you.

When setting your SSID, make it something cryptic that has meaning to you, but doesn't reveal anything about the data or owner of the AP. An example would be 5TIMdN2, for "This is my data network's second access point". The less scanning passerby know about the network, the better.

Security Options

Almost all consumer access points have basic wireless security options, like MAC filtering and basic encryption. Enable MAC filtering at the very least, identifying all of the legitimate NICs that require access to the protected network. Encryption is HIGHLY recommended as it sends a clear signal to common passerby that some effort will be needed to gain access to the network. Select a level of encryption appropriate for your data stream. I recommend WPA-PSK for typical home use as it's relatively more difficult to break than WEP, meaning more work and your public access network becomes that much more attractive. Disabling the SSID Broadcast may hide your AP from scanners for a time, but it can also cause association problems for legitimate clients using Wireless Zero Config.

Final Notes

Remember, this is security through diversion and is not designed to thwart the determined hacker. The most pertinent points I can reinforce about this strategy are make the public access point as open and attractive as possible, and make the production data network as hard to penetrate as is reasonable for your environment.

Feedback

Questions and comments can be sent to pinowudi@yahoo.com

Netgear WSG11v1 54Mbs 802.11g PCMCIA Wireless Adapter

Tested with Windows XP SP2 and Fedora Core 2

This is the only wireless adapter I've owned that doesn't work in either Windows or Linux. The Linux part I can understand since it uses the wlan-ng driver set and it's mostly due to my lack of knowledge of these drivers. Windows is beyond me since it's advertised as being supported for all current versions.

The original driver loaded and worked for a few hours under the Windows Zero Configuration drivers until the laptop hibernated. On resume, the laptop froze in a blue screen of death indicating the WSG11 as the culprit. This was consistent, happening every time without fail.

Searching the Netgear http://www.netgear.com support site revealed a compatibility problem with XP SP2 and provided a beta driver (2.9.??). I downloaded it and reinstalled. The driver interface is much improved, now providing its own driver setup utility, so no more Windows Zero Config. It worked through the first hibernate, but has since caused three blue screens. It's still not production material.

SMC 2835 802.11b PCMCIA Client Adapter

Tested with Windows XP and Fedora Core 2

Windows

Reception and range are excellent. Simple drivers use the integrated Windows Zero Config for configuration. No vendor-supplied interface. Works well and is simple to install.

Linux

Unfortunately, the chipset does not have a viable LINUX driver.

Intel Centrino 802.11b mini-PCI Client Adapter

Tested with Windows XP on a Dell Inspiron m600

The Centrino works well on startup, but does not survive hibernation and refuses to reactivate without a reboot. Switching from Wireless Zero Config to the Intel configuration tool remedied the blue screen crashing on standby wake. The Intel tool is very well designed, with configuration for every feature of the card and WLAN discovery tools.

Cisco 340 802.11b PCMCIA Client Adapter

Tested with Windows XP and Fedora Core 2

Windows

Works well with Windows when using the Cisco drivers. Ultimately configurable with respect to transmission power and power use settings.

Linux

The LINUX kernels > 2.3 have the airo_cs module precompiled, making most distributions compatible by default. This supports basic use, but is very hard to configure in any non-standard setup. I was never able to get it working with WEP encryption. I also had difficulty getting the unit to work with Kismet in rfmon mode.

Linksys WRT54G

This is one of the best consumer-grade products I've seen. It has a good mix of features for security and setup with a easy-to-use web-based configuration tool. Excellent coverage and speed. Cisco also offers a buy-back program for Cisco AP upgrades which is very attractive.

Product Information

http://www.linksys.com/products/product.asp?grid=33&scid=35&prid=601

Satire on Government-Regulated Computer Security

This is hilarious. I had to post it.

From DShield listservice on March 23,2005

Dear Mr. Smith,

We, the government of the United States of America, have detected an unauthorized attempt to use a file sharing application on your personal computer. According to our records, you are not licensed to execute any software applications with a security risk rating of 3 or above.

As you know, the "Computer Safety for the People" Act of 2007 prohibits individual computer users from executing potentially dangerous software applications without proper government-licensed permission. This Act was instated to keep citizens such as yourself safe from malicious computer attacks so that we can all enjoy a safer Internet. Each violation of this act could result in fines of up to $10,000 or more.

We have already given you the freedom to browse the World Wide Web and send/receive E-mail, which is all you should really need to do anyway. Because sharing files with other computer users over the Internet represents a much increased security risk, you are not permitted to do so without government authorization.

If you would like to apply for a Class 3 software license, you will need to undergo necessary computer skills training and examinations at a local government facility just like everybody else. Remember, this is not only for your own good, but for the greater good of the society.

Thank you for your cooperation.
-We the People.

-- MS (initials used to protect privacy)

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.

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]

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.