Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2013-08-19 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
NMAP 6.40 Released (www.nmap.org), Release Notes at www.nmap.org/changelog.html
ISC StormCast for Tuesday, August 20th 2013 http://isc.sans.edu/podcastdetail.html?id=3488

ZMAP 1.02 released

Published: 2013-08-19
Last Updated: 2013-08-19 14:47:10 UTC
by Rob VandenBrink (Version: 1)
0 comment(s)

The folks at ZMAP have released version 1.02 of their scanning tool ( https://zmap.io/ )

ZMAP's claim to fame is it's speed - the developers indicate that with a 1Gbps uplink, the entire IPv4 space can be scanned in roughly 45 minutes (yes, that's minutes) with non-specialized hardware, which is getting close to 100% efficiency on a 1Gbps NIC.   Note that even now, you should design your hardware carefully to get sustained 1Gbps transfer rates.  While not many of us have true 1Gbps into our basements, lots of us have that at work these days. 

With this tool out, look for more "internet census" type studies to pop up.  Folks, be careful who you scan - strictly speaking, you can get yoursefl in a lot of trouble probing the wrong folks, especially if you are in their jurisdiction!

It's also worth mentioning that running a tool like this can easily DOS the link you are scanning from.  Taking 100% of your employer's bandwidth for scanning is good for a whole 'nother type of discussion.

It's safest to get a signed statement of work, and run this on a test subnet before using it "for real".  If anyone has used ZMAP in a production scan, please use our comment form to let us know how you found the tool

Scan safe everyone!

===============
Rob VandenBrink
Metafore

0 comment(s)

Business Risks and Cyber Attacks

Published: 2013-08-19
Last Updated: 2013-08-19 12:55:13 UTC
by Guy Bruneau (Version: 1)
1 comment(s)

According to LLoyd's (An insurance market company) latest survey, it ranks Cyber Risk as the number three overall risks amongst 500 senior business leaders it surveyed. "It appears that businesses across the world have encountered a partial reality check about the degree of cyber risk. Their sense of preparedness to deal with the level of risk, however, still appears remarkably complacent."[1]

Last year, several well know companies experienced significant breaches such as Yahoo, Verison, Twitter, Google where thousands of users were required to change their passwords. Some of the changes implemented since then include two-factor authentication by Google and Apple to name a few.

Do you think that business executives are more aware now of the reality of cyber attacks?

[1] http://www.lloyds.com/news-and-insight/risk-insight/lloyds-risk-index/top-five-risks
[2] https://isc.sans.edu/diary/Twitter+Confirms+Compromise+of+Approximately+250%2C000+Users/15064
[3] https://isc.sans.edu/diary/Verizon+Data+Breach+report+has+been+released/15665
[4] https://isc.sans.edu/diary/Apple+ID+Two-step+Verification+Now+Available+in+some+Countries/15463

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Keywords: Cyber Attacks Risks
1 comment(s)

Running Snort on ESXi using the Distributed Switch

Published: 2013-08-19
Last Updated: 2013-08-19 09:14:45 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)
This is a guest diary contributed by Basil Alawi

In a previous diary I wrote about running snort on Vmware ESXi[1] . While that setup might be suitable for small setup with one ESXi host, it might be not suitable for larger implementations with multiple VSphere hosts. In this diary I will discuss deploying Snort on larger implementation with SPAN/Mirror ports.

SPAN ports require VMware Distributed Switch (dvSwitch) or Cisco Nexus 1000v. VMware dvSwich is available with VMware VSphere Enterprise Plus while Cisco Nexus 1000v is third party add-on. Both solutions required VSphere Enterprise Plus and VMware vCenter.

Test Lab

The test lab consists of Vmware ESXi 5.1 as host, VMware vCenter 5.1, Kali Linux, Security Onion and Metaspoitable VM. ESXi 5.1 will be the host system and Kali VM will be the attack server, while Metaspoitable will be the target and Security Onion will run the snort instance. (Figure 1).

Figure 1

Figure 1(Test Lab)

Configuring dvSwitch:

 

 The VMware vDS extends the feature set of the VMware Standard Switch, while simplifying network provisioning, monitoring, and management through an abstracted, single distributed switch representation of multiple VMware ESX and ESXi Servers in a VMware data center[2].

To configure the SPAN ports on VMware dvSwitch :

1.     Log in to the vSphere Client and select the Networking inventory view

2.     Right-click the vSphere distributed switch in the inventory pane, and select Edit Settings (Figure 2)

Figure 2

Figure 2

                                    3- On the Port Mirroring tab, click Add

Figure 3

4-Enter a Name and Description for the port mirroring session

Figure 4

5- Make sure that the Allow normal IO on destination ports checkbox is deselected If you do not select this option, mirrored traffic will be allowed out on destination ports, but no traffic will

Be allowed in.

6-Click Next

7- Choose whether to use this source for Ingress or Egress traffic, or choose Ingress/Egress to use this source for both types of traffic.

8-Type the source port IDs and click >> to add the sources to the port mirroring session.

9- Click Next.

Figure 5

 

10- Choose the Destination type port ID.

 

11- Type the destination port IDs and click >> to add the destination to the port mirroring session

12- Click Next

13- Verify that the listed name and settings for the new port mirroring session are correct

14- Click Enable this port mirroring session to start the port mirroring session immediately.

15- Click Finish.

For this lab the traffic going to metaspoitable VM will be mirror to eth1 on Security Onion Server.  

Running sniffer on eth1 can confirm that the mirror configuration is working as it should be:

tcpdump –nni eth1

 

Figure 7

 

 

 

 

Testing Snort

The first test is fingerprinting the metaspoitable vm with nmap and snort detected this attempted successfully.

nmap –O 192.168.207.20 

figure 8

The second test is trying to brute forcing metaspoitable root password using hydra

hydra –l root –P passwords.txt 192.168.207.20 ftp

               Figure 9

The third attempt was using metasploit to exploit metaspoitable:

Figure 10


[1] https://isc.sans.edu/diary/Running+Snort+on+VMWare+ESXi/15899

[2] http://www.vmware.com/files/pdf/technology/cisco_vmware_virtualizing_the_datacenter.pdf

 

5 comment(s)
Diary Archives