Classes/Logs/2012/September/17/00-01

23:58 <@rorschach> here's the class schedule and signup roster for this week
23:58 <@rorschach> www.blackhatlibrary.net/Current:Classes
23:58 <@rorschach> if you have a topic idea signup
23:59 <@rorschach> if you would like to do something but don't know what to talk about, pm me and I might be able to help
00:00 <@rorschach> if you have something you WANT someone to talk about come talk to us and we might be able to work 
                   something out
00:00 < lighthouse> if we were already signed up for the previous emails/classes do we have to sign up again at that URL 
                    for the next classes?
00:00 <@rorschach> and of course, tell all of your friends to come so we can share the knowledge
00:00 <@rorschach> :)
00:01 <@rorschach> no, these are open classes
00:01 <@rorschach> the signups are for scheduling a class
00:02 <@rorschach> speaker signups

00:16 <~hatter> ok guys here we go 
00:17 <~hatter> We're gonna do a little timeslot about security infrastructure and related components
00:19 <~hatter> Essentially security infrastructure at an internet security level is defined as intrusion detection 
                systems and intrusion prevention systems on the host and network layers (and also sometimes the OS and 
                application layers) which plug into a security infrastructure management system
00:19 <~hatter> This security infrastructure management system is typically accessed by the security personell at any 
                given NOC (network operations center) 
00:21 <~hatter> Open-Source Network intrusion detection & prevention systems include snort and sancp
00:21 <~hatter> there are also a variety of other tools
00:22 <~hatter> Like portsentry, shadow, tripwire, cisco ips/ids (stay away from those)
00:22 <~hatter> (ciscos, I mean)
00:23 <~hatter> Sometimes a security infrastructure management system is also integrated with filesystem integrity check 
                daemons and other standard services (smtp/pop/ftp/web/authentication/other common services)
00:25 <~hatter> Host-based intrusion detection and prevention systems include samhain and ossec - amongst some other more 
                specific service and application-level engines
00:25 <~hatter> like naxsi, suhoshin, and apache's mod_security
00:25 <~hatter> Firewalls are usually utilized by prevention systems and/or infrastructure management systems
00:26 <~hatter> these may consist of iptables, nufw, pf, ipchains, etc all the way to sonicguard, bigip, or a variety of 
                other appliances
00:27 <~hatter> Without proper firewalls, a security administrator may be unable to thoroughly mitigate an attack without 
                experiencing downtime.
00:27 <~hatter> Systemic failures can happen if appropriate infrastructures for logging all of these infrastructure 
                components are not in place during an incident
00:27 <~hatter> (or before one)
00:29 <~hatter> At the operating system level, other measures and enforcement protocols can be used to ensure integrity 
                (pam, auditd, grsec, pax, selinux)
00:30 <~hatter> Some good/open source sim's I'd recommend are opensims, ossim, and prelude siem.  
00:30 <~hatter> Prelude's frontend (Prewikka) is written in python, its kinda a pain to get running, but awesome once it 
                works
00:35 <~hatter> ok so you have a few different options when mitigating network based attacks
00:35 <~hatter> you can allow the traffic ( bad idea ) 
00:35 <~hatter> you can block/drop the draffic
00:35 <~hatter> or you can reflect the traffic
00:36 <~hatter> Blocking or reflecting are always the best solutions given different circumstances
00:37 <~hatter> for example, during a ddos, if you are sure a domain is the target and you have the ip address of the 
                command and control server, it would not even be remotely illegal for you to update the dns record to 
                point to the C&C server's ip address.  This would also cook the botnet, allowing you after a few moments 
                to update the dns record back to its original value, restoring uptime to the site
00:39 <~hatter> 1s
00:39 <~hatter> fixin somethin
00:40 <~hatter> fixt
00:41 <~hatter> In other cases when you know less information, simply dropping traffic is the appropriate response to a 
                ddos.
00:41 <~hatter> When you block the traffic using icmp unreachable or tcp reset messages, this actually makes your 
                appliances send more data, increasing the effectiveness of the denial of service attack.
00:42 <~hatter> likewise, it is advisable to chmod 0 affected directories, chattr +ia, and chown to root when a web 
                application has been compromised, unless the flaw is known.
