Troubleshooting Tip

I was asked to help with a webserver whose web pages could not be browsed/accessed from outside.
The first thing i did was to check for network connectivity. If i could ping the server and it responded, then it means there is a valid network connection between the web server and my PC.

c:\>ping 202.91.xxx.xx5

Pinging 202.91.xxx.xx5 with 32 bytes of data:
Reply from 202.91.xxx.xx5: bytes=32 time=44ms TTL=120
Reply from 202.91.xxx.xx5: bytes=32 time=46ms TTL=120
Reply from 202.91.xxx.xx5: bytes=32 time=49ms TTL=120
Reply from 202.91.xxx.xx5: bytes=32 time=46ms TTL=120

The next step was to see if I could browse the site from INSIDE the web server. If i could not browse from INSIDE the webserver, then it means that there was an error in provisioning the website in IIS. For this test, i simply fired up the Internet explorer and entered the UR L (Uniform resource locator). The URL format is something like this: http://www.google.com

If you dont see any error messages, but instead, see the website pop up, then the next logical step would be to take a look at the firewall settings of your windows web server.

On a Windows 2003 or older machine, you go to the /control panel/network connections and select the network card. On the next popup window, click on Properties

You will then see the Local Area Connections Properties. Click [Advance] to show the Windows Firewall settings.

Click [Advance] a second time to show the Network Connections Settings:

From here, click on [Settings] to show the configurable options:

Make sure that the items highlighted in yellow are CLICKED (enabled).

Reading Notes on Communications and Trust in Global Virtual Teams

Can we trust people who we don’t know, have never seen or met, and live in another part of the world altogether? Julie, Vemmy and Gekling would probably say no, since they wrote about Charles Handy’s paper. They would echo John Naisbitt’s ‘High Trust needs High Touch’ mantra – the more virtual an organization, the higher the need to meet in person.

However, Jarvenpaa and Leidner would beg to differ. It seems they found an ‘exception’- the formation of ‘swift trust’ – however fragile and temporal among globally dispersed teams. These teams had no common past or future, were culturally diverse and geographically dispersed and only communicated electronically. In a way, if Charles were to be believed, trust would never form in such teams.

But Jarvenpaa and Leidner did find such teams forming trust. The two factors that foster swift trust among globally dispersed teams include communications and actions – both at the onset of team formation and in order to sustain it.

At the onset of team formation, social communication (social exchanges and pleasantries), and enthusiasm were the two key communication activities that helped foster trust. While individual initiative and ability of the team to cope with technical uncertainty were the two key actions that helped in team trust formation.

Then to keep the high trust levels, high trust teams used predictable communication schedules and substantial and timely responses to keep members abreast of team affairs. In terms of actions, high trust teams used positive leadership, and phlegmatic (strong solid temperament) responses to crises, and successfully transitioning from social and procedural to a task oriented approach.

Some other related insights of the paper include:
1. Swift trust could also be the result of ‘importation’ when an outsider prespecifies the pattern of behavior or when a homogenous team shares the same a priori expectations of appropriate behavior.

2. The use of electronically facilitated communications diminishes any cultural differences. The asynchronous mode gives people more time to process messages and to respond to it. There might be fewer language errors particularly from non-native speakers too. In addition, there won’t be ‘regional accents’ that increase any cultural differences.

GSM Spoofing for Under 6000 USD

Two security researchers Wednesday [August 03, 2011] unveiled a remote-controlled, unmanned aerial vehicle (UAV) that is capable of cracking Wi-Fi passwords, exploiting weak wireless access points, and mimicking a GSM tower to intercept cell phone conversations

The Wi-Fi Aerial Surveillance Platform (WASP) was built by Mike Tassey and Richard Perkins, two security researchers seeking to show how an ordinary remote controlled hobby airplanes can be easily converted into something more sinister.

The WASP system, introduced by the pair at the at the Black Hat conference being held here this week, is upgraded version of a model unveiled at last year’s Defcon hacker conference in Las Vegas.

The bright yellow, six-foot, 13-pound spy drone is capable of flying at altitudes of up to 22,000 feet and staying aloft for up to 45 minutes at a time.

Updates include the ability to function as a spoofed GSM tower to intercept cell phone conversations, and to intercept Bluetooth communications.

The airframe of WASP is a surplus U.S. Army drone that was used for target practice purposes. The rest of the hardware and the software used in the drone are all readily available technologies, according to Tassey and Perkins.

