|
|
November 19 As always I'm long overdue for an update. I've been busy with other more important things, but I figured since I had to document this for others within my group, here would be the best place since it might benefit others as well.
For today's exercise we'll be creating an EtherChannel between a Red Hat Enterprise 5 server, and a Cisco Catalyst 3750 Switch. This is actually far simpler then it sounds, and can be completed in about ten minutes.
We'll begin with configuring the IEEE 802.3ad Dynamic link aggregation (AKA EtherChannel) on the Red Hat Enterprise Linux server. Begin by logging in via SSH, Telnet or directly on the console itself. I do recommend having access to the console directly, so should anything go wrong and you lose network connectivity you'll be able to easily change things back.
Once logged into the server, switch user to "root" if you're not already logged in as root. Change directory to "/etc" and modify the "modprobe.conf" file using your favorite text editor such as "vi". I personally like using "nano". Add the lines in bold from the example "modprobe.conf" below to your file. Then save your changes and return to the bash prompt.
Sample /etc/modprobe.conf
alias scsi_hostadapter megaraid_sas
alias scsi_hostadapter1 usb-storage
alias eth0 bnx2
alias eth1 bnx2
alias bond0 bonding
options bond0 miimon=100 mode=4 lacp_rate=1
Next we need to create a network script for the "bond0" interface that we defined above in the "modprobe.conf" file. This will be used to configure the network properties for the virtual adapter. Once again, use your favorite text editor to create a new file called "ifcfg-bond0" in the "/etc/sysconfig/network-scripts" directory. In this file you will define the device name used above"bond0", IP address, gateway, network mask etc for the virtual adapter. Below is an example.
Sample /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETWORK=192.168.0.0
NETMASK=255.255.255.0
IPADDR=192.168.0.25
USERCTL=no
GATEWAY=192.168.0.1
TYPE=Ethernet
IPV6INIT=no
PEERDNS=yes
When you're done configuring the properties of the virtual adapter, save your changes and exit the editor.
The next step is to modify the network script for each adapter that will be added to the EtherChannel. The adapters that we'll be using in this server are eth0 and eth1. Please note your interfaces may be different, so check before continuing.
Start by modifying "ifcfg-<int>" using your text editor, where <int> is the interface name. In this case my file name is "ifcfg-eth0". Add the proper references to the virtual adapter created above "bond0" and remove any IP information such as IP address, gateway, netmask etc since that information will be handled by the virtual adapter. Below is an example of the "ifcfg-eth0" file. Note the bold items are required for the EtherChannel to function properly.
Sample /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:11:22:33:44:55
ONBOOT=yes
MASTER=bond0
SLAVE=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes
Repeat the steps above for each additional interface you add to the Etherchannel.
Sample /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
HWADDR=66:77:88:99:aa:bb
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
TYPE=Ethernet
USERCTL=no
Now that each physical adapter has been associated to the virtual adapter, it's now time to create the EtherChannel on the Cisco switch that this server is connected to. In this example I'll be using two Cisco Catalyst 3750G switches in a stack. In addition to the added benefit of increased bandwidth that the EtherChannel provides, having multiple switches will add switch level redundancy to the EtherChannel.
Begin by logging into the switch, entering configuration mode, and creating the EtherChannel interface. The EtherChannel interface, also known as a "Port-channel", is a virtual interface. You can use any number from 1-48 that isn't already assigned to another EtherChannel. In this example I'll be using "28". Configure all the properties such as VLAN, switchport mode etc. that you would normally define on the physical interfaces. Please note that the properties defined in the EtherChannel will override any interface configuration you have defined on the physical interfaces this Etherchannel is assigned to.
Switch# config terminal
Switch(config)# interface Port-channel28
Switch(config-if)# description SERVER
Switch(config-if)# switchport access vlan 123
Switch(config-if)# switchport mode access
Switch(config-if)# spanning-tree portfast
Next we'll need to configure the physical interfaces by associating them to the EtherChannel we created above. I like to mirror the configuration of the EtherChannel on the physical interfaces, so in the event the EtherChannel on the far end of the link becomes misconfigured the server will still be accessible. The line in bold is the only required change that needs to be made on the physical interfaces.
Switch(config)# interface GigabitEthernet1/0/8
Switch(config-if)# description SERVER-1
Switch(config-if)# switchport access vlan 123
Switch(config-if)# switchport mode access
Switch(config-if)# channel-group 28 mode passive
Switch(config-if)# spanning-tree portfast
Repeat the process for each additional interface in the EtherChannel.
Switch(config)# interface GigabitEthernet2/0/8
Switch(config-if)# description SERVER-2
Switch(config-if)# switchport access vlan 123
Switch(config-if)# switchport mode access
Switch(config-if)# channel-group 28 mode passive
Switch(config-if)# spanning-tree portfast
It's now time to restart the network service on the Linux server. Optionally you can reboot the Linux server if that's easier.
[root@SERVER network-scripts]# service network restart
Shutting down interface eth0: /etc/sysconfig/network-scripts/ifdown-eth: [ OK ]
Shutting down interface eth1: /etc/sysconfig/network-scripts/ifdown-eth: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface bond0: [ OK ]
Check the status of the EtherChannel on the Linux server. If the EtherChannel is operating properly you should see "Bonding Mode: IEEE 802.3ad Dynamic link aggregation" when you concatenate "/proc/net/bonding/bond0"
[root@SERVER ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.2.4 (January 28, 2008)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
802.3ad info
LACP rate: fast
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 17
Partner Key: 28
Partner Mac Address: 01:23:45:67:89:ab
Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:11:22:33:44:55
Aggregator ID: 1
Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 66:77:88:99:aa:bb
Aggregator ID: 1
To check the status of the etherchannel on the Cisco switch, use the "show ether-channel" command.
Switch# show etherchannel port-channel
Group: 28
----------
Port-channels in the group:
---------------------------
Port-channel: Po28 (Primary Aggregator)
------------
Age of the Port-channel = 12d:18h:33m:47s
Logical slot/port = 10/28 Number of ports = 2
HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = LACP
Port security = Disabled
Ports in the Port-channel:
Index Load Port EC state No of bits
------+------+------+------------------+-----------
0 00 Gi1/0/8 Passive 0
0 00 Gi2/0/8 Passive 0
Time since last port bundled: 7d:07h:50m:28s Gi2/0/8
Time since last port Un-bundled: 7d:07h:51m:31s Gi1/0/8
At this point you should have a fully functional EtherChannel. If you have any questions feel free to post comments, or contact me directly.
 April 06 This week I had need to control the on/off status (power) of a device in my home on a regular schedule, but also wanted the flexibility of overriding the status remotely via the Internet. Sure this sounds like a perfect application for X10 devices, but being a network geek I have parts lying around my home that are equally capable of performing the same job. Even better, they're free, since I already own.
I dragged out an old APC MasterSwitch model AP2111 that I had lying around the house. The MasterSwitch allows individual control of each receptacle in the PDU via HTTP, Telnet, and SNMP. Unfortunately the MasterSwitch does't have any built-in ability to schedule power state changes (on/off). Current MasterSwitch models can be fairly expensive, but used, discontinued models like my AP2111 can be had for less than $50.00 on eBay.
Since the MasterSwitch supports SNMP we can leverage the free tool Net-SNMP to remotely change power state of the receptacles. NET-SNMP is available on most flavors of Unix such as Linux and Solaris. NET-SNMP is also available for Windows.
When used in conjunction with a powerful program scheduler such as cron (unix) or Windows Scheduled Tasks, we can fully automate the powering on or off of devices connected to the MasterSwitch on a regular schedule. Here's a quick how-to.
Assumes the MasterSwitch is connected to the network, has and IP address and is accessible via HTTP and SNMP from another computer.
1) Enable SNMP on the APC MasterSwitch
1.1) Login to the APC MasterSwitch and expand "Network" from the left hand navigation.
1.2) Click "SNMP"
1.3) Under the heading SNMP select "Enabled" and click "Apply"
2) Configure the SNMP Write Community string on the MasterSwitch
2.1 Under "Access Control" enter a SNMP community string that will be used to access the MasterSwitch. "Private" is the default.
2.2 In the "NMS/IP" field enter the IP address of the machine that will be accessing the MasterSwitch, or use "0.0.0.0" for any.
2.3 Ensure the "Access Type" is set to "Write"
2.4 Click "Apply"
3) Using a Windows machine that already has NET-SNMP installed, create a new scheduled task
3.1 Click 'Start" - "Control Panel" - "Scheduled Tasks" - "Add Scheduled Task"
3.2 When the wizard begins click "Next"
3.3 Click "Browse" and navigate to the NET-SNMP BIN directory (Default is "c:\usr\bin") and select "snmpset.exe"
3.4 Name the the task and select the frequency that it will run.
3.5 Enter the account credentials that the process will execute under. Note: This user must have read/execute permission to "snmpset.exe"
 
