From pmui at groundworkopensource.com Tue Sep 2 10:49:35 2008 From: pmui at groundworkopensource.com (Peter Mui) Date: Tue, 2 Sep 2008 10:49:35 -0700 Subject: BayLISA Monitoring SIG: Weds, Sept 10 2008, 7PM Message-ID: (Hi: You're invited to the BayLISA Monitoring SIG, Weds, Sept 10 2008, 7PM. See the meeting announcement pasted below: feel free to post it and/or forward it along to anyone else who might be interested. Many thanks, and hope to see you there! -Peter) ================================================= Monitoring SIG XVII: IPV6 Era of Transformation Stephan Baur, Sr. Director, Enterprise Architecture & Technology, Cisco Roger R?ttimann, Director Software Development, GroundWork Open Source Inc. In the near future the internet will run out of available addresses. To fix this problem a new addressing scheme named IPV6 was introduced to supplement the current IPV4 standard. With the benefits of having more addresses available comes the complexity, cost and risks of converting existing functioning systems to IPV6. Should a System Administrator be concerned about upgrading their network to IPV6? What are the benefits? We'll present a high-level view of the challenges IPv6 presents to systems and network operators. We provide a short review of IPv6, what the network landscape will look like for a long time to come and provide some thoughts what IPv6 means for software, systems and network engineers -- tactically and strategically. What: BayLISA Monitoring SIG XVII: IPV6 Era of Transformation Who: Anyone interested in IT monitoring issues and tools (newbies particularly welcome!) When: Wednesday, Sept 10 2008, 7PM Where: GroundWork Open Source, 139 Townsend St., San Francisco How: 139 Townsend St. is very near AT&T Ballpark. It is one and a half blocks from the CalTrain Depot. Take the MUNI N or T or trolley to 2nd and King (ballpark stop) or take the 30 or 45 bus (among others) crosstown. Free evening street parking can probably be found because the Giants are playing an afternoon game that day (vs. Arizona, 12:35 start) and it should be over by the time the SIG starts. There are several fee-based parking garages around in case of parking difficulty. Cost: Free!! Back to school pizza, carbonated and non-carbonated drinks, and healthy (and questionably healthy) snacks provided by GroundWork. We'll open up the doors at 6:30 or so and start the formal part of the meeting promptly at 7PM. RSVP (not necessary, but helpful): Peter Mui, pmui at groundworkopensource.com, 415-992-4573, www.groundworkopensource.com NOTICE: This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this email or its contents is strictly prohibited.If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.duboff at sun.com Wed Sep 10 03:56:24 2008 From: alan.duboff at sun.com (Alan DuBoff) Date: Wed, 10 Sep 2008 03:56:24 -0700 (PDT) Subject: Stephen Smalley to speak at SVOSUG on 09/25/08 Message-ID: Stephen Smalley of the National Security Association will be speaking this month at the SVOSUG meeting, on Sept. 25th, at the Sun Santa Clara campus, in the room above the auditorium. This is located not far from Montague Expressway and 101. Stephen will talk about Flask and Type Enforcement. This is an excellent opportunity for all of the open source communities to hear and ask any questions about this technology they might have. Stephen doesn't make it out to this coast too often, so I'd like to let folks know ahead of time so they can plan ahead. Flask and Type Enforcement is the technology used in SELinux today, and the same technology being worked on for OpenSolaris, where Stephen is sharing the lead with John Weeks of Sun Fed on the FMAC project. You can find out more about FMAC at the OpenSolaris project page. Sun Fed will be supplying pizza and beverages for this event. Please join us on the evening of Sept. 25th at 7:30pm. You can always find the most current info on my blog, which is located at: http://blogs.sun.com/aland/ -- Alan DuBoff - Solaris x86 IHV/OEM Group From sigje at sigje.org Wed Sep 17 20:51:47 2008 From: sigje at sigje.org (Jennifer Davis) Date: Wed, 17 Sep 2008 20:51:47 -0700 (PDT) Subject: BayLISA Meeting IS ON tomorrow, Thursday Sep 18, 2008 Message-ID: <20080917205021.U61043@slick.sigje.org> The meeting is happening tomorrow. We are going to talk about security and monitoring/forensics. If anyone has any topics they want to bring up, that will be fine too :) This will be an interactive session so come share your experiences. -- Jennifer Davis http://www.baylisa.org - BayLISA events From david at catwhisker.org Fri Sep 19 06:54:39 2008 From: david at catwhisker.org (David Wolfskill) Date: Fri, 19 Sep 2008 06:54:39 -0700 Subject: Speaking of security and intrusion attempts... :-} Message-ID: <20080919135439.GA11991@bunrab.catwhisker.org> Caveat Lector: Although I used to be a sysadmin, that's not what I'm paid to do any more. Nevertheless, I do act in that role for my one networks at home; while there's no plausible way I could think of my home as a "large installation" for a sysadmin, there are a few things here & there that might be of interest. Also (Caveat continued), my "exposed" machines all run FreeBSD. While some approaches I use may well be usable (possibly with appropriate modifications) in oher environments, those other environments are not my focus, and I don't pretend to know how to go about it. Ref. Jennifer's comments last night about checking logs: given the relatively low profile -- and relatively low exposure -- I don't use real time IDS. I do, however, try to examine the logs every morning (for the previous day), checking for specific things: * /var/log/access.log Among other things, sshd logs here for each attempt to login via ssh, successful or otherwise. * /var/log/security If ipfw(8) is configured to log anything as a result of seeing traffic, this is where it's logged. Now, I have things set up so that sshd on one of my internal machines on the "trusted" network may be reached from machines on other networks (including the "guest" network at home). Authentication is only via SSHv2 public key. I also run ipfw(8) (a packet filter that has been part of FreeBSD for over a decade) on the "firewall" machine (a triply-homed FreeBSD box). Among the things I have it configured to do: * Log every attempt to initiate an SSH connection. * Use ipfw(8) "tables" (accessed internally in a way very similar to routing tables) to block certain types of traffic. In particular: * Table 1: there are a couple of ipfw(8) rules for this one. One blocks all incoming traffic from any netblock cited in table 1. The other blocks all outgoing traffic to any netblock cited in table 1. * Table 2: An ipfw(8) rule blocks all incoming 22/tcp traffic from any netblock cited in table 2. * Table 3: An ipfw(8) rule blocks all incoming 80/tcp and 443/tcp traffic from any netblock cited in table 3. (I've been thinking of setting up a table of netblocks that would be subject to DUMMYNET "traffic shaping" -- this would provide a somewhat slow, lossy connection for certain especially "deserving" netblocks. I may also create a table to block 25/tcp from certain netblocks, rather than using sendmail(1)'s access database: the ipfw(8) table would certainly be more efficient and less resource-intensive.) So I use a fairly simple shell script in the morning to show me the appropriate log entries from the beginning of yesterday to the present time; a quick scan is usually enough to determine if more attention is warranted. This morning was one of the time that "more attention was warranted." There were well over 1K SSH login attempts from 6 different IP addresses yesterday. For each of the source IP addresses, I checked WHOIS, then sent off a note to the listed contact for the netblock. (I make no attempt to correlate the IP address with a domain, nor to contact whoever is allegedly responsible for the domain.) I have a "boilerplate" template set up, and I make the appropriate changes, then read in the appropirate log entries. The message provides information about what the log entries are showing, as well as specifying the current offset from UTC. The message is also not accusatory: it is a message that I would appreciate receiving, were any of my systems implicated in such activity. The template also includes a Bcc: to myself and a Reply-To: for (which, like postmaster@, bypasses several anti-spam checks). I admit that response to this varies. And I have responses for some of those (non-)responses: * Silence. Most often, there's no response to my notification. That's not entirely a Bad Thing, if the abuse ceases. But if I get no response and the abuse continues, the netblock gets added to Table 1. At that point, the abuse stops -- for my network, at least. Further, if I encounter another netblock for which the contact information is the same as one I've added to Table 1, I add the new netblock to Table 1 as well. Case in point: CHINANET-*. * Auto-response. Thanks; I kinda knew that my message was Very Important to you. Right. I treat this as I do the above "Silence": if the abuse stops; fine. If not, I make it stop. * Semi-canned response. This tends to be from RIPE nets -- a note saying that they've chastised the person(s) responsible for the network in question. Same as Silence. :-} * Thanks. Yeah, sometimes I actually am lucky enough to send one of these to someone who is both clueful and professional enough to appreciate the notification, take constructive action, and thank me for it. That alone nearly makes the exercise worthwhile. And unless I perceive egregious attempts from such netblocks, I won't block them: I have reason to believe that someone is actively trying to do the right thing. * Message non-delivery notification. This could be from any of several reasons: for example, the contact address from WHOIS might be no longer current. (In that case, if I have reason to believe that my message did not get through to anyone -- I will use all salient contacts from WHOIS on the original message -- the netblock is added to Table 1 (on the grounds that no one appears to be "minding the store"). Another reason: Some MTAs are configured to reject mail from what appear to be residential customers' machines (vs. the residential customers going through their ISPs). Those get added to Table 1. So far, I don't recall getting any responses questioning what I reported or denying the attempts. :-} I add a netblock to Table 2 if I see many more log entries from the packet filter for a given source address than I see from sshd(8). I don't know exactly what they're doing except that for whatever reason, sshd(8) isn't logging most of the activity. I don't like it; it makes me nervous. Table 2 tends to make me ... a bit less nervous. I've also cobbled up some scripts & Makefiles to make messing about with these ipfw(8) tables less labor-intensive than it might otherwise be. For example, one of the scripts runs whois(1) against a token and amkes a reasonable attempt to extract the CIDR block specification from it. There's a somewhat-hackish directory structure associated with this: at the top level, there's one directory for each ipfw(8) table. Within each of these, there's a Makefile and there is one subdirectory for each registry; the name for the subdirectory is the same as the argument to (FreeBSD's) whois(1) client (without the leading hyphen) -- e.g., RIPE netblocks will be in the "r" subdirectory; ARIN netblocks in "a"; APNIC in "A", LACNIC in "l"...). Each of these is populated with files; the name of a file is the name of the netblock (except for LACNIC netblocks, as they have "inetnum"s insteadof "netname"s); the content of each file is a list, one per line, of CIDR blocks associated with that token. The Makefile runs the above-mentiond whois-parsing script on any file that is newer than its subdirectory. So I merely need to touch(1) an appropriate filename (twice, if it didn't already exist) and run make(1); that will populate the file with the CIDR blocks and update a file that is a concatenation of all of them for a given table. I have another script that adds lines from specified file(s) to the appropriate table. And I actually maintain this structure both on my home firewall and on my laptop (since the laptop is sometimes exposed to the Internet, after all). To quote Alastor "Mad-Eye" Moody (from the "Harry Potter" books): CONSTANT VIGILANCE! Anyway, that's enough rambling: I need to do other things today. Peace, david -- David H. Wolfskill david at catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From aland at softorchestra.com Mon Sep 22 22:58:49 2008 From: aland at softorchestra.com (Alan DuBoff) Date: Mon, 22 Sep 2008 22:58:49 -0700 (PDT) Subject: Stephen Smalley to speak at SVOSUG on Thur. 09/25/08 Message-ID: [I redirected this message from blw@ to baylisa@, as I thought the latter list better matched the subject matter. -- postmaster@] [*** Jennifer, I can update the page if you want to give me access per our conversation last week] This meeting have moved back to the Mansion due to scheduling conflicts, and if you haven't seen the Mansion before, it's a great place, built in the Arts & Crafts style in 1915. It is one of the historical buildings on the Agnew Campus in Santa Clara. When: Thursday, Sept. 25, 2008 Where: Sun's Santa Clara Campus Mansion (SCA07 just across the road from the Auditorium) What: Security technologies to confine flawed and malicious software Time: 7:30pm-10:00pm You are invited to hear Stephen Smalley, of the US National Security Agency (NSA), speak on security technologies to confine flawed and malicious software. Stephen was instrumental in bringing the Flux Advanced Security Kernel (Flask) and Type Enforcement (TE) technologies to Linux through the SELinux project. Flask is a flexible form of mandatory access control (MAC) that has been gaining popularity since its introduction in SELinux, SEBSD, and SEDarwin. Stephen is now involved as a project lead on the OpenSolaris.org Flexible Mandatory Access Control (FMAC) project that is integrating FLASK and TE into OpenSolaris. Stephen Smalley Bio: Stephen Smalley is a Technical Director in the Defense Computing Research Office of the National Information Assurance Research Laboratory of the NSA. Mr. Smalley received a 2005 Director of National Intelligence (DNI) Fellows award for his technical achievements within the Intelligence Community. Prior to his work on OpenSolaris and SELinux, Mr. Smalley performed research and development in the area of operating system security through the development and analysis on a series of secure research operating systems. Mr. Smalley received his B.S. degree in Computer Science and Mathematics from the Rose-Hulman Institute of Technology. For additional info please see the following URLs: OpenSolaris.org Flexible Mandatory Access Control Project Page: http://opensolaris.org/os/project/fmac/ NSA SELinux Reference: http://www.nsa.gov/selinux/ Map to the Mansion: http://maps.yahoo.com/#mvt=m&lat=37.393386&lon=-121.955218&zoom=16&q1=4070%20George%20Sellon%20Circle%2095054 We may also have some pizza and sodas. I would like to ask that people are careful around the antique mission furniture. It's no problem for us to eat in the mansion, but we try to keep the pizza boxes in the kitchen, so that the steam and oil doesn't discolor the furniture.;-) -- David H. Wolfskill david at catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key.