BlueCoat appliance LED guide

LED reference guide:

210 Model:

Disk LED:

Green- drive being accessed

Off- no disk activity

Net Adapter:

Off- no link

Green- Link is up

Flashing green to amber- Link is up and network activity is occuring

System indicator:

Off- nothing to report or not powered on

Green- Unit is healthy

Amber- Unit is unhealthy. Perform maintenance check before it becomes critical

Flashing green to amber- critically unhealthy

510/810 Model:

Disk drive:

Off-drive not connected

Green-drive being accessed

Solid amber-drive not well

LCD display- illuminates when the Proxy SG is powered up. The front panel LCD turns off after 30 seconds. This is configurable.

Defining proxy rules on the Proxy SG

The Visual Policy Manager (VPM) is graphical policy editor included with the ProxySG. VPM allows

you to define Web access and resource control policies without having an in-depth knowledge of Blue

Coat Systems Content Policy Language (CPL) and without the need to manually edit policy files.

This chapter

Policies tell the Proxy SG what to do with intercepted traffic.

Traffic can be forwarded, blocked, redirected to another host or port, sent for webfiltering or AV scanning, etc.

Standard policies are created in the Visual Policy Manager and more complex policies are configured on the command line CPL (not covered here).

Like most policies, the VPN is read from top down in the following order:

• Administration Authentication—Determines how administrators accessing ProxySG must

authenticate.

• Administration Access—Determines who can access the ProxySG to perform administration

tasks.

• DNS Access—Determines how the ProxySG processes DNS requests.

• SOCKS Authentication—Determines the method of authentication for that access the proxy

through SOCKS.

• Web Authentication—Determines whether user clients that access the proxy or the Web must

authenticate.

• Web Access—Determines what user clients accessing the proxy or the Web can access and any

restrictions that apply.

• Web Content—Determines caching behavior, such as verification and ICAP redirection.

• Forwarding—Determines forwarding hosts and methods. Unlike most policies, each policy can have multiple layers. For example, there can be several Web Authentication layers. In the event that multiple layers exist, enforcement is read from left to right. When a hit is made on a particular layer, it then proceeds to the next layer to the right. THE ACTION OF THE LAST LAYER WILL BE ENFORCED.

NOTE:

If a policy is configured to bypass, the proxy traffic must be transparent since all explicit traffic is directed to the proxy server itself and a bypass rule is telling the proxy to ignore this traffic.

After new policies are created, they must be installed by selecting File>Install Policies. If this is not done, all new policies will be lost once the VPM is closed.

However new rules can be created and disabled.

Defining proxied services on the Proxy SG

Service Groups dictate whether policy is bypassed or intercepted and are defined by port and address range.

Additionally, there is a port detection utility that can be used to detect services over non-standard ports.

Services are configured in the following location:

Configuration> Services>Proxy Services.

If a service is not defined here, it will not be proxied (bypassed).

The proxy drop down in the service creation screen defines which proxy service (aka client worker) handles the traffic. For example, if an http service is created and the proxy service is TCP-Tunnel, the traffic will be evaluated at the tcp layer only. If HTTP is selected, more checks can be performed on the traffic.

If there are overlapping services, the more specific service will be used (for example if one service uses a network and the other uses a host, and both match traffic, the host configuration will be used).

If a service is configured to intercept traffic, policies are checked to determine the action.

If the client connects explicitly to the ProxySG but there is not a service matching that connection that is set to intercept, the connection is refused and the client displays an error.

When the client is transparently proxied, there is a difference between bridging mode and all other transparent proxy deployments. In bridging mode the traffis is allowed to reach the requested origin content server. For all other deployments, verify that the settting ENABLE IP FORWARDING in the management console under Config>Network>Routing>gateways is checked.

Traffic flow:

1.All traffic is processed at the network layer. If traffic matched the bypass list the traffic is passed.

2.The remaining traffic is processed at the service level. If it matches an intercept, the proces moves to step 3.

3.Intercepted traffic goes through policy processing.

Creating new users and groups on the Proxy SG

Users and groups are added via the CLI

Security local-user-list create LocalRealmUserList

Security local-user-list edit LocalRealmUserList

Group create executives

user create boss

User edit boss

Password pass

Group add executives

Exit

User create bob

User edit bob

Password pass

Exit

To use these users in policy, open VPN and create a Web Auth layer. The action will be local auth (auth>new>local>select your realm).

Next create a web access layer that uses these users (source should be local user/group).

