text:
The RULES have been updated as of 3/8/2013. Please review them and make sure you're up to date! -dotcom
WASHINGTON (AP) The House voted decisively late Wednesday to reject a bipartisan budget mixing tax increases with spending cuts to wring $4 trillion from federal deficits over the coming decade.The 382-38 roll call paved the way for Republicans to muscle through their own, more stringent budget on Thursday, a measure that would blend deeper spending reductions in safety-net programs for the poor with a plan to dramatically overhaul Medicare. The vote also underscored the partisan polarization dominating Washington this election year, with leaders of both parties showing little inclination to compromise and let the other side claim a victory.The bipartisan measure rejected Wednesday was patterned on a plan by President Barack Obama's 2010 deficit commission and was written by moderate Reps. Steve LaTourette, R-Ohio, and Jim Cooper, D-Tenn."This is the only bipartisan way to solve the nation's problems," Cooper said."When you know you have a good deal is when the left and right are pounding the snot out of you, and that's what's happening today," LaTourette said.House Budget Committee Chairman Paul Ryan, R-Wis., was the only lawmaker to speak against the plan, saying it relied too heavily on tax increases and not enough on spending cuts.The plan won praise from outside budget experts. But GOP leaders have been unwilling to stray from party principles on taxes while top Democrats have shown no give on cuts to social programs.The bipartisan alternative was similar to a proposal crafted by former White House chief of staff Erskine Bowles, a Democrat, and former GOP Sen. Alan Simpson of Wyoming, co-chairmen of Obama's deficit commission, whose package ended up being ignored by lawmakers.The measure, like the Simpson-Bowles plan, called for a tax overhaul that would bring the top tax rate down from 35 percent to 29 percent or lower, financed by repealing various tax breaks, deductions and credits. Overall revenue would rise by $1.2 trillion since the money raised by eliminating dozens of tax breaks would exceed the revenue lost by lowering rates.The vote came shortly after the Republican-run chamber unanimously rejected Obama's $3.6 trillion budget for next year in a roll call forced by GOP lawmakers to embarrass Democrats.Republicans have opposed Obama's budget all year, criticizing its tax increases on the wealthy and saying it lacks sufficient spending cuts.Democrats have defended Obama's budget priorities but voted "no" as a bloc Wednesday night as the House rejected the president's plan 414-0.Republicans said Democrats were afraid to vote for Obama's proposed tax increases and extra spending for energy and welfare. Democrats indicated they were worried that voting for Obama's budget would let Republicans accuse them in re-election campaigns of endorsing every part of it, including details they might oppose.The House also rejected a plan by the Congressional Black Caucus, 314-107, that was more generous than Republicans to many domestic programs.At the center of Wednesday's debate, however, was a budget-slashing GOP plan by Ryan that would quickly bring the deficit to heel but only through unprecedented cuts to programs for the poor such as food stamps, Medicaid, college aid and housing subsidies. The Republican budget also reprises a Medicare plan that would switch the program for those under 55 today from the traditional framework in which the government pays doctor and hospital bills to a voucher-like approach in which the government subsidizes purchases of private health insurance.The GOP plan was set to pass on Thursday, but swiftly die in the Democratic-controlled Senate. Under the arcane budget rules of Congress, the annual budget resolution is a far-reaching but nonbinding measure that sets the parameters for follow-up legislation.The measure reopens last summer's hard-won budget and debt deal with Obama, imposing new cuts on domestic agencies while easing cost curbs on the Pentagon that gained bipartisan support just months ago. It would set in motion follow-up legislation that would substitute $261 billion in spending cuts spaced over a decade for $78 billion in automatic spending cuts that would cut the Pentagon budget by about 10 percent next year and cut numerous domestic programs as well.The election-year GOP manifesto paints clear campaign differences with Obama, whose February budget submission offered tax increases on the wealthy but mostly left alone key benefit programs like Medicare, Medicaid and food stamps. Obama and his Democratic allies instead promise to protect programs aimed at the elderly and the poor.Ryan said the GOP plan steps in aggressively to prevent a European-style debt crisis that would swamp the economy and force draconian spending cuts and tax increases."Let's not wait until we have a crisis. Let's not wait until interest rates go up and we're in sort of a European meltdown mode," Ryan said. "Let's do it right and do it now, because then we can keep the promises that government has made to people who need it the most."But Democrats said the Ryan plan makes spending cuts that are simply too extensive, knocking millions of people off of food stamps and forcing states to drop Medicaid nursing home coverage for many elderly people. At the same time, Democrats said the GOP budget promises a radical overhaul of the tax code that would deliver big tax cuts to upper-income people while taking away tax deductions and credits important to the middle class and the poor, like the child tax credit, and deductions for health insurance, mortgage interest and contributions to charity.Democrats say the GOP Medicare proposal, similar to a plan that started a political firestorm last year, would cut costs steeply and provide the elderly with a steadily shrinking menu of options and higher out-of-pocket costs."It is not bold, not bold to provide tax breaks to millionaires while ending the Medicare guarantee for seniors and sticking them with the bill for rising health care costs," said Maryland Rep. Chris Van Hollen, the top Budget Committee Democrat. "It is certainly not brave to cut support for seniors in nursing homes, individuals with disabilities and poor kids. And it is not fair to raise taxes on middle-income Americans, financed by another round of tax breaks for the very wealthy."Compared with Obama's budget, the GOP measure includes deficit cuts totaling $3.3 trillion spending cuts of $5.3 trillion tempered by $2 trillion in lower taxes over the coming decade. The deficit in 2015, for example, would drop to about $300 billion from $1.2 trillion for the current budget year. But the GOP measure despite assumptions of major cuts to transportation, education and food aid doesn't achieve balance for almost three decades, leading conservatives to offer an even tougher plan that would come to balance in five years.The GOP measure is likely to pass almost exclusively with GOP votes, though some tea party lawmakers will oppose it for not going far enough.


text:
Message Board
Khushwant Singh Message Board
Talk about the novels, new and used books that Singh has written!
Author Singh's Book Reviews
Truth, Love and a Little Malice
Khushwant Singh was born in 1915 in Jadali, Punjab, India. He was educated in Lahore and in London. He practiced law for several years before joining the Indian Ministry of External Affairs in 1947. His diplomatic postings include Canada, London, and later Paris where he was assigned to UNESCO. Singh began his career as a journalist with All India Radio in 1951. He went on to become the editor of several Indian magazines and newspapers. Today h...

subset: commoncrawl


text:
How do I create a Tomcat user in Simple Control Panel?
Some of the information in this article is advanced material we make available as a courtesy. Please be advised that you are responsible for properly following the procedures below. Customer Support cannot assist with these topics.
For security reasons, there is no default user configured for Tomcat web administration, but you can create a Tomcat user in SSH.
To Create a Tomcat User
- Connect to your server via SSH (more info).
- Switch to the root user (more info).
- Edit the /usr/java/tomcat-5.5/conf/tomcat-users.xml file, for more information on editing files in SSH see the following.
- Add an entry by changing the user name and password as appropriate.
Note: For the changes to take effect, you will need to restart the Tomcat service with the service tomcat55 restart command.


text:
Students present research findings at Northwest conference
December 18, 2013
Lewis & Clark students presented a diverse array of research findings to an audience of more than 500 people at the Murdock College Science Research Program's recent Conference on Undergraduate Research.
Two student teams showcased their research discoveries with oral presentations: Leah Weston '14 and Kyla Hamling '14 discussed neuron development in zebra fish, while Amaya Lucas '15 and Reuben Peterson '14 talked about their use of holographic tweezers in studying microscopic bubbles.
Eight additional students assembled poster presentations for the conference, which addressed topics in the natural sciences and psychology. These included effects of invasive plant removal, atomic optics, energy generation and storage in metal oxide films, the role of games in children's problem-solving skills, and the relationship between binge drinking and risky behavior, among others.
"The Murdock conference offers our students a wonderful opportunity to share their research with interested students and faculty members from other Northwestern colleges," said Associate Professor of Physics Michael Broide. "Presenting a talk or poster to such a large audience forces students to sharpen their communication skills and enrich their understanding of their own research."
Lewis & Clark collaborated with the M.J. Murdock Charitable Trust to host the 22nd annual conference in Vancouver, Washington. The college is one of 11 liberal arts institutions in the Pacific Northwest to receive funding from the Murdock trust for the purpose of strengthening faculty and student research efforts in the sciences. All student research that appeared at the conference was conducted during the summer and under the mentorship of faculty advisors as part of the John S. Rogers Science Research Program.
Katrina Staaf '16 contributed to this story.
Science Opportunities


