|
Several changes to LBNL’s wireless networking configuration
are being implemented in order to ensure compliance with DOE
requirements as well as provide appropriate protection both
to and from wireless hosts. All of these policies will be
in effect on September 22, 2004, though some have already
taken effect before then. The policies are listed and described
below:
- Microsoft RPC Services Disallowed from
Wireless to LBLnet
- Internet-to-Wireless Traffic Policy Switches
from “Default Allow” to “Default Deny”
- Wireless Hosts Cannot Offer Most IP Services
to the Internet
- Dynamic Blocking of Hostile Wireless Hosts
None of these policy changes are expected to have significant
adverse impact on the Lab community and its use of wireless
networking. They primarily enhance protection and reduce cyber
risk and cyber monitoring efforts. However, as with any significant
configuration changes, there can be unforeseen side-effects.
If you believe any of these policies significantly interfere
with LBNL work, please contact the CPP Group. We will work
to understand the issues and will identify measures to mitigate
the side-effects as appropriate, including configuration alternatives,
policy exceptions, etc.
For more information about:
Policy Details
1. Microsoft RPC
Services Disallowed from Wireless to LBLnet
Because we no longer allow MS RPC services from the Internet
to LBLnet, and regulatory requirements dictate that we trust
visitor’s computers (connected to lbnl.us) no more than
we trust Internet hosts, we must now bring the wireless-to-LBLnet
policy in line with the Internet DMZ policy and block MS RPC
services. Microsoft RPC services include access to Microsoft
file shares, printing to Microsoft print servers, and “browsing”
for Microsoft networking services.
The impact of this policy is minimal, but not zero, as a
small number of LBNL employees currently use these services
(e.g., printing from wireless to Microsoft print servers).
Most of them have been contacted and apprised of this change
in the several months prior, and they have already implemented
functional alternatives. However, those who we’ve not
been able to identify and individually notify may experience
a service interruption.
The are two simple ways to mitigate or eliminate adverse
side effects of this policy:
- Use LBNL-Supported Software VPN
When using the software VPN while connected to wireless,
your computer gets an lbl.gov IP address, you become part
of LBLnet proper, and this policy does not affect you. You
can obtain information and support for VPN at LBLnet’s
Web site.
- Direct IP Printing
If your only need is for printer access, you can print
directly to most printers and bypass the intermediate
Microsoft print server. For assistance with this option,
contact the Help Desk (x4357 or help@lbl.gov)
2. Internet-to-Wireless Traffic
Policy Switches from “Default Allow” to “Default
Deny”
Historically, there have been few static restrictions on
traffic between the Internet and the wireless network, and
the policy is said to be “default allow,” i.e.,
all traffic is allowed unless there is a rule blocking a specific
type. For example, port 445 (MS RPC) traffic from the Internet
to wireless is blocked.
Because the variety of legitimate traffic is fairly small
(and well understood), and the range of illegitimate inbound
traffic is great and threatening, it is prudent to reverse
the traffic-filtering policy from “default allow”
to “default deny,” which is to say that known,
legitimate services will be explicitly allowed, and all other
Internet => wireless traffic will be blocked.
We do not expect this policy change to have significant adverse
impact on LBNL community and wireless users. This policy change
has no effect on client-initiated connections (e.g., Web browsing,
email send and receive, etc). Known legitimate applications
that do require Internet-initiated connections, such as Instant
Messaging, personal remote access, and desktop teleconferencing
systems, are explicitly allowed.
Accordingly, the primary effect will be a dramatic reduction
in the quantity of hostile traffic seen by wireless hosts,
resulting in enhanced protection for wireless hosts, reduced
cyber risk, and reduced cyber monitoring overhead.
3. Wireless Hosts Cannot Offer
Most IP Services to the Internet
Computers attached to the wireless network may not operate
most IP-based services for Internet clients, including http,
ftp, smtp, etc. In other words, you may not run a Web server,
an ftp server, email server, etc., on the wireless network
in order to offer those services to Internet hosts (outside
lbl.gov).
This policy has no bearing on IP connections originating
from a wireless hosts; for example, it has no effect on the
operation of a Web browser, an ftp client program, an email
reader, etc., on a wireless host.
We believe this policy will have little-to-no adverse impact
on the Laboratory community, as such services (legitimate
ones) are not generally being operated now.
The primary enforcement of this policy will consist of blocking,
at the network level, most IP connections originating from
the Internet and destined for lbnl.us (wireless) IP addresses.
However, for technical reasons, some traffic may not actually
be blocked, and successful communications at the network/IP
level should not be construed as policy allowance.
This policy does not apply to connections from lbl.gov, nersc.gov,
or es.net (which are not considered part of the Internet in
policy terms), and this policy change has no effect on any
networking traffic between those domains. Although, technically,
nothing prohibits one from operating services such as http
on a wireless host and have them accessible from these domains,
it is still not generally recommended.
4. Dynamic Blocking of Hostile
Wireless Hosts
Although CPP operates the BRO (intrusion detection) software
to monitor the traffic between wireless and LBLnet (similar
to how Internet => LBLnet traffic is monitored), in the
past, we have not implemented real-time, automated blocking
of traffic from wireless hosts identified by BRO as hostile
(e.g., scanning.) As of September 2, 2004, this has been implemented.
This policy change should have litte-to-no adverse affect
on legitimate LBNL work. However, an employee with an infected
computer connecting to wireless could be affected, i.e., detected
and blocked from accessing LBLnet, which is a good thing.
|