Proxy SG Policy Tracing

Can only be used for troubleshooting intercepted traffic (not bypassed).

A trace can be setup per rule , using the Track column of the rule, or by criteria, by setting up a trace rule.

Policy tracing can be enabled globally (not recommended) or filtered for specific traffic.

Globally enabled via Configuration>Policy>Policy Options>Default Policy tracing

To perform a policy trace for specific access:

Create a new layer for the access you want to trace. For example, create a web access layer with a client ip of 10.1.1.1. In the track column, select Verbose tracing. Install policy

Once a policy trace is turned on, you can view the trace file created by going to https://:8082/Policy

Each transaction is evaluated separately

Policy is traced until a match is made in policy. For example, if there are 3 rules on a layer, and the 1st rules matches the traffic. Rules #2 and 3 are not evaluated.

The results in the trace reflects the browser transactions and not necessarily the user transactions.

Checkpoint Splat source based routing

Policy based routing (source based routing):

Note- this should apply to all flavors of Linux

Scenario: The default router is 1.1.1.2 however, a second router (1.1.1.3) should be used for all

traffic from internal network 10.0.0.0/24.

In this example :

fw IP -1.1.1.1.

Router 1- 1.1.1.2

Router2- 1.1.1.3

Internal net-10.0.0.0/24

DMZ net- 192.168.0.0/24

Commands:

View the route table names

cat /etc/iproute2/rt_tables

[Expert@Demo]# cat /etc/iproute2/rt_tables

#

# reserved values

#

#255 local

#254 main

#253 default

#0 unspec

#

# local

#

#1 inr.ruhep

22 Verizon

The number above (22) represents the priority number of that table. Therefore this table will be read before the main table, which is the table that is modified when the "route add" command is used.

Add a link for the second router:

echo "23 adsl" /etc/iproute2/rt_tables

Define the traffic that will use this link:

ip rule add from 10.0.0.0/24 table adsl

Specify the gateway address for this the table:

ip route add default via 1.1.1.3 dev eth0 table adsl

Since the access to the DMZ will not go through router2, add another route for DMZ access

via its interface

ip route 192.168.0.0/24 dev eth0 table adsl

Make these changes active.

ip route flush cache

These changes are not retained after a reboot. Therefore add the following lines

to the rc.local file (/etc/rc.local )

ip rule add from 10.0.0.0/24 table adsl

ip route add default via 1.1.1.3 dev eth0 table adsl

ip route add 192.168.0.0/24 dev eth2 table adsl

ip route flush cache

Alternatively rules can be added that specify a source and destination network.

ip rule add from 10.0.0.0/24 to 209.134.190.0/23 table adsl

Limits:

Linux supports a max of 252 tables

Checkpoint does not support source or policy based routing

Troubleshooting:

netstat -rn does not show source routes.

To view source routes:

cat /etc/iproute2/rt_tables

To view the tables

ip route list table

To view the routes

This command does not take into account whether the gateway is active.

Cisco SSL Anyconnect VPN example

config t

webvpn

svc image disk0:/anyconnect-win-2.0.0343-k9.pkg 1

tunnel-group-list enable

enable outside

svc enable

exit

ip local pool SSLClientPool 192.168.100.1-192.168.100.50 mask 255.255.255.0

access-list NONAT extended permit ip 192.168.5.0 255.255.255.0 192.168.100.0 255.255.255.0

access-list vpnssl-split extended permit ip 192.168.5.0 255.255.255.0 192.168.100.0 255.255.255.0

nat (inside) 0 access-list NONAT

username userA password test123

username userA attributes

service-type remote-access

exit

username userB password test12345

username userB attributes

service-type remote-access

exit

group-policy SSLCLientPolicy internal

group-policy SSLCLientPolicy attributes

dns-server value 192.168.1.51 192.168.1.61

wins-server value 192.168.1.51 192.168.1.61

address-pools value SSLClientPool

split-tunnel-policy tunnelspecified

split-tunnel-network-list value vpnssl-split

webvpn

vpn-tunnel-protocol svc

svc keep-installer installed

exit

sysopt connection permit-vpn

tunnel-group SSLClientProfile type remote-access

tunnel-group SSLClientProfile general-attributes

default-group-policy SSLCLientPolicy

tunnel-group SSLClientProfile webvpn-attributes

group-alias SSLVPNClient enable

exit

wr mem

wr stand

debug command

sh vpn-sessiondb svc,