Web User Interface

Deploying Juniper Firewalls

Brad Woodberg , ... Ralph Bonnell , in Configuring Juniper Networks NetScreen & SSG Firewalls, 2007

WebUI

The Web user interface is the easiest type of management to use. Because of its simple point-and-select nature, it gives the end user a jumpstart into the management of the Juniper firewall. You can see in Figure 3.1 that the interface is very straightforward. On the left-hand side of the browser is the menu column. From here you can choose from the various configuration options. This menu can be either Dynamic Hypertext Markup Language (DHTML) based, the default, or Java based. The functionality is the same, but the look and feel is slightly different. By default, the WebUI is configured to work over only the Hypertext Transfer Protocol (HTTP). It can, however, be configured to work over Hypertext Transfer Protocol Secure (HTTPS). This provides a mechanism to secure your Web management traffic. Most of the popular Web browsers such as Internet Explorer, or Firefox work well with it.

Figure 3.1. Web User Interface

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491181500058

Big Data

Vijayakumar Nanjappan , ... Ka L. Man , in Big Data Analytics for Sensor-Network Collected Intelligence, 2017

3.1.4 Web-based user interfaces

A Web user interface or Web app allows the user to interact with content or software running on a remote server through a Web browser. The content or Web page is downloaded from the Web server and the user can interact with this content in a Web browser, which acts as a client. The distributed nature allows the content to be stored on a remote server, while the ubiquitous nature of the Web browser permits a convenient access to the content. The most common Web applications are Webmail, online shopping, online document sharing, social media, and instant messaging. A vast amount of data exists now, generated by these types of interfaces.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128093931000015

Policy Configuration

Brad Woodberg , ... Ralph Bonnell , in Configuring Juniper Networks NetScreen & SSG Firewalls, 2007

Creating a Policy

In this section, we will begin to work with policies. In all of the previous sections of the book we have worked with both the CLI and the WebUI in the same section. However, in this section we will look at the WebUI and the CLI in separate sections. This will bring better clarity to the two different methods of creating a policy. Even though the CLI is not as easy to use as the WebUI, knowing how to use the CLI is crucial. The configuration is always stored as CLI commands, so knowing what each command does will empower your use of the platform.

Creating a Policy via the WebUI

The WebUI is easier to interpret, it allows for easier modification of the policy, and at times can be faster to use. When you start to have over 20 policies on your firewall, the CLI will seem as if all the policies run together, whereas on the WebUI, the icons and coloration of the policies will seem to flow. This is all a matter of preference, but I suggest using whatever tool makes the most sense to you. There is no reason to make the administration of the Juniper firewall harder on yourself than it has to be. In Figure 4.9, you will see what the main policy page looks like. This page is the root of all policy creation in the WebUI.

Figure 4.9. The Root of Policy Creation

From here, we can do everything we need to do with policies. We can create, remove, reorder, search, enable, disable, and clone policies. To access this screen, simply select the Policies link from the menu on the left side of the screen. As you can see in Figure 4.9, currently we only have one policy. This policy allows any source to go to any destination via any protocol. The action (indicated by the checkmark in the green circle) is permit. Table 4.1 lists the different icons that may be displayed on this screen, as well as their descriptions.

Table 4.1. Policy Action Icons

Action Icon Description
Permit
The permits the traffic specified in the policy.
Deny
This denies the traffic specified in the policy.
Tunnel
The policy permits and then tunnels the matching traffic.
Bi-Directional Tunnel
The policy permits and then tunnels the matching traffic. It also has a matching policy that has the source and destination reversed.
Policy Based NAT
This policy permits the traffic matching the policy but it also performs NAT on the traffic.

These various policy icons are very informative and simple to understand. When defining a new policy from the WebUI, you begin by selecting the source and the destination zones. Once you select the zones and create the new policy, there is no way to change the source and destination zones. If you wish to change the source and destination zones, you must delete the undesired policy and then create a new one with the correct zones.

Use the following steps to create a policy via the WebUI:

1.

Access the Juniper screen administration tools page and click Policies in the menu.