3.6 Check the box "Open Advanced propertied for this task when I click Finish" and then click "Finish"
3.7 In the task "Run" field, add the necessary parameters specifying the MasterSwitch IP address, community string, outlet number and action in the following format.
"C:\usr\bin\snmpset.exe" -v 1 -c {community} {ipaddress} 1.3.6.1.4.1.318.1.1.6.5.1.1.5.1.1.{outlet} i {action}
{community} is the SNMP community string specified earlier in step #2.3
{ipaddress} is the IP address of the APC MasterSwitch
{outlet} is the electrical outlet number on the MasterSwitch that the device you wish to control is connected
{action} is the power function you wish to perform. See table below
(1) Immediately turn the outlet on
(2) Turn the outlet on after delay
(3) Immediately turn the outlet off
(4) Turn the outlet off after delay
(5) Immediately reboot the outlet
(8) Cancel pending command
The example below connects to the APC MasterSwitch at "10.0.0.35" using the community string "private" and immediately turns off outlet 5.
"C:\usr\bin\snmpset.exe" -v 1 -c private 10.0.0.35 1.3.6.1.4.1.318.1.1.6.5.1.1.5.1.1.5 i 3
If needed, create an additional scheduled task to power the device back on.
As always, if you have any questions post them here. Enjoy
January 05 I once again find myself documenting the undocumented as I continue my crusade to eliminate independent authentication databases in favor of more centralized approaches such as LDAP and RADIUS.
I covered a similar topic before in a segment entitled APC Web/SNMP & RADIUS Authentication where I walk through integrating APC management hardware with a Microsoft IAS back end. Thus eliminating the need for independently managed local usernames/passwords on each piece of APC equipment. This also allowed administrators to use their familiar Active Directory credentials, and improved auditing and logging since changes were tied back to the individual who logged in instead of a generic "device specific" local administrator account.
This segment will cover integrating Cisco's Wireless Control System (WCS) with Microsoft's Internet Authentication Service (IAS) which is Microsoft's implementation of a Remote Authentication Dial-in User Service (RADIUS) Server.
For the purposes of this LAB I'm using three servers and one workstation, all of which are located on the same subnet as pictured below.
If you haven't already done so you'll need to register IAS with Active Directory.
Create a RADIUS Client
First we need to create a RADIUS Client in IAS that will represent our WCS Server. In IAS right click on "RADIUS Clients" and select "New RADIUS Client"
The new RADIUS client wizard will walk you though the process of adding the RADIUS device.
To keep things simple and avoid any potential confusion, In the "Friendly name" field I named the object "WCS-SERVER".
Next, populate the "Client address (IP or DNS)" field with the IP address or DNS name of the WCS Server and then click "Next".
On the following screen select "RADIUS Standard" from the Client-Vendor list. Then enter a shared secret (password) that WCS will use to authenticate to IAS. In this case I'm using the shared secret "WCS". Confirm your shared secret and click "Finish". Do NOT check the box "Request must contain the Message Authenticator attribute".
Note: Shared secrets are case sensitive.
Create a RADIUS Policy
Now we need to create a Remote Access Policy. We'll begin by defining who has access to WCS. To begin right click on "Remote Access Policy" and select "New Remote Access Policy"
When the New Remote Access Policy Wizard begins click "Next".
Select "Set up a custom policy" under "How do you want to set up this policy?" Then create a name for your policy. I've decided to name mine "Cisco WCS". Once you've named your policy click "Next".
On the Policy Conditions page click "Add" and select "Windows-Groups" and click "Add" again.
In the Groups page click "Add" and select the Active Directory user group you want to have administrative access to WCS. In my case I have added the Domain Admins group. Click "OK" when you have finished adding groups.
Once again on the Policy Conditions page click the "Add" button and choose "Client-Friendly-Name" from the list and click "Add".
In the Client-Friendly-Name window type "WCS-SERVER". This will ensure that this Remote Access Policy only applies to the "WCS-SERVER" RADIUS client that we defined ealier. When you are done click "OK".
Your Policy conditions should look similar to the image below. If everything looks good then click "Next".
On the Permissions screen select "Grant remote access permission" and click "Next".
On the Profile page click "Edit Profile" and go to the "Authentication" tab. Check the box labeled "Unencrypted authentication (PAP, SPAP). Uncheck all other boxes.
Next, click on the "Encryption" tab and clear all the checkboxes except "No encryption"
It's at this point that things begin to get interesting. Click on the "Advanced" tab and remove all attributes that are listed, and then click "Add". Select "Vendor-Specific" from the list and click "Add".
Click "Add" Again and the "Mutivalued Attribute Information" window appears. click "Add" one last time to add an attribute value to the list.
In the "Vendor-Specific Attribute Information" click on the vendor list and select "Cisco". Select the radio button "Yes it conforms" and lastly click "Change Attribute".
It is here, in the Vendor Specific Attribute (VSA) that we define the RADIUS response messages sent back to WCS upon a successful authentication.
We begin by changing the "Vendor-assigned attribute number". This number will always be "1" for all WCS VSA(s).
The first "Attribute value" that we'll define is the WCS roll that the user who successfully authenticated to RADIUS will have in WCS. Earlier we defined that Active Directory Domain Admins would be the only users who would be able to successfully authenticate to this RADIUS policy. It's only fitting that these same users be WCS Admins. So in the "Attribute value" we enter "Wireless-WCS:role0=Admin" and click "OK".
At this point you might think we're done in IAS but far from it. It seems that not only must you define the roll that the authenticated user will be member of, but you must also specifically define the permissions the user will have inside WCS. At this time there are currently 45 "tasks" within WCS that can be controlled through RADIUS. You must include each task as a VSA that you want your users to have access to in WCS. For instance, I want my Domain Admins to have access to the Audit Reports within WCS. So I need to include a VSA with the appropriate Value as such.
Below is a listing of all current WCS tasks as of version 4.2.62.0 in proper VSA format. They will need to be added individually to grant users logging in to WCS full access.
Wireless-WCS: task1 = Audit Trails
Wireless-WCS: task2 = TACACS+ Servers
Wireless-WCS: task3 = RADIUS Servers
Wireless-WCS: task4 = Logging
Wireless-WCS: task5 = Licensing
Wireless-WCS: task6 = Scheduled Tasks and Data Collection
Wireless-WCS: task7 = User Preferences
Wireless-WCS: task8 = System Settings
Wireless-WCS: task9 = Diagnostic Information
Wireless-WCS: task10 = View Alerts and Events
Wireless-WCS: task11 = Email Notification
Wireless-WCS: task12 = Delete and Clear Alerts
Wireless-WCS: task13 = Pick and Unpick Alerts
Wireless-WCS: task14 = Severity Configuration
Wireless-WCS: task15 = Configure Controllers
Wireless-WCS: task16 = Configure Templates
Wireless-WCS: task17 = Configure Config Groups
Wireless-WCS: task18 = Configure Access Points
Wireless-WCS: task19 = Configure Access Point Templates
Wireless-WCS: task20 = Configure Choke Points
Wireless-WCS: task21 = Monitor Controllers
Wireless-WCS: task22 = Monitor Access Points
Wireless-WCS: task23 = Monitor Clients
Wireless-WCS: task24 = Monitor Tags
Wireless-WCS: task25 = Monitor Security
Wireless-WCS: task26 = Monitor Chokepoints
Wireless-WCS: task27 = Access Point Reports
Wireless-WCS: task28 = Mesh Reports
Wireless-WCS: task29 = Client Reports
Wireless-WCS: task30 = Inventory Reports
Wireless-WCS: task31 = Performance Reports
Wireless-WCS: task32 = Security Reports
Wireless-WCS: task33 = Location Server Management
Wireless-WCS: task34 = View Location Notifications
Wireless-WCS: task35 = Maps Read Only
Wireless-WCS: task36 = Maps Read Write
Wireless-WCS: task37 = Client Location
Wireless-WCS: task38 = Rogue Location
Wireless-WCS: task39 = Planning Mode
Wireless-WCS: task40 = Ack and Unack Alerts
Wireless-WCS: task41 = Migration Templates
Wireless-WCS: task42 = Configure Spectrum Experts
Wireless-WCS: task43 = Monitor Spectrum Experts
Wireless-WCS: task44 = Interferers Search
Wireless-WCS: task45 = Audit Reports
When you're done entering all the tasks you want your users to have access to as VSA's in IAS, your Multivalued Attribute Information window should look similar to the following.
We've finally completed the configuration of IAS. Click "OK"on each open window to confirm your changes until you're back at the main IAS MMC.
Configure WCS
Now that setting up IAS is behind us, it's now time to configure WCS to use the RADIUS server as its method of authentication.
We begin by accessing the web interface of WCS and logging in as the WCS administrator. Click "Administration" - "AAA" from the top navigation bar. Then select "RADIUS" from the menu on the left. On the "Select a command" pull-down choose "Add RADIUS Server" and click "GO".
In the fields enter the information about the RADIUS server that we defined earlier in the "Create a RADIUS Client". Then click "Submit"
Once the RADIUS servers are defined in WCS we need to enable RADIUS authentication. To do this, click on "AAA Mode" from the menu on the left. select the "RADIUS" radio button and ensure "Fallback on Local" is checked so we don't get locked out of WCS if the RADIUS server was to become unavailable.
When your done click "OK".
From here you should logout and test your RADIUS authentication. Provided that all the steps were followed correctly, you should be able to login successfully as any user in the Domain Admins group of Active Directory.
As always, if you have any questions feel free to contact me.
June 05 It's been a long time since my last update and I've received quite a few requests for an update, so I thought I would carve out some time to update the blog. I've been working on a few different projects lately that are worthy of posting about, but none of them are complete, so for this posting I'll be doing something fairly straightforward that everyone can use. Simple Network Management Protocol (SNMP) has existed for a very long time and there are many tools out there that can leverage SNMP to provide useful metrics for measuring your network or server usage and health. A short list of some of these tools include the following. This list is by no means exhaustive. It serves as a small example of the many tools available that are capable of leveraging SNMP. The type of information you can retrieve using SNMP is too numerous to list here, but a few examples are listed below. - CPU Utilization
- Memory Utilization
- Disk Usage
- Network Bandwidth
- Network Errors
Before you can take advantage of what SNMP has to offer you must first configure SNMP on the device you wish to monitor. For the purpose of this blog entry I will be focusing on SNMP read only, AKA "SNMP GET". I will not be spending much, if any time on SNMP write, AKA "SNMP SET". Though it is important for you to note that not only can you access device information remotely using SNMP, in most cases you can also configure device settings remotely using SNMP. In the examples below I will be using a Cisco Catalyst 3750 running IOS 12.2(35)SE2. SNMPv1/v2 with Cisco IOS Configuring SNMP v1 and v2 in IOS is a fairly straightforward process. All that is required is set a community string (name), and to define the permissions that the community will have. For instance, the example below provides read only access "RO" using the specified community string "public". "RO" is the most common SNMP permission type. The second example provides read/write "RW" access using the specified community string "private". "RW" access is potentially dangerous and I don't recommend configuring a read/write community unless you have a specific need. Even then you should consider using SNMPv3 and/or limiting SNMP access to a specific IP address. switch(config)# snmp-server community public RO
switch(config)# snmp-server community private RW Also, you can configure some additional SNMP options which might be helpful. When you have a large number of SNMP devices, keeping track where they are located or who is responsible for them can be helpful. switch(config)# snmp-server location 1 Main St - Anytown USA
switch(config)# snmp-server contact Joe Smith - 800-555-1212 Lastly, if you are using a Network Management Solution (NMS) such as CiscoWorks, or SolarWinds Cirrus, that allows you to remotely upgrade code on your IOS switch, you might want to allow the NMS to reboot the switch using SNMP once the upgrade has completed successfully. To allow this you will need to configure a read/write community such as the one in the example above, as well as add the following command to your switch. switch(config)# snmp-server system-shutdown To test your SNMP configuration download and install NET-SNMP for your specific client operating system. I recommend downloading a build that includes SSL. This will be important later. Once NET-SNMP is installed you can run "snmpget" to retrieve the information from your switch. The example below queries the contact information we configured earlier on the switch. C:\usr\bin>snmpget -v2c -Cf -c public 10.0.32.6 system.sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: Joe Smith - 800-555-1212 SNMPv3 with Cisco IOS Configuring SNMPv3 is slightly more complicated then configuring SNMPv1 and SNMPv2, but it provides greater security by adding authentication (username/password) as well as encryption to the protocol. This is important if regulations mandate the use of high level security standards, such as Sarbanes Oxley or HIPPA. You begin the configuration of SNMPv3 on your IOS switch by creating an SNMP "view". A "view" defines what information the SNMP user/group will have access to when they query the device. The example below creates a view called "MyView" that includes access to the "internet", "system", "interfaces" and "chassis" SNMP OIDs on the device. switch(config)# snmp-server view MyView internet included
switch(config)# snmp-server view MyView system included
switch(config)# snmp-server view MyView interfaces included
switch(config)# snmp-server view MyView chassis included In the next step we create an SNMP group called "MyGroup". This group is then granted access to the view "MyView" that we created in the previous step, with read only permissions. switch(config)# snmp-server group MyGroup v3 auth read SNMPv3 Lastly, we create a SNMP user called"MyUserName" and grant it access to the group "MyGroup" that we created earlier. We will need to provide an authentication password, as well as a privacy password which will serve as the encryption key for the protocol. NET-SNMP requires that these passwords be a minimum of eight characters in length. switch(config)# snmp-server user MyUserName MyGroup v3 auth md5 MyAuthPass priv des56 MyPrivPass If you haven't already done so, you'll want to configure the SNMP location and contact information so we can test the SNMP configuration. switch(config)# snmp-server location 1 Main St - Anytown USA
switch(config)# snmp-server contact Joe Smith - 800-555-1212 To test the SNMPv3 configuration of the switch we will once again use NET-SNMP. It's important that you've installed a build of NET-SNMP that includes SSL if you plan on test SNMPv3. Once NET-SNMP is installed you can run "snmpget" to retrieve the information from your device. When you execute the command below NET-SNMP queries the SNMP contact information we configured earlier on the switch. C:\usr\bin>snmpget -v3 -u MyUserName -l authPriv -a MD5 -A MyAuthPass -x DES -X MyPrivPass 10.0.32.6 system.sysContact.0 should return the following.. SNMPv2-MIB::sysContact.0 = STRING: Joe Smith - 800-555-1212 - Good luck
November 05 I am long overdue for an update to the blog so I thought RSPAN would be something that is fun and easy to do.
RSPAN (Remote Switched Port Analyzer) is a method of mirroring a physical interface on a Cisco device remotely, eliminating the need to be on the same switch as the device you wish to monitor. RSPAN is a great tool for troubleshooting a server or workstation’s network communications. RPSAN can also be used in conjunction with an IDS system such as SNORT for monitoring potential threats. The best part is that this can all be done without leaving your seat.
Configuring RSPAN is fairly straightforward. The concept is similar to a local SPAN port, but instead of the destination being another local interface on the same switch the destination becomes a dedicated RSPAN VLAN. This RSPAN VLAN is then trunked to another switch where your capture device is located.
In this example I am going to RSPAN a gigabit interface on a remote Cisco Catalyst 6500 to a local Cisco Catalyst 3750 where I am located. The Catalyst 6500 is running IOS version 12.2(18)SXF5 and the Catalyst 3750 will be running IOS version 12.2(25)SEC.
We start by creating a new dedicated RSPAN VLAN on the Catalyst 6500. This VLAN cannot be used for any other purpose then RSPAN.
6500#config terminal
6500(config)#vlan 199
6500(config-vlan)#name RSPAN_VLAN
6500(config-vlan)#remote-span
6500(config-if)#end
This step should be repeated on the Catalyst 3750 and any other devices between. The RSPAN VLAN will not cross layer 3 boundaries so there must be layer 2 connectivity between the RSPAN source and destination switches.
Then we must add the RSPAN VLAN to the trunk interface connecting these two switches
6500(config)#interface Gi2/24
6500(config-if)#switchport trunk allowed vlan add 199
Repeat this step on the Catalyst 3750 for the corresponding trunk interface
Now we will ensure there are no other SPAN sessions configured on either switch.
6500(config)#no monitor session all
Next, we will configure the RSPAN source on the Catalyst 6500
6500(config)#monitor session 2 source interface Gi7/1 tx
6500(config)#monitor session 2 destination remote vlan 199
6500(config)#exit
Now you should double check your work on the remote end.
6500#sh monitor session 2
Session 2
---------
Type : Remote Source Session
Source Ports :
TX Only : Gi7/1
Destination RSPAN VLAN : 199
On the Catalyst 3750 we can now configure the RSPAN destination, provided that the RSPAN VLAN was created in the steps above.
3750(config)#monitor session 2 source remote vlan 199
Again, double check your work.
3750#sh monitor session 2
Session 2
---------
Type : Remote Destination Session
Source RSPAN VLAN : 199
Destination Ports : Fa1/0/1
Encapsulation : Native
Ingress : Disabled
At this point you should be able to connect to Port Fa1/0/1 on the Catalyst 3750 and use your favorite capture program such as WireShark to capture traffic going to the server connected to Gi7/1 on the Catalyst 6500. 
February 28 APC Web/SNMP cards AP9617 and newer such as (AP9618 and AP9619) with AOS firmware v2.6.4 or greater have RADIUS authentication as a feature. RADIUS allows you to use a centralized user database to authenticate against, such as active directory or local user accounts in FreeRADIUS. If you have a large number of APC devices such as SmartUPS, Masterswitches or Metered PDUs then you will probably be very interested in RADIUS to control user access.
Could you imagine creating and maintaining accounts on 100+ devices? What if you had to change the administrator password?
RADIUS is much easier to manage and maintain but it does require a little time investment up front to make the magic happen. APC provides instructions on how to configure the device to use a RADIUS server in the manual. They even include some examples on how to configure FreeRADIUS. The trouble is, I'm not running FreeRADIUS. I’m running IAS. APC also provides some very basic guidelines that should apply to any RADIUS server, but unfortunately these instructions are about as clear as mud. Frustrated with the lack of any IAS directions I decided to create my own. I am using a lab environment that consists of the following items.
Windows Server 2003 SP1 Active Directory
Windows Server 2003 SP1 IAS (Internet Authentication Services)
APC AP9617 Web/SNMP Management card with AOS Firmware v2.6.4
APC SmartUPS with SmartSlot
Before we can begin, IAS must be installed and registered in Active Directory.
We will need to be sure that the two devices are reachable. If both the APC units and your RADIUS server are on the same network segment then this is probably not an issue, but in an enterprise deployment it is very possible that these would be on different subnets. So let’s start by pinging our APC unit from the IAS server
C:\>ping 10.0.2.38
Pinging 10.0.2.38 with 32 bytes of data:
Reply from 10.0.2.38: bytes=32 time=1ms TTL=128
Reply from 10.0.2.38: bytes=32 time=1ms TTL=128
Reply from 10.0.2.38: bytes=32 time=1ms TTL=128
Reply from 10.0.2.38: bytes=32 time=1ms TTL=128
Create a RADIUS Client
Once we have confirmed that the device is reachable we can create a RADIUS Client. In IAS right click on "RADIUS Clients" and select "New RADIUS Client"
The new RADIUS client wizard walks you though the process of adding your RADIUS device.
In the "Friendly name" field name the object "APC UPS" or anything that begins with "APC". This will be important when we create the Remote Access Policy later on.
Next, populate the "Client address (IP or DNS)" field with the IP address or DNS name of the APC Management card in the UPS and then click "Next".
On the following screen select "RADIUS Standard" from the Client-Vendor list. (APC is not in the list) Then enter a password the device will use to authenticate to IAS in the "Shared secret" field. In this case I am using the shared secret "APC". Confirm your shared secret and click "Finish". Do NOT check the box "Request must contain the Message Authenticator attribute".
Note: Shared secrets are case sensitive.
Create a RADIUS Policy
Now we will need to create a Remote Access Policy. We will first create a policy that will allow Domain Adminis administrator access to the Web/SNMP card. To begin right click on "Remote Access Policy" and select "New Remote Access Policy"
When the New Remote Access Policy Wizard begins click "Next".
Select "Set up a custom policy" under "How do you want to set up this policy?" Then create a name for your policy. I have decided to name mine "APC Policy". Once you named your policy click "Next".
On the Policy Conditions page click "Add" and select "Windows-Groups" and click "Add" again.
In the Groups page click "Add" and select the Active Directory user group you want to have administrator access to your APC devices. In my case I have added the Domain Admins group. Click "OK" when you have finished adding groups.
Once again on the Policy Conditions page click the "Add" button and choose "Client-Friendly-Name" from the list and click "Add".
In the Client-Friendly-Name window type "APC*". This will ensure that this Remote Access Policy only applies to RADIUS clients whose name begins with "APC". This is something we defined above when we originally created the RADIUS client in IAS. When you are done click "OK"
Your Policy conditions should look similar to this.
Once you have double checked your settings click "Next". On the Permissions page select "Grant remote access permission" and click "Next"
On the Profile page click "Edit Profile" and go to the "Authentication" tab. Check the box labeled "Unencrypted authentication (PAP, SPAP). Uncheck all other boxes.
Next, click on the "Encryption" tab and clear all the checkboxes except "No encryption"
Lastly; click on the "Advanced" tab and remove all attributes that are listed, and then click "Add". Select "Service-Type" from the list and click "Add".
Under the "Attribute value" pull down select "Administrative" and click "OK".
Back at the Add Attribute page click "close" and you will be return to the profile window. It should look like this.
Click "Apply" then click "Ok".
At this point you should be back at the New Remote Access Policy Wizard. Click "Next", and then click "Finish".
You should now have a fully working RADIUS policy that will allow your Domain Admins administrator access to your APC Web/SNMP enabled UPS. You can try accessing the web interface or SSH/Telnet interface if you have that enabled. You can also create a "Device" policy if you like. Device access on an APC unit allows full control over the device the Web/SNMP card is attached to. For example, if you have the Web/SNMP card installed in a UPS, the device permission would allow the user to manage the UPS but it would not allow that user to modify settings related to the Web/SNMP card such as TCP/IP or SNMP settings. This could be helpful if you have a helpdesk staff that needed to check the estimated run time of the UPS, but you did not want them to modify any critical settings of the unit.
To create a RADIUS policy to allow the helpdesk staff access to your APC equipment with the Device permissions start by creating a new security group in Active Directory. I have named mine "Helpdesk". Add the users you would like to have Device permissions to your APC devices to your newly created security group.
Once you have created your security group in Active Directory and added your users to the group you then need to create a new RADIUS Policy. Follow the same steps under "Create a RADIUS Policy" with the exceptions listed below. You do not need to create the RADIUS client again.
You will need to create your new RADIUS policy with a unique name. I have decided to name my Device access RADIUS Policy "APC Helpdesk"
When adding conditional policy attributes select "Windows-Groups" as you did before, but this time add your newly created group instead of Domain Admins.
Follow the instructions as they are written above until you add the "Service-Type" attribute. This attribute determines what access level the user will have once they have authenticated. "Administrative" would give the user Administrator access to the device. To give the user Device level access only, choose "Login" from the "Attribute value" pull down.
Continue to follow the directions above until you have finished creating your RADIUS Policy. When you have completed your Helpdesk staff should have Device level access to your APC RADIUS clients.
So that's how to manage access to your APC equipment using IAS in a nutshell.
if you're blessed with the talent, utilize it to the fullest be true to yourself and stay humble.
-Blackalicious         
January 08 I recently had the misfortune of troubleshooting a problem with SMTP on a Microsoft Exchange server. This ordinarily would not have been so difficult but this SMTP server required authentication. I was disappointed with the lack of useful information provided to me by the traditional mail client why SMTP was failing, so I decided to telnet to the SMTP server and see what was up. It was a little difficult at first to figure out the proper way of authenticating within a telnet session but after some research I was able to figure it out. Below is the process that I followed.
First telnet to the SMTP server on port 25
telnet smtp.domain.com 25
You should receive a message similar to the following
220 smtp.domain.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.2499 ready at Mon, 2 Jan 2006 14:45:31 -0500
Next we will issue the command “EHELO” to begin our session.
EHLO
You should receive a similar response
250-smtp.domain.com Hello [10.1.2.32]
more... verbs
250 OK
NOTES:
ESMTP uses ehlo as a greeting - to establish an initial connection.
SMTP uses helo instead of ehlo.
250 - Means that the action which you requested, completed OK. (Remember codes beginning with 2yz indicate success.
For simplicity, I have omitted the list of extra ESMTP verbs.
Now for the tricky part. Because this SMTP server requires authentication we will use the “AUTH LOGIN” command.
AUTH LOGIN
334 VXNlcm5hbWU6
The response of “VXNlcm5hbWU6” might seem a little strange, but after decoding from Base64 it all becomes clear. “VXNlcm5hbWU6” is “Username:” Since we are being challenged in Base64, we will need to respond in Base64. You will need a Base64 encoder/decoder. I recommend http://www.dillfrog.com/tools/base-64_encode/
Enter your Base64 encoded username into your telnet session. I recommend copy/paste from the site above.
dXNlcm5hbWU=
334 UGFzc3dvcmQ6
From our Base64 decoder you will see that “UGFzc3dvcmQ6” means “Password:” Enter your password in Base64.
cGFzc3dvcmQ=
235 2.7.0 Authentication successful.
If you entered the correct username & password for a working account you should have successfully authenticated. Now we will compose the message. We begin by specifying who the message is from using “MAIL FROM”, then identifying who the message is to using “RCPT TO”. Here is an example.
MAIL FROM: username@domain.com
250 2.1.0 username@domain.com....Sender OK
RCPT TO: recipient@domain.com
250 2.1.5 recipient@domain.com
Now we can begin composing our message. We start with the “DATA” command.
DATA
354 Start mail input; end with <CRLF>.<CRLF>
If you wish to have a subject line enter “Subject:” then your subject line text. In order to conform to RFC 882 you must have two carriage returns (enter twice) after your subject line before composing the body of your message.
Subject: This is my subject
This is the body of my message
.
250 2.6.0 <SMTPvgs0LtQ5A0JB0i00002712@SMTP.domain.com> Queued mail for delivery
After your subject line and two carriage returns you can begin typing your message. When you are done composing, type a period “.” on a line by itself and press enter. This will denote the end of your message and deliver the email. Once your message is sent you can issue the “QUIT” command to end your SMTP session with the server.
QUIT
221 2.0.0 smtp.domain.com Service closing transmission channel
Here is the whole sequence without interruption
telnet smtp.domain.com 25
220 smtp.domain.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.2499 ready at Mon, 2 Jan 2006 14:45:31 -0500
EHLO
250-smtp.domain.com Hello [10.1.2.32]
more... verbs
250 OK
AUTH LOGIN
334 VXNlcm5hbWU6
dXNlcm5hbWU=
334 UGFzc3dvcmQ6
cGFzc3dvcmQ=
235 2.7.0 Authentication successful.
MAIL FROM: username@domain.com
250 2.1.0 username@domain.com....Sender OK
RCPT TO: recipient@domain.com
250 2.1.5 recipient@domain.com
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Subject: This is my subject
This is the body of my message
.
250 2.6.0 <SMTPvgs0LtQ5A0JB0i00002712@SMTP.domain.com> Queued mail for delivery
QUIT
221 2.0.0 smtp.domain.com Service closing transmission channel
Enjoy
December 18 Private VLANs have some level of mystique which is probably due to its confusing and complicated implementation. The easiest thing to understand about a Private-VLAN is the end result.
What is the purpose of private VLANs?
Private VLANs are more or less what the name implies. The illusion is that each physical access port on the network is on its very own individual VLAN. Of course this is not really the case; as that would be extremely difficult to build, and almost impossible to maintain. Instead, Private VLANs provide all the security of separate individual VLANs for your access ports, with the ease and simplicity of managing a traditional LAN.
Ports within a Private VLAN are broken up into three categories, isolated, community, and promiscuous. Hosts connected to a promiscuous port can talk to any port, including isolated and community ports. Promiscuous ports are usually reserved for router interfaces, printers and servers on the same VLAN which all clients need access to. Hosts connected to isolated ports can not communicate with anyone else on the same VLAN with the exception of promiscuous ports. Isolated ports are most commonly used in Schools, dormitories, hotels, libraries and other public locations. Hosts connected to community ports may communicate to other common community ports or promiscuous ports but may not talk to isolated ports. More on community ports later.
I am going to give an example of how to create and configure a private VLAN on a network that consists of two Cisco Catalyst 3750’s both connected to a common 6500 running CatOS with two MSFCs.
The scenario is this. A local convention center is going to be providing internet access to each booth. The network administrator wishes to keep the convention traffic separate from the administrative systems, and also ensure that the users who will be renting the booths will be protected from the users in surrounding booths.
I will start by creating a new VLAN on the 6500. This VLAN will be the Primary VLAN. Every private VLAN begins with a primary VLAN. This primary VLAN is basicly your regular VLAN, in which the isolated and community VLANs will be associated. The Primary VLAN is also the only VLAN you need to be concerned about when configuring your MSFC.
6500# (enable) set vlan 11 name Convention_Primary_VLAN pvlan-type primary
Next I will create an isolated VLAN, I know this sounds confusing but trust me, this is how it works.
6500# (enable)set vlan 111 name Convention_Isolated_VLAN pvlan-type isolated
If you plan on using a community private VLAN create it now with “pvlan-type” of “community”
Now we need to associate the isolated VLAN and any community VLANs that are created with the primary VLAN.
6500# (enable) set pvlan 11 111
Lastly we need to create a VLAN mapping for the MSFCs to allow the traffic from the isolated VLAN and any community VLANs that were created to route beyond the local subnet.
6500# (enable) set pvlan mapping 11 111 15/1
6500# (enable) set pvlan mapping 11 111 16/1
If you are running in Native IOS mode you must go to each VLAN and create a private VLAN mapping
6500# config t
6500(config)#interface vlan 11
6500(config-if)#private-vlan mapping 111
If you have not already done so, add the newly created VLANs to the trunk port interfaces that serve as the uplink to the edge switches.
6500# (enable) set trunk 3/9 11,111
6500# (enable) set trunk 3/10 11,111
If you have any access ports on the 6500 you wish to add to the private VLAN you can do so now.
6500# (enable) set pvlan 11 111 9/22
That’s it for the CatOS side. On the MSFC you will need to create a VLAN interface for the primary VLAN. No interfaces should be created for your isolated or community VLANs.
MSFC# config terminal
MSFC(config)# interface vlan 11
MSFC(config-if)# description Convention_VLAN
MSFC(config-if)# ip address 10.0.1.1 255.255.255.0
Nothing additional needs to be configured on the MSFC.
We can now turn our attention to the edge switches. In this case I am using a Cisco Catalyst 3750. We will begin by creating the primary and isolated VLANs on the switch. (note VTP mode must be “transparent” for private VLANs to function properly)
3750# config terminal
3750#(config)# vtp mode transparent
3750#(config)# vlan 11
3750#(config-vlan)# name Convention_Primary_VLAN
3750#(config-vlan)# private-vlan primary
3750#(config-vlan)# vlan 111
3750#(config-vlan)# name Convention_Isolated_VLAN
3750#(config-vlan)# private-vlan isolated
Now we must associate the isolated VLAN with the primary VLAN.
3750#(config-vlan)# vlan 11
3750#(config-vlan)# private-vlan association 111
Lastly we need to add interfaces on the switch to the private VLAN. In this case we will be adding ports 13 – 24.
3750#(config-vlan)# interface range fa1/0/13 -24
3750#(config-if-range)# switchport private-vlan host-association 11 111
3750#(config-if-range)# switchport mode private-vlan host
Duplicate this process on the second 3750 and begin testing. Begin by plugging a host into any of the isolated ports configured on the 3750. Assign an IP address or get one from a DHCP server. I will configure my first machine with the IP address of 10.0.1.5/24. Next attach a host to an isolated port on the second 3750 or the optional isolated port we configured on the 6500. Give the host an IP address, or obtain one from a DHCP server. Mine will be 10.0.1.6/24.
You can now begin testing the configuration. Start by trying to ping each host from the other. If you look at the ARP table on the each of the hosts you will notice that you are unable to ARP the other host. You can try IPX and Appletalk if you wish. The results will be the same. The only interface in the configuration above that the hosts should be able to ping is the router.
Community VLANs
Community VLANs are created the exact same way as isolated VLANs. What makes them powerful is that you can have multiple community VLANs associated with a single primary VLAN. An example of its use would be if you had a corporate P2P application and you wanted all the machines in marketing to be able to share files with each other but not with sales. You also wanted the people in sales to share files with each other but not with marketing. Community VLANs allow you to do this within the same IP subnet.
Notes
It should be said that if you are running Native IOS on your 6500 and you configure private VLANs for the first time Sticky ARP is enabled by default. Sticky ARP is a Cisco security feature designed to be used with static IP addressing to prevent ARP spoofing. This means that once an ARP entry is created on the router this entry becomes permanent until the 6500 is rebooted. This is far from ideal in a DHCP environment. You will find clients making DHCP requests, receiving DHCP offers and accepting these offers but unable to access the network because the IP address the client was assigned once belonged to a different MAC address. With that said, Sticky ARP should be disabled either globally or on the specific VLANs that you will be running Private VLANs on.
To disable Sticky Arp globally:
6500# config terminal
6500(config)#no ip sticky-arp
To disable Stick Arp on a specific VLAN
6500# config terminal
6500(config)# interface Vlan11
6500(config-if)# ip sticky-arp ignore
If you have security concerns about disabling Sticky ARP I strongly suggest you look into IP source guard which is part of Cisco's DHCP Snooping protection. More on that later.
         
Update: I came across the following error the other day and thought it was note worthy since it was related to the private VLAN configuration.
%PM-SP-3-ERR_INCOMP_PORT: 9/21 is set to inactive because 9/1 is a dynamic trunk port
It seems that if you have an interface configured for a private vlan "9/21", and another interface configured as a trunk "9/1" sharing the same ASIC you will run into a similar error message. Although this is not particularly note worthy I should point out that in my configuration 9/1 is not explicitly defined as a trunking interface. In fact it was being used as an access port, not a trunk port.
So what's the problem then?
Well all interfaces by default are configured as dynamic trunk ports. This can be seen by running the IOS command
IOS-6509# show interface trunk module 9
This will display the trunking status of the interfaces on module 9.
Port Mode Encapsulation Status Native vlan
Gi9/1 desirable negotiate other 1
For private-vlan interfaces to work properly with non-private-vlan interfaces on the same switch, within the same ASIC, dynamic trunking must be disabled on all non-private-vlan interfaces.
IOS-6509# config terminal
IOS-6509(config)# interface g9/1
IOS-6509(config-if)# switchport mode access
For instance, on a WS-X6548-GE-TX ports 1 though 24 share an ASIC. If you were to have interface 1 configured as a typical access port, and interface 2 configured for a private-vlan, you must disable dynamic trunking on port 1.
Check the configuration and make sure trunking is disabled.
IOS-6509# show interface trunk module 9
Port Mode Encapsulation Status Native vlan
Gi9/1 off 802.1q not-trunking 1
December 09 I remember a time when every network equipment manufacturer offered a free Windows TFTP Server for download. There also were tons of freeware TFTP Servers available all over the net created by individuals. That time seems to have passed. It's getting more and more difficult to find a decent TFTP Server these days. Even Cisco, the largest supplier of network equipment in the world no longer offers a free TFTP Server.
My requirements are probably high. The TFTP Server must run as a Windows service; must support very large file transfers, and most importantly, must be free.
For years I had been using 3Com's TFTP Service. This met my needs at the time. It runs as a Windows Service, and of course, it's free. To be completely honest this is an excellent free TFTP Server, but the maximum file size supported is 32Meg. Any file transferred that is larger then 32Meg dies at the 32meg mark and does not continue. Needless to say it was time to bid farewell to my Trusty 3Com TFTP Server.
3Com also offers the 3CServer which, other then being extremely old is truly a fantastic TFTP Server. In addition to being a TFTP Server, 3CDaemon is also a Syslog Server, FTP Server and TFTP Client. This is an excellent Swiss army knife of network tools, but alas the 3CDaemon does not run as a Windows service, nor does it support files larger then 32Meg.
If you Google "Free TFTP Server" your first hit is the SolarWinds TFTP Server. I happen to own the SolarWinds Engineers Edition which also contains this utility. To be honest the same version of the SolarWinds TFTP Server that you download for free is what comes with the Engineers Edition.
This was by far the worst of the free TFTP Servers I tried. Not only does it not run as a Windows Service (which could be resolved following the directions from one of my previous blog entries) but the file size limitation is a ridiculous 16meg. You would be better off running either of the free 3Com TFTP Servers over this crappy one from SolarWinds.
Finally I happened upon TFTP Nirvana. Most people are not aware that Windows 2000 Server and Windows Server 2003 both come with a great TFTP server. The only trouble is you need to install RIS (Remote Installation Services) to get it. The Windows TFTP Server seems to meet all of my criteria. It's free, as in "included in the OS". It runs as a Windows service, and I have been unable to find any file size limit. The only Trouble is that you need to install RIS to get the TFTP Service. Morgan Simonsen has eliminated the need to install RIS with his custom TFTP installation script. TFTPDaemon v1.1 contains everything you need to install Microsoft's TFTP service on any Windows 2k, XP, 2k3 machine.
December 04 After many attempts, and plenty of failure I have finally managed to get my Linux laptop to connect to my 802.1x WPA secured wireless network. In the end the process was fairly straight forward, but the directions were elusive. Here is my home made directions that should be reasonably portable to other networks and fairly easy for others to follow.
I am running Mandriva Linux (Formerly Mandrake) 2006 Free, which is a 3 CD set. It contains just about everything you need to get started including " wpa_supplicant" which is required for connecting to 802.1x WPA, and WPA2 protected wireless LAN's. Mandriva 2006 comes with wpa_supplicant v0.4.4.
The first thing we need to do is get the wireless card recognized under Linux. To determine if the card is detected by Linux run "lspci" which is included in the pciutils ebuild.
#lspci
02:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
If your card is not being detected you need to reconfigure you kernel with Wireless LAN support and PCMCIA support depending on your setup.
Next create a directory "/lib/windrivers" and place the windows drivers in the newly created directory.
Now we can now load the Windows driver.
# ndiswrapper -i /lib/windrivers/net5211.inf
Installing net5211
no dev ATHER_DEV_2023.ndi
I have no idea what the "no dev ATHER_DEV_2023.ndi" means but it seems to have no negative effect.
Load kernel module
#modprobe ndiswrapper
If nothing goes wrong you when you run "dmesg" you should see something that looks like this.
#dmesg
wlan0: ndiswrapper ethernet device 00:0f:b5:10:64:74 using driver net5211, configuration file 168C:0013.5.conf
wlan0: encryption modes supported: WEP, WPA with TKIP, WPA with AES/CCMP
If you now run "ifconfig" you should see your wireless interface "wlan0"
#ifconfig
wlan0 Link encap:Ethernet HWaddr 01:1B:A3:29:43:52
inet6 addr: fe84::22f:b4ff:fe10:6474/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:108255 errors:0 dropped:0 overruns:0 frame:0
TX packets:110633 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:95583648 (91.1 MiB) TX bytes:8298335 (7.9 MiB)
Memory:10800000-1080ffff
It's now time to modify our "wpa_supplicant.conf" file located in "/etc" I am running 802.1x PEAP, MSCHAPv2 and below is my configuration file.
network={
scan_ssid=1
ssid="Cisco"
key_mgmt=IEEE8021X
eap=PEAP
identity="domain\username"
password="password"
phase2="auth-MSCHAPV2"
}
Now for the moment we've all been waiting for. Time to run wpa_supplicant.
#wpa_supplicant -d -D ndiswrapper -i wlan0 -c /etc/wpa_supplicant.conf
Trying to associate with 00:11:5c:6b:90:e0 (SSID='Cisco' freq=2442 MHz)
Associated with 00:11:5c:6b:90:e0
EAP-MSCHAPV2: Authentication succeeded
EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed
If the command was successful you will need to restart the DHCP client. Most Linux distros use PUMP, but this is Mandriva so we use "dhclient"
#dhclient
Internet Systems Consortium DHCP Client V3.0.3
Copyright 2004-2005 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
Listening on LPF/wlan0/01:1B:A3:29:43:52
Sending on LPF/wlan0/01:1B:A3:29:43:52
Sending on Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.37 -- renewal in 332826 seconds.
That's it! Enjoy.
   November 25 I received a Sony PSP for my birthday so the very first thing I did was find out to what extreme I could mod it. I've always wanted to run classic console games on a portable device and the Sony PSP seemed like the perfect device to do so. Unfortunate to my surprise my Sony PSP came preloaded with firmware v1.52, which made this dream virtually impossible. The first step to achieving gaming nirvana was to find a way to back-rev my firmware to v1.50, where emulators are once again a reality on the PSP.
I rummaged around the internet and found many different directions on how to downgrade the firmware but one set of directions stood out from the rest. They were clearly written, extremely accurate, and even contained screenshots! There is not a more comforting feeling when following directions then seeing what you see in a screenshot. It happily confirms that you are on the right track.
If you are running v1.51 or v.1.52 you will need to first upgrade to v2.0. If you are running v2.1 or greater then you are totally screwed. At this time there is no method of downgrading a PSP from v2.1 or greater. Download the 2.0 Firmware from PSP-Hacks.com. If you download the 2.0 Firmware from another location make certain that it is legit. Below are the MD5 and CRC values that you can use to confirm that your PSP 2.0 firmware is legit.
File Name: EBOOT.PBP
MD5: 50C7032754835B588319C1A6C652CDC0
CRC32: F8639FF2
You can use a program like KanaChecksum to validate the MD5 or CRC32 of your EBOOT.PBP 2.0 Firmware file.
Once you have obtained your PSP 2.0 firmware, connect your Sony PSP to the USB port of your computer and put your PSP into USB connect mode.
On your computer navigate to your PSP drive in "My Computer" and create a folder named "PSP" on the Memory Stick. Within the "PSP" folder, create a folder named "GAME". Within the "GAME" folder, create a folder named "UPDATE". (Folder names are not case-sensitive.)
Copy the PSP 2.0 firmware file "EBOOT.PBP" into the newly created "UPDATE" folder on your Memory Stick.
| Notices |
| Before starting the update, you must do the following: |
|
Check that the battery is fully charged. |
|
Connect the AC adaptor to the PSP™ system and plug it into an electrical outlet. |
| |
| During the update: |
|
Do not remove the AC adaptor. |
|
Do not turn off the system or remove the Memory Stick Duo™ media. |
| If an update is canceled before completion, the system software may be damaged, requiring servicing to repair or exchange. |
On your PSP, navigate to the memory stick and select "PSP Update ver 2.00" to begin the update.
After you PSP reboots you should be running v2.00 code. This can be verified by checking "System Information" on your PSP. You should also notice the new Internet Browser that comes with the 2.0 code. It is now time to begin the downgrade to v1.50.
Step 1
File Name: MPHDowngrader.zip
MD5: 48A7BBFEF906FEDCED221D1342604A55
CRC32: 786F1F10
File Name: EBOOT.PBP
MD5: E32EB27980BA8B291EB803E3397E4B24
CRC32: A13CEEEB
Step 2: Connect your PSP to your computer via USB. On your memory stick, create a folder called UPDATE inside /PSP/GAME/ and place the EBOOT.PBP file from the 1.50 update inside this UPDATE folder.
If you have already upgraded to 2.0 using the steps above a EBOOT.PBP file already exist. You will need to overwrite this file with the 1.5 EBOOT.PBP.
Step 3: Unzip MPHDowngrader.zip. Drop overflow.tif into your /PSP/PHOTO/ folder. Put both "h.bin" and "index.dat" in the root of your Memory Stick.
Step 4: Disconnect your PSP from your computer and plug in the AC adapter.
Step 5: Navigate to Photo then Memory Stick via the PSP’s menu system and start scrolling down through your photos until you reach the "overflow.tif" picture.
You’ll know you’ve hit it when everything freezes and you get a black screen with a bunch of white text output.
If your PSP freezes without going to this black text screen, then hold the power button for about 10 seconds until the PSP shuts down, then hit the power button again to start it back up. Repeat this step until you get that black screen.
Step 6: Don’t panic. Hold the power button for about 10 seconds until the PSP powers off. Hit the power button again. Your PSP will start up, and if you navigate to your System Information, you’ll discover that your PSP thinks it is running version 1.0 of the firmware. It isn’t and you cannot run homebrew (yet).
Step 7: Navigate to Game—>Memory Stick, hit the X button, and navigate to the 1.5 updater. Make sure you have your PSP plugged in or the upgrade won’t work. Click the X button and update like you normally would. At the end of the upgrade you will receive an error saying that the upgrade failed and to contact Sony. Don’t panic. Ignore this and again force your PSP to power off and reboot.
Step 8: After the PSP reboots you will receive an error screen that is scary and confusing because it is in multiple languages. Don’t panic. Find the language you can understand and read the corresponding line. It notes that your preferences are fragged and that you need only hit the O button to restore some default-ish settings. Hit the O button.
Step 9: The PSP will start back up and you will go through the initial setup like the day when you first bought your PSP. Do so and then go to the system info pane again, where you will see that you are rocking version 1.5. Run homebrew at will.
A special thanks to Eliot Phillips and Hack A Day for some totally kick-ass directions!
Now it's time to get down and play some games. Download yourself a copy of Yet Another Homebew Pack which contains, among other things an original Nintendo (NES), Super Nintendo (SNES), Turbo GFX, Gameboy/Gameboy Color, Genisis, and a NeoGeo emulators.
Copy the contents of the "GAME" folder in the archive to the "/PSP/GAME" folder on your PSP Memory Stick. copy some ROMS to your PSP and enjoy.
November 22 There are many products on the internet that allow your to run any Windows application as a service. FireDaemon is just one of many that come to mind, but did you know that this could be done without the use of 3rd party applications. This ability has actually existed since Windows NT 4.0 but has not been very well advertised.
If you can find your Windows Resource Kit CDs you will need " INSTSRV.EXE" and " SRVANY.EXE". Once you have found these files ensure they are in your search path.
Next you will need an application you want to run as a service. For the purpose of this example I will use ShoutCast. This is an excellent freeware streaming audio server.
Once Shoutcast is installed we will open a command prompt and head to the Shoutcast directory. Mine is located in "C:\Program Files\SHOUTcast". The Shoutcast server executable is "sc_serv.exe".
To make Shoutcast run as a Windows Service we will first run the following command.
If the command was successful you should see the following message.
The service was successfuly added!
Make sure that you go into the Control Panel and use
the Services applet to change the Account Name and
Password that this newly installed service will use
for its Security Context.
Now that the service has been sucsessfully created we now need to modify it's properties. Open Regedit and go to the following key.
Example - "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<My Service>"
Mine - "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ShoutCast"
Right click on the service name key 'mine being ShoutCast', and add a new key called "Parameters"
Under the "Parameters" key create a new "String Value" called "AppDirectory". Then populate this string value with the path to your application. This is sometimes referred to as the run directory because this will be the location where the application will be run from. This is more important when you have application dependencies that do not exist in your search path.
Mine - "C:\Program Files\SHOUTcast"
Next, also under the "Parameters" key create another "String Value" called "Application". This is the path and executable that the service will run when it is started.
Mine - "C:\Program Files\SHOUTcast\sc_serv.exe"
At this point your service should start, but if you are like me you have optional switches you need to set to get the program to execute properly. For this you will need to create one final string value under "Parameters" called "AppParameters". Populate this string value with any optional executable switches you may need to set.
Mine - "config.ini"
When you are done your "Parameters" key should look similar to this.
You can now close the registry editor and start your custom made service. Enjoy!
November 20 I had someone ask me how you can build access lists for firewalls, routers and such if you are in a DHCP (Dynamic Host Configuration Protocol) environment. The very nature of DHCP is dynamic; meaning that the IP address you have today is not necessarily the IP address you will have tomorrow, or next week. That makes IP address specific access lists fairly difficult to maintain. One option is to configure the machine for a static IP address. This is where the machine no longer participates in DHCP and as such is no longer manageable from the DHCP server. This workaround is suitable for very small environments but still has the potential for IP address conflicts. An IP address conflict is when two or more machines on the same network are configured for the same IP address. The end result is usually neither machine working. This happens because the DHCP server is unaware of the Static IP address assigned to the computer, so the DHCP server offers this seemingly unused IP address to another client on the network causing an IP address conflict.
The proper way to handle this problem is with manual DHCP, also called a DHCP reservation. By finding the MAC Address of the network card we can create a DHCP reservation in the DHCP server so the client will always receive the same IP address. We start by getting to the command prompt
Click "Start" - "Run" type "cmd" then click "ok"
Once you are at the command prompt type "ipconfig /all" and then press "enter"
You should see something similar to the following.
Ethernet adapter Wireless Network Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Dell TrueMobile 1400 Dual Band
Physical Address. . . . . . . . . : 00-90-30-29-38-DA
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.0.22
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
DHCP Server . . . . . . . . . . . : 192.168.0.1
DNS Servers . . . . . . . . . . . : 4.2.2.2
38.8.81.2
Primary WINS Server . . . . . . . : 192.168.0.1
As you can see from the output above the client has an IP address of "192.168.0.22". We will now make a DHCP reservation on the DHCP server for this client for the same IP address. Before we can do this we will need the MAC address of the client. This is listed in the "Physical Address" field above.
Now go to your DHCP server and open DHCP by going to "Start" -" Run" - type "dhcpmgmt.msc" and then click "ok"
We expand the tree until we see "Reservations" for our DHCP scope. Click on "Reservations" then click "Action" at the top of the MMC and select "New Reservation"
Create a name for your reservation. Then type the IP address you want the client to have. In the "MAC Address" field enter the Physical Address / MAC Address of the client. Lastly type a description so you will know why you have created this reservation in the future. Then click "Add"
That should be it. Now you can build your firewall policies, or router access lists around this IP address with the comfort of knowing that this clients IP address will not change.
November 11 I use to dread the thought of opening a PDF file. Adobe Acrobat is such a little piggy. It's faster for me to open Word, a full blown document viewer and editor then it takes to open Adobe Acrobat Reader, which is just a document viewer.
I have used many PDF reader alternatives such as Ghostview but to be completely honest, these alternative PDF readers, although significantly faster in every way to their mainstream competitor, are usually more hassle then they are worth. Short of killing every living person who creates PDF files, the only other reasonable alternative is to find a way to make Adobe Acrobat Reader more palatable.
The root cause of the terrible startup performance is the gazillion plugins that are loaded when you launch Acrobat Reader. You would not believe the useless nature of most of these plugins. The process is simple. Remove the useless crap and you should see a 500% improvement in startup performance.
Surgery begins by locating your "plug_ins" folder. Mine is located in
"C:\Program Files\Adobe\Acrobat 7.0\Reader\plug_ins"
Create a Plug_ins_disabled folder in "C:\Program Files\Adobe\Acrobat 7.0\Reader\"
Move the entire contents of "C:\Program Files\Adobe\Acrobat 7.0\Reader\plug_ins" to "C:\Program Files\Adobe\Acrobat 7.0\Reader\plug_ins_disabled"
Now you can copy the few plugins you actually need back into "C:\Program Files\Adobe\Acrobat 7.0\Reader\plug_ins". I recommend copying "Search.api", which adds text search abilities which is always nice to have, and "EWH32.api" which is the external window handler. "EWH32.api" is important to proper operation of Adobe Acrobat Reader.
After you have completed the steps above you should be very impressed with not only how much faster Acrobat Reader opens, but also how much less memory it consumes.
If the steps listed above seem too difficult to follow, or you’re simply looking for something easier, Joseph Cox has created a freeware tool called "Adobe Reader Speed-Up" which essentially performs the same function but has a nice GUI interface to make the process as painless as possible.
Update 9/17/06
I have found utopia and it is called "Foxit Reader". I was disgusted at the unbelievable size of Acrobat Reader, coming in at a whopping 130 Megabytes installed for a READER!!! I was hell bent on finding a suitable alternative. Despite the performance improvement from the method posted above this monster was still not suitable for lower spec'd machines. Usually those lacking sufficient memory.
A few months ago I stumbled upon Foxit Reader which comes in at under 3 megabytes. Better yet, Foxit doesn't need to be installed. It's a self containted exacuatable, but there is an optional installer if that is your preference. Oh, and the best part, Foxit Reader is absolutely Free!
Since using Foxit Reader my PDF file launch times are absolutely instantaneous. I have started to fall in love with PDF files thanks for Foxit. It only took me two days of use before I was comfortable that I could completely rid myself of Acrobat Reader once and for all. It has been two months now and I have spread Foxit like a virus. I can still say I am overjoyed beyond words with it. Thank you Foxit Reader for ridding me and so many others of the crapware that is Acrobat Reader.
     October 30 When it rains, it pours. I haven't updated this blog in months, and now three times in one day.
Anyone who does P2P file sharing, or port scans running NMAP knows the frustrations imposed by Windows XP SP2. It seems Microsoft thought it would be a good idea to limit the number of raw sockets, or half open connections on a PC to only 10; with no 'supported' method of increasing this cap.
I have tried about a half a dozen tools and applications that claim to fix this problem in the tcpip.sys file, but only the Event ID 4225 Patcher has managed to do the trick 100% of the time. What I like most about this tool is that it shows you what your existing setting is, and allows you to easily restore the setting back to default. Although this tool does not completly remove the limitation, it does bump the limit from 10, to a more reasonable 50 half open connections.
 Remote Desktop is awsome. I use it constantly. However, Windows XP does not allow concurrent sessions for its Remote Desktop feature. What this means is that if a user is logged on at the local console, a remote user has to kick him off (and ironically, this can be done even without his permission) before starting work on the box. This is irritating and removes much of the productivity that Remote Desktop brings to Windows. Read on to learn how to remove that limitation in Windows XP SP2.
A much touted feature in SP2 (Service Pack 2) since then removed; was the ability to do just this, have a user logged on locally while another connects to the terminal remotely. Microsoft however removed the feature in the final build. The reason probably is that the EULA (End User License Agreement) allows only a single user to use a computer at a time. This is (IMHO) a silly reason to curtail Remote Desktop's functionality, so we have a workaround.
Microsoft did try out the feature in earlier builds of Service Pack 2 and it is this that we're going to exploit here. We're going to replace termserv.dll (The Terminal Server) with one from an earlier XP SP2 build (2055).
To get Concurrent Sessions in Remote Desktop working, follow the steps below exactly:
#1 Download the " termserv.zip" file and extract it somewhere.
#2 Reboot into Safe Mode. This is necessary to remove Windows File Protection.
#3 Copy the "termserv.dll" in the zip to "%windir%\System32 and %windir%\ServicePackFiles\i386". If the second folder doesn't exist, don't copy it there.
#4 Delete "termserv.dll" from the dllcache folder: "%windir%\system32\dllcache"
#5 Merge the contents of "Concurrent Sessions SP2.reg" file into the registry
#6 Make sure Fast User Switching is turned on. Go Control Panel -> User Accounts -> Change the way users log on or off and turn on Fast User Switching.
#7 Open up the Group Policy Editor: Start Menu > Run > 'gpedit.msc'
#8 Navigate to Computer Configuration > Administrative Templates > Windows Components > Terminal Services. Enable 'Limit Number of Connections' and set the number of connections to 3 (or more). This enables you to have more than one person remotely logged on.
#9 Reboot back into normal Windows and try out whether Concurrent Sessions in Remote Desktop works.
If anything goes wrong, the 'termserv_sp2.dll' is the original file you replaced. Just rename it to termserv.dll, reboot into safe mode and copy it back.
If you aren't so daring as to attempt the procedure above give the Sala Source Terminal Server Patch a try. This free installer should automate the steps above, complete with an uninstall should you want to remove it.
Notes: 1) You MUST be running Windows XP SP2 PRO
2) Fast User Switching MUST be enabled
3) The computer CAN NOT be a member of a domain
Once you are done, using one of the two methods above you should now be able to have someone on the console of your computer, and two people connected via RDP. I have found no method of getting more then three people on a single Windows XP SP2 machine so far, but if you have a need to, and your pockebook allows, you can always purchase WinConnect Server XP which allows you to have upto 21 users connected to a single Windows XP SP2 machine.
The Bluetooth File Transfer profile is pretty cool but if you've ever tried to transfer something large you will quickly realize this is next to impossible. For instance, my Smartphone, an MPX220 has only 32meg of storage space on the device, but I also have a 512meg MiniSD card to handle the big stuff. The trouble is, when you transfer something from your computer to your Smartphone, the saved item always goes to "\Storage\My Documents" which is the phones local storage, not the storage expansion card. This is fairly limiting as you can not transfer items that are larger then the free space on your phones built-in strorage.
After screwing around for a while I found a way to change the default save location for incomming BlueTooth file transfers. For the purposes of this example the default (built-in) storage on the phone is "\Storage" and my MiniSD card is "\Storage Card"
You will need to obtain a Registry Editor for the Smartphone or Windows Mobile device. I recommend " PHM Registry Editor". It's easy to use, and best of all it's free.
Once you have installed your registry editor goto the following registry key.
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Obex\Services\{f9ec7bc4-953c-11d2-984e-525400dc9e09}\BaseDir"
There you will change the default save location from "\Storage\My Documents\" to some place else, such as "\Storage Card\My Documents"
Exit the registry editor and give it a shot. Now you are only limited to the free space on your storage card.
Update: 9/17/06
I received my new iMate Smartflip / QTEK 8500 a few weeks ago and I noticed that Bluetooth file transfer to the device was disabled by default. This is probably due to security concerns. Anyway this was fairly easy to enable using your registry editor of choice.
Goto the following key
HKEY_LOCAL_MACHINE\Software\Microsoft\Obex\
Change the following DWORD value from "0" to "1"
IsEnabled = 1
Once you reboot the phone OBEX Bluetooth file transfers are enabled
 July 30 Not everyone has a domain/Active Directory. Some people have a small office with a handful of computers. If you are running Windows XP in your small office you might want to take advantage of one of the coolest features in Windows XP, Remote Assistance. Remote Assistance allows you to help a friend or co-worker with a difficult problem they might be having with their computer. There are many different ways you can initiate Remote Assistance. Most commonly these methods require the end user to initiate a request for help. In an environment where your users may be incapable of requesting assistance on their own you can initiate Remote Assistance without solicitation. The only guidelines are that you must be logged into your machine with an account that also exists on the remote with the same password. You should also be a member of the same workgroup.
