| It appears that we have sufficient interest in a Linux Security Lab meeting. Further discussion involves: 1) General Structure: This is a lab - this means that it follows a format something similar to the Install Fest. Free form group interaction, content experts, setups by all, testing by all interested and fun! It's not going to be a slide demonstration. We are actually going to do good/bad security things with Linux in order to learn. 2) Facilities: We need power and network? White Board would be suite? Ideas? 2) Security, Disclaimers, etc. We will be using live distro's, therefore we can be assured of some amount of safety using our Notebooks or other computers. We might print up a sign that announces this as a PLUG trusted training session, therefore misuse or any aggressive exploits to any but targeted equipment is unethical and will meet with aggressive retaliation. Anyone joining the lab can be asked to sign a roster at the door that clearly states that the information provided can and will send the participants to jail, should they attempt to reproduce without signed authorization or contract/employment relationship. 3) Scope: Brief overview of OSI Layered "Bottom Up" Security iptables snort nmap ssh keys/sshd nessus/nc Discussion including buffer overflow/ExecShield, binary CRC checks, basic ip spoofing and tunneling. NOTES: We can't get into IPv6 GRE multicast tunneling, DNS tunneling or advanced networking, but we will cover some protections that will stop all but the likes of Crispen Cowen. These concepts will NOT serve the Desktop user and Systems Administrator any if X is left running with a Firefox URI or XSS ssl tunnel exploit (clicking on a link or accepting a PDF) [all we would see in the way of logged packets would be the XSS exploited at google.com or another website triangulated via proxy (the evildoers source address are hidden on the other side of the XSS web site with no way to access their logs)]. A complete "top down" Application web security review can take years [ & study content should change with the advent of PCI compliance (required in 2008 for all companies accepting credit cards) because of the layer 7 Application switch solutions that keep big online shops from being required to do quarterly code reviews)]. We might best refer interest parties for that related discussion and lab to a night at the local OWASP meeting? > On Wed, Jul 2, 2008 at 2:55 PM, Lisa Kachold <l_iesa@yahoo.com> |