00:42 <~hatter> traffic can be analyzed in realtime using a variety of sniffers
00:43 <~hatter> A lot of people just use tcpdump
00:43 <~hatter> Its a relatively standard command line tool
00:43 <~hatter> It does not have any attack functionality though, while things like ettercap aren't quite as good for 
                inspection but are great for attacks.
00:45 <~hatter> Sancp will make packet & pcap recordings
00:45 <~hatter> that you can inspect later using tcpdump or other pcap utilities
00:45 <~hatter> you can also just use hexdump
00:45 <~hatter> if you're into that sort of thing :)
00:48 <~hatter> there are multiple types of analysis employed by security infrastructure,
00:48 <~hatter> lets focus on integrity checking, signature based analysis, and behavior based analysis for the moment
00:49 <~hatter> Whenever you have the ability to do so, integrity checks should be done using multiple hashing 
                algorithms.  Additionally, third party systems may monitor the databases of the integrity checksums to 
                determine their integrity as well
00:50 <~hatter> The reasoning behind using multiple hashing algorithms for checksums applies due to hash collision attacks
00:50 <~hatter> It is possible to perform a collision attack using appended data against nearly any single checksum 
                algorithm
00:50 <~hatter> however because of the math involved, using multiple hashing alorithms that differ in origin may prove 
                impossible to collide at the same time
00:51 <~hatter> signature based analysis typically uses regular expressions or similar definitions for static file and/or 
                memory analysis at runtime
00:51 <~hatter> This is typically a poor solution as blacklisting will nearly always fail
00:52 <~hatter> (Perhaps a more bayesian style filtering approach is needed on a more general scale.)
00:52 <~hatter> Behaviour based analysis is a good solution however its still very young, and the technology needs 
                further growth before it can be adopted on a wider scale
00:54 <~hatter> Additionally, some behavior based intrusion detection systems are prone to false positives from licensing 
                engines, due to the polymorphic nature of modern software protections and their similarity to malware.
00:54 <~hatter> This can cause certain systemic failures if not properly integrated (part of the youth of the technology)
00:56 <~hatter> disaster recovery systems and monitoring systems may also be parts of security infrastructures
00:56 <~hatter> this includes backups, systems like nagios which check for service uptime, and database replication 
                systems for hotswitch configurations
00:57 <~hatter> Disk and filesystem cryptography also applies to security infrastructure
00:57 <~hatter> in some cases, they are legally required for various levels of legal business compliance in the united 
                states and other nations
00:58 <~hatter> This includes things like HIPAA for medical records and PCI for stored credit card data
00:58 <~hatter> This also includes stuff like application level hashing and salting for authentication
00:59 <~hatter> That kind of thing can also be required for various levels of legal compliance
00:59 < corvus> Isnt it true that adequate Disaster recovery implementations are often the largest point of failure in a 
                security policy?
00:59 <~hatter> corvus: usually either that or an audit/review process for production systems to begin with
00:59 <~hatter> but yes
01:00 <~hatter> Its usually one of those two things
01:00 < lighthouse> could you possibly give an example or two of a simple setup for a home network and maybe one for a 
                    small - medium sized business as far as what security hardware and software would be on each?
01:00 <~hatter> that is responsible for systemic failure
01:00 <~hatter> I'll go ahead and give it a go
01:00 < lighthouse> also, I have tried to setup snort for windows but to no avail, is there any way to use snort to 
                    protect a primarily windows network ?
01:01 <~hatter> Snort is a network layer inspection system
01:01 <~hatter> that means that you can install it on a single linux host
01:01 <~hatter> that also acts as a router
01:01 <~hatter> for the rest of the network
01:01 <~hatter> Say you had a switch (not a hub)
01:01 <~hatter> You'd set up your linux machine with snort 
01:01 <~hatter> as a router, then plug it into the switch
01:01 <~hatter> as well as the modem
01:01 <~hatter> the switch would then provide access to the rest of the network
01:01 <~hatter> via the router/NIDS
01:01 < lighthouse> so I could use one computer with a linux install with snort that acts as a router before the actual 
                    router?
