zoneminder on 1001x eepc

Use built in camera: /usr/bin/mplayer tv:// -tv driver=v4l2:device=/dev/video0 -vo png -frames 10

Run this script in an area zoneminder can access the png files, the first few will be blank while the camera loads.  I take the 4th or 5th frame as a file type source in zoneminder, and have zone minder read that file into its db as a camera monitor, which creates events. 

#!/bin/bash
cd /var/www/html
while [ 1 ]
do
/usr/bin/mplayer tv:// -tv driver=v4l2:device=/dev/video0 -vo png -frames 10 > /dev/null 2>&1
sleep 10
done

I tried using zoneminder to detect the camera natively with some zmu commands but gave up and just wrote the above mplayer script to create png images.

Another method which worked with a usbcam which didn't seem to like mplayer was:

avconv -f video4linux2 -s 640x480 -i /dev/video0 -ss 0:0:2 -frames 1 out.jpg


References and other notes:

http://defectio.blogspot.com/2012/09/connecting-webcam-to-zoneminder.html

failed capture commands with the eepc:

# zmu -d /dev/video0 -q -v
Error, failed to enumerate standard 0: Connection timed out

another failed attempt at mplayer:

# mplayer tv:// -vo aa -monitorpixelaspect 0.5 -quiet

MPlayer2 2.0-728-g2c378c7-4 (C) 2000-2012 MPlayer Team

Cannot open file '/root/.mplayer/input.conf': No such file or directory

Failed to open /root/.mplayer/input.conf.

Cannot open file '/etc/mplayer/input.conf': No such file or directory

Failed to open /etc/mplayer/input.conf.

Playing tv://.

Detected file format: TV

Selected driver: v4l2

 name: Video 4 Linux 2 input

 author: Martin Olschewski <olschewski@zpr.uni-koeln.de>

 comment: first try, more to come ;-)

v4l2: your device driver does not support VIDIOC_G_STD ioctl, VIDIOC_G_PARM was used instead.

Selected device: USB 2.0 Camera

 Capabilities:  video capture  streaming

 supported norms:

 inputs: 0 = Camera 1;

 Current input: 0

 Current format: YUYV

tv.c: norm_from_string(pal): Bogus norm parameter, setting default.

v4l2: ioctl enum norm failed: Inappropriate ioctl for device

Error: Cannot set norm!

Selected input hasn't got a tuner!

v4l2: ioctl set mute failed: Invalid argument

Error opening/initializing the selected video_out (-vo) device.

v4l2: select timeout

v4l2: ioctl set mute failed: Invalid argument

v4l2: 0 frames successfully processed, 1 frames dropped.

Exiting... (End of file)

#  v4l2-ctl --list-devices

USB 2.0 Camera (usb-0000:00:1d.7-6):

        /dev/video0

https://wiki.zoneminder.com/Hardware_Compatibility_List#USB_Cameras

http://ubuntuforums.org/showthread.php?t=1939703


Another method of capturing I like is using a cheap pci capture card and normal CCTV cameras, 4 channels, and these zone minder settings.

source /dev/video0
video for linux version 2 capture method
device channel 0
device format ntsc
capture palette YUYV
768x480, 10 frames/second

All of this was done using Ubuntu 16.04 x86_64

hddtemp + gkrellm

Here is how I got gkrellm to show my hard drive temperatures on kali2.

apt-get -y install hddtemp gkrellm*

edit /etc/default/hddtemp set RUN_DAEMON="true"
update-rc.d hddtemp enable
/etc/init.d/hddtemp start still didnt start in daemon mode,

http://ubuntuforums.org/showthread.php?t=1359129 shows you have to run
sudo dpkg-reconfigure hddtemp
I set it in suid mode and to run in daemon mode, then ran /etc/init.d/hddtemp start and it kept running:

# ps aux | grep hdd
root     25386  0.0  0.0   6308  1968 ?        S    18:07   0:00 /usr/sbin/hddtemp -d -l 127.0.0.1 -p 7634 -s | -S 600 /dev/sda /dev/sdb /dev/sdc

testing it: # telnet localhost 7634

next I try gkrellm-hddtemp: http://www.guzu.net/linux/hddtemp.php

$ make

Type 'make gkrellm1' and then 'make install1'
  or 'make gkrellm2' and then 'make install2'

$ dpkg -l gkrellm
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  gkrellm        2.3.6~rc1-1  amd64        GNU Krell Monitors

so I want make install2