2.

Click New. A screen similar to the one shown in Figure 4.10 will be displayed.

Figure 4.10. Policy Definition Screen
3.

Enter the policy Name. This should be a descriptive name that will allow you to identify what the policy does.

4.

Use the Source Address options to specify the source address for the policy. If it is a new address, select the New Address option and enter the IP address range. If the address already exists in the address book, select the Address Book Entry option and enter the name of the entry. You can select multiple address book entries by clicking the Multiple button.

5.

Use the Destination Address options to specify the source address for the policy. If it is a new address, select the New Address option and enter the IP address range. If the address already exists in the address book, select the Address Book Entry option and enter the name of the entry. You can select multiple address book entries by clicking the Multiple button.

6.

Use the Service drop-down list to specify the services you want to use in this policy. Select a single service or group of services, or select ANY, or click Multiple if you wish to specify multiple (but not all) services.

7.

Use the Application drop-down list to map a custom-defined service to a specific application layer.

8.

Use the Action drop-down list to specify whether matching traffic will be permitted, denied, or tunneled. If you select Tunnel, you must also select an option from the Tunnel drop-down list. To apply deep inspection groups to the policy, click the Deep Inspection button. (Deep inspection is explained in more detail in Chapter 10.)

9.

The Antivirus Objects section allows you to specify which antivirus scanners will be applied to the policy. To select an antivirus object, select it from the Available AV Object Names list on the right, and then click the << button to place it in the Attached AV Object Names list on the left.

10.

If you selected Tunnel in the Action drop-down list, use the Tunnel VPN drop-down list to specify the appropriate VPN tunnel. (VPN configuration is discussed in greater detail in Chapter 11.)

11.

If you wish to turn on logging for this policy, enable the Logging checkbox.

12.

If you wish to place this policy at the top of the list of policies with matching source and destination zones, enable the Position at Top checkbox.

13.

Click OK.

Reordering Policies in the WebUI

Once you have all of your policies created in the WebUI, you may find you need to reorder them. Every newly created policy is placed at the bottom of the policies that have the same source and destination zones unless you enabled the Position at Top option when creating the policy. Once the policy is created, you can modify the policy placement on the Policies list page. Table 4.2 shows the different icons you can use to reorder policies.

Figure 4.11. Order Policies by Number

Figure 4.12. Choose Policy Placement

Table 4.2. Policy Action Icons

Icon Description
Selecting this option allows you to choose the placement of your policy, by policy number. A pop-up window will be displayed, asking you where you want to place your policy based upon the number of your policy. (See Figure 4.11 for an example.)
This option allows you to specify where you want to place your policy based upon a selection screen. At the selection screen, you can click on a similar arrow to choose where you want to place your policy. (See Figure 4.12 for an example.)

Tools & Traps…

Negation

When creating policies and working with address book entries, you can enable an option called negate. This concept is used on several firewall products and can be quite useful depending on what you are attempting to accomplish. The negate option is available for the source and destination addresses. The option is turned on for either source or destination addresses, and can be turned on separately for each policy.

Turning on the negate option will apply the following logic: everything except the selected objects. For example, suppose you created a policy with the following configuration: Source: 10.10.10.0/24 Negated; Destination: Any; Service: FTP; Action: Permit. You are effectively saying, "Allow any source address to FTP, except for 10.10.10.0/24." This can save you time instead of making a policy to deny the 10.10.10.0/24 network to access FTP and then a second policy to allow access to FTP to any.

The negate option can be used in both the WebUI and the CLI. To use this option in the WebUI when you are creating a policy, click the Multiple button for the source or destination address. Once you have selected what you want to negate in the pop-up window, enable the Negate the Following option, which can be found in the upper left-hand corner of the window. To use this from the command line, you must first create the policy, then go into the sub-shell for the policy and negate the source address and destination address. See the following command for an example:

Other Policy Options in the WebUI

Some additional WebUI options may be helpful as you begin to create policies. These options are available from the root policies page in the WebUI (see Figure 4.13).