The plane packs a small Linux-based computer running the Backtrack 4 suite of penetration testing tools. Another of its systems is designed to collect telemetry data that is sent to a ground-based base station which then uses it for real-time tracking.

The base station also serves as a network router for connecting other workstations to the payload on the drone, and houses systems used to offload processor intensive applications, such as password cracking.

Perkins and Tassey also installed a new Universal Software Radio Peripheral (USRP) that allows the drone to mimic a GSM cell phone tower. The technology can be used to spoof a cellular provider’s mobile service so that outbound calls made by users of that server are routed through the USRP.

The GSM spoofing ability is borrowed from a demonstration last year at Defcon by hacker Chris Paget, which showed how cell phones could be tricked into connecting with specially rigged “towers’ placed close enough to the target phones.

The updated unmanned aerial vehicle supports 4G networks and is capable of receiving and executing instructions delivered over the Internet from anywhere in the world.

The pair said the drone parts and its construction cost some $6,000.
Read more here:
http://www.computerworld.com/s/article/print/9218866/Researchers_show_off_homemade_spy_drone_at_Black_Hat?taxonomyName=Security&taxonomyId=17

Forensics Made Easy with Memoryze

Researchers have devised a new more efficient way to glean attacker information from a machine’s physical memory, which often contains valuable bits of information that can help get to the bottom of a breach investigation case.

The new physical memory forensics feature is now part of Mandiant’s free Memoryze tool.

Previous forensics techniques attempted to reduce the number of binaries using so-called pattern-matching. The Mandiant researchers used hashing instead to shrink a large amount of data into known good and known bad chunks — legitimate Windows processes and third-party apps would fall in the “good” category, for example.

Butler and Murdock demonstrated how to generate a hash of a binary from memory that matches the hash on disk. “Using this technique of comparing hashes and eliminating the things we already know about, we can greatly reduce the dataset of things that need to be investigated further,” Butler says.

The bottom line: Attackers leave a bigger memory footprint than they realize.
From: http://www.darkreading.com/database-security/167901020/security/storage-security/231400009/new-free-tool-helps-gather-attackers-footprints.html

PLDT MyDSL issues with Wifi Router

My brother caught up with me over the weekend and it seems that our techies at Bitstop wasn’t able to help him with a particularly vexing issue he has been having with his PLDT MyDSL broadband internet. His setup included a Linksys Wifi router that lets him connect wirelessly to the internet. Over the last 2 weeks, it suddenly stopped working.

Then when my techies went over, they were able to make the PLDT MyDSL work by hooking up a switch and connecting the rest of the PCs in the LAN to it. Of course, without the WiFi router, my brother couldn’t connect wirelessly. So they suspected that the fault was with the Wifi Router and made my brother purchase a new Wifi.

When the new Wifi router came in, they hook it up and still got the SAME error. The issue is that when they hookedup a Wifi router, they couldn’t access the internet. However, they can verify that the PLDT MyDSL was working because they could access the internet if they connected a PC/laptop directly to the PLDT router/device.

So I asked that my same techies go over to my brother’s house and revisit all the settings.
I asked my techie to connect a laptop directly to PLDT’s MyDSL router/device. Then I asked him to issue the command on the command prompt:

IPCONFIG /all

Here is what I got:
Connection-specific DNS Suffix . :

Physical Address. . . . . . . . . : 00-1E-68-4F-B5-D3
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.1.34
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1
Lease Obtained. . . . . . . . . . : Monday, July 25, 2011 11:30:02 AM
Lease Expires . . . . . . . . . . : Thursday, July 28, 2011 11:30:02 AM

The above details tell us the following:

1. The PLDT device is serving DHCP (dynamic host configuration Protocol) packets. This means that the default setting in most PCs (DHCP assigned IP address) would work. The PLDT device will be assigning the proper IP address to whatever device was connected to it.
2. The PLDT device has the IP address 192.168.1.1 assigned to itself. This is the gateway to the internet.
3. The PLDT device has DNS (Domain name service) running.

So the next step is to verify the IP address of the TPLINK router. And here is what I was told. The TPLINK device LAN IP was set to 192.168.1.1.
That was all I needed to figure out what was wrong with the setup.

The two devices (PLDT MYDSL router and the TPLINK router) were both using the SAME IP address. No wonder it wasn’t working when you connect the TPLINK to the PLDT device! There can only be one device using the IP address in the LAN.

So the solution to this ‘vexing’ case was to assign TPLINK with another network IP address. I chose 192.168.2.1
Case solved.