$ make gkrellm2
gcc -Wall -fPIC -O2 -DGKRELLM2 `pkg-config --cflags gtk+-2.0` -I. -c gkrellm-hddtemp.c
gkrellm-hddtemp.c: In function ‘string_extents’:
gkrellm-hddtemp.c:93:22: warning: passing argument 1 of ‘gdk_string_extents’ from incompatible pointer type
   gdk_string_extents(ext->ts.font, string, &ext->lbearing, &ext->rbearing,
                      ^
In file included from /usr/include/gtk-2.0/gdk/gdk.h:42:0,
                 from /usr/include/gtk-2.0/gtk/gtk.h:32,
                 from /usr/include/gkrellm2/gkrellm.h:47,
                 from gkrellm-hddtemp.c:40:
/usr/include/gtk-2.0/gdk/gdkfont.h:122:10: note: expected ‘struct GdkFont *’ but argument is of type ‘struct PangoFontDescription *’
 void     gdk_string_extents (GdkFont     *font,
          ^
gcc -shared -Wl -o gkrellm-hddtemp.so gkrellm-hddtemp.o
gcc: error: unrecognized command line option ‘-Wl’
Makefile:19: recipe for target 'gkrellm2' failed
make: *** [gkrellm2] Error 1

googling "gcc: error: unrecognized command line option ‘-Wl’"  I find:
http://stackoverflow.com/questions/33114509/gcc-error-unrecognized-command-line-option-wl-in-makfile

so I try to compile it with Wall instead of Wl and it works:

$~/dev/gkrellm-hddtemp-0.2-beta$ gcc -shared -Wall -o gkrellm-hddtemp.so gkrellm-hddtemp.o

$ sudo make install2
install -d /root/.gkrellm2/plugins/
install gkrellm-hddtemp.so /root/.gkrellm2/plugins/

then I run it again as my normal user since it seems to be using ~/.gkrellm2 instead of some dir in /etc, and restart gkrellm:

I see hddtemp in the plugins list and enabling it shows 3 boxes with temperatures.  Success!

Now how to make gkrellm show smartd status?

DD-WRT WRT310Nv2 vs E3200

Using a WRT310Nv2 running Firmware: DD-WRT v24-sp2 (08/12/10) mini

Release 2.0 Broadcom 4716 @ 300 MHz 32 MB RAM 4 MB Flash 2.4 GHz Radio

My favorite setting for gaming reduces the transfer queue length to decrease latency:
Administration-> Commands and enter:

ifconfig eth0 txqueuelen 2
ifconfig eth1 txqueuelen 2

No more buffer bloat!  Using the txqueuelen tuning reducing the ping rate to a Neverwinter Nights server noticeably.

Buffer Bloat is bad! :
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=694799

Next project is to compare the WRT310Nv2 with a http://www.dd-wrt.com/wiki/index.php/Linksys_E3200

I would like to try using the E3200 as a USB file server while also keeping the txqueuelen tweaks...

The E3200 has 500MHz processor, a USB2.0 port, and 2.4ghz AND 5Ghz radios.

So why is the E3200 better than the WRT310Nv2?  The 5Ghz radio and faster cpu and usb port is why.

Confirmed after adding dd-wrt v24-sp 12/11/14 mini that 5ghz wifi and usb2.0 disk does NOT work

http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F#File_Versions

Upgraded to mega...
That got me many more options, yay :)
One was a USB and NAS tab, with proftpd and samba.
Enabling core usb support and usb storage support...
enable ssh support, ssh in to see if it sees drive
looks like 5ghz does not work even with mega



After replacing the WRT310Nv2 with the E3200 I ran some tests.
USB File sharing worked with FAT32 formated usb disks at about 8M/s.
My raspberry pi can only go about 2-3M/s.

Then I have the same tunings above for latency plus some iptables rules to create a SPAN port which I monitor with OSSIM USM 5.2.0 community edition running on a VMware virtual machine, OSSIM is swapping with only 6G of ram I need to upgrade :)

So my onboot commands to customize ddwrt and send a copy of all traffic to 192.168.1.2 look like:

ifconfig eth0 txqueuelen 2
ifconfig eth1 txqueuelen 2
iptables -t mangle -A POSTROUTING -d 0.0.0.0/0 -j ROUTE --tee --gw 192.168.1.2
iptables -t mangle -A PREROUTING -s 0.0.0.0/0 -j ROUTE --tee --gw 192.168.1.2

How Mutant Exploits Defeat IDS 2006

How Mutant Exploits Defeat IDS

A report on the ACM paper:
“Testing Network-based Intrusion Detection Signatures Using Mutant Exploits”
Downloaded from:
http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES320&coll=portal&dl=ACM via a search for “mutant”.

A well known network security concept, Intrusion detection systems function by listening on the network for suspicious activity. This paper explores some of their weaknesses and shows that they are not very effective when exploit mutations are applied.

According to the authors the tested IDS's are “network-based misuse detection systems”. An example of network misuse could be running an exploit against a server, scanning the entire network for hosts, or sending traffic which results in a Denial of Service attack.

The authors preform rigorous tests of 2 IDS systems, ISS RealSecure and Snort. These were chosen because they “represent the leading products in the open-source and commercial worlds” and “possess excellent attack detection capabilities and correctly manage many different types of evasion”. Both of these IDS systems are reliant on “signatures” of known attacks. At first glance this seems a very effective way of detecting network-misuses, however this paper shows that in reality, doing this is much more difficult.

It is difficult because “attacks that exploit a certain vulnerability may do so in completely different ways”. While it is easy to write IDS signatures for publicly known exploits, realistically not all exploits are going to be released, nor will all versions of a specific exploit be released. One would think “well how am I supposed to detect misuses that I don't even know exist?”. A valid question, however the problem gets even worse.

IDS systems typically have signatures for thousands of exploits. These signatures are very static, effectively searching for a specific packet or set of packets sent across the network. Problems arise however, when an exploit is modified or “mutated” in ways that allow it to still function in compromising a host, yet in a way which obfuscates the network traffic. The paper breaks down such “Mutation Mechanisms” into a number of groups. 

Network Layer Mutations include using Ipv6 to evade Ipv4 only IDSs, and IP Packet Splitting to evade IDS systems that are not smart enough to reassemble packets before checking them against attack signatures.
Application Layer Mutations include Protocol Rounds, FTP Evasion Techniques, HTTP Evasion Techniques, and SSL NULL Record Evasion Techniques. All of these mutations change the data sent to the application by the exploit, in a way which the application can still understand the attackers message however the message does not match the IDS signature for the attempted exploit. Also, “examples of HTTP protocol evasion techniques include neglecting the use of carriage returns, random insertion of whitespace characters, and inserting junk characters into parsed numerical fields”. While RFCs strictly specify protocols, often times real products are more lax in regards to them, allowing for the strange behavior which makes such mutations possible.

Exploit Layer Mutations are the newest of the group. They include polymorphic shellcode, and Alternate Encodings. ADMmutate “generates self-decrypting exploit payloads that will defeat most popular NIDS shellcode detectors, including "XOR-encoded payloads, randomized NOP generation, and support for banned characters".

The shellcode part of the exploit is easily added to IDS signatures. Since many exploits use predefined shellcode. IDS check for shellcode because regardless of the exploit some shellcode usually has to be pushed onto the compromised host in order to run some command for the attacker. Encoding the shellcode in a different format works as does the “insertion of non-destructive junk instructions and the reordering/substitution of code”. In this way you have a functional shellcode which does not match any IDS signatures.

Alternate Encodings work by encoding the exploit into some format the server can decode and execute, but the IDS does not. Examples include TAR, ZIP, or url encoding via hex.

The paper tested 10 exploits mutated in various ways. The exploits were run against the server. Detection results were collected from the IDS systems. Success results were collected from an “oracle” application which they used to check whether the exploit was successful.

The exploits were chosen to represent the range of target operating systems, protocols, and categories of attacks. Linux, Windows, OpenBSD, FTP, HTTP, IMAP, RPC, and SSL were tested, along with buffer overflow and directory traversal attacks.

The following specific exploits were tested:
IIS Escaped Characters Double Decoding
WU-ftpd Remote Format String Stack Overwrite
Microsoft DCOM-RPC aka blaster
IIS Extended Unicode Directory Traversal
NSIISlog.DLL Remote Buffer Overflow
IIS 5.0 .printer ISAPI Extension Buffer Overflow
WS-FTP Server STAT Buffer Overflow Denial-Of-Service
Apache HTTP Chunked Encoding Overflow
OpenSSL SSLv2 Client Master Key Overflow

Each exploit was run through the authors' “mutation engine” to generate mutant exploit combinations. Once a particular exploit was found which evaded the IDS systems yet still functioned, the authors moved on to the next exploit. One point made by the authors is that for some exploits the number of functional mutations could be quite large, leading to “an unmanageable number of mutant exploits”. The mutation engine tried using a variety of the previously mentioned methods.

The results of all these tests were quite sobering. Snort only detected 4 out of 10 of the mutant exploits, and IIS RealSecure only detected one. So what does this tell us? That a determined attacker could probably easily evade most commercial signature based IDS systems. I would say that signature based IDS are good for detecting "canned" exploits run at the "script kiddie" level. However, for someone who understands how they work, they seem to be rather trivial to defeat with automated tools such as ADMmutate.

Security means defense in depth, and signature-based IDS systems are only one layer. Another type of IDS system is based on Cisco's netflow technology. While I am not aware of any commercial products which do this, it is possible to correlate the data from Cisco router's netflows, in order to detect suspicious patterns such as port scans. Professor Skwarek touched on this briefly in his network security class.

Another layer of IDS that should not be over looked is host based IDS systems. Often exploits create anomalies in the log files which can be watched for and reported, possibly even before the attacker explores enough of the compromised system to discover the alarm message has been sent. Attackers can modify logs, change configuration files, or replace system binaries with trojaned "rootkits". 

Such changes can be detected with programs like tripwire, chkrootkit and rkhunter. Tripwire keeps a database of the hashes of the system files it protects. Chkrootkit and rkhunter act similar to network based IDS systems except they scan the system files for suspicious names, rootkit strings and configuration changes. However, these also are reliant on signatures and thus vulnerable to mutations of the known rootkits.