Tuesday, November 27, 2012

Youtube Architecture


Platform

  1. Apache
  2. Python
  3. Linux (SuSe)
  4. MySQL
  5. psyco, a dynamic python->C compiler
  6. lighttpd for video instead of Apache

What's Inside?

The Stats

  1. Supports the delivery of over 100 million videos per day.
  2. Founded 2/2005
  3. 3/2006 30 million video views/day
  4. 7/2006 100 million video views/day
  5. 2 sysadmins, 2 scalability software architects
  6. 2 feature developers, 2 network engineers, 1 DBA

Recipe For Handling Rapid Growth

while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}


This loop runs many times a day.

Reference : 
http://highscalability.com/youtube-architecture

Sunday, August 26, 2012



DLNA and the connectivity

Wednesday, February 15, 2012

Cisco Design Guide

Main Design Site

College

LAN Guide
http://www.cisco.com/en/US/docs/solutions/Enterprise/Education/CCVE_DepGd/ccve_sba_LAN_DepGd.pdf

WAN Guide
http://www.cisco.com/en/US/docs/solutions/Enterprise/Education/CCVE_DepGd/ccve_sba_WAN_DepGd.pdf

Friday, February 10, 2012

Hacking Cisco with SNMP

Being able to evaluate the strength of a customers infrastructure is a very important part of a penetration test. Many pen testers limit their tests by overlooking the SNMP protocol and the devices that use it. With a successful discovery of SNMP Community Strings you can go as far as to reconfigure a device for remote access (ssh, telnet, http/https) or setup a SPAN port to sniff internal traffic. Before we start there are a few things you should know about SNMP:

UDP Port 161. Since its UDP its fast.
Community Strings provide either Read or Read-Write permissions. Obviously we prefer RW.
SNMP v1-v2 is clear text. v3 is encrypted.
Here is the usual process taken to attack SNMP and the tools that will help you do it.



1) Obtain Community Strings
-Sniff clear text – Wireshark use the filter: udp port 161
-Guessing Community Strings – Onesixtyone, Metasploit (auxiliary/scanner/snmp/snmp_login), snmpblow

2) Setup TFTP Server

3) Identify Updating MIB : snmpwalk

4) Download Device Configs : snmpblow

5) Crack Enable Passwords (salted MD5) : John the Ripper , oclHashcat

6) Modify Config

7) Update Device Config : snmpset

You can see that these steps are pretty straight forward. Have fun experimenting with the tools. I would HIGHLY discourage attacking SNMP in a production environment unless you have thoroughly experimented with the process in a controlled lab.

Copy & Paste From :

Friday, February 3, 2012

Route Map


Step 1 - define an ACL

Keep in mind that whatever is permitted by this ACL is what will be matched. You don't want to permit everything. Usually, I take advantage of the implicit deny at the bottom of the ACL and just create an ACL that permits what I am going to take action on in the route-map.

So, just create a simple ACL:

Router(config)# access-list 101 permit ip any host 10.1.1.1

This ACL permits only traffic with a destination IP of 10.1.1.1 (the traffic we want to send elsewhere)

Step 2 - create a route-map

To create a route-map, go into route-map configuration mode, like this:

Router(config)# route-map reroute10traffic permit 10

Router(config-route-map)#

Next, set your match policy to match the traffic in ACL 101, like this:

Router(config-route-map)#match ip address 101

This will match all the traffic permitted through ACL 101.

Next, you need to set some action on that traffic. What do you want to happen to that traffic? Let's tell the router to send it out interface Fast Ethernet 3/0, like this:

Router(config-route-map)#set interface Fa3/0

Step 3 - Apply the route-map to the interface

Next, you need to apply this policy/route-map to the interface where the traffic is coming in.

Router(config)# interface Fast Ethernet 3/0

Router(config-if)#ip policy route-map reroute10traffic

Reference :

Friday, January 27, 2012

Top 10 Cisco Wireless “Good to Know”

This is a list of Cisco Wireless related facts that have evoked a “really? well I wish I knew that before…” moment for me and many others.

Hopefully this will help others save some time and frustration.

Please post suggestions for additions, as I’m sure there are other topics that fit these criteria.

Top 10 Cisco Wireless “Good to Know”

1) Controller interface vlan tagging, native vlan 1

Cisco Switches by default do not tag the native vlan. Also by default, the native vlan is 1, therefore vlan 1 is untagged.

When establishing a trunk to a Cisco Wireless LAN Controller, it's important to be aware of how tagged vs untagged are identified.

(4400-A) >show interface summary

Interface Name Port Vlan Id IP Address Type Ap Mgr Guest

--------------- ---- ---------- -------------- ----- ------ -----

ap-manager 1 untagged 1.1.1.118 Static Yes No

management 1 untagged 1.1.1.111 Static No No