Figure 4.13. Additional Policy Options
▪

Edit Use a policy's Edit link to modify its configuration.

▪

Clone Use this option to create a copy of the policy. The policy's original information will be displayed, but can be edited for your needs. This can save time when creating multiple policies that have only slight differences.

▪

Remove Click a policy's Remove link to delete it. The policy will immediately be removed from the firewall.

▪

Enable Use this option to enable or disable the policy.

Creating a Policy via the CLI

Even though the point-and-click nature of the WebUI may make policy management easier, the CLI provides the fastest methods of policy management. Using the CLI requires more memorization of the commands and the order in which you use them. Once you get a grasp of CLI policy management, it will become an effective management tool. Three basic commands can be used to manage policies. The first command is set policy, which is the root of all policy creation. All commands that involve creating and manipulating policies begin here. The second command is get policy, which displays information about all, or specified, policies. Finally, the unset policy command is used for removing policies.

To view a list of all existing policies, enter the command get policy. You can also list policies by specifying the source and destination zones. This is done with the command get policy from <Src-Zone> to <Dst-Zone>. A list of all policies matching the specified parameters will be displayed. Use the command get policy global to view all of the global policies. Finally, use the command get policy all to view all of the policies, including the global policies. The get policy command supports the following parameters:

▪

ID This is the ID number of the policy. It is a unique number that is used to identify the policy.

▪

From The source zone.

▪

To The destination zone.

▪

Src-address The source address objects.

▪

Dst-address The destination address objects.

▪

Service The service specified for the policy.

▪

Action The action to apply to the traffic that matches the policy.

▪

State Whether the policy is enabled or disabled.

▪

ASTLCB This represents which special properties are turned on in the policy. A = Authentication, S = Scheduling, T = Traffic Shaping, L = Logging, C = Counting, B = HA Backup.

You can even look at the configuration of a policy by using the get policy id <number> command, where <number> is the policy ID.

Creating a policy via the CLI requires the same components as if you were using the WebUI. The full command for creating a policy via the CLI is

Five areas in the preceding example command must be filled in to complete the policy. The <Src-Zone> or source zone, <Dst-Zone> or destination zone, <Src-Address> or source address book entry, <DstAddress> or destination address book entry, service, and action. These are the same five minimum options you would use when creating a policy from the WebUI. Once you create the policy, it is given a policy ID or unique identifier. This identifier is used to reference the policy throughout the system. The firewall will return policy ID = <Identifier> once the policy has been created.

Notice that this command only allows you to specify one source address, one destination address, and one service. You can add more once the policy has been created by using the set policy id <ID Number> to enter the sub-shell that allows you to modify the policy. The sub-shell for policies is the only sub-command shell in the entire firewall.

Once in the policy sub-shell, you have the same options as in the regular shell: set, get, and unset. Using the set command, you can add additional source addresses, destination addresses, and services, as well as other policy options. The unset command is used to remove parts from the policy, and the get command is used to obtain information about the policy. When creating policies from the CLI, you can place a policy in a specific position as it is created by entering the following command:

Specify the <ID> as the ID number of the policy you want to place the policy before. If you want to create a policy and place it at the top of the list of policies with the same source and destination zone, you would use the following command:

The following is a snippet of code that shows an example of creating a policy and manipulating it in the sub-shell.

Other Policy Options Available in the CLI

Once you have all of your policies defined, you can use the CLI to reorder the policies. To move an existing policy above another, use the following command:

Specify the policy you want to move with its policy ID as <ID1> and the policy you want to move it before as its policy ID as <ID2>. To move an existing policy after another, use the following command:

Specify the policy you want to move with its policy ID as <ID1> and the policy you want to move it after as its policy ID as <ID2>. This may seem like an insignificant option, but if you have ever used a Cisco IOS or Cisco PIX access list, you will appreciate this option. Neither Cisco OS allows you to manipulate the policies or access lists this way. Instead, you must first remove all of the applied policies and then add them all back to the firewall. Finally, you can delete policies via the CLI. To delete a policy from the CLI, you must know the policy ID of the policy you want to remove, and then use either the unset policy id <ID> or unset policy <ID> command.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978159749118150006X