So for this exercise I have two Windows XP machines. One is mine 10.0.0.1/24, and the other is the remote. 10.0.0.2/24. We are both in the workgroup "WORKGROUP". I have an account on my machine and on the remote computer with the username "aLTeReGo" with a password of "password". I am an administrator on both computers.
(Configure Unsolicited Remote Assistance on remote computer)
Open the MMC - Click "Start" - Click "Run" - type "mmc" - click "ok"
Go to - "File" - "Add/Remove Snap-in"
Select "Group Policy" - Click "Add"
Make sure the Group Policy Object listed is "Local Computer" and click "Finish"
Close the "Add Standalone Snap-in" window
Click "Ok" on the "Add/Remove Snap-in" Window
Expand "Local Computer Policy" [+] - "Computer Configuration" [+] - "Administrative Templates" [+] - "System" [+]
Click on "Remote Assistance"
On the right window pane double click "Solicited Remote Assistance"
In the "Solicited Remote Assistance Properties" click "Enabled" then Click "Apply" and "ok"
Also on the right window pane double click "Offer Remote Assistance"
In the "Offer Remote Assistance Properties" click "Enabled"
Be sure "Allow helpers to remotely control the computer" is selected in the "Permit remote control of this computer pull down box.
Lastly, click on the "Show" button next to "helpers:"
In the "Show Contents" window click "Add"
Type the name of the users account you wish to receive unsolicited remote assistance from. In this case I type "aLTeReGo" and click "ok"
Make sure the users name is listed in the "Show Contents" window before clicking "ok"
Click "Apply" and then "ok" on the Offer Remote Assistance Properties page.
(Let’s help someone)
On the Remote computer Sally is logged in as a normal user and has called me for help. I have already configured Sally's machine with the above steps. I have created a shortcut on my desktop that takes me directly to Remote Assistance. The shortcut target is.
"%windir%\PCHealth\HelpCtr\Binaries\helpctr.exe /url hcp://CN=Microsoft%20Corporation,L=Redmond,S=Washington,C=US/Remote%20Assistance/Escalation/unsolicited/unsolicitedrcui.htm"
When I click on that shortcut I am asked to enter the IP or name of the remote machine. I enter Sally's IP address 10.0.0.2 and click "Connect".
At this point I am connected to Sally's machine and I am able to help her.
July 26 I have recently been challenged by my Senior Desktop Tech to prepare for Wake on LAN. The desktop group will be utilizing Microsoft's SMS for remote software distribution and it is preferable to perform this function after hours so as not to disturb the end users during normal operating hours. At present SMS does not provide any wake on LAN ability (WoL) out of the box so the desktop group has decided to use SMSWakeUp by 1E software. This particular SMS product utilizes directed broadcast for WoL. Anyone who knows anything about network security knows that directed broadcast is evil. Most commonly associated with Smurf and Fraggle attacks, directed broadcast allows a client to send a broadcast packet to another subnet. In the case of a Smurf attack, which is the most common, the attacker sends an ICMP Echo Request packet (ping) to the broadcast address of the remote subnet (10.0.1.255 in the case of a 10.0.1.0/24). The result of the ICMP being broadcast across the entire subnet is all devices on that subnet will return an ICMP Echo Reply. In the cast of our test network a maximum of 254 devices could return ICMP Echo Reply packets. On larger subnets this could be thousands of clients. If the attack was prolonged, beyond a single ICMP broadcast the result would most likely be a denial of service (DoS) attack. This would bring the network to a crawl or possibly a dead stop until the attacker can be found and stopped. Fraggle is exactly the same as Smurf but it uses UDP instead of ICMP, but both use directed broadcast to attack the network. So with that little bit knowledge under your belt why would you want to enable directed broadcast anyway? Well in my case it's the only WoL method supported by SMSWakeUp. Come to think of it I can't think of any reason why you would ever want to enable directed broadcast other then for WoL. So it's best to ensure that it is disabled whenever it's not needed. This is the default behavior for all Cisco equipment since 1994. For the purpose of this article I will assume that the router is default and directed broadcast disabled. VLAN1 will be the source of the WoL where our SMS server resides, and VLAN2 is where all of our clients are. The SMS server is 10.0.0.1 and the remote client is 10.0.1.10/24 (255.255.255.0). The only interfaces that need to be modified are the interfaces that the device you want to wake up is located. So in this case it's VLAN2. (Configuring the interface to allow directed broadcast) router# config terminal router(config)# interface vlan 2 router(config-if)# ip directed-broadcast 102 router(config-if)# end The "102" specifies an access list that we will define to limit who can send directed broadcasts. This is EXTREAMLY important as explained above. (Define the directed broadcast access list that will limit who can send directed broadcast) router# config terminal router(config)# access-list 102 permit udp host 10.0.0.1 host 10.0.1.255 eq 1778 router(config)# access-list 102 deny ip any any router(config)# end The above configuration limits directed broadcast to the 10.0.1.0/24 subnet "VLAN2" from only the SMS server "10.0.0.1". All other directed broadcasts from any other machine would be dropped by the router. Now if you have no access lists defined on the VLAN, or your access lists are inward in direction "ip access-group XXX in" you are done. SMSWakeUp should work. Any other wake on LAN utility should work provided you replaced the "1778" above with your products appropriate port number. However, if your access lists are running on the outwardly directions (ip access-group XXX out) then you still have more work to do. Because outbound access lists are similar to fire walling a VLAN all traffic coming into that VLAN is denied unless otherwise stated. Inbound access list allow all traffic to enter the VLAN but limit what traffic can leave that VLAN. If you have inbound access lists the WoL directed broadcast is inherently allowed because of the direction of the access list. Your only protection is the directed broadcast access list we defined above. This should be sufficient for most applications and is most commonly found way of writing access lists. (Define VLAN access list to allow directed broadcast to enter the VLAN) For this demonstration I will use access list 103 but you can apply this to any existing outbound access list. router# config terminal router(config)# access-l 103 permit udp host 10.0.0.1 host 10.0.1.255 eq 1778 log router(config)# access-l 103 permit udp host 10.0.0.1 host 255.255.255.255 eq 1778 router(config)# access-l 103 deny ip any any router(config)# end The above VLAN access list permits only the SMS server "10.0.0.1" to broadcast to the 10.0.1.0/24 subnet. All other traffic is denied. Again this access list is not necessary if you have inbound access lists. July 20 Anyone who has to manage access lists on routers or firewalls will know what I'm talking about. RPC through packet filters sucks. If you leave a Windows server as-is out of the box RPC is uncontrollable using literally any port above 1024. This makes filtering traffic impossible. The RPC service on a server is used for many different Windows services such as the Management consoles for DNS, DHCP, and SMS to name only a few. Active Directory and Exchange also use RPC for various reasons such as Outlook client connections to the Exchange server. It is particularly desirable to protect your Exchange server to the absolute best of your abilities and having no access control in place to prevent hackers from intruding on your exchange server is a big mistake.
The trick to securing the server but still allowing things to work is to limit RPC to a range of ports. In the case of Exchange you can statically map specific ports for the necessary services further limiting your exposure.
If you wanted to limit RPC to a port range between 5000 and 5020 on a Windows NT/2000/2003 Domain controller for instance you would go to the following registry key.
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
Create a new Key called "Internet" under "Rpc"
Within the "Internet" key create a new Multi-string Value called "Ports" with the value "5000-5020"
Next create a "String Value" called "PortsInternetAvailable" with a value of "y"
Lastly create a "String Value" called "UseInternetPorts" with the value of "y"
When you are done it should look like the following
Ports: REG_MULTI_SZ: 5000-5020
PortsInternetAvailable: REG_SZ: Y
UseInternetPorts: REG_SZ: Y
After you reboot the machine the RPC port range will take affect.
If you are Running Microsoft Exchange 2000/2003 you will want to statically map the ports used instead of allowing Exchange to dynamically selecting a port at random. The three services that will need to be statically mapped to a port are the System Attendant, Information Store, and the Name Service Provider Interface (NSPI).
First we will statically assign the System Attendant to port 5001 by going to the following Registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters
Now set the "TCP/IP Port" string value with value "5001"
Next stately assign the Service Provider Interface (NSPI) services to port 5002 by changing the string value "TCP/IP NSPI" to "5002"
Lastly we will assign the Information Store to port 5003 by going to the following registry key.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Modify the string value "TCP/IP Port" to "5003".
When you reboot your Exchange server the changes will take effect. Now you can significantly reduce the number of exposed ports on your Exchange Server.
|
Tools 