When going through a WLC's initial startup wizard, if untagged for the Management Interface’s vlan is desired, enter '0' (zero) when prompted for the management interface's vlan, as this is equivalent to 'untagged':

(Cisco Controller)

Welcome to the Cisco Wizard Configuration Tool

Use the '-' character to backup

Would you like to terminate autoinstall? [yes]:

Management Interface VLAN Identifier (0 = untagged): 0

2) AP Image Names: w7 vs w8

ap image names:

w7 = standalone

w8 = lightweight

examples:

Lightweight/controller based/capwap/lwapp image:

Cisco IOS Software, C1130 Software (C1130-K9W8-M), Version 12.4(23c)JZ, RELEASE SOFTWARE (fc1) c1130-k9w8-mx.124-23c.JZ

Autonomous/IOS/Standalone image:

Cisco IOS Software, C1140 Software (C1140-K9W7-M), Version 12.4(21a)JY, RELEASE SOFTWARE (fc1)c1140-k9w7-mx.124-21a.JY

3) AP Part Numbers: LAP vs AP

Most Cisco Access Points are available with two part numbers.

LAPxxx = shipped new from manufacturing with lightweight image

APxxx = shipped new from manufacturing with autonomous image

Same physical hardware.

Example:

Same physical ap's, the first is shipped with a lightweight image, the second with an IOS image:

AIR-LAP1142N-A-K9

AIR-AP1142N-A-K9

Most AP's can be converted between both modes.

4) Wireless LAN Controller DHCP Handling

Wireless Lan Controllers perform 'dhcp proxy' by default. The ‘Dhcp Server’ IP Address configured on controller interfaces acts the same way as an 'ip helper' statement on a Cisco router.

With this configuration in place, an IP Helper statement on the wireless clients’ default gateway router is not necessary.

DHCP Proxy can be configured via the WLC’s GUI in 6.x and 7.x code (Controller -> Advanced -> DHCP).

Earlier code requires CLI access for configuration:

(WLC) >show dhcp proxy

DHCP Proxy Behaviour: enabled

(WLC) >config dhcp proxy disable

(WLC) >show dhcp proxy

DHCP Proxy Behaviour: disabled

Bootp-Broadcast:disabled

5) Lightweight AP modes: Local vs H-Reap

Local mode Access Point: tunnels all traffic to controller, controller responsible for tagging packets and putting them on the wired network, AP's switchport configured in access mode/non trunk.

H-Reap mode Access Point: ap's function similarly to standalone ap's, tag their own traffic, AP's switchport configured as trunk. Vlan tagging requires configuration on each H-Reap mode AP (Via the controller’s Gui).

6) Legacy Access Points End of Support

1500 Series, LAP-1505, LAP-1510: Last supported in 4.2.M controller code.

1000 Series, AP1010, AP1020, AP1030: Last supported in 4.2 controller code.

http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn601820.html#wp586876

These Access Points will not join a controller running code later than supported.

7) AP console settings

•9600 baud

•8 data bits

•1 stop bit

•No parity

*********No hardware flow control******

These are the same settings for other Cisco devices. It is essential that AP's console session have flow control disabled. Most other Cisco devices will tolerate this setting if not disabled, but AP's will not. The result is typically no display and/or keyboard response.

8) WLC Dynamic Interfaces, Does it Route?

Those familiar with Cisco routing and switching may get the impression that Wireless Lan Controllers have routing capability. This may seem apparent due to the fact that multiple dynamic interfaces with ip addresses may be configured. WLC's do not route.

The ip addresses assigned to the dynamic interfaces are not used for client traffic passing through the controller.

Dynamic interfaces' IP addresses most useful function is to verify trunk tagging functionality.

For example, we've added a vlan 10 routed SVI on the connected L3 switch. The WLC is directly connected to the L3 switch, and the relevant port is configured to trunk.

Once we've added a WLC dynamic interface mapped to vlan 10, with a correct ip address, we should be able to ping it from the L3 switch. If not, ensure that vlan 10 is forwarding on the switch’s trunk port.

Another use for the dynamic interface IP address is for use with multicast. For wireless multicast receivers connected to local mode ap's, the controller will proxy/spoof IGMP reports to the wired network using the client's corresponding dynamic interface IP address.

9) Multicast

By default, multicast traffic is not forwarded by Wireless Lan Controllers for local mode ap's.

A common source of confusion is that Autonomous Mode AP's will forward multicast just as they would unicast, so no configuration is required. In the instance of Autonomous AP's being converted to Controller Based/Lightweight, multicast will no longer work until configured on the controller.

Since Controller based H-Reap mode ap's forward their own traffic, multicast will behave as if the AP were a standalone AP, and no controller configuration is required.

10) Anchored Wlans. Where does authentication occur?

For Layer 3 authentication, e.g. Web Auth, authentication handling occurs on the Anchor Controller.

For Layer 2 authentication, e.g. 802.1x, authentication handling occurs on the Foreign controller.





Reference: