A subscriber profile specifies services for automatic connection. The subscriber profile also controls whether or not the service is hidden or not. If an auto connect service is hidden, it does not appear in the service list displayed on a service connection page.
In RADIUS mode, to configure a service for automatic connection, use the Account-Info A attribute in the subscriber profile. See Table C-6 for more information.
In LDAP mode, to configure a service for automatic connection:
Subscribers can use the web portal's self-management features to select and deselect the auto connect feature for a service.
Administrators can use CDAT to maintain subscriber profiles. See the Cisco Distributed Administration Tool Guide for information.
Return a service list to SSG—In this case, RDP includes the subscriber's service list and related information in replies to SSG, and SSG performs automatic connections for services marked for auto connection in the subscriber's profile.
The service information consumes memory on the SSG host.
Not return a service list to SSG—In this case, SSG cannot perform automatic connections. The advantage to this configuration is that it saves memory on the SSG host.
In this case, you can configure the SESM application to perform automatic connections. The following line in the application MBean configuration file (for example, nwsp/config/nwsp.xml) controls whether the SESM web application performs automatic connections:
If the subscriber's home URL is set to an autoconnect service, the pop-up window for the service might appear before the connection completes. If this occurs, the following message appears in the pop-up window:
Page cannot be displayed.
The URL is correct. If the subscriber waits a short time and resubmits the request using the URL already displayed in the window, the service pages appear.
For example, a subscriber might select the auto connect property for a service, log out of SESM, log back in, and notice that the service was not automatically connected. Caching in the RDP causes this delay.
Caching in RDP improves system performance. The deployer can turn off caching or reduce the cache period, but those actions impact performance.
The SESM session might expire, for example, because the subscriber closed the browser or navigated away from the SESM pages. When the SESM session expires:
Without single sign-on, subscribers are required to reauthenticate when they navigate back to the SESM portal application. As a result of the reauthentication, SSG reconnects the auto connect services.
We recommend running SESM portal applications with single sign-on turned on.
Personalized portals—Taylor the subscriber experience based on location characteristics.
Access policies—Allow free services to a certain segment of subscribers based on connection characteristics, such as VPI ranges or subinterface ranges. For example, location awareness could permit certain subscribers from a certain location to gain access to the Internet service without authentication.
Redirections—Redirect all browsers with particular location characteristics to a specified portal page.
The portal can use the location as a dimension in the user shape to help determine the resources to use in the returned JSPs. NWSP uses this method to determine a location-specific image to use in the NWSP banner. See the Subscriber Edge Services Manager Web Developer Guide for more information about the user shape mechanism, the location attribute in the locationDimension.jsp, and the SESMSession object.
NWSP uses the location dimension in the user shape to return different images on JSP pages based on location. To implement this usage, NWSP uses the configured location name to identify the subdirectory containing the correct image for each location. Therefore, the configured names must match the subdirectory names. For examples, see the following:
nwsp
webapp
london
newyork
paris
NWSP associates arbitrary attributes to locations. The location names in the arbitrary attributes configuration must match the names used in location awareness configuration. For examples, see the "Configuring Arbitrary Attributes" section.
Note To use location awareness based on complete ID, your SSG platforms must be running
Cisco IOS Release 12.3(1)T or the X train for Release 12.2(8)B.
Use the Location MBean to define location names and the attributes that are associated with each location. For information about the Location MBean, see the "Multikey Authentication" section.
You can use multiple attributes to define a location. For example, the installed nwsp.xml file configures a "paris" location that applies to all sessions with a VPI from 1 to 3 on the subinterface ATM3/0. Both requirements must match for the location to apply to a session.
Each attribute definition in a location is restricted to one value or one range. However, you can define more than one location with the same name using the same attributes, but with different attribute values. For example, you could define two "london" locations, each one using a different IP address range.
Identify the first matching location—The portal associates the first location whose configured attributes match all of the attributes of the edge session. The ordering of locations in the configuration file is important. NWSP implements location awareness using this method.
Identify all matching locations—This feature provides a way to process nesting and overlapping locations. The portal must be customized to process all matching locations in some way. To implement this feature, see the next section.
To implement nested or overlapping locations, you can customize the portal to use the getLocations method. This method returns an iterator over all the locations that match the attributes for the session, in the order that the locations appear in the configuration file.
In the following example, two locations overlap for sessions with a client IP address in the range 10.4.0.0 to 10.8.0.0.
Location A is defined for client IP range 10.0.0.0 to 10.8.0.0.
Location B is defined for client IP range 10.4.0.0 to 10.32.0.0.
In the following example, two locations overlap for sessions with a client IP address in the range 10.0.0.0 to 10.8.0.0 that are connected via the subinterface Ethernet 0/0.
Location A is defined for client IP range 10.0.0.0 to 10.8.0.0.
Location B is defined for the sub-interface Ethernet 0/0.
Location A is defined for the sub-interface ATM0 and VPI number 1 to 3.
Location B is defined for the sub-interface ATM0.
When defining nested interfaces, it is usually best to define the smallest location first. In the example above, this would be Location A. This is because only the first match is returned when looking for a single location, so any nested locations would effectively get hidden if they were not placed in the configuration before the location they are nested inside.
There is no restriction on how deeply locations can be nested.
To configure locations based on IP address subnets, use the SSG MBean. Use setSubnetAttribute entries with the SESSION_LOCATION argument. The following example from nwsp.xml shows the attributes required for location awareness:
Table 5-5 describes how to format subnet entries. The following points relate specifically to location awareness:
ipAddress and mask indicate one of the following:
A range of subscriber IP addresses (a subnet)—Use the IP address and Mask fields to indicate a subnet of IP addresses to associate with the same location. If port-bundle host key is configured on the SSG, the range will apply to SSG IP addresses, rather than subscriber IP addresses.
A specific IP address—The IP address is that of the client, or, if port-bundle host key is configured on the SSG, one of the SSG IP addresses specified in the port-bundle host key port map configuration.
location is the location you want to associate with ipAddress. Any value is acceptable, but it must match your intended uses.
Any value is acceptable, but it must match your intended uses. For example:
NWSP uses different images for each location. The images are stored in subdirectories whose
The following example associates locations with subscriber subnets. The example associates a different subscriber network with each of the three example locations defined in Step 2. In the NWSP application, when subscribers from the 144.0.0.0 network point their browsers to the NWSP URL, they receive a page containing the words New York under the NWSP logo.
When the port-bundle host key feature is configured on the SSG, location must be associated with an SSG IP address, rather than the subscriber's IP address. In the following example, the IP address is an SSG source IP address included in the port mappings during port-bundle host key configuration.
Step 1 Install SESM in RADIUS or LDAP mode, using a typical or custom installation. (Do not use Demo.)
Note You cannot use Demo mode to show location awareness using complete ID attributes.
Step 2 Comment out the location subnet entries in the SSG MBean.
Step 3 Edit the Location MBean to include a specific IP address for the "paris" location. Use the IP address of a client machine that is available for the demonstration. Use the same IP address in the start and end parameters.
Step 4 Add a new location to the Location MBean for "newyork." (Use this value because the installed files include a subdirectory and an image for the newyork value.) For example, insert these lines into the locations array:
Step 6 Open browsers on each of the client systems.
Step 7 From each browser, go to the SESM URL. For example, go to http://serverName:8080.
Step 8 Notice the images in the banners on each browser. One should say London; the other should say New York.
Step 9 On a third machine, repeat steps 7 through 9. The banner should not include a city name, because the third browser's IP address is not associated with any location in the configuration file.
To demonstrate location awareness based on subnet entries, use the following procedure:
Step 1 Install SESM in Demo mode.
Step 2 Edit setSubnetAttribute parameters in the SSG MBean to include specific IP addresses for two different client machines that are available for the demonstration. For example:
Step 4 Open browsers on each of the client systems.
Step 5 From each browser, go to the SESM URL. For example, go to http://serverName:8080.
Step 6 Notice the images in the banners on each browser. One should say London; the other should say Paris.
Step 7 On a third machine, repeat steps 7 through 9. The banner should not include a city name, because the third browser's IP address is not associated with any location in the configuration file.
For example, NWSP uses arbitrary attributes to associate URLs with locations. In this case, the elements in the multi-dimensional table are as follows:
One dimension of the table consists of the location values, which must be defined using the location awareness feature.
Another dimension is the URL to associate with each location.
At run time, SESM constructs a reference table holding all of the configured values. The arbitrary attribute values are available for use by the SESM portal. For example, NWSP uses arbitrary attributes associated with locations to help determine the initial URL for an Internet service pop-up window.
attributeID identifies a category of entries in the attribute table. Use the same attributeID for all entries associated with the same purpose.
attributeKey identifies the location values. For example, the installed WebApp MBean includes the values london, paris, and newyork. The location values must be defined in the location awareness feature.
Note Make sure the location values match exactly the definitions used for location awareness. For
example, the "London" and "london" are considered different values.
Note The user shape mechanism and the addDimension calls are different features. The user shape
mechanism has no dependencies on any values defined in the addDimension calls.
attributeResult defines a URL that you want to associate with the attributeKey.
1. If the subscriber request was captured by the SESM Captive Portal application, the subscriber's initial URL request is used.
2. Otherwise, if a location in an addDimension call matches the LOCATION attribute from the SESMSession object, the URL associated with the location is used.
3. Otherwise, if the subscriber profile includes a non-blank H attribute, that URL is used.
Demonstration Procedure
To demonstrate the use of an arbitrary attribute to control an item on a JSP page, use the following procedure.
Step 1 Configure location awareness. You can use either location awareness method: subnets configured in the SSG MBean, or complete ID attributes configured in the Location MBean.
Step 2 Edit the parameters to the addDimension calls in the WebApp MBean. Make sure the second argument in the addDimension call matches exactly the location strings you defined for location awareness. The installed nwsp.xml file contains the following lines:
Step 4 Start a browser on a system whose location was configured in Step 1.
Step 5 Go to the NWSP URL.
Step 6 Login using the following values:
RADIUS mode demos:
User: radiususer
Password: cisco
LDAP mode demos:
User: golduser
Password: cisco
Step 7 Select the Internet service from the NWSP service list (if the Internet service was not automatically configured.)
A service pop-up window appears, attempting to go to the URL in the addDimension call. For example, the london location attempts to go to www.london.com.
Note If you configured the Captive Portal application, the browser's original request is honored
instead of the arbitrary attribute associated with the location.
My Firewall page—This is a basic firewall page that allows subscribers to create filters on specific applications and protocols. The subscriber can choose to permit or deny all traffic for each of the applications/protocols. The list of applications and protocols that appears on the My Firewall page is preconfigured by the deployer in the Firewall MBean.
Advanced Firewall page—This page provides a way for the subscriber to create more specific filters than the basic page. They can create filters that permit or deny traffic for specific source and destination IP addresses, ranges of IP addresses, or ports.
The SESM firewall features are supported only when SESM is running in LDAP mode with RDP deployed in non-Proxy mode. The SSG (or some other cooperating network element that can process extended access control lists) is required.
The ACLs are stored in the subscriber profiles as a standard RADIUS attribute with number 26 (vendor specific attribute), subattribute number 1 (Cisco AV-pair). A subscriber profile might have many ACL entries, which together determine which traffic is permitted and denied on the connection.
The ACLs are added to the profile in two ways:
The SESM portal creates the ACLs and adds them to the profile as a result of subscriber entries on the portal firewall pages.
Deployer administrators manually create correctly formatted ACLs and enter them in the subscriber profile using CDAT.
SESM and SSG (or another cooperating network element) implement the personal firewall ACLs as follows:
SSG sends an access-request message to RDP.
During authentication processing, RDP obtains the subscriber profile from the directory and includes all of the profile information, including the ACLs, in the access request reply it sends back to the SSG.
The SSG applies the ACLs against traffic to and from the subscriber's connection.
In the SESM ACLs in a subscriber profile, priority is based on an ACL number . (The lowest ACL number is applied first.) The ACL numbering scheme used by SESM enforces the following general priorities:
Administrative ACLs have the highest priority. These ACLs are entered by the deployer in CDAT should contain ACL numbers in the range from 100 to 109. It is up to the administrators entering the ACLs to enforce this convention.
ACLs generated from the Advanced Firewall page have the next priority. The SESM portal automatically assigns these ACL numbers.
ACLs generated from the My Firewall page have the lowest priority. The SESM portal automatically assigns these ACL numbers.
See the "ACL Number Assignments" section for a description of how SESM assigns the ACL numbers to ensure that the most specific ACLs are applied first, and the more general ACLs last.
Firewall Enabled or Disabled—When the page displays, this button indicates whether any subscriber-entered filters exist for this subscriber:
Enabled—At least one subscriber-entered filter exists in the subscriber's profile. The filters can be those entered on the My Firewall or Advanced Firewall page. Administrative ACLs, if any exist in the profile, are not considered.
Disabled—This subscriber profile contains no subscriber-entered filters. If the window opens with Enabled selected, and the subscriber clicks Disabled followed by OK, it deletes all subscriber-entered filters from the subscriber profile. The action does not delete administrative ACLs if the adminstrator used the reserved administrative ACL numbers (numbers 100 through 109.)
Note Once deleted, the ACLs cannot be retrieved. They must be reentered.The deployer might want
to customize the NWSP My Firewall page to remove the Disable button or move the button to
the Advanced Firewall page.
Permit All Else or Deny All Else buttons
When a subscriber profile contains one or more ACLs, an implicit default denies all other traffic not addressed by the existing ACLs. This deny-all-else implicit default is imposed by the Cisco router hosting the SSG or other cooperating network element.
The Permit All Else or Deny All Else radio buttons offer a way for the subscriber to explicitly impose a default behavior. A deployer could decide not to display these buttons and allow the implicit behavior to operate. In this case, the page would not need the Deny button next to each application.
When firewalls are enabled, the subscriber must consider whether to permit or deny traffic for each of the applications listed on the Firewall page. To do this, the subscriber can:
Consider each application separately, and select whether to permit or deny traffic for it.
Allow the default action to apply. They choose the default action by selecting either the Permit All Else or Deny All Else button.
Applications/Protocols
Lists the applications available for firewall settings. This list is configured by the deployer, as described in the "Configuring the Firewall Pages" section. For each application in the list, the subscriber can specify whether to deny or permit traffic. The ACLs that NWSP generates for this page will specify that all source and all destination IP addresses are subject to the control being defined in the ACL.
Note The subscriber can use the Advanced Firewall Page to obtain finer control in the ACLs, such as
specifying specific IP addresses or ports that are subject to the control.
Permit/Deny/Default buttons—The portal determines the initial setting for each item in the Application/Protocol list, as follows:
If no ACLs exist or if only one ACL exists in the subscriber's profile for the application/protocol, Default is selected. In a typical production deployment, most applications initially appear in the default state, because there are no specific ACLs in the subscriber profiles.
If the application/protocol has more than one ACL in the subscriber profile:
If all ACLs have the same permission (that is, all are permit or all are deny), then the corresponding Permit or Deny is selected.
Otherwise, if some ACLs specify permit and others deny, then Default is selected for that application.
First Time Access of My Firewall Page
The default state of a subscriber profile is one in which no ACLs are defined. The first time the subscriber goes to the My Firewall page, the settings are:
Firewall Disabled—Indicating that there are no ACLs imposing any controls on traffic to or from the subscriber.
Deny All Else—Ignore this button when firewalls are disabled.
For all applications and protocols, the Default buttons are selected.
When ACLs exist in the subscriber profile, the SESM portal analyzes the ACLs and renders the page based on the ACLs, as described in the previous section.
From me/To me entries—Subscribers can enter filters for upstream or downstream traffic.
From me to these destinations— These entries filter messages that the subscriber can initiate.The filters are based on the destination IP address, port, protocol, and application entered by the subscriber.
The source is the subscriber. In the NWSP application, the source IP address for these entries is always set to "any" and source port is not specified. SESM developers can alter the Advanced Firewall JSP, adding fields to let the subscriber enter source IP address and port.
To me from these sources—These ACLs filter messages that the subscriber can receive. The filters are based on the source IP address, port, protocol, or application entered by the subscriber.
The destination is the subscriber. In the NWSP application, the destination IP address for these entries is always set to "any" and destination port is not specified. SESM developers can alter the Advanced Firewall JSP, adding fields to let the subscriber enter destination IP address and port.
See the Subscriber Edge Services Manager Web Developer Guide and the SESM javadoc for more information about development options for JSP pages.
Any/Specific Address—Indicates whether this ACL applies to any IP address or to specific IP addresses provided in the IP Address and Mask fields.
IP Address and Mask—Specifies the source or destination IP address or address range that is being permitted or denied. Any ACL can specify IP addresses. Be sure to click the Specific Address radio button (above) if you are including an IP address.
The mask for ACLs is inverted from the more familiar net mask. Bits in the mask are zero if the respective bit in the address should match. For example, if the ACL should filter addresses x.x.x.0, then the mask is 0.0.0.255.
IP Protocol—Specifies the Internet protocol to filter:
Any IP—Filters all IP traffic.
tcp—Filters TCP traffic.
udp—Filters UDP traffic.
<0-255>—Filters traffic based on a protocol number specified in the IP Protocol Number field.
IP Protocol Number—A number in the range 0 through 255. Protocol numbers refer to protocol configurations on the SSG host or other routing device. For example, TCP corresponds to the protocol number 6.
Port Operator (=, !=, >, <)—Valid only when IP Protocol is TCP or UDP. The operator applies to the application protocol port number. (Each application protocol name is an alias to a port number.) The operator is used to compare the port in a packet to the port specified in the ACL.
= requires the port values to match
!= requires that the port values not match
> requires that the port in the packet be greater than the port value specified in the ACL
< requires that the port in the packet be less than the port value specified in the ACL
Choose <0-65535> from this drop down list and provide the appropriate port number in the Port Number field.
Choose an application from the Application drop down list. This list consists of all of the application port aliases configured in the Firewall MBean for TCP. The corresponding port number automatically appears in the Port Number field.
In NWSP, the Application drop down list is meaningful only when IP Protocol is TCP. If IP Protocol is UDP, the subscriber must choose <0-65535> and explicitly enter the correct UDP port number in the Port Number field.
Note If the subscriber chooses an application from the list when IP Protocol is UDP, NWSP uses the port number that corresponds to the selected application. The deployer could customize NWSP to implement a separate drop down list for UDP applications. Alternatively, the deployer could remove the Internet Protocol and Internet Protocol Number fields, making TCP the default, in which case the existing list of applications would always be appropriate.
Port Number—Valid only when IP Protocol is TCP or UDP and Application Protocol is <0-65535>. Enter the application port to filter. The port number must match the port configured for the application or protocol on the SSG host device or other cooperating network element.
Permit—Adds the permit keyword to the generated ACL. The permit keyword allows a message to travel to its destination when the message matches the conditions in the ACL.
Deny—Adds the deny keyword to the generated ACL. The deny keyword prevents a message from traveling to its destination when the message matches the conditions in the ACL..
Delete Entry—Deletes this ACL from the subscriber profile. If this is a new entry, using this button has no effect on the subscriber profile.
Note To be added to the subscriber profile, a new entry must have either the Permit or Deny button
selected.
The three action buttons at the bottom of the window are:
OK—Adds the changes to the subscriber profile.
Go Back— It cancels any changes you made on the page since last using OK and returns to the My Firewall page
Reset—Cancels any changes you made on the page since last using OK and redisplays the page, showing the settings that currently exist in the subscriber profile.
Depending upon CDAT privileges, which are assigned within CDAT, the administrator might be permitted to add, change and delete ACLs from the profile through CDAT.
NWSP does not provide a way for subscribers to view the generated ACLs.
A specific port number associated with the chosen application.
Subscribers must use the Advanced Firewall page to create ACLs that filter on specific addresses or multiple port numbers.
The ACLs generated from the My Firewall page are in the following form:
[inacl# | outacl#]Number=permissionprotocol any any eq portNumber [established]
Where:
inacl# or outacl# is used, depending on the value of the direction attribute in the Firewall MBean.
inacl#—Applies the ACL to upstream traffic, which is traffic from the subscriber
outacl#—Applies the ACL to downstream traffic, which is traffic to the subscriber
All TCP connections require a return path. A block on upstream traffic also affects the traffic traveling in the opposite direction, and vice-versa, if there is no ACL allowing established connections in the same direction as the block. For example, blocks on downstream traffic and an ACL allowing established connections on downstream traffic would allow the TCP upstream traffic.
The choice of whether to control the in or out direction in the My Firewall ACLs is a matter of preference for the deployer to decide. All ACLs generated from the My Firewall page use the same direction.
protocol is the configured protocol for the application, as defined in the Firewall MBean. Examples are tcp, udp, ip, and so on.
"any any" are keywords in the source IP address and destination IP address fields. The keyword "any" specifies that all source and all destination IP addresses are subject to the control being defined in this ACL. Subscribers must use the Advanced Firewall page to create filters on specific IP addresses.
"eq" is a keyword in the operator field. The keyword "eq" specifies that the filter applies to traffic whose source or destination port matches (equals) the value in portNumber. All ACLs generated from the My Firewall page use the "eq" keyword. Subscribers must use the Advanced Firewall page to specify other operators.
portNumber is the port number related to the application, as defined in the Firewall MBean.
inacl#—The subscriber entered the ACL in the "From me to these destinations" section. The ACL applies to upstream traffic, which is traffic from the subscriber.
outacl#—The subscriber entered the ACL in the "To me from these sources" section.The ACL applies to downstream traffic, which is traffic to the subscriber.
All connections have a return path. A block on upstream traffic also affects the traffic traveling in the opposite direction, and vice-versa. The choice of whether to control the in or out direction in the Advanced Firewall is a matter of preference for the subscriber.
ACL numbers are not permanent. Each time a subscriber uses the firewall pages to add or change ACL entries, the SESM portal reexamines all ACLs in the subscriber's profile and reassigns ACL numbers.
Table 10-2: ACL Numbers for Automatically Generated ACLs
Priority
ACL Number
Explanation
Highest Priority
100 - 109
Reserved for administrative ACLs.
110 - 119
ACLs from the Advanced Firewall page, when no application is specified. The explanation below for the 3rd digit applies to these ACLs as well.
120 - 189
ACLs from the My Firewall page. The numbers within this range are assigned as follows:
1st digit—Is always 1 (1xx)
2nd digit—Indicates the number of ACL entries that currently exist in the subscriber's profile for the same application:
12x—Applications with 1 ACL entry
13x—Applications with 2 ACL entries
...and so on
18x—applications with 7 or more ACL entries
3rd digit—Indicates how specific the IP addresses and ports are, with lower numbers (higher priority) given to ACLs containing the most specific address and port information:
1x0—Not used.
If neither source nor destination addresses are "any":
1x1—Both source and destination ports are specified
1x2—Either source or destination port is specified
1x3—Neither source nor destination port is specified
If either source or destination addresses is "any"
1x4—Both source and destination ports are specified
1x5—Either source or destination port is specified
1x6—Neither source nor destination port is specified
If both source and destination ports are "any"
1x7—Both source and destination ports are specified
1x8—Either source or destination port is specified
1x9—Neither source nor destination port is specified
Example: A profile contains two ACLs for the same application, both with specific source addresses, destination addresses of "any", and no ports. The ACL number for both is 136.
190 not used
191 - 193
Internet protocol (IP) settings on the Advanced Firewall page:
191—Both source and destination addresses are specified
192—Either source or destination address is specified
193—Neither source nor destination address is specified
Lowest priority
194 - 196
Internet protocol (IP) settings on the My Firewall page:
194—Both source and destination addresses are specified
195—Either source or destination address is specified
196—Neither source nor destination address is specified
Although the LDAP directory is updated with the new information, the new ACLs do not take effect until a subscriber reauthenticates (logs out and logs in again). Also, the RDP cache must be refreshed, which by default takes 10 minutes. Due to the possibility of just having missed a refresh, the minimum guaranteed time is double the cache refresh time.
Interaction Between Entries on the My Firewall and Advanced Firewall Pages
The ACLs created from the Advanced Firewall pages have higher priority than ACLs created from the My Firewall page. Therefore, the subscriber might see filtering information on the My Firewall page that does not get applied to traffic because it is overridden by filters on the Advanced Firewall page.
Similarly, ACLs created by administrators (if they use the reserved ACL numbers 100 through 109) have the highest priority. Therefore, the subscriber might see filters on either the My Firewall or Advanced Firewall page that does not get applied to traffic because it is overridden by the administrative filters.
Safeguards
SESM and SSG include the following safeguards regarding firewalls:
Subscribers cannot inadvertently deny themselves access to the SSG or the default network. SSG does not apply ACLs if the packet is going to the default network.
Subscribers cannot inadvertently deny themselves access to open garden services. SSG does not use the subscriber's personal ACLs on packets coming from and going to open-garden services or in local-forwarding. (A set of host ACLs might apply in these cases.)
ACLs generated from the Firewall pages are correctly formatted.
Subscribers must have the SESMFirewall permission to use the firewall pages. Subscriber permissions are assigned in CDAT, in the user and group windows.
Administrators must have the appropriate permissions to add or update user profiles. Administrator permissions are assigned in CDAT.
If you create ACLs in CDAT using ACL numbers in the range from 110 to 196, (the ACLs reserved for use by the subscriber self-configured ACLs), you risk the following:
You might interfere with the personal firewall settings created by the subscriber.
You provide the opportunity for the subscriber to reverse your settings.
Step 2 Log in as an administrator with permissions to modify subscriber profiles.
Step 3 Access the subscriber or group profile.
Step 4 Enter the ACLs in the Local RADIUS attribute field, using the format described in the following section.
Step 5 If a subscriber is currently logged into an SESM session, the new ACLs do not take effect until the subscriber reauthenticates (logs out and logs in again). Also, the RDP cache needs to be refreshed, which by default takes 10 minutes. Due to the possibility of just having missed a refresh, the minimum guaranteed time is double the cache refresh time.
This section describes the format of the firewall entries in the Local RADIUS attribute field in CDAT. The ACLs entered in CDAT can use the full range of ACL options as described in the Cisco IOS documentation for extended ACLs.
The general format for the Local RADIUS attribute field is:
attribute:value
In the case of the firewall ACL entries:
attribute is Cisco_AV
value is the ACL whose format is described below
The format of the ACLs entered by administrators is:
ACLnumber is in the range from 100 to 109. The numbers indicate priority in the ACL evaluation. ACLs with the lowest numbers are analyzed first. The order is important because ACL processing stops when the first match occurs.
ACLs whose numbers are in the range 100 to 109 will have higher priority than any ACLs created by subscribers using the My Firewall page. (The range of ACL numbers reserved for use by the My Firewall page is 110 to 196.)
ACLs whose numbers are in the range 100 to 109 cannot be modified by the subscriber (because the My Firewall page will not modify ACLs whose numbers are in that range), although the subscriber can delete those ACLs along with all others with the Disable Firewall button.
permission is one of the following values: permit or deny
protocol is the configured protocol for the application, as defined in the Firewall MBean. Examples are tcp, udp, ip, and so on.
source and destination are in the form:
{any | IPaddressmask} [portOperatorportNumber]
where portOperator values are: lt (less than), gt (greater than), eq (equal), neq (not equal), and range (inclusive range). The range operator requires two port numbers. All other operators require one port number.
Example
The following examples, using ACL number 100, were set by an administrator in CDAT.
Cisco_AV:ip:inacl#100=permit tcp any 10.0.0.0 0.0.0.0 eq 80
Cisco_AV:ip:outacl#100=permit tcp any any established
Note There is an implicit deny at the end of an ACL list. When an ACL list exists, only explicitly permitted
traffic is permitted.
The SESM firewall feature creates extended ACLs. For more information about ACL formats and processing, refer to the Cisco IOS documentation on extended ACLs. The following references point to documentation for Cisco IOS Release 12.2:
Configuration Guide—In the Configuring IP Services guide, see the "Filtering IP Packets Using Access Lists" section. The online link is:
Command reference—In the Cisco IOS IP Command Reference, Volume 1 of 3, Addressing and Services, see the "IP Services Commands" section. The online link is:
1. Add the authentication fields to the portal logon page.
This step requires portal customization. SESM is installed with an example 3-field authentication page that you can implement The example authentication fields are: username, password and telephone number. (Telephone number is the RADIUS attribute CALLING_STATIOIN_ID).
To change the NWSP logon page to prompt for these three keys and process them:
to: <param-value>/pages/accountLogon3Key.jsp</param-value>
2. In LDAP mode, configure RDP to authenticate on the same fields that are specified on the logon page.
You can configure RDP to use any number of fields for authentication. Any standard RADIUS attribute field is a valid key.
a. Edit the DESSAuthenticationHandler Mbean from the RDP management console, or manually edit rdp.xml.
b. Add items to the AuthAttribute attribute. To configure with the installed example in NWSP that uses three keys, make sure the following items are listed in AuthAttribute, in this order: USER_PASSWORD, CALLING_STATION_ID. (The USER_NAME attribute is always used for authentication and should not appear in the AuthAttribute array.)
3. In RADIUS mode, logic to authenticate with multiple keys must exist in the RADIUS server you are using. Verify that this logic exists with your RADIUS server vendor.
4. Make sure that the subscriber profiles includes the values against which to authenticate. In LDAP mode, administrators can enter the APN and NAS identifier attributes as group values. See the Cisco Distributed Administration Tool Guide for more information.
SSG supports per-subscriber and per-service hierarchical policing. The parameters that implement these policies are specified in subscriber and service profiles:
To implement per-subscriber policies—Use the Q attribute in the subscriber profiles.
To implement per-service policies—Use the Q attribute in a service profile.