text:
The Broadway run of the high-flying cheerleading musical "Bring It On" is heading into overtime. Producers of the show said that they are extending its limited engagement through Jan. 20 at the St. James Theater in New York. The musical had been scheduled to run through Oct. 7.
"Bring It On," which is inspired by the 2000 movie of the same name starring Kirsten Dunst, tells the story of perky cheer captain Campbell, who gets reassigned from her affluent high school to an urban district. She eventually leads her new school in a cheer competition against her old teammates.
The musical opened a national tour last year at the Ahmanson Theatre in Los Angeles. (It had its world premiere at Atlanta's Alliance Theatre earlier that year.)
The previous tenant of New York's St. James was another musical with L.A. connections, "Leap of Faith," which closed in May after less than a month of regular performances.
"Bring it On" has seen decent business during its preview period, with performances playing to approximately 90% capacity. The show, which officially opened Aug. 1, features an A-list writing team that includes Lin-Manuel Miranda, Tom Kitt, Jeff Whitty and Amanda Green.
It is the first new musical of the 2012-13 Broadway season.
'Bring It On: The Musical' is in a spirited legal tussle
'Bring It On' on Broadway gives credit to movie screenwriter
'Bring It On' screenwriter reaches settlement with stage musical


text:
Sguil on RedHat HOWTO
Note: This HOWTO is only for Sguil 0.7.0. If you're using Sguil 0.6.1, use this version of the HOWTO instead.
- 1 Purpose of This Document
- 2 Designing Your NSM Infrastructure
- 3 Prerequisites
- 4 Gathering the Network Data
- 5 Compiling the Software
- 6 Installing the Software
- 7 Configuration
- 7.1 Configuring the Server
- 7.2 Configuring a Client
- 7.3 Configuring a Sensor
- 8 More Information
- 9 Appendix A:Configuring Bonded Interfaces
- 10 Appendix B:Monitoring VLAN Traffic
- 11 Appendix C: Installing on Other Platforms
- 12 References
Purpose of This Document
The purpose of this document is to show how to compile, install and configure Sguil 0.7.0 on a RedHat Enterprise Linux 4 (RHEL) system. By following these instructions, you'll be able to put together your own Network Security Monitoring (NSM) infrastructure very quickly.
Designing Your NSM Infrastructure
Before installing, you should have a clear view of what you want your NSM infrastructure to look like. A full discussion of this is outside the scope of this document, but the key questions to be answered are:
- What sorts of things will I be looking for (eg., Insider attacks, Internet-based compromises, Virus/Worm activity, access to critical information assets)
- Which parts of my network should I monitor?
- Where can I place my sensors in order to best achieve my goals?
- How can I get access to the traffic (eg, SPAN ports, taps or other methods)
- How much data travels over these network links, and how much can I afford to capture?
Sguil supports many types of deployments, from the "all-in-one" where the sensor, database and sguil server are deployed on the same hardware, to the distributed configuration where multiple sensors report back to a dedicated database/server system. This document will allow you to install either of the above, or anything in between. Any piece of the sguil infrastructure can share a computer system with any other piece, so even though we refer to separate database machines, sensors and consoles, these can easily be placed on a single machine if enough computing and storage resources are available.
A note on multiple sensors: Sguil is quite capable of running multiple sensors (sniffing different networks) on the same system. Provided you have enough system resources (network cards, CPU, RAM, HD space and PCI bandwidth) this is no problem. If you install sensors as indicated in this document, you can easily configure multiple sensors on a single computer.
In this document, we will assume that the central database and the sguil server daemon are installed on the same system (as is recommended for all but exceptionally large installations). Thus, the terms database server and sguil server are used interchangeably. If this is not the case for your environment, adjust accordingly.
Sguil runs on a variety of Unix and Unix like systems, both *BSD and Linux based. For the purposes of this document, we will assume that you are going to install and run sguil on Red Hat Enterprise Linux (RHEL) 4. The Workstation version is fine (and certainly less expensive), but if you have AS or ES versions, these will work as well. Other versions of RHEL may also be compatible but have not been tested. Free clones of RHEL (e.g., CentOS or Whitebox Linux) should also be compatible.
Server Hardware
The hardware necessary to run sguil depends entirely upon the amount of network traffic you plan to monitor, how much of it you store and how long you store it. The public demonstration server at demo.sguil.net gets by with a 133MHz Pentium system, though for production systems you'll want something beefier.
For the sguil server, try to find something with a lot of memory and a fast disk. The MySQL database will need a lot of RAM for caching results from its queries, and a fast disk will speed up the access time while doing sequential searches.
You may find it helpful to place the MySQL storage on a separate disk partition, or even a separate disk. It doesn't matter where you mount this storage area, but for convenience, I'll assume that that you're going to mount it on the same directory path you're using for the sensor data directory (see below), referred to in this document as $NSM.
The following table is a useful guideline for a good server hardware configuration. Feel free to adjust it up or down depending on the size of your installation.
|Disk Storage
|150GB (Consider a RAID5 array for speed & reliability)
Estimating the Size of the Database
The disk space required to host the database varies depending on how many sensors you have and how busy your network is. Most of the space is taken up by session records. Each session record takes up approximately 170 bytes of disk space, including database overhead like indices. If you have 3 million records per day, that comes to about 486MB/day of space.
By contrast, an alert consumes around 625 bytes on average, including packet information and other supporting data, but there are usually far fewer alerts than network sessions on a reasonably well-tuned sensor. In fact, the ratio of alerts to sessions is nearly 0, therefore you can safely ignore everything but the session data when sizing your database partition. For a production sensor with a several months of session and alert data, you'll probably want anywhere from 50GB - 100GB of free disk space devoted to MySQL, depending on your data retention policy.
Sensor Hardware
The sensors typically store PCAP files of all network traffic they monitor, so they usually require more disk space than the central database server. A large, fast disk is the most important thing for a sensor; they need to write raw packet data to the disk as fast as it comes off the wire, and there can be quite a lot of it. It would not be out of the question to consider large RAID5 arrays here, at least for the systems at your network perimeter. At the very least, buy a single big disk to use just for the data storage. With 500GB disks available now, storage for the sensors should be no problem. If you're running multiple sensors on the same machine, you'll probably want to double the RAM and multiply the storage space by the number of sensors on the system.
|Disk Storage
|300GB or more
Whatever you choose for storage, you'll need to mount it somewhere in order for it to be useful. The sguil documentation recommends mounting it as /snort_data, but at least one other well-known installation guide[1]recommends using /nsm instead. You can mount it wherever you like. In this document, we'll refer to the mountpoint as $NSM.
If you're deploying multiple sensors on the same system, be sure to give each of the sensors their own data partition. Each of the sensors has a unique name, and will have a directory named $NSM/$SENSORNAME (e.g., /nsm/sensor1, /nsm/sensor2, etc). Sguil uses this space to store packet capture data (among other things), and when the partition starts to get full, it deletes the oldest packet data for the sensor in order to make room for newer captures. The algorithm it uses assumes that each sensor has it's own partition, so they each need to be mounted separately, otherwise one sensor will eventually take up all the storage space and others won't get any.
Another thing to take into account when preparing the data partitions is how they are mounted. Sguil is constantly writing data to the disk, but it rarely reads it back. Therefore, it makes sense to optimize the filesystem for write performance. This can be accomplished by using the async and noatime mount options, as in the following /etc/fstab entry:
LABEL=nsm /nsm ext3 defaults,async,noatime 1 2
As for network interfaces, you'll need one for the system itself to use (the "management interface") and one or more to sniff network traffic (the "monitoring interfaces"). While the management interface obviously requires an IP address and full network setup, the monitoring interfaces should be configured without addresses or network parameters of any sort. The number and type of monitoring interfaces you need will be dictated by the type of data collection you use and the number of sensors you will install on the system. Switch SPAN ports usually require only a single monitoring NIC, while most taps require two NICs (one for each direction of traffic on the monitored link).
Sguil depends on several different pieces of software in order to do its job. Many of them come with RHEL, but some do not, and in the case of MySQL, you might want to use your own version anyway. The following table is a list of the required software, versions and download sites.
|Download Location
|4.1.x versions also work
|Neither newer nor older versions may be used.
|126.96.36.199 (or newer)
You will also need to register for a free snort.org account in order to download IDS rules
|1.6.2 versions don't seem to work correctly for Sguil yet, but the developer is working on this.
|You must use the version with the built-in Sguil modifications. The standard PADS version will not work.
|Server, Client
|Provides for an encrypted data channel between the sguil server and the analyst consoles or sensors
|Server, Sensor, Client
|Note: 0.7.0 is currently in test release, so you'll need to fetch the CVS version.
|Sguil startup scripts
|Server, Sensor
|I've put together a set of prepackaged startup scripts for the various components. These files come with the InstantNSM distribution.
Gathering the Network Data
Before you can consider creating your first sguil sensor, you should already know how that sensor will acquire its data. The sensor needs to be able to sniff the network traffic on the monitored link, a topic which is outside the scope of this document. For more reading on this topic, I recommend The Tao of Network Security Monitoring.[2]
If you are using a network tap to gather your data, you'll notice that you will need to connect two different network cables to the sensor system. Most taps split the output into two streams, corresponding to the transmit and receive leads on the monitored network link. Although the process is not as well documented as it should be, Linux allows you to create bonded network interfaces, or virtual interfaces which correspond to two or more physical interfaces. When monitoring taps, bonded interfaces are extremely useful because they allow you to treat both physical interfaces as a single virtual interface, which greatly simplifies the configuration of the various data acquisition tools. If you are planning to use channel bonding on your sensor, see Appendix 1: Configuring Bonded Interfaces.
Compiling the Software
This section shows how to compile all the required software. Since you should under no circumstances have a C compiler installed on a sensor box, compile these on another RHEL3 box and copy them over to the server and sensor later.
Most packages use the standard GNU configure script. The instructions will place each of these in their own directory under /usr/local/package-version, so once you have compiled them you can simply copy the directories to the appropriate server or sensor system.
In the following sections, I will assume that you have already downloaded the source distributions for each package and have extracted them each to their own directory.
Issue the following commands to compile the MySQL server and client.
# cd mysql-5.0.45 # ./configure --prefix=/usr/local/mysql-5.0.45 --enable-assembler \ --enable-local-infile --enable-thread-safe-client --without-debug --with-openssl # make # make install
Issue the following commands to compile libpcap:
# cd libpcap-0.9.7 # ./configure --prefix=/usr/local/libpcap-0.9.7 # make # make shared # make install # make install-shared # ln -s /usr/local/libpcap-0.9.7 /usr/local/libpcap
Issue the following commands to compile libnet:
# cd Libnet-1.0.2a # ./configure --prefix=/usr/local/libnet-1.0.2a # make # make install # ln -s /usr/local/libnet-1.0.2a /usr/local/libnet
In order to compile snort, you must first install the pcre-devel RPM on your system. RHEL comes with this RPM, and it can easily be installed using the up2date command (or your distribution's equivalent), like so:
# up2date pcre-devel
Issue the following commands to compile snort:
# export PATH=$PATH:/usr/local/libnet/bin # cd snort-188.8.131.52 # ./configure --prefix=/usr/local/snort-188.8.131.52 \ --with-libpcap-includes=/usr/local/libpcap/include \ --with-libpcap-libraries=/usr/local/libpcap/lib \ --with-libnet-includes=/usr/local/libnet/include \ --with-libnet-libraries=/usr/local/libnet/lib \ --enable-flexresp --enable-dynamicplugin # make # make install
Before compiling PADS, you must patch it to fix several bugs with daemon mode and other features Sguil uses, but which aren't working well in PADS. The necessary patch file (pads.patch) is included in the patches subdirectory of the InstantNSM distribution.
# cd pads-1.2 # patch -p0 < /path/to/instantnsm/patches/pads.patch
You can read the pads.patch.README file in the same directory for more detailed explanation of these fixes.
Once you've patch the source, issue the following commands to compile PADS:
# export LDFLAGS="-L/usr/local/libpcap/lib -Xlinker -rpath -Xlinker /usr/local/libpcap/lib" # export CFLAGS="-I/usr/local/libpcap/include" # ./configure --prefix=/usr/local/pads-1.2 # make # make install
If you like, you can now remove the pcre-devel RPM, like so:
# rpm -e pcre-devel
SANCP deviates from the standard installation method by using a simple makefile instead of the GNU automatic configuration. Before you can compile it, you must edit the file called Makefile and change the CFLAGS= line to look like the following (all on a single line):
CFLAGS= -O3 -s -I/usr/local/libpcap/include -L/usr/local/libpcap/lib \ -Xlinker -rpath -Xlinker /usr/local/libpcap/lib
After you have edited the makefile, you can then issue the following commands to compile SANCP:
# make # mkdir -p /usr/local/sancp-1.6.1d/bin # cp sancp /usr/local/sancp-1.6.1d/bin
Sguil itself is just a set of Tcl scripts, so technically you don't need to compile it. You will find it convenient, however, to move the directory you downloaded into /usr/local like all the other software in this section. The distribution already comes as a tarball that you can simply unpack. If you downloaded it to /tmp/sguil-0.7.0.tar.gz, you can use something like:
# cd /usr/local # tar xfvpz /tmp/sguil-0.7.0.tar.gz
Barnyard requires the Tcl development package be installed. RHEL comes with this RPM, and it can easily be installed using the up2date command (or your distribution's equivalent), like so:
# up2date tcl-devel
Before compiling barnyard, you must patch it to include the newest version of the sguil support (the included sguil support is very old, and is incompatible with newer versions of sguil). You will need access to the sguil source tree, so make sure you've already downloaded and extracted it to the disk. Issue the following commands to patch and compile barnyard. In this example, $SGUIL refers to the location of the top of the downloaded source tree:
# cd barnyard-0.2.0 # cp $SGUIL/sensor/barnyard_mods/op_sguil.* src/output-plugins # cp $SGUIL/sensor/barnyard_mods/configure.in . # cd src/output-plugins # patch -p0 < $SGUIL/sensor/barnyard_mods/op_plugbase.c.patch # cd ../.. # autoconf # ./configure --prefix=/usr/local/barnyard-0.2.0+sguil --enable-tcl --with-tcl=/usr/lib # make # make install # cp -r ./etc /usr/local/barnyard-0.2.0+sguil
Don't remove the tcl-devel RPM yet. You'll need it again when compiling the other Tcl-related packages.
P0f is another tool that deviates from the standard GNU automatic configuration. Before compiling it, you must edit the mk/Linux file. Find the line that starts with LIBS= and change it something like the following (all on one line):
LIBS = -lpcap -I/usr/local/libpcap/include -L/usr/local/libpcap/lib
After you have made the change, issue the following commands to compile p0f:
# make # mkdir -p /usr/local/p0f-2.0.8/sbin # cp p0f p0frep /usr/local/p0f-2.0.8/sbin
Issue the following commands to compile Tcpflow:
# ./configure --prefix=/usr/local/tcpflow-0.21 --with-pcap=/usr/local/libpcap # make # make install
Issue the following commands to install Tcllib:
# ./configure --prefix=/usr/local/tcllib-1.9 # make install
Mysqltcl requires the MySQL development package. This is a standard part of RHEL, and can be installed with the following command:
# up2date mysql-devel
Now issue the following commands to install Mysqltcl:
# ./configure --prefix=/usr/local/mysqltcl-3.03 --exec-prefix=/usr/local/mysqltcl-3.03 # make # make install
If you like, you can now remove the mysql-devel RPM, like so:
# rpm -e mysql-devel
Compiling TclTLS is very similar to compiling the other packages that use the GNU automatic configuration script, except that it uses the OpenSSL library to provide the TLS functionality. This library is included by default on most RHEL systems, but RHEL 3 links it with Kerberos, and thus the compiler must be instructed where to find the necessary Kerberos include files in addition to everything else.
If you're using RHEL 3, you'll need to issue the following command before compiling TclTLS
# export CC="gcc -I/usr/kerberos/include"
Issue the following commands to compile TclTLS.
# ./configure --prefix=/usr/local/tcltls-1.5 --with-ssl-dir=/usr # make # make install
If you like, you can now remove the tcl-devel RPM, like so:
# rpm -e tcl-devel
Installing the Software
Once you have compiled the software, installing it on the various systems is straightforward. The only hard part is remembering which packages are installed on which systems. For example, only the server system needs MySQL, but only the sensors need snort or any of the other data gathering tools. The following sections tell you which packages to install on which hosts.
How to copy the software: Remember that we compiled each package to reside in it's own directory (typically named like /usr/local/software-version). This makes it very easy to copy from system to system. The easiest way to copy a package is to use the scp command (secure copy), part of the SSH command suite. To copy a directory from the local machine to a machine called rsystem, use a command like the following:
# scp -rp /usr/local/snort-2.4.3 rsystem:/usr/local
Each of the directories you copy will have a software name and a version number embedded in it. To make it easier to upgrade individual software packages later, also make sure to create a symbolic link like so:
# ln -s /usr/local/software-version /usr/local/software
This is important because the configuration examples in this document are going to refer to software with these version-less pathnames. Then, for example, if you need to upgrade snort to include a security patch, you won't have to change any of your other software or sguil configuration files, you'll just change the /usr/local/snort symlink to point to the newest version.
On your server
Before installing the packages you just compiled, you should install a few RPMs that the sguil server needs. You will need to install the tclx package. This can be conveniently installed in one step as follows:
# up2date tclx
If the MySQL server is already installed via RPM, you should also remove it with the following command:
# rpm -e mysql-server
Now copy over the MySQL, Mysqltcl, Tcllib, TclTLS, Tcpflow, p0f and sguil software directories to the server system (see the notes at the beginning of this section, and don't forget to make the version-less symbolic links).
For convenience (and because we'll use these later), also create links to some of the important individual binaries, like so:
# ln -s /usr/local/tcpflow/bin/tcpflow /usr/local/bin # ln -s /usr/local/p0f/sbin/p0f /usr/local/bin # ln -s /usr/local/mysql/bin/mysql /usr/local/bin # ln -s /usr/local/mysql/bin/mysqladmin /usr/local/bin # ln -s /usr/local/mysql/bin/mysqlcheck /usr/local/bin # ln -s /usr/local/mysql/bin/mysqld_safe /usr/local/bin # ln -s /usr/local/mysql/bin/mysqldump /usr/local/bin # ln -s /usr/local/mysql/bin/mysql_install_db /usr/local/bin
In addition, you'll need to make a few symbolic links to make the Tcllib and Mysqltcl packages available in a directory where the Tcl interpreter will be able to find them. Use the following two commands to hook these into the standard location:
# ln -s /usr/local/mysqltcl/lib/mysqltcl-3.03 /usr/lib # ln -s /usr/local/tcllib/lib/tcllib1.9 /usr/lib
On your sensor
The sguil sensor needs to be able to find the tcpdump binary when extracting data from the full packet logs. It also needs the tclx package, which provides various Tcl programming extensions. You can easily install these as follows:
# up2date tcpdump tclx
Now you can install the software you just compiled. Copy over the pads, barnyard, sancp, libnet, libpcap, snort, and sguil software directories to the server system (see the notes at the beginning of this section, and don't forget to make the version-less symbolic links).
For convenience (and because we'll use these later), also create symbolic links to some of the important individual binaries, like so:
# ln -s /usr/local/barnyard/bin/barnyard /usr/local/bin # ln -s /usr/local/sancp/bin/sancp /usr/local/bin # ln -s /usr/local/snort/bin/snort /usr/local/bin # ln -s /usr/local/pads/bin/pads /usr/local/bin
On your client system
You don't need much software to support the analyst consoles, but there are a few RPMs to install, as shown below:
# up2date wireshark-gnome tclx tcllib itcl
Now just copy over the sguil directory and add a symbolic link to the client:
# ln -s /usr/local/sguil/client/sguil.tk /usr/local/bin
Since most of the components of sguil are really independent programs, special care is required in order to configure them such that they all work properly together. Once you've got the hang of it, it's not difficult, but there are a lot of files to edit, and things can be pretty confusing. In this section, you'll learn how to configure the pieces to work together smoothly.
Configuring the Server
To configure the sguil server, log on to the server system and perform the following procedures as root.
Preparing the OS
First, you need to add a new local user (called sguil) who will own all the files and processes associated with the sguil server. I recommend using the -u option to specify a particular UID. The exact value isn't important (choose one that's not already in use) but specifying it explicitly is convenient when you want to transfer sguil-owned files to and from your sensor systems. (Note: useradd will also create a sguil group in addition to the user account).
# useradd -u 400 -d /home/sguil -c "SGUIL User" sguil
Next, you must populate your local sguil directory structure. Remember, the root of your local storage can be anywhere, but in these instructions I'm going to refer to it as $NSM.
# mkdir -p $NSM/sguild_data/archive # mkdir $NSM/sguild_data/rules # mkdir $NSM/sguild_data/load # chown -R sguil.sguil $NSM/sguild_data
Configuring the MySQL Database Server
If you've ever had the RPM version of the MySQL server installed on this system, you may already have a mysql user account to go with it. By default, this will use a UID and GID of 27. If this account already exists, you can skip this step, but if not, you'll need to create one. The following command will create a mysql account and group using compatible settings. (Note: useradd will also create a mysql group in addition to the user account).
# useradd -u 27 -d /var/lib/mysql -s /bin/bash -c "MySQL Server" mysql
Most of the local storage requirement on the server is for the MySQL database. Using the commands below, we'll relocate the database directory from the default /var/lib/mysql to the $NSM/mysql directory. We'll also add a symbolic link to the old location for compatibility.
# mkdir $NSM/mysql # chown -R mysql.mysql $NSM/mysql # chmod 755 $NSM/mysql # rm -rf /var/lib/mysql # ln -s $NSM/mysql /var/lib/mysql
MySQL Startup Scripts
Now you should install the MySQL startup script and the configuration file that came in the package you downloaded earlier. In addition to copying the startup script into place, you'll need to edit it to reflect the location of the MySQL binaries, and use the chkconfig command to set it to start at boot time. You won't actually start the service yet, though. That comes a little later.
You should have already unpacked the startup files into their own directory when you unpacked the rest of the downloaded software. Assuming the startup files are in $STARTUPFILES, you can use the following commands to install the default MySQL config file and cause the daemon to run at boot time:
# cp $STARTUPFILES/my.cnf /etc # cp $STARTUPFILES/mysqld /etc/init.d # sed -i 's/MYSQLD_SAFE/\/usr\/local\/bin\/mysqld_safe/g' /etc/init.d/mysqld # sed -i 's/MYSQL_INSTALL_DB/\/usr\/local\/bin\/mysql_install_db/g' /etc/init.d/mysqld # sed -i 's/MYSQLADMIN/\/usr\/local\/bin\/mysqladmin/g' /etc/init.d/mysqld # chkconfig --add mysqld # chkconfig mysqld on
Next, create the initial database structure, like so:
# /usr/local/mysql/bin/mysql_install_db --user=mysql
Now we can finally start MySQL. We follow this with a database ping just to make sure it started properly.
# service mysqld start # mysqladmin ping
Creating Database Users
For security, the first order of business now that the server is running is to change the passwords for the MySQL root account (the database administrator).
# mysql -u root mysql mysql> update user set Password=OLD_PASSWORD("new_password") where User = "root"; mysql> flush privileges; mysql> exit
MySQL authentication and backwards compatibility: You'll notice here and elsewhere in this document that we are using the MySQL OLD_PASSWORD() macro instead of the newer PASSWORD() macro when setting database passwords. This is to ensure compatibility with legacy MySQL systems, especially the 3.2x versions that ship with many Linux systems. If you know that you are using 4.x or newer versions everywhere, you can safely replace OLD_PASSWORD() with PASSWORD() everywhere in this document.
With the basic MySQL infrastructure up and running, we can now concentrate on creating the sguil database itself. First, lets create a sguil user in MySQL so the sguil server on this machine can log into the database. You'll need to log in with the MySQL root password. When you issue the GRANT command to create a new database account, you'll also specify the password for that account. Pick something different from the MySQL root password.
# mysql -u root -p mysql
Enter password: password
mysql> GRANT ALL PRIVILEGES ON sguildb.* TO sguil@localhost IDENTIFIED BY "sguil_password"; mysql> GRANT FILE ON *.* to sguil@localhost; mysql> update user set Password = OLD_PASSWORD("sguil_password") where User = "sguil"; mysql> FLUSH PRIVILEGES;
Creating the Sguil Database
Now you must create the empty database (called sguildb) to store all the data:
# mysql -u sguil -p -e "CREATE DATABASE sguildb" # mysql -u sguil -p -D sguildb < /usr/local/sguil/server/sql_scripts/create_sguildb.sql # mysql -u sguil -p -D sguildb -e "show tables"
This last show tables command should show you a list of all the tables in your new database, similar to the following. If you don't see something like this, your database has not been created.
# mysql -u sguil -p -D sguildb -e "show tables" +-------------------+ | Tables_in_sguildb | +-------------------+ | history | | nessus | | nessus_data | | pads | | portscan | | sensor | | sessions | | status | | user_info | | version | +-------------------+
At this point, we're done with MySQL configuration, so we move on to the sguil server.
Configuring the Sguil Daemon
First, we need to create a directory to hold the PID file:
# mkdir /var/run/sguil # chown sguil.sguil /var/run/sguil
Next we need to create a directory structure to hold the sguil server's configuration files. We'll also copy the defaults from the sguil source directory so we'll have a baseline to customize.
# mkdir -p /etc/sguild/certs # cp /usr/local/sguil/server/sguild.conf /etc/sguild # cp /usr/local/sguil/server/autocat.conf /etc/sguild # cp /usr/local/sguil/server/sguild.users /etc/sguild # cp /usr/local/sguil/server/sguild.queries /etc/sguild # cp /usr/local/sguil/server/sguild.access /etc/sguild # cp /usr/local/sguil/server/sguild.email /etc/sguild # cp /usr/local/sguil/server/sguild.reports /etc/sguild # chown -R sguil.sguil /etc/sguild
Edit the /etc/sguild/sguild.conf file you just created to make the following changes. In each case, find the line that sets the indicated variable name (shown in UPPER_CASE) and change it to the indicated value. Remember to replace the $NSM variable with the location of your local storage directory!
set SGUILD_LIB_PATH /usr/local/sguil/server/lib set DEBUG 0 set SENSOR_AGGREGATION_ON 0 set RULESDIR $NSM/sguild_data/rules set DBPASS "your_sguil_db_password" set DBUSER sguil set LOCAL_LOG_DIR $NSM/sguild_data/archive set TCPFLOW /usr/local/bin/tcpflow set P0F 1 set P0F_PATH /usr/local/bin/p0f set TMP_LOAD_DIR $NSM/sguild_data/load
Now we need to create an SSL certificate to be used for encrypting communications between the sguil server, sensors and analyst consoles. RHEL automates most of the process, as shown below:
# cd /usr/share/ssl/certs # make sguild.pem
This will create a file called /usr/share/ssl/certs/sguild.pem. The PEM file is actually just a text file that contains both the private key and the public certificate. It looks like this:
-----BEGIN RSA PRIVATE KEY----- MIICWwIBAAKBgQCxFTbTzpeU2z1u7PinG0TjLq6UZUT4TWUfyj5DJogwOXteHQkd lYvwUZgtUmQmyYBmTMbFGeHSJ/TXnFUUETfG3FHel/zeWer5QqJoezERT2RvZ7CK [DELETED] 5C7aUaFqAsUCj4rOnQJAK46SuoVYYM8/eZLSP6iOYZK1dj74+8ScM8KYzxS9xeTD phabxc/FbbuCrcDyxlfFW91RbFVCNFFFe2qpDRB1Nw== -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIID0zCCAzygAwIBAgIBADANBgkqhkiG9w0BAQQFADCBqDELMAkGA1UEBhMCVVMx ETAPBgNVBAgTCFZpcmdpbmlhMRUwEwYDVQQHEwxXaWxsaWFtc2J1cmcxFTATBgNV [DELETED] CSEb3wRxje9WILnkpNOf5ETPW4x/WSFFNfcqzeeuNDFzE2zBv9S2dLeGtHc3JvKL Q808wzYJvS9FeilVKwyxDIRplELRjrI= -----END CERTIFICATE-----
Sguil needs these to be in separate files, so edit it with your text editor. Copy everything between the "BEGIN RSA PRIVATE KEY" line and the "END RSA PRIVATE KEY" line (inlcuding the "BEGIN" and "END" lines!) to a file in the sguil daemon configuration directory called /etc/sguild/certs/sguild.key. Similarly, copy everything between the "BEGIN CERTIFICATE" and "END CERTIFICATE" lines (including the "BEGIN" and "END" lines) to a file called /etc/sguild/certs/sguild.pem.
Configuring Analyst Accounts
Lets add some sguil accounts for the security analysts. Remember, analysts don't necessarily have to have local OS accounts in order to use sguil. Sguil has it's own account database. Use the command below to create an account named sguil.
# /usr/local/sguil/server/sguild -adduser sguil
Sguil Startup Scripts
Finally, copy over the sguild startup file from the unpacked sample startup file directory ($STARTUPFILES), and configure sguild to run at boot time.
# cp $STARTUPFILES/sguild /etc/init.d # sed -i 's/SGUILD/\/usr\/local\/sguil\/server\/sguild/g' /etc/init.d/sguild # sed -i 's/TCLTLS_SO/\/usr\/local\/tcltls\/lib\/libtls1.50.so/g' /etc/init.d/sguild # chkconfig --add sguild # chkconfig sguild on # service sguild start
Sguild should now be running. Use a command like ps -eaf | grep sguil to ensure that you see three sguild processes (sguild forks off a couple of helper processes when it starts).
At this point, I recommend that you reboot the server system to double check that the MySQL daemon and the sguil server both start properly.
Configuring a Client
Configuring a sguil client console is pretty easy. The software is already installed on your analyst workstation (you did this in a previous section), so all you need to do is copy the default client configuration file and make a few changes to tailor it to your local environment:
# cp /usr/local/sguil/client/sguil.conf /etc/sguil.conf
Basic Configuration Settings
Make the following changes. In each case, find the line that sets the indicated variable name (shown in UPPER_CASE) and change it to the indicated value.
set SERVERHOST sguil_server_hostname set SGUILLIB /usr/local/sguil/client/lib set DEBUG 0 set OPENSSL 1 set TLS_PATH /usr/local/tcltls/lib/libtls1.50.so set STATUS_UPDATES 10 set WIRESHARK_STORE_DIR /var/tmp
There are numerous other settings you may want to play around with, but these are the most important ones to get the console working properly.
Using Third-Party DNS Servers for Stealth Analysis
NSM analysis requires a lot of data, and probably the most commonly-used data comes from DNS lookups of (possibly) hostile IPs. For most events, looking up the IPs in DNS isn't really a problem. Some more skilled attackers, though, make a habit of monitoring the DNS servers for their own domains. This helps them to see which sites have detected their activity and started to investigate. For example, if they see a flurry of DNS queries coming from www.yourdomain.com 6 hours after they launched their last attack attempt, they will probably assume that some system admin or security analyst has detected their activity. Maybe they will figure it's too risky and go away, but often they simply increase their stealth and keep right on hacking.
Starting with version 0.7.0, Sguil now comes with the innate ability to forward some DNS queries to a third-party DNS provider (e.g., OpenDNS). The way this works is that you can configure an external DNS server and a list of your own internal IP networks. Whenever the Sguil console attempts to do a DNS lookup on an IP address, it will consult this network list. Addresses that fall within one of the entries on the list will be resolved normally (using whatever servers your analyst workstation normally uses). However, addresses that do not correspond to one of the list items are considered potentially hostile, and all DNS lookups will be directed to the third-party DNS server that you specify. This helps cloak your analysis activity. Attackers may be able to discover that someone has detected their activity, but none of the queries will be traceable to your network.
To configure this, you just need to make a few simple changes to the sguil.conf file:
set EXT_DNS 1 set EXT_DNS_SERVER 18.104.22.168 set HOME_NET "192.168.1.0/24 10.0.0.0/8"
Set EXT_DNS to 1 to enable the third-party DNS feature (or 0 to disable it). Then set EXT_DNS_SERVER to the single IP address of the server you want to use. The example above points to the OpenDNS resolver, which is probably reasonable for most sites. Finally, set HOME_NET to the space-delimited list of CIDR blocks that describe all the IPs that will be resolved locally (that is, it's a list of "your" networks).
By the way, no matter what the setting of the EXT_DNS variable, you can turn this feature on and off on demand as long as you've set the other two variables. Just check/uncheck the Enable External DNS box on the Sguil console.
Starting the Analyst Console
Now you are finally ready to try out your sguil system! Launch the client by running the sguil.tk script.
# /usr/local/bin/sguil.tk
You should see a log in screen with the "Sguild Host" set to your sguil server. Log in with the username and password you created earlier and make sure the "Enable SSL" button is checked. If all goes well, you should see the sguil main screen, but there will be no data because you have not yet created any sensors. But we can take care of that!
Configuring a Sensor
Configuring a sensor is probably the trickiest part of this whole document, but by following these instructions, a little practice can make it a quick and (fairly) painless event. Well, ok, just quick.
Naming Your Sensor
First, choose a name for your sensor. Each sensor must have a unique name, usually something to remind the analyst which link the sensor monitors. For example, you might call your Internet-facing sensor border if it's at the "border" of your network. Maybe it'll be finance if it's monitoring the financial subnet. Whatever you choose, just make sure it's meaningful. Also avoid special characters. In fact, it's best if you restrict it to alphanumeric only, and avoid all punctuation, dashes, underscores, spaces or other characters.
For the rest of this section, we'll refer to the name of the sensor as $SENSORNAME.
Preparing the OS
Just as with the server, you need to add a new local user (called sguil) who will own all the files and processes associated with the sguil sensor. (Note: useradd will also create a sguil group in addition to the user account).
# useradd -u 400 -d /home/sguil -c "SGUIL User" sguil
Next, you must populate your local sguil directory structure. Remember, the root of your local storage can be anywhere, but in these instructions I'm going to refer to it as $NSM. Also create a symlink from /var/log/snort-$SENSORNAME to $NSM/snort-logs/$SENSORNAME, just for convenience
# mkdir -p $NSM/snort-logs/$SENSORNAME/OLD # mkdir -p $NSM/snort_data/$SENSORNAME/dailylogs # mkdir -p $NSM/snort_data/$SENSORNAME/sancp # chown -R sguil.sguil $NSM/snort-logs $NSM/snort_data # ln -s $NSM/snort-logs/$SENSORNAME /var/log/snort-$SENSORNAME
Now we need to create a directory to hold the PID files. If this system has already had a sguil server or sensor configured on it, you can skip this step.
# mkdir /var/run/sguil # chown sguil.sguil /var/run/sguil
Configuring Snort IDS Rules
Now create a directory to hold the snort rules for this sensor. Note that this should be owned by root and set to group root, not owned by sguil. This is just a little extra security measure to help keep you from accidentally modifying and/or deleting files in this directory later:
# mkdir /usr/local/snortrules-$SENSORNAME # chown -R root.root /usr/local/snortrules-$SENSORNAME
Now extract the snort rules you downloaded from snort.org into /usr/local/snortrules-$SENSORNAME and configure them to your taste. This part is outside the scope of this document; just be sure that when you finish, all the configuration files are in a flat directory structure, and not in subdirectories (i.e., you have /usr/local/snortrules-$SENSORNAME/snort.conf, /usr/local/snortrules-$SENSORNAME/sid-msg.map, etc).
When editing your snort.conf file, be sure to enable the perfmonitor preprocessor. This component dumps out snort performance stats, which sguil will read and display in the console's "Snort Statistics" tab. This is a convenient way to keep track of all of your snort sensors in one place and allows you to monitor link usage, packet loss, and number of alerts. For most sensors, you can simply include the following line in your snort.conf file:
preprocessor perfmonitor: time 300 file $NSM/snort_data/$SENSORNAME/snort.stats pktcnt 10000
Once you've got the ruleset that you want, be sure to copy them to the sguil server system as a directory called $NSM/rules/$SENSORNAME. This is important because the sguil server will need to reference the rules in its local directory in order to show them to you in the analyst console. If the sensor and the server are on the same system, you can shortcut this by just creating a symbolic link:
# ln -s /usr/local/snortrules-$SENSORNAME $NSM/sguild_data/rules/$SENSORNAME
Sensor Configuration
Now comes the tricky part: configuring the different information gathering programs to work together.
Start by creating a directory in which all the various configuration files will live. Since we're using these tools as part of a sguil sensor, we'll keep them all in the same directory, /etc/sguil.
# mkdir /etc/sguil
Now copy the various default configuration files from their original locations into the new directory. Note that we will also rename most of these file to include the $SENSORNAME, so that we can easily have more than one configuration for each sensor on the machine. The sancp.conf file is an exception, since all sensors on the machine can share the same configuration file.
# cp /usr/local/sguil/sensor/sancp/sancp.conf /etc/sguil/sancp.conf # cp /usr/local/sguil/sensor/sancp_agent.conf /etc/sguil/sancp_agent-$SENSORNAME.conf # cp /usr/local/sguil/sensor/pads_agent.conf /etc/sguil/pads_agent-$SENSORNAME.conf # cp /usr/local/sguil/sensor/pcap_agent.conf /etc/sguil/pcap_agent-$SENSORNAME.conf # cp /usr/local/sguil/sensor/snort_agent.conf /etc/sguil/snort_agent-$SENSORNAME.conf # cp /usr/local/barnyard/etc/barnyard.conf /etc/sguil/barnyard-$SENSORNAME.conf
Now you must edit each of the agents' config files to configure them for this sensor.
SANCP Agent
Edit /etc/sguil/sancp_agent-$SENSORNAME.conf to set the following variables:
set DEBUG 0 set SERVER_HOST ip_addr_of_sguild_server set HOSTNAME $SENSORNAME set NET_GROUP $SENSORNAME set LOG_DIR $NSM/snort_data set SANCP 1
PADS Agent
Edit /etc/sguil/pads_agent-$SENSORNAME.conf to set the following variables:
set DEBUG 0 set SERVER_HOST ip_addr_of_sguild_server set HOSTNAME $SENSOR_NAME set NET_GROUP $SENSORNAME set LOG_DIR $NSM/snort_data
You also need to create a simple config file for the PADS binary itself. Create the file /etc/sguil/pads-$SENSORNAME.conf with the following contents:
daemon 1 pid_file /var/run/sguil/pads-$SENSORNAME interface monitoring_interface network your_CIDR_block output fifo: $NSM/snort_data/$SENSORNAME/pads.fifo
Set monitoring_interface to the interface you're monitoring (e.g., "eth1") and your_CIDR_block to the CIDR notation for the "inside" of the network that you're monitoring on that link (e.g., "192.168.7.0/24").
PCAP Agent
Edit /etc/sguil/pcap_agent-$SENSORNAME.conf to set the following variables:
set DEBUG 0 set SERVER_HOST ip_addr_of_sguild_server set HOSTNAME $SENSORNAME set NET_GROUP $SENSORNAME set LOG_DIR $NSM/snort_data
Snort Agent
Edit /etc/sguil/snort_agent-$SENSORNAME.conf to set the following variables:
set DEBUG 0 set SERVER_HOST ip_addr_of_sguild_server set HOSTNAME $SENSORNAME set NET_GROUP $SENSORNAME set LOG_DIR $NSM/snort_data set PORTSCAN 0 set SNORT_PERF_STATS 1
Barnyard Config
Next, edit /etc/sguil/barnyard-$SENSORNAME.conf and make the changes indicated below. You're going to set the "hostname" to the sensor's name, delete the default filter, comment out the alert_fast and log_dump output plugins and set the sguil sensor name.
config hostname: $SENSORNAME config filter: #output alert_fast #output log_dump output sguil: sensor_name $SENSORNAME
To change the port this instance of the snort agent listens on, make the following additional modification to /etc/sguil/snort_agent-$SENSORNAME.conf:
set BY_PORT $UNIQUE_PORT
You'll also need to tell this instance of barnyard what port to use. Do this by editing the /etc/sguil/barnyard-$SENSORNAME.conf like so:
output sguil: sensor_name $SENSORNAME, agent_port $UNIQUE_PORT
Startup Scripts
Now you should install the startup scripts for the sensor processes, using the ones that came in the package you downloaded earlier. In addition to copying the startup scripts into place, you'll need to use the chkconfig command to set them to start at boot time. Don't start them yet, though. You'll do that later, after you edit the scripts to change some of the defaults.
You should have already unpacked the startup files into their own directory when you unpacked the rest of the downloaded software. Assuming the startup files are in $STARTUPFILES, you can use the following commands to install the startup files and cause them to run at boot time. Notice that the sample script names all end in "-sensor". You'll replace this with "-$SENSORNAME" when you copy the files into the system directory.
# cp $STARTUPFILES/barnyard-sensor /etc/init.d/barnyard-$SENSORNAME # cp $STARTUPFILES/sancp-sensor /etc/init.d/sancp-$SENSORNAME # cp $STARTUPFILES/sancp_agent-sensor /etc/init.d/sancp_agent-$SENSORNAME # cp $STARTUPFILES/pads_agent-sensor /etc/init.d/pads_agent-$SENSORNAME # cp $STARTUPFILES/pcap_agent-sensor /etc/init.d/pcap_agent-$SENSORNAME # cp $STARTUPFILES/snort_agent-sensor /etc/init.d/snort_agent-$SENSORNAME # cp $STARTUPFILES/sguil_logger-sensor /etc/init.d/sguil_logger-$SENSORNAME # cp $STARTUPFILES/snort-sensor /etc/init.d/snort-$SENSORNAME # cp $STARTUPFILES/pads-sensor /etc/init.d/pads-$SENSORNAME # chkconfig --add barnyard-$SENSORNAME # chkconfig --add sancp-$SENSORNAME # chkconfig --add sancp_agent-$SENSORNAME # chkconfig --add pads_agent-$SENSORNAME # chkconfig --add pcap_agent-$SENSORNAME # chkconfig --add snort_agent-$SENSORNAME # chkconfig --add sguil_logger-$SENSORNAME # chkconfig --add snort-$SENSORNAME # chkconfig --add pads-$SENSORNAME # chkconfig barnyard-$SENSORNAME on # chkconfig sancp-$SENSORNAME on # chkconfig sancp_agent-$SENSORNAME on # chkconfig pads_agent-$SENSORNAME on # chkconfig pcap_agent-$SENSORNAME on # chkconfig snort_agent-$SENSORNAME on # chkconfig sguil_logger-$SENSORNAME on # chkconfig snort-$SENSORNAME on # chkconfig pads-$SENSORNAME on
Now you'll have to make a number of edits to the various startup files to set executable paths and environment variables.
In /etc/init.d/barnyard-$SENSORNAME, find the line that says "SENSOR=SENSORNAME" and change it to replace "SENSORNAME" with the name of your sensor. Also replace the string "BARNYARD" with "/usr/local/bin/barnyard" wherever it appears.
In /etc/init.d/snort-$SENSORNAME, find the line that says "SENSOR=SENSORNAME" and change it to replace "SENSORNAME" with the name of your sensor. Find the line that says "NSMDIR=NSMDIRECTORY" and change the it to reflect the path to your local $NSM/snort_data directory. Also find the line that says "IFACE=INTERFACE" and change it to list the name of the interface on which you will be monitoring (e.g., "INTERFACE=eth1"). Also replace the string "SNORTBIN" with "/usr/local/bin/snort" wherever it appears.
Make the same edits to /etc/init.d/sancp-$SENSORNAME as you made to the "SENSORNAME", "NSMDIRECTORY" and "IFACE" settings in /etc/init.d/snort-$SENSORNAME. Also replace "SANCPBIN" with "/usr/local/bin/sancp" wherever it appears.
Make the same edits to /etc/init.d/pads-$SENSORNAME as you made to the "SENSORNAME" and "NSMDIRECTORY" settings (there is no "IFACE" setting) in /etc/init.d/snort-$SENSORNAME. Also replace "PADSBIN" with "/usr/local/bin/pads" wherever it appears.
In /etc/init.d/sancp_agent-$SENSORNAME, find the line that says"SENSOR=SENSORNAME" and change it to replace "SENSORNAME" with thename of your sensor. Also replace the strings "SANCP_AGENT_TCL" with"/usr/local/sguil/sensor/sancp_agent.tcl" and "TCLTLS_SO" with"/usr/local/tcltls/lib/libtls1.50.so".
In /etc/init.d/pads_agent-$SENSORNAME, find the line that says"SENSOR=SENSORNAME" and change it to replace "SENSORNAME" with thename of your sensor. Also replace the strings "PADS_AGENT_TCL" with"/usr/local/sguil/sensor/pads_agent.tcl" and "TCLTLS_SO" with"/usr/local/tcltls/lib/libtls1.50.so".
In /etc/init.d/pcap_agent-$SENSORNAME, find the line thatsays"SENSOR=SENSORNAME" and change it to replace "SENSORNAME" withthename of your sensor. Also replace the strings "PCAP_AGENT_TCL"with"/usr/local/sguil/sensor/pcap_agent.tcl" and "TCLTLS_SO"with"/usr/local/tcltls/lib/libtls1.50.so".
In /etc/init.d/snort_agent-$SENSORNAME, find the line thatsays"SENSOR=SENSORNAME" and change it to replace "SENSORNAME" withthename of your sensor. Also replace the strings "SNORT_AGENT_TCL"with"/usr/local/sguil/sensor/snort_agent.tcl" and "TCLTLS_SO"with"/usr/local/tcltls/lib/libtls1.50.so".
Finally, edit /etc/init.d/sguil_logger-$SENSORNAME to change "SENSOR=SENSORNAME" to replace "SENSORNAME" with the name of your sensor. This component requires a bit of extra configuration. First, each must have it's own copy of the script that collects the full packet data.
# cp /usr/local/sguil/sensor/log_packets.sh /etc/sguil/log_packets-$SENSORNAME.sh
Now edit /etc/sguil/log_packets-$SENSORNAME.sh to make the following changes. Remember to set INTERFACE to the monitor interface (e.g., eth1, bond0, etc).
HOSTNAME="$SENSORNAME" SNORT_PATH="/usr/local/bin/snort" LOG_DIR="$NSM/snort_data" INTERFACE="monitor_interface" OPTIONS="-u sguil -g sguil -m 122"
PCAP Monitor Cron Job
You'll also need to add the following cronjob for root to start/restart the logging process on a regular schedule. For most links, once an hour is good, though if you have a particularly high volume link, you may wish to run the job more frequently.
# Restart the sguil packet logger on a regular basis 0 * * * * /etc/init.d/sguil_logger-$SENSORNAME restart
Testing Your Sensor Startup
Now reboot the sensor to make sure everything starts up properly. If it does, you should see the following eleven processes running (in addition to whatever other sguil components you may have configured on this machine):
# ps -eaf | grep -i sguil sguil 3121 1 0 08:45 ? 00:00:00 /usr/local/bin/pads -c /etc/sguil/pads-testse sguil 3132 1 2 08:45 ? 00:00:01 /usr/local/bin/snort -u sguil -g sguil -m 122 sguil 3166 1 0 08:45 ? 00:00:00 tclsh /usr/local/sguil/sensor/pads_agent.tcl sguil 3167 3166 0 08:45 ? 00:00:00 cat /nsm/snort_data/testsensor/pads.fifo sguil 3201 1 0 08:45 ? 00:00:00 tclsh /usr/local/sguil/sensor/pcap_agent.tcl sguil 3236 1 0 08:45 ? 00:00:00 tclsh /usr/local/sguil/sensor/sancp_agent.tcl sguil 3279 1 0 08:45 ? 00:00:00 /usr/local/bin/snort -u sguil -g sguil -m 122 sguil 3318 1 0 08:45 ? 00:00:00 tclsh /usr/local/sguil/sensor/snort_agent.tcl sguil 3319 3318 0 08:45 ? 00:00:00 tail -n 1 -f /nsm/snort_data/testsensor/snort sguil 3352 1 0 08:46 ? 00:00:00 /usr/local/bin/barnyard -c /etc/sguil/barnyar sguil 3361 1 0 08:46 ? 00:00:00 /usr/local/bin/sancp -d /nsm/snort_data/tests
Eleven processes per sensor is a lot, and if you're a bit confused about what they're all for, don't worry. It's actually fairly straightforward.
First, there are the processes that gather the NSM data: two copies of snort (one in IDS mode, one in packet logging mode), one instance of SANCP to gather session data, and one copy of PADS to keep track of services that are being used on your network. Each of these also has an associated agent process (e.g., snort_agent or pads_agent) that communicates the NSM data back to the sguil server. There's also barnyard, which reads the binary IDS alerts from Snort and converts them into a format suitable for sguil. Finally, there's an instance of cat that is responsible for getting the information out of the PADS file and into the PADS agent, and a tail process that's constantly reading the Snort performance stats that are displayed in the GUI.
See. Easy, huh?
Your sensor is now configured! Log in with your analyst console and you should start seeing alerts. If so, you're done!
More Information
The first place to look for more information on sguil is the project's web page at http://www.sguil.org/. Specifically, take a look at the FAQ and the wiki.
The project also maintains mailing lists, which are invaluable sources of information. You can search the archives or subscribe to the lists from the mailing list page.
Finally, if you need more immediate help, or if you just want to chat with the developers and other sguil users, please join us on the project's IRC channel, #snort-gui on irc.freenode.net.
Appendix A:Configuring Bonded Interfaces
Configuring bonded interfaces in RHEL is straightforward, though it does involve editing a few configuration files. In this example, I will assume that you are trying to bond two physical interfaces (eth1 and eth2) into a single virtual interface (bond0). If you're going to use different physical interfaces, or if you are creating more than one bonded interface, adjust the filenames by changing the numbers at the end (eg, you might meld eth3 and eth4 into a second bonded interface called bond1).
All RHEL network interfaces are configured via files in the /etc/sysconfig/network-scripts directory, so first become root, then change your directory to that location:
% su - # cd /etc/sysconfig/network-scripts
Next, using your favorite editor, create the file ifcfg-bond0 with the following contents:
DEVICE=bond0 BOOTPROTO=none ONBOOT=yes
Each of your physical interfaces should already have an ifcfg-ethx file in that directory, so edit the files that go with the cards you are bonding to look something like the following (note that the DEVICE= line will be different in each file):
DEVICE=eth1 HWADDR=XX:XX:XX:XX:XX:XX BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes
You will probably already have other configuration lines in these files. If so, delete them. They will mostly likely contain networking parameters that don't apply to cards used as packet sniffers. I definitely recommend making sure that you have the HWADDR= line, though, followed by the network card's MAC address (AKA the ethernet address). This associates the logical ethx device with a specific hardware card, which will be important if you later upgrade your kernel or introduce new network interfaces, which can reorder the cards.
Now that the network configuration is done, you also need to ensure that the channel bonding kernel driver is automatically loaded whenever this interface is brought up. To do this, add a line like the following to the /etc/modprobe.conf file (some distributions may call this /etc/modules.conf):
alias bond0 bonding
If you are configuring more than one bonded interface, you'll need one of these lines for each. Remember to change bond0 on each line as appropriate.
Now reboot the system and, if everything went well, you should see an additional network interface called bond0:
sensor:/> ifconfig bond0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth0 Link encap:Ethernet HWaddr 00:0C:29:C9:0F:B7 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4978 errors:0 dropped:0 overruns:0 frame:0 TX packets:2848 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4386932 (4.1 Mb) TX bytes:386103 (377.0 Kb) Interrupt:10 Base address:0x1400
More information on configuring bonded interfaces under RHEL can be found in the Red Hat Linux Enterprise 4 Reference Guide.[3]
Appendix B:Monitoring VLAN Traffic
With more and more organizations relying on VLANs to provide logical traffic separation over a shared physical network, it's important to be able to monitor these packets as well. Some of the software we're using understands these natively (Snort), some need configuration tweaks (sguil, SANCP) and some require some special patching (tcpflow). This section will describe extra steps you should take if your sensors are monitoring traffic with 802.1Q VLAN tags.
First, make sure SANCP is set to start with the "--strip-8021Q" command line option. (If you're using a version of SANCP prior to 1.6.2, use the "--strip-80211" option instead. Knowledgeable readers will notice that 802.11 has nothing to do with 802.1Q tags, but nevertheless this is the correct option name.) You can do this editing your /etc/init.d/sancp-$SENSORNAME file and uncommenting the line that starts with "VLAN=", then restarting that service.
Next, edit your /etc/sguil/sensor_agent-$SENSORNAME file to enable VLAN support in the sguil sensor agent. Simply find the line that says "set VLAN 0" and change it to "set VLAN 1" and restart the sensor agent.
Finally, the tcpflow software needs to be patched to include VLAN tag support. The patch is included in the patches/tcpflow-0.21-vlan-patch file in the InstantNSM [4] distribution. Switch into your existing tcpflow source directory, apply the patch, then continue compiling according to the directions given elsewhere in this document.
# cd tcpflow-0.21 # patch < tcpflow-0.21-vlan-patch
Since tcpflow resides on the sguil server, if any of your sensors monitor VLAN trunks, you need to install this patch. Don't worry, it will still work with your non-VLAN sensors as well.
Once you've performed these procedures, you should be able to monitor VLAN traffic with ease.
You may also wish to visit the NSM and VLANs page for more info, including patches for additional NSM tools which are not part of the sguil suite proper.
Appendix C: Installing on Other Platforms
The Sguil server and sensors can actually be installed on most versions of Linux or *BSD. This section presents some notes on adapting the HOWTO for various platforms. I have not tried any of these, so I can't promise that they work.
Debian (Etch)
VictorJ reports that this HOWTO generally works on Debian Etch, and you can also use some of the OS-provided versions of the necessary software. You should be able to install the packages below with apt-get:
# apt-get install mysql-server
Here is the list of packages you can use:
- mysql-server
- p0f
- tcpflow
- tcllib
- mysqltcl
- tcltls
- tcl8.3
- tclx8.3
For more information, read VictorJ's original blog post.
Ubuntu (Feisty)
VictorJ has gotten the 0.7.0 client running on Ubuntu Feisty, and notes that he used the following OS packages:
- tcl8.4
- tclx8.4
- tk8.4
- iwidgets4
You will also need tcllib, but the package from Feisty is too old. The one from Gutsy will work however. See this updated blog post for details.
For more information, read Victor's original blog post.
- ↑ Bejtlich, Richard, Sguil Installation Guide v0.5.3_05, http://sguil.sourceforge.net/index.php?page=latest_docs
- ↑ Bejtlich, Richard, The Tao of Network Security Monitoring: Beyond Intrusion Detection, Addison-Wesley Professional, 2004
- ↑ Red Hat Enterprise Linux 4: Reference Guide
- ↑ InstantNSM


text:
Leonard Cohen
For six decades, Leonard Cohen revealed his soul to the world through poetry and song—his deep and timeless humanity touching our very core.
Simply brilliant. His music and words will resonate forever.
There are few artists in the realm of popular music who can truly be called poets, in the classical, arts-and-letters sense of the word.
Among them are Bob Dylan, Lou Reed, Joni Mitchell and Phil Ochs. Leonard Cohen heads this elite class.
In fact, Cohen was already an established poet and novelist before he turned his attention to songwriting. His academic training in poetry and literature, and his pursuit of them as livelihood for much of the Fifties and Sixties, gave him an extraordinary advantage over his pop peers when it came to setting language to music. Along with other folk-steeped musical literati, Cohen raised the songwriting bar.
Cohen's recording career spans forty years, commencing with the 1967 release of his debut album, Songs of Leonard Cohen. He was in his early thirties and seven years older than Dylan, and his age set him apart from the young musicians who dominated the rock and folk worlds. Cohen was born and raised in the city of Montreal, a city whose rich history and thriving culture served to train his writer's muse on three fundamental preoccupations: romance, religion and politics. His first musical group, the Buckskin Boys, played traditional music at square dances. He studied poetry at Montreal's McGill University and published his first collection, Let Us Compare Mythologies, as part of the McGill Poetry Series. His favorite literary figures included the Spanish poet Federico Garcia Lorca, the Canadian poet Irving Layton and Beat Generation figurehead Jack Kerouac.
In 1958 Cohen lived in New York, where he briefly attended Columbia University. He received a grant for his writing that allowed him to travel the world and make the Greek island of Hydra his on-and-off home for a fertile seven-year period. Cohen relocated to the States in 1966 and tried his hand at songwriting, largely as a reaction to having experienced the starving lot of the poet and novelist. By then he had published four books of poetry and two novels (including the celebrated Beautiful Losers). "But I found it was very difficult to pay my grocery bill," Cohen said in 1971. "I've got beautiful reviews for all my books, and I'm very well thought of in the tiny circles that know me, but...I'm really starving."
Beyond the promise of better income, his entrée into the music world greatly increased the audience for his poetry. Cohen has always been adamant about the power of words to change individual lives and even entire societies for the better. "I always feel that the world was created through words, through speech in our tradition, and I've always seen the enormous light in charged speech," Cohen told interviewer Robert Sward. "That's what I've tried to get to [and] that is where I squarely stand."
Cohen found an early supporter and sponsor in Judy Collins, who introduced his songs to the world via her recordings of "Suzanne" (still his best-known song) and "Dress Rehearsal Rag" on her 1966 album In My Life. Legendary A&R man John Hammond signed Cohen to Columbia Records, and his first three albums for the label—Songs of Leonard Cohen (1967), Songs from a Room (1969) and Songs of Love and Hate (1971)—represent the fruitful first phase in an episodic recording career. The hallmarks of Cohen's style were his plainspoken vocals, spare arrangements, deep but accessible lyrics and an abiding preoccupation with the feminine mystique. Cohen's tightly constructed verses served the rhyming and meter demands of pop-song form without sacrificing the higher ends of poetry.
As a songwriter Cohen seemed somewhat less comfortable in the Seventies than he had in the Sixties, recording only four albums of new material—Songs of Love and Hate (1971), New Skin for the Old Ceremony (1974), Death of a Ladies' Man (1977) and Recent Songs (1979)—in that decade. The first and last of these were marked by strong songwriting and sympathetic production, whereas Death of a Ladies' Man was marked by difficulties with producer Phil Spector.
Cohen's output was lesser still in the Eighties, but the pair of albums he did release—Various Positions (1984) and I'm Your Man (1988)—are indisputable classics. The first of these found Cohen writing about spirituality; one of its songs ("Hallelujah") is among his best-loved and most-recorded, having been covered by Jeff Buckley, Rufus Wainwright and Allison Krauss. The release of Various Positions was accompanied by the publication of Book of Mercy, a self-described "book of prayer." I'm Your Man was arguably Cohen's greatest set of songs since his 1967 debut, containing such classics as "Tower of Song," "Everybody Knows" and "First We Take Manhattan." In 1992 some of rock's most respected acts, including R.E.M., the Pixies and Nick Cave, contributed to the Leonard Cohen tribute album I'm Your Fan. Another Cohen tribute album, Tower of Song: The Songs of Leonard Cohen (1995), included cover versions from more mainstream artists, including Don Henley, Billy Joel and Elton John.
Cohen's most disenchanted and apocalyptic work, The Future, appeared in 1992. In the title track, he sang, "Get ready for the future, it is murder." Not surprisingly, Cohen retreated to a mountaintop monastery in Southern California for five years, during which he studied with and served his Zen master, Joshu Sasaki-Roshi. "It was one of the many attempts I've made in the past thirty or forty years to address acute clinical depression," he acknowledged in a 2001 interview. That year, he released Ten New Songs, his first studio album in nearly a decade. He has since issued Dear Heather (2004) and produced Blue Alert (2006), an album by backup singer Anjani. Between their releases came the documentary I'm Your Man (2005), which featured live performances of Cohen's songs from U2, Beth Orton and others.
On his ties to Columbia Records, similar in mutual loyalty and longevity to the careers of Bob Dylan and Bruce Springsteen, Cohen told writer William Ruhlmann, "I never sold enough records to make them dependent on my next record or to make them anxious about it. On the other hand, I never lost them any money. [The records] seem to sell themselves in modest quantities with very little money necessary for promotion."
Cohen has earned a better living as a singer-songwriter than he would have as a poet and novelist alone. Yet he has enjoyed the poet's advantage of not having to compromise his dignity by indulging in the often-distasteful rituals of pop celebrity. In other words, he has drawn the best from both worlds, forging a wholly unique and remarkable niche for himself. There's no denying that Cohen's voice has deepened and coarsened over the years, but there's still a marvelous musicality to his phrasing and poetical lilt to his lyrics that attests to an unquenchable spirit.
In his notes for The Essential Leonard Cohen, writer Pico Iyer noted, "The changeless is what he's been about since the beginning…Some of the other great pilgrims of song pass through philosophies and selves as if through the stations of the cross. With Cohen, one feels he knew who he was and where he was going from the beginning, and only digs deeper, deeper, deeper."
Cohen's artistic outlook might best be expressed in his own words with this lyric from "Anthem": On Anthem (1992), he wrote: "There is a crack, a crack in everything / That's how the light gets in." He remarked, "That's the closest thing I could describe to a credo. That idea is one of the fundamental positions behind a lot of the songs."
Inductee: Leonard Cohen (born September 21, 1934, died November 7, 2016)


text:
BIG FLOWER EATER Plays Theater for the New City, Now thru 2/24
In past generations, women had status in Asian societies as shamans, but such mysticism is now frowned on in most modern Asian cultures. Still, the idea of powerful ancient matriarchies is magnetic for many Asian American women who grew up in traditional families. Victoria Linchong is like many Americans of immigrant parents who seek their roots but feel disconnected from their heritage. She was inspired by memories of her Taiwanese grandmother to create "Big Flower Eater," a whimsical collage of folktales, rituals, dance and historical texts. Performed by an ensemble of three Asian-American actresses, the play conjures the untold history of women in Asia through shamanism in three different cultures: Hmong, Taiwanese and Korean. It will be presented by Theater for the New City tonight, February 7 to 24.
In the play, a young Taiwanese-American woman pastes her grandmother's fortunes on her bathroom wall, setting off a host of unearthly activities in her small Lower East Side apartment. The ghost of her eccentric grandmother takes up residence in the ceiling causing a constant leak and attracting the lost soul of an epileptic Hmong girl. The mysterious malfunctions of the bathroom are finally explained with a visit from a Korean-American friend, whose disturbing receptivity to the spirits leads to a revelation regarding the long tradition of shamanism in her now-Christian family. The play culminates in a re-enactment of a Korean shamanistic ritual, with traditional drumming by Vongku Pak. The title is taken from a derogatory Chinese term that literally means big flower eater but colloquially means dreamer or fool.
Linchong drew upon her grandmother's superstitions in creating the piece. She writes, "After my grandmother died, I found a woven pouch, which contained several mysterious pieces of red paper covered with Chinese calligraphy. My mother told me they were fortunes and I surmised that my grandmother had them cast for several members of my family. On the suggestion of my boyfriend at the time, I pasted the fortunes on my bathroom wall, which then began to leak and fluctuate oddly between heat and cold. I joked at the time that my grandmother was unhappy about the location of her fortunes, but the joke stopped being so funny after the entire ceiling came down, ruining all but a few of the fortunes.
"Later, I was inspired by two books on Asian shamanistic beliefs to develop the joke into a play: 'The Spirit Catches You and You Fall Down' by Anne Fadiman, in which an epileptic Hmong girl becomes the center of a struggle between the California medical establishment and her refugee family's traditional beliefs; and 'Comfort Woman' by Nora Okja Keller, about a young girl's troubled relationship with her mother, whose traumatic experience as a comfort woman during the Korean War has exacerbated her preternatural ability as a spiritual medium."
"Big Flower Eater" is conceived and directed by Ms. Linchong, whose family is originally from Taiwan. In addition to Linchong the play is acted by Kira Onodera (Japan) and Katherine Yew (Korea) to percussive accompaniment by Vongku Pak (Korea). Lighting Design is by Dan Winters; video design is by Sergei Krasikov and set design is by Craig Napoliello.
The piece was devised using exercises developed by Complicite and Frantic Assembly, two British theater companies. It was workshopped at Horse Trade Theatre Company in 2011.
Victoria Linchong (director, actor) is a Taiwanese-American theater and film artist. She started her theatrical career at the age of fourteen as an actress in TNC's annual summer Street Theater. Her producing credits include five plays by James Purdy, including "Sun of the Sleepless" (TNC, 1989) with Laurence Fishburne and Sheila Dabney, and the Obie Award winning anti-war event "Stop the Way: a Festival for Peace in the Middle East" (TNC, 1990). More recently, she produced, directed and acted in "Paper Angels" by Genny Lim, which workshopped in New York City and traveled to San Francisco, where it played to capacity crowds outdoors in Chinatown and won Best of the San Francisco Fringe. She is currently in post-production on "Almost Home: Taiwan," a documentary on Taiwan's identity and independence. She studied acting with Sanford Meisner and at the British American Drama Academy at Oxford University in England. She is the Artistic Director of Direct Arts, an intercultural theater and film company. Linchong writes, "I am pleased to return to Theater for the New City, one of the most innovative and courageous theater producers in America. TNC was instrumental to my development as an actress, writer, director and producer. I am indebted to Crystal Field, Mark Marcante and the amazing family of artists at TNC, who gave me my first opportunities and continue to encourage me in my work."
Kira Onodera (actor) is a Japanese-American actor, director and playwright from the Bay Area. She started her career at the San Francisco Shakespeare Festival and the Asian American Theater Company then attended SUNY Purchase. She has performed at The Endinburgh Fringe Festival and the Rattlestick Theater. She most recently directed two original short plays as part of Leviathan Lab's "Migration Nation." Her one-woman show, "The Crease Question," has been performed at the Michael Chekhov Theater Company, Starbucks Salon, Manhattan Theater Source's "Estro-genius" festival, The People's Improv Theater and Three-Legged Dog. (www.kiraonodera.com)
Katherine Yew (actor), born in Seoul, South Korea, has been a New Yorker since the age of four. She studied music and voice technique at Columbia University and Manhattan School of Music. She is a member of La MaMa's Great Jones Repertory Company and Pioneers Go East Co. Internationally, she has performed in Tapei, Rome, Spoleto, and Venice, including the Venice Biennalle. Her voice has been featured in such films as "Dummy," with Oscar-winner Adrien Brody, and the critically acclaimed "Man Push Cart. " Her original music compositions have been used to stage "S16:Luna Nera," a multi-media installation piece on the lives of sulfur miners in Sicily, "The Question of Solitude," a mini-opera based on the James Bond legacy, and "Love Cripple," an original dance piece that premiered at LaMaMa ETC.
Vongku Pak (percussion) is a Korean-born New York City based performing/teaching artist and producer. A master of various Korean traditional folk arts, including poongmul and samulnori, he studied with Korea's National Human Treasure, Hyungsoon Kim and Kibock Kim. He also uses his Western drama training from Brooklyn College, where he is completing his BA in Theater, to bring new facets into his art. Mr. Pak has performed at Lincoln Center Out of Doors Festival, Brooklyn Academy Of Music, Carnegie Hall, the Chihuahua International Festival in Mexico and Istanbul CID-UNESCO. In addition, he has participated in international festivals in 15 European countries, as well as Korea and the Dominican Republic. He has been featured on WPIX11 Morning News and Fox TV's Good Day New York. In addition to performing, he teaches drumming, mask dance. (www.Koreandrum.org)The production will run tonight, February 7 to 24, 2013 at Theater for the New City, 155 First Ave. (corner of E. 10th Street), Thursdays to Saturdays at 8:00, Sundays at 3:00. Tickets are $12. Box office (212) 254-1109, www.theaterforthenewcity.net. CRITICS ARE INVITED on or after FEBRUARY 8.
Pictured: Kira Onodera, Victoria Linchong, Katherine Yew. Photos Credit: Jonathan Slaff.


text:
Price: Regular price £42.73
Dales Gargrave Lilac is suitable for severe domestic and general contract upholstery and curtains. Professional dry clean only.
Composition: 100% Pure New Wool
Pattern Repeat: 23.1cm x 23.5cm
Width: 137cm (54ƒ?�) useable
Price: Per Metre
Meets British Standards
BS EN 1021.1-2.2006 (Cigarette & Match) for domestic upholstery.
BS EN 5867.2 Type B for contract curtains.
BS 5852 Part 2. Crib 5 for contract upholstery.
All fabrics achieve 40,000 rubs on Martindale abrasion


text:
Was excited to read this, given my recent interest in paranoia as a social-media state of mind, but ended up disappointed by this chapter, and may not read the rest of the book. But a few things struck me as worth preserving here for future reference.
The gist of it seems derived from the Deleuze essay on "control societies," though with a dubious emphasis on sexuality as the chief basis of subjectivity. Social technologies implement the control society, which makes freedom less a matter of open-ended possibility (freedom to) and more a matter of safety (freedom from). The attractiveness of the predominance of "freedom from" hinges on generalized paranoia.
The end of the Cold War has not dispelled paranoia but rather spread it everywhere: invisibility and uncertainty—of the enemy, of technology—has invalidated deterrence and moved paranoia from the pathological to the logical. This twinning of control and freedom subverts the promise of freedom, turning it from a force that simultaneously breaks bonds and makes relation possible to the dream of a gated community writ large.The internet medium becomes the field in which these affective shifts can occur.
Is the Internet a tool of freedom or control? Does it enable greater self-control or surveillance?... These questions and their assumptions are not only misguided but also symptomatic of the increasingly normal paranoid response to and of power. This paranoia stems from the reduction of political problems into technological ones—a reduction that blinds us to the ways in which those very technologies operate and fail to operateI bolded the part that seems key. The kind of paranoia social technologies instigate aren't political; they are personal. They don't prompt users to become suspicious of state or corporate power so much as present an illusion of radically decentralized power where all peers are potential enemies, and privacy is the preserve of the elite and the status aspiration of everyone else.
I'm most interested in Chun's suggestion that "the delusion of constant surveillance" is performing certain ideological work; she doesn't say this in the chapter, but this delusion is at once the fantasy of becoming a celebrity, of being worthy of being watched, as it is a paranoid fear. This is reminiscent of Althusser's classic interpellation theory, which holds that we are enjoy being singled out by institutional power (or "ideological state apparatuses") because it individuates us. When the advertisement, says "Hey, you," and we are flattered and impressed with our own importance. Individuation feels like a recognition of our autonomy, but it is a manifestation of the way we are controlled. (I suppose you could trace a lot of that back to Foucault as well.)
Every moment we are afraid for our privacy, we are thrilled by our celebrity. We can fantasize about people following our every move captured in social media, but that is not the point. Most shit we put up is ignored or vanishes from people's consciousnesses. What does matter though is the way the data persists and its context degrades, leaving it available to pop up in search queries and be put to whatever use the social-media companies or the state decide.
Chun argues that "Digital language makes control systems invisible: we no longer experience the visible yet unverifiable gaze but a network of nonvisualizable digital control." I think that sounds right, but I would modify that to speculate that we imagine control as gossipy neighbors spying (which diminishes its threat to a degree and makes it partly appealing), making us overlook how control is systemic and sustained by digital networks' ubiquitous data capture (regardless of whether any human ever reads all of it). The point is not that our privacy is invaded by this or that person; it's that no one is permitted to be private by default. It's a privilege of power.
Not only are we individuated by receiving attention on social media; we are also individuated by giving it. Chun notes that "Even when 'lurking,' you constantly send information. It is impossible to resist subjectivity by doing nothing (as Baudrillard once argued and encouraged) if we jack in or are jacked in." That seems like something we can easily overlook in an effort to use social media to our ends without having it warp our subjectivity.


text:
Established in 1949, Wilfreda Beehive is a South Yorkshire based, family run business that has built its success from a professional and caring attitude towards its customers.
As one of the regions largest bus and coach tour operators, we offer a range of services aimed at holiday makers, local businesses, schools and private hire. Having made major investments in our coach fleet, we're proud to be able to offer exceptionally high levels in both luxury and on board facilities.
Our carefully selected coach holiday destinations will help ensure your travelling experience with us will be as memorable and enjoyable as possible.
And if you add to this the genuine way we care for our customers, it's not surprising that over the years many have become more like familiar friends.
We look forward to travelling with you.


text:
The TMP006 infrared thermopile temperature sensor
Summary: This article explains how to interface the Texas Instruments TMP006 non-contact IR temperature sensor evaluation module (TMP006EVM) to a Linux computer using the Bus Pirate from Dangerous Prototypes. A small Java program has been written which queries the TMP006 registers using the Bus Pirate, calculates the object temperature and outputs to the screen. Some basic theory of operation is explained and a temperature vs time charts from a cooling mug of coffee and the sky at sunset is presented.
Texas Instruments (TI) recently announced the TMP006, infrared thermopile temperature sensor – ideal for non-contact temperature measurements in the range -40°C to +125°C. The sensor costs just $1.50 in quantity. As with most TI parts, an evaluation kit (TMP006EVM) is available, but at the significantly higher price of $50.
- a TMP006 sensor mounted on a PCB module with a 10 pin header for I2C lines and power
- a SM-USB-DIG: a general purpose USB to I2C/SPI interface which TI use for other evaluation modules also.
The kit also comes with a USB memory stick with the evaluation software, plastic protective case/cover for the SM-USB-DIG and TMP006 module, a USB extension cable, and 30cm ribbon cable suitable for separating the SM-USB-DIG and TMP006 module.
The supplied software is based on National Instruments LabView and is Windows only. As one would expect from TI, it's easy to install (although it's over 100MB in size!), looks good and works well.
But I use Linux.
My first idea was to write a Linux driver for the SM-USB-DIG. This sub-project has advanced quite a bit, and thanks to a helpful post by a TI employee the protocol has been decoded.... but it isn't returning reliable data just yet.
To expedite matters, I have set the SM-USB-DIG aside for the moment, and turned to the handy Bus Pirate instead.
The TMP006 communicates with the world using I2C/SMBus. Four pins from the TMP006EVM module header (H1) need to be connected:
- H1 Pin 1: I2C SCL connects to the Bus Pirate CLK
- H1 pin 3: I2C SDA connects to the Bus Pirate MOSI
- H1 pin 6: Vcc (3.3V) connects to the Bus Pirate 3.3V
- H1 pin 8: Gnd connects to the Bus Pirate GND.
- Register 0x00: 16 bit signed voltage output from the thermopile (read only)
- Register 0x01: 14 bit die temperature sensor (read only)
- Register 0x02: configuration (read/write)
- Register 0xFE: manufacturer ID (read only, always 0x5449)
- Register 0xFF: device ID (read only, always 0x0060)
The object temperature is a function of the die temperature and the thermopile voltage output. It's not a simple function – some math is involved which is documented in the TMP006 Users Guide, page 10.
To test, connect to the Bus Pirate, enter I2C mode, select 100kHz speed (although slower speeds will be fine too), apply power to the 3.3V line ('W' command) and enter the following command:
[0x80 0xFE [0x81 r r]
All going well the following response should be received:
I2C> [0x80 0xfe [0x81 r r]
WRITE: 0x80 ACK
WRITE: 0xFE ACK
WRITE: 0x81 ACK
READ: 0x54
READ: ACK 0x49
This command will read register 0xFE (the manufacturer code) and should return 0x5449.
The normal Bus Pirate interface is written with human interaction through a terminal emulator in mind. Which is great for debugging stuff, but not so handy if a computer program is to be controlling the Bus Pirate. Fortunately, for direct computer control, a binary mode is also available.
I wrote this Java program which uses the Bus Pirate's binary I2C mode to continuously query the TMP006 die temperature and thermopile voltage registers and calculate the temperature of the object in front of the sensor. The RXTX Java IO library is required (available as the librxtx-java package in Ubuntu). [I can re-write this for Python or C. Leave a comment at the end of the post if you're interested in seeing this implemented in another language].
Compiling and running the Java program:
javac TMP006.java
java TMP006 /dev/ttyUSB4 > tmp006.dat
Replace /dev/ttyUSB4 with what ever device the Bus Pirate is connected to. If all goes well you should see the data that looks like this in tmp006.dat (use tail -f tmp006.datto view the log file in real time.
1309198469685 65421 2956 23.09375 24.638878222595167
1309198471555 65422 2956 23.09375 24.66207367078897
1309198473401 65423 2956 23.09375 24.68526379750324
1309198475244 65420 2956 23.09375 24.61567745003481
The columns are:
- Time stamp (milliseconds)
- 16 bit value from register 0x00
- 16 bit value from register 0x01
- Tdie (degrees C)
- Tobj (degrees C)
This gnuplot command will generate a nice chart from the data:
plot 'tmp006.dat' using 1:5 title 'Tobj (C)', \
'tmp006.dat' using 1:4 title 'Tdie (C)'
Theory of operationEvery object emits a characteristic electromagnetic radiation called "black body radiation". The spectrum depends (among other things) on the object's temperature. This is the phenomenon that causes 'red hot' objects to glow a dull red and 'white hot' objects to glow bright yellow/white. Objects at human temperatures also glow, but in the far infrared part of the spectrum which is not visible to the human eye.
The above chart shows the black body radiation spectrum for melting ice (blue), human skin temperature (red) and a typical mug of coffee (green). The spectrum curves are derived using Plank's Law. Also shown is the TMP006's area of sensitivity (4µm to 8µm [1][2]) and the location of the visible part of the electromagnetic spectrum.
The TMP006 measures the intensity of IR radiation in the 4µm to 8µm region of the spectrum using the Seebeck effect. The measuring circuit built into the the chip/sensor converts the intensity of incident radiation into a voltage which is reported back to the application. Using this voltage, and the temperature of the sensor itself a good estimate of the temperature in front of the sensor can be calculated. The necessary equations are detailed in the TMP006 Users Guide, page 10.
Two things to note. The sensors field of view is a solid angle extending 30 degrees from the normal. Beyond that the sensitivity falls off sharply. Also it is assumed that the emissivity of the target object is reasonably high (> 0.7). Objects such as wood, skin, water and generally anything that's not very white or shiny has a high emissivity and can be measured this way. To get a good reading on shiny metal surfaces that have very low emissivities, it's recommended to cover the area being measured with black tape or paint a patch with black paint.
Some resultsThis is a chart of the measured temperature of a mug of coffee left cooling. There is approx one temperature sample taken every second. As one would expect, this is a classic Newtons Law of Cooling curve.
This next chart is a temperature vs time chart of the sensor looking up at a cloudless sky (a rare day in the west of Ireland!). I was a little surprised by the results: I expected to see colder temperatures. My other IR thermometers report temperatures well below 0°C when pointing at the sky (away from the sun). Some buildings were in the sensor's field of view which might explain the higher than expected temperatures.
ConclusionThe TMP006 looks like a useful sensor. Looking at TI's promotional material for it, it would seem that they have the mobile devices market in mind. Being able make an instant temperature measurement would certainly be a useful feature for high end smart phones. Also it has a digital interface removing the need for analog signal conditioning and ADC, thus simplifying design and reducing component count.
The volume price of just $1.50 seems very reasonable. Unfortunately the tiny 1.6mm square WCSP (Wafer level Chip Scale Package) and the stringent PCB layout guidelines [3] make this device difficult to use unless you have access to a advanced surface mount soldering workshop. Hopefully this sensor will be available on a breakout board in the near future.
Footnotes and references[1] TMP006 Users Guide (SBOU107), page 2.
[2] Discussion on TMP006 at TI forums
[3] TMP006 Users Guide (SBOU107), Layout Guidelines, page 6.
Diagram on principles of operation taken from TI promotional material.


text:
|2011-12-17, 21:12
|Link #1962
Wielder of the Bracelet
Eh I dunno this still sounds like a remake to me, I mean a remake is more then just re-doing the original with prettier graphics. Rebuild is a pretty weak comparison because that's completely different. I also personally think this is better then the original, a lot of the complaints so far are just sorta "Weak" in my mind. That's not to say there isn't one or two Valid Points, but eh it just feels like your holding it up to some impossible standard, and while the original was great I'm not sure it's quite as amazing as your making it out to be.
Also we only have two out of 6 Routes cleared, and your comparing these two routes to the entire complete storyline of the original which isn't really fair here, we still have quite a bit of plot left to see where things go.
|2011-12-17, 21:16
|Link #1963
Traveler of Infinity
Join Date: Mar 2009
Location: Japan
|visual novel
|Thread Tools