Dissecting the Juniper Firewall

Brad Woodberg , ... Ralph Bonnell , in Configuring Juniper Networks NetScreen & SSG Firewalls, 2007

Juniper Firewalls

Juniper Networks' premier security platform is the NetScreen firewall product line. This product line provides integrated firewall and Internet Protocol Security (IPSec) VPN solutions in a single appliance. The NetScreen firewall core is based on stateful inspection technology. This technology provides a connection-oriented security model by verifying the validity of every connection while still providing a high-performance architecture. The NetScreen firewalls themselves are based on a custom-built architecture consisting of application-specific integrated circuit (ASIC) technology. ASIC is designed to perform a specific task at a higher performance level than a general-purpose processor. ASIC connects over a high-speed bus interface to the core processor of the firewall unit, a reduced instruction set computing (RISC) CPU.

The firewall platform also contains additional technologies to increase your network's security. First, the products support deep inspection. This technology allows you inspect traffic at the application level to look for application-level attacks. It can help prevent the next worm from attacking your Web servers or someone from trying to send illegal commands to your SMTP server. The deep inspection technology includes a regularly updated database as well as the capability for you to create your own custom expression-based signatures. All the appliances include the capability to create IPSec VPNs to secure your traffic. The integrated VPN technology has received both the Common Criteria and the ICSA www.icsalabs.com) firewall certifications. Thus, the IPSec VPN technologies have good cross-compatibility as well as standards compliance. Juniper also offers two client VPN solutions to pair with the NetScreen firewall. First, NetScreen-Remote provides the user with the capability to create an IPSec connection to any NetScreen firewall or any IPSec-compliant device. The second client product is NetScreen-Security Client. This product not only creates IPSec tunnels but also includes a personal firewall to secure the end user's system. The NetScreen firewall product line leverages the technologies of Trend Micro's and Kaspersky Lab's antivirus software. This software allows you to scan traffic as it passes directly through the firewall, thus mitigating the risks of viruses spreading throughout your network.

The latest product set for the firewall line from Juniper is the SSG. The SSG product line was designed with key ideas in mind. First, it provides at high speeds advanced security features such as antivirus protection, antispam protection, IPS capabilities, and integrated URL filtering. Second, all the SSG products allow you to use WAN interfaces on the firewall, thereby enabling you to connect your firewall directly to a T1, digital subscriber line (DSL), or ISDN (Integrated Services Digital Network) link, to name a few. It gives you the capability to bypass the need to have a router on every WAN link. Because the SSG products are also built for future services, the architecture on the devices has changed from that of the traditional NetScreen firewall. SSG firewalls do not contain ASICs as the NetScreen firewalls do. However, this does not mean that the SSG firewall does not offer the same levels of performance as its cousin, the NetScreen product.

The Juniper firewall platform provides you with three management options:

▪

Command-Line Interface (CLI) The CLI provides the most granular control over the platform through straightforward interaction with the operation system (ScreenOS).

▪

Web User Interface (WebUI) The WebUI is a streamlined Web-based application with a user-friendly interface that allows you to easily manage the NetScreen appliance. Both WebUI and CLI are consistent among all the NetScreen firewall products—this means that once you have experience using one firewall model (for example, 5GT), you can easily apply your knowledge to other models (such as 208) in the NetScreen firewall product line.

▪

NetScreen Security Manager (NSM) A centralized enterprise-class solution that allows you to manage your entire NetScreen firewall infrastructure. The NSM provides not only a central console to manage your firewalls and Juniper IDP products but also consolidated logging and reporting. This is a great option that allows you to see all your network's activity from a central location.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491181500046

Deciding on a Firewall

In Firewall Policies and VPN Configurations, 2006

Management

The NetScreen firewall platform provides three management options:

■

CLI Provides the most granular control over the platform through straightforward interaction with the operation system (ScreenOS).

■