01:01 <~hatter> you could use that on either a home network or a business network
01:02 <~hatter> yep
01:02 <~hatter> you sure could do that
01:02 < lighthouse> could that be done with saturn (a server I have with a custom hardened version of linux on it)?
01:02 <~hatter> probably.
01:03 < lighthouse> but easier to go with a less complicated distro?
01:03 <~hatter> could really be done with nearly any system
01:03 <~hatter> you don't need a super power house for it
01:03 <~hatter> however 
01:03 <~hatter> it's good to have that system locked down
01:03 <~hatter> remember, it's going to be the gateway
01:03 <~hatter> so
01:03 <~hatter> if it gets hit by something, your whole network is at risk
01:03 <~hatter> so you might want to set up the modem -> router -> snort machine -> switch -> network
01:03 <+foo> Security Onion has a lot of these tools built in: https://code.google.com/p/security-onion/
01:04 <~hatter> ^
01:04 <+foo> it's good stuff

01:07 < lighthouse> how much security needs to be implemented to eliminate 90-95% of all most threats?
01:07 <~hatter> lol you mean
01:07 <~hatter> how much shit do you need to turn off
01:08 <+foo> ^
01:08 <~hatter> not how much stuff do you need to add
01:08 <~hatter> xD
01:08 < Dwaan> i think im gonna have a play with snort now
01:08 < lighthouse> lol
01:08 <+foo> lighthouse: most issues are caused by enabled but unused functionality
01:08 <+foo> lighthouse: for example, take office workstations, most are allowed full access to the internal network
01:09 <+foo> aside from p2p functionality, there is no reason workstations need to talk to each other
01:09 < lighthouse> what I am saying is, won't most threats / malware be thwarted by a few levels of security? I mean, 
                    yes its best to be 100% secure (if thats even possible) but mnost dont have to worry about being 
                    hacked by the alphabet boys
01:09 <+foo> yet, as demonstrated by extensive malware propagation of many environments, workstations are allowed to not 
             only talk to each other but also attack each other unchecked
01:09 <+foo> lighthouse: 100% "security" is not possible
01:10 < lighthouse> if the SNA (scrambled for obvious reasons) wants to see what you are doing, more then likely they 
                    will be able to, no?
01:10 < Dwaan> foo: YES
01:10 < Dwaan> i try to tell people this
01:10 < Dwaan> so many people have the attitued like
01:10 < lighthouse> unless you have a bunker with electromagnetic shielded walls, they can see what you are doing
01:10 < Dwaan> 'meh, noone gonna do anything malicious on our network'
01:10 <+foo> https://www.sans.org/critical-security-controls/ here are the things to do to get "mostly secure"
01:10 < Dwaan> why bother
01:10 < Dwaan> etc
01:10 <+foo> as in, "must be this tall to ride"
01:11 <+foo> Dwaan: most organizations have no clue what their workstations do, what the traffic flow is, what is on the 
             network let alone what is installed on system X
01:11 < lighthouse> an IDS dsoes not actually prevent attacks, correct? just the IPS?
01:11 <+foo> Intrusion Detection System
01:12 <+foo> detects attacks
01:12 < Dwaan> foo: exactly
01:12 < Dwaan> lazy
01:12 <+foo> IPS, Intrusion Prevention Systems, are typically IDS + Active Response
01:12 < Dwaan> wow
01:12 < Dwaan> security onion
01:12 < Dwaan> looks nice
01:12 <+foo> Dwaan: lazy, organic growth, lack of administrative processes
01:13 <+foo> it's the defense-in-depth philosophy, at your external perimeter (outside of the FW) it makes sense to have 
             an IDS
01:13 <+foo> inside the FW, it makes sense to have an IPS
01:14 <+foo> but your IDS outside should do more than just look for attacks, it should gather network statistics and 
             information about traffic flow
01:14 <+foo> your internal IPS would take care of the "attacks" that your router and fw were unable to handle
01:14 <+foo> zzzzzZZZZzzz[m3n]: you about ready to jump in?
01:15 <+foo> lighthouse: think about a castle and the various layers of defense
01:15 <+foo> you have your castle wall
01:15 <+foo> with archers and buckets of boiling oil and firebombs
01:15 <+foo> you have a moat and a big gate
01:15 <+foo> but you also have scouts out looking for attackers
01:16 <@zzzzzZZZZzzz[m3n]> Just a moment, yes
01:16 <+foo> inside the castle walls you have segmentation of areas to limit attackers
01:16 < lighthouse> teachers: analogys = awesome
01:16 <+foo> but open areas that trusted parties can get into
01:17 <+foo> each of these areas have guards and access controls