WebUI A streamlined Web-based application with a user-friendly interface that allows you to easily manage the NetScreen appliance. Both WebUI and CLI are consistent among all of the NetScreen firewall products (i.e., once you learn one firewall model, you can easily apply your knowledge to the other models in the NetScreen firewall product line.

■

NSM This is a centralized enterprise class solution that allows you to manage your entire NetScreen firewall infrastructure. The NSM not only provides a central console to manage your firewalls, it also provides consolidated logging and reporting. This great option allows you to see all of your network's activity from a central location.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597490887500062

Nokia Network Voyager

Andrew Hay , ... Warren Verbanec , in Nokia Firewall, VPN, and IPSO Configuration Guide, 2009

Introduction

"Nokia Network Voyager?" asked Mark. "What's that?"

Shin connected his laptop's network cable to the management switch used to access the internal interface of each Nokia appliance. "The Nokia Network Voyager," explained Shin, "Is the Web user interface front-end for the configuration and day-to-day administration of the Nokia appliances." Shin brought up a Web browser and entered the IP address of the first appliance in the address field. "Using the Voyager interface, I can configure every feature of this appliance." Shin logged in using the administrator username and password he specified during installation. "I can configure basic system settings, install and manage additional software packages, back up and restore the system, and tune the security settings."

Shin moved throughout the interface, configuring the system to the test specifications. Mark ensured that the checklist he had prepared was marked as completed as Shin moved through the various sections. Ming scribbled notes throughout the entire configuration session as Marty looked over her shoulder.

"Looks fairly easy to configure," Marty said.

"It's probably one of the easiest enterprise class systems to configure and secure," responded Shin. "No more messing around at the command line in configuration files to shut down unnecessary services, add/remove users, etc."

Marty liked that idea. He knew, from personal experience, that the more you had to configure in configuration files, the higher the chance of administrative error. "I really like this user interface and I think our Ops guys are going to as well."

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492867000048

Cloud Computing Infrastructure for Data Intensive Applications

Yuri Demchenko , ... Charles Loomis , in Big Data Analytics for Sensor-Network Collected Intelligence, 2017

6.4.2 Deployment UC2: Cloud virtual pipeline for microbial genomes analysis

The second bioinformatics use case "Cloud virtual pipeline for microbial genomes analysis" is developed by the platform IFB-MIGALE (Jouy-en-Josas, France, http://migale.jouy.inra.fr/). This application requires several components: a user web interface, a relational PostgreSQL database, and a complete computing cluster with a master and several nodes to perform the data-intensive analyses. The infrastructure for running the application in a classical (static) way on bare-metal servers in IFB-MIGALE premises was ported to the cloud and extended with "1-click" deployment features by using the SlipStream cloud deployment automation platform. The VM images were exported from the IFB's private cloud and registered in the Marketplace of the StratusLab community cloud used by the French research community. For further deployments and possible applications migration, the IFB-core produced a deployment recipe based on SlipStream that instantiates the complete application with all the required VMs on the target infrastructure.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128093931000027

Influences of architectural and implementation choices on CyberInfrastructure quality—a case study

Emilia Farcas , ... Celal Ziftci , in Software Quality Assurance, 2016

13.3.2 PALMS

PALMS (Demchak et al., 2012; Demchak and Krüger, 2012) merges data from physical activity sensors (e.g., accelerometers and heart rate monitors) with GPS data to construct a detailed picture of a participant's day: travel patterns, locations, durations, and levels of physical activity and sedentary periods. PALMS supports the research of a worldwide community of exposure biologists who study human health as a function of geographical location and ambient conditions. Thus, PALMS employs a number of principle investigators, each defining distinct studies involving study participants, data collection, and analysis. Each study is unique as to content, funding agency requirements, and personnel organization.

13.3.2.1 Architecture

The PALMS CI follows the Rich Service architectural pattern. In particular, it exposes different sets of services for authorization and authentication, data repository access, data processing, study configuration, and CI configuration. The CI uses an Enterprise Service Bus (ESB) architecture where all services are accessed using standardized XML messages. The front end UI of PALMS runs in the web browser as a JavaScript application leveraging the Google Web Toolkit (GWT) technology. It communicates with a Tomcat web server using an internal RPC protocol defined by GWT. The web server transforms the UI requests into CI requests via a standard SOAP web service interface exposed by PALMS' CI. These requests are then converted into XML messages and sent to the proper services in the CI. Each service request is authenticated, and a policy engine is used to enforce policies defined by study researchers. The PALMS system is essentially a batch processing system. It supports uploading data in batches from the web UI. Each data element is then processed using study-defined algorithms that run in the Java Virtual Machine (JVM) and connect to the rest of the CI using a service interface. All data is persisted in a relational MySQL database.

Services in the CI use the following pattern, where each service has three parts: (i) one interface that defines methods to call; (ii) a proxy that implements the interface, converts each service request to a standard XML message, and dispatches the message using the MULE ESB; (iii) the actual implementation of the service as another Java class. The ESB infrastructure processes the XML messages generated by the proxy (ii) and calls methods defined by the implementation class (iii) as specified in a configuration file. This approach has several benefits. For example, all requests can easily be redirected to remote machines, and additional services can be injected and manipulate all service requests—we use this ability to enforce policies. The price to pay is more complexity in debugging the code and having to write more classes for each service (Figure 13.3).

Figure 13.3. PALMS overview.

13.3.2.2 Implementation

The front end is a web interface. We developed it using GWT, a Java-based framework that compiles Java code to JavaScript that executes natively inside web browsers. The main benefit is that this approach enables programmers to share some code with the back end (also written in Java) and enables us to use just one language for developing all parts of PALMS, thus limiting the need of having developers with different skills. To simplify the front end development, we decided to connect the Web UI to the web server using the RPC protocol supported natively by GWT and to translate these requests in service requests to the CI using SOAP. The CI uses MULE, a Java based ESB. The version 1.4 of MULE that was available during development has limitations that lead to developing very verbose code. Newer MULE versions improve on this aspect but require extensive changes of older code. A set of repository services encapsulate all data access—they abstract the concrete database used, in this case MySQL. The use of these services enables data access and storage to be treated like any other service of the platform, supporting complex policies that can be defined on each data element.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128023013000132

Design and management of vehicle-sharing systems: a survey of algorithmic approaches

D. Gavalas , ... G. Pantziou , in Smart Cities and Homes, 2016

2 Challenges and objectives in the design of vehicle-sharing systems

Recent research analyzed the factors affecting the success of bike-sharing programs [10,11]. These factors range from the built environment (infrastructures, facilities at work, etc.) to factors related to the natural environment (topography, seasons and climate or weather), socioeconomic and psychological factors (attitudes and social norms, ecological beliefs, habits, etc.), and other factors related to utility theory (cost, travel time, effort and safety). Factors gaining growing interest involve bike station location, cycling network infrastructure (bike paths) and the operation of bicycle redistribution system [12]. The stations must be located in close proximity to one another and to major transit hubs and be placed in both residential (origin) and commercial or manufacturing (destination) neighborhoods, which makes bike-shares ideal as a commuter transportation system [1,13]. Existing examples show that the bike stations should not be located more than 300–500 m from important traffic origins and destinations. Given the complexity of bicycle facility planning and the importance of station distribution for operating bike-sharing programs, formal approaches are needed to model the problem variables and derive optimal solutions with respect to minimizing investment cost and maximizing utility for the users. Among others, optimal solutions should determine the number, location, and capacity (in bikes and docks) of the stations as well as the bicycle lanes needed to be setup.

On the other hand, equally important for bike-sharing systems success is to guarantee bicycle availability. Each rental station must carry enough bicycles to increase the possibility that each user can find a bicycle when needed. Therefore, measures of service quality in the system include both the availability rate (ie, the proportion of pick-up requests at a bike station that are met by the bicycle stock on hand) and the coverage level (the fraction of total demand at both origins and destinations that is within some specified time or distance from the nearest rental station). Due to the one-way rental policy, bikes are likely to get stuck in areas of lower individual mobility demand (cold spots) while needed in zones of higher demand (hot spots). To make the system more efficient and more profitable, this imbalance of supply and demand could be adjusted by applying different intervention (ie, relocation) strategies [14].

The need to ensure vehicle availability in high-demand areas is also acknowledged for car-sharing systems [15]. However, relocation of cars is more troublesome than that of bicycles (up to 60 bicycles can be transported altogether to hot spots on a bicycle carrier, contributing to cost and effort savings [16]). Some studies suggest the use of road vehicles (car carriers) with fully automated driving capabilities (typically moving along dedicated tracks), coordinated by centralized management systems, able to autonomously relocate to satisfy user demands [17]. Redistribution of vehicles may also be provided by a fleet of limited capacity tow-trucks located at various network depots; using such an approach the problem can be conveniently modeled as pickup and delivery problem [9]. However, dedicated transport trucks are of little use in most urban settings due to stations not easily reachable by heavy-duty trucks and the time consuming vehicle loading/unloading operations [18]. Thus, the scheme most commonly encountered in practice engages teams of employed drivers who undertake the relocation of vehicles thereby significantly increasing operational cost.

Recently, the decreased manufacturing cost of EVs along with their ecofriendly characteristics (fuel economy and lowered greenhouse gas emissions) has attracted the attention of car-sharing companies c . So far, the main body of EVs-relevant algorithmic research focuses on novel energy-efficient routing algorithms motivated by the unique characteristics of EVs (limited cruising range, long recharge times and the ability to recuperate energy during deceleration or when going downhill) [19,20].

EV-sharing systems are also unique with respect to their design and operational requirements. Specifically,

1.

Sufficient battery availability at pick-up time should be ensured so as to travel reliably to user's destination [21].

2.

Vehicle relocation policies should take into account the energy availability of vehicles at stations, in addition to physical availability [22].

3.

Pick-up/drop-off locations are determined by the existence of charging stations (for instance, the 300 Car2Go vehicles and other EVs in Amsterdam have access to 320 charging stations in the city area).

4.

The anticipated transformation of urban parking stations to charge-park stations in support to EV power demands is expected to create considerable load on the power grid, hence, intelligent approaches are in need to flatten the load peak, thereby deferring investments in grid enhancement [23].

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128034545000134

Medium Business (<2000 People)

In Firewall Policies and VPN Configurations, 2006

Network Access Restrictions

Cisco ACS uses the Network Access Restrictions (NAR) feature to control who can log on at a particular access point, such as the firewall. NAR is an optional configuration component; therefore, ACS may require you to enable the display of NAR settings in the ACS Web interface before you can access the appropriate settings. To enable NAR, login to the Web user interface, which can be accessed directly from the server at http://localhost:2002/.

Once connected to the ACS user interface, select the Interface button located to the left of the screen, and select the Advanced Options link. Now you can enable either "User-Level Network Access Restrictions" or "Group-Level Network Access Restrictions." Group-level NAR is preferable, because it becomes easier to manage as user numbers increase. Finally, click Submit to apply any changes (see Figure 9.11).

Figure 9.11. Configuring Group-level NAR with Cisco ACS

When NAR is enabled at either the user or group level, you will see NAR settings listed on the configuration screens for user or group properties, respectively.

Defining NAR rules allows configuration under two similar headings in the ACS interface: Define IP-based access restrictions and Define CLI/DNIS-based access restrictions. You will use the IP-based option for PIX that the Caller-ID (CLI) and Dialed Number Identification Service (DNIS) refers to, both of which are used in dial-up situations to identify the telephone number the user is coming from and the telephone number they have dialed. For IP-based restrictions, the "Address" option refers to the user's source IP address. If you want to allow users in this group to authenticate to the firewall from all IP addresses, you can enter an asterisk (*) in the address field and in the port field.

This NAR configuration is a type of ACL, and as such, it allows a "permit of deny" action to be applied to all entries on the list. You can pick either permit or deny for the entire list. This limitation is likely to affect the way you define the group's NAR list.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597490887500116