U.S. patent application number 14/064005 was filed with the patent office on 2014-07-17 for auditing communications.
This patent application is currently assigned to Xceedium, Inc.. The applicant listed for this patent is Xceedium, Inc.. Invention is credited to David Van.
Application Number | 20140201817 14/064005 |
Document ID | / |
Family ID | 49596839 |
Filed Date | 2014-07-17 |
United States Patent
Application |
20140201817 |
Kind Code |
A1 |
Van; David |
July 17, 2014 |
AUDITING COMMUNICATIONS
Abstract
Auditing a communication is disclosed. Credentials are received
from a client. It is determined whether the client is authorized to
communicate with a remote resource. If it is determined that the
communication with the remote resource is allowed, a communication
is forwarded from the local resource to the remote resource.
Inventors: |
Van; David; (Somerset,
NJ) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Xceedium, Inc. |
Herndon |
VA |
US |
|
|
Assignee: |
Xceedium, Inc.
Herndon
VA
|
Family ID: |
49596839 |
Appl. No.: |
14/064005 |
Filed: |
October 25, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11786970 |
Apr 13, 2007 |
8595794 |
|
|
14064005 |
|
|
|
|
60792160 |
Apr 13, 2006 |
|
|
|
60857659 |
Nov 7, 2006 |
|
|
|
Current U.S.
Class: |
726/4 |
Current CPC
Class: |
G06F 21/00 20130101;
H04L 63/08 20130101; G06F 21/30 20130101; H04L 63/00 20130101; H04L
67/141 20130101; H04L 63/1416 20130101; H04L 63/10 20130101; H04L
63/108 20130101; H04L 63/1466 20130101 |
Class at
Publication: |
726/4 |
International
Class: |
H04L 29/06 20060101
H04L029/06 |
Claims
1. A system, comprising: an interface configured to receive
credentials from a client, wherein the client is configured to
receive and follow instructions for accessing a remote resource;
and a gatekeeper device configured to, using a processor, determine
whether the client is authorized to communicate with the remote
resource, wherein a communication from the client that is intended
for the remote resource is forwarded from the client to the remote
resource in response to determining that the communication is
authorized.
2. The system recited in claim 1, wherein the instructions include
mapping a client local resource with the remote resource through
the gatekeeper.
3. The system recited in claim 1, wherein the instructions include
information associated with at least one of a port binding and a
port forwarding.
4. The system recited in claim 1, wherein determining whether the
client is authorized includes determining whether the credentials
are valid.
5. The system recited in claim 1, wherein determining whether the
client is authorized includes determining whether a client request
occurs at an authorized time.
6. The system recited in claim 1, wherein determining whether the
client is authorized includes determining a window of time during
which a communication request from the client to remote resource is
authorized.
7. The system recited in claim 1, wherein communications from the
client that are intended for the remote resource continue to be
forwarded from the client to the remote resource.
8. The system recited in claim 1, wherein the gatekeeper device is
further configured to determine whether the client ceases to be
authorized to communicate with the remote resource.
9. The system recited in claim 8, wherein forwarding of
communications from the client to the remote resource is refused in
response to determining that the client is no longer authorized to
communicate with the remote resource.
10. The system recited in claim 8, wherein forwarding of
communications from the client to the remote resource is refused
after a period of time upon determining that the client is no
longer authorized to communicate with the remote resource.
11. A method, comprising: receiving, via an interface, credentials
from a client, wherein the client is configured to receive and
follow instructions for accessing a remote resource; and
determining, using a gatekeeper device, whether the client is
authorized to communicate with the remote resource, wherein a
communication from the client that is intended for the remote
resource is forwarded from the client to the remote resource in
response to determining that the communication is authorized.
12. The method of claim 11, wherein the instructions include
mapping a client local resource with the remote resource through
the gatekeeper.
13. The method of claim 11, wherein the instructions include
information associated with at least one of a port binding and a
port forwarding.
14. The method of claim 11, wherein determining whether the client
is authorized includes determining whether the credentials are
valid.
15. The method of claim 11, wherein determining whether the client
is authorized includes determining whether a client request occurs
at an authorized time.
16. The method of claim 11, wherein determining whether the client
is authorized includes determining a window of time during which a
communication request from the client to remote resource is
authorized.
17. The method of claim 11, wherein communications from the client
that are intended for the remote resource continue to be forwarded
from the client to the remote resource.
18. The method of claim 11, further comprising, determining, using
the gatekeeper device, whether the client ceases to be authorized
to communicate with the remote resource.
19. The method of claim 18, wherein forwarding of communications
from the client to the remote resource is refused in response to
determining that the client is no longer authorized to communicate
with the remote resource.
20. The method of claim 18, wherein forwarding of communication
from the client to the remote resource is refused after a period of
time upon determining that the client is no longer authorized to
communicate with the remote resource.
21. A computer program product, the computer program product being
embodied in a computer readable storage medium and comprising
computer instructions for: receiving credentials from a client,
wherein the client is configured to receive and follow instructions
for accessing a remote resource; and determining, by a gatekeeper
device, whether the client is authorized to communicate with the
remote resource, wherein a communication from the client that is
intended for the remote resource is forwarded from the client to
the remote resource in response to determining that the
communication is authorized.
Description
CROSS REFERENCE TO OTHER APPLICATIONS
[0001] This application is a continuation of co-pending U.S. patent
application Ser. No. 11/786,970, entitled AUDITING COMMUNICATIONS
filed Apr. 13, 2007 which is incorporated herein by reference for
all purposes, which claims priority to U.S. Provisional Patent
Application No. 60/792,160 entitled MULTI-NETWORK CONNECTIVITY
filed Apr. 13, 2006 which is incorporated herein by reference for
all purposes and also claims priority to U.S. Provisional Patent
Application No. 60/857,659 entitled AUTOMATIC INTERVENTION filed
Nov. 7, 2006 which is incorporated herein by reference for all
purposes.
BACKGROUND OF THE INVENTION
[0002] One tool used in network security is the ability to monitor
and log administrator actions. For example, when an administrator
logs into a production server at midnight each night, runs assorted
tests, and emails log files associated with the results of those
tests to another server, each of those actions may be monitored and
logged. If problems occur, the administrator(s) logged into the
system at the time of the problem can be questioned and their
actions can be evaluated.
[0003] Typically when administrators find themselves performing the
same set of tasks repeatedly, they seek to automate those tasks.
For example, instead of manually running the tests and emailing the
results each night, an administrator might create a cron job or
batch file that performs those actions, schedule it to run every
night at midnight, and then cease logging in at night.
Unfortunately, while automating tasks can be efficient, it can also
pose security risks. While the nightly actions continue to be
performed, the administrator has ceased logging in and thus the
monitoring system that monitors the actions of the administrator
may no longer be effective at determining the administrator as the
source of the activity. This can be particularly problematic in the
case of consultants or other temporary employees that may leave
batches processes behind when they stop administering the
enterprise.
[0004] Therefore, it would be desirable to have a better way to
monitor and authenticate activity.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] Various embodiments of the invention are disclosed in the
following detailed description and the accompanying drawings.
[0006] FIG. 1 is a block diagram illustrating an embodiment of an
environment in which point to multi-point connections are made.
[0007] FIG. 2 is a flow chart illustrating an embodiment of a
process for communicating with a plurality of networks.
[0008] FIG. 3 is a block diagram illustrating an embodiment of a
gatekeeper.
[0009] FIG. 4 is a flow chart illustrating an embodiment of a
process for enrolling a user with a gatekeeper.
[0010] FIG. 5 is a flow chart illustrating an embodiment of a
process for enrolling a user with a gatekeeper.
[0011] FIG. 6 is a flow chart illustrating an embodiment of a
process for establishing a session with a gatekeeper.
[0012] FIG. 7 is a flow chart illustrating an embodiment of a
process for establishing a session with a client.
[0013] FIG. 8 is a flow chart illustrating an embodiment of a
process for communicating information across a plurality of
networks.
[0014] FIG. 9 is a flow chart illustrating an embodiment of a
process for communicating information across a plurality of
networks.
[0015] FIG. 10 is a block diagram illustrating an embodiment of an
environment having communication auditing.
[0016] FIG. 11 is a flow chart illustrating an embodiment of a
process for auditing a communication.
[0017] FIG. 12 is a flow chart illustrating an embodiment of a
process for auditing a communication.
[0018] FIG. 13A is a block diagram illustrating an embodiment of an
environment having network security.
[0019] FIG. 13B is a block diagram illustrating an embodiment of an
environment having network security.
[0020] FIG. 14 is a flow chart illustrating an embodiment of a
process for detecting unauthorized commands.
[0021] FIG. 15 is a flow chart illustrating an embodiment of a
process for detecting unauthorized commands.
DETAILED DESCRIPTION
[0022] The invention can be implemented in numerous ways, including
as a process, an apparatus, a system, a composition of matter, a
computer readable medium such as a computer readable storage medium
or a computer network wherein program instructions are sent over
optical or communication links. In this specification, these
implementations, or any other form that the invention may take, may
be referred to as techniques. A component such as a processor or a
memory described as being configured to perform a task includes
both a general component that is temporarily configured to perform
the task at a given time or a specific component that is
manufactured to perform the task. In general, the order of the
steps of disclosed processes may be altered within the scope of the
invention.
[0023] A detailed description of one or more embodiments of the
invention is provided below along with accompanying figures that
illustrate the principles of the invention. The invention is
described in connection with such embodiments, but the invention is
not limited to any embodiment. The scope of the invention is
limited only by the claims and the invention encompasses numerous
alternatives, modifications and equivalents. Numerous specific
details are set forth in the following description in order to
provide a thorough understanding of the invention. These details
are provided for the purpose of example and the invention may be
practiced according to the claims without some or all of these
specific details. For the purpose of clarity, technical material
that is known in the technical fields related to the invention has
not been described in detail so that the invention is not
unnecessarily obscured.
[0024] FIG. 1 is a block diagram illustrating an embodiment of an
environment in which point to multi-point connections are made. In
the example shown, client 102 is used to administer various nodes
(also referred to herein as "devices") in three networks. Examples
of users of client 102 include in-house engineers/administrators,
consultants, vendors, and managed service providers (hereinafter
referred to collectively as "administrators"). In some cases,
administrators administer entire nodes (such as a file server). In
other cases, administers administer subsets of nodes such as by
administering particular services without administering other
services on the same node. As used herein, the "resources"
administered by an administrator refer to the nodes and/or services
an administrator is authorized to access. Some of the resources
administered may be critical pieces of infrastructure, such as
production servers or databases.
[0025] Network 106 is an enterprise network located in Denver that
includes (among other nodes) a Windows server 116, a router 118,
and a database server 120. Network 108 is an enterprise network
located in San Francisco that includes (among other nodes) a Linux
server 122, a router 124, and a switch 126. Network 109 is an
enterprise network located in Sydney that includes (among other
nodes) a firewall 128 and a router 130. In the example shown,
networks 106-109 are disjoint, meaning that they do not share a
direct connection (e.g., from network 106 to network 108) but
instead are connected via the Internet 104. In some embodiments the
networks may be in close physical proximity but otherwise disjoint,
such as in an environment where blade computers and virtualization
software are used.
[0026] In the example shown, a particular administrator (also
referred to herein as "Alice") has the responsibility of
administering resources on nodes 116-122 and 126-130 using her
company issued laptop, client 102. Alice does not administer node
124. Other examples of clients include workstations, personal
computers, and cellular phones/personal digital assistants (PDAs),
as well as other types of information appliances, as applicable. In
some embodiments, an agent 150 facilitates communication between
client 102 and networks 106-109.
[0027] Suppose Alice is physically located in Albuquerque. As
described in more detail below, she uses client 102 to maintain
concurrent sessions with gatekeepers 110, 112, and 114. After
authenticating Alice, the gatekeepers provide client 102 with
instructions that map ports on Alice's laptop with services on the
devices she is authorized to administer. Alice is presented an
abstracted consolidated view of those resources on networks 106-109
to which she is authorized access, and cannot view the resources on
those networks that she is not authorized to access. Networks
106-109 may each contain hundreds or thousands of nodes.
Nonetheless, using the techniques described herein, only the subset
of resources Alice is authorized to access will be visible to her.
For example, after authenticating to gatekeepers 110-114 and
initiating sessions with those gatekeepers, Alice will be able to
copy files from Windows server 116 to Linux server 122 by using
native tools on her laptop such as the file explorer and/or an scp
client, while simultaneously viewing the configuration of firewall
128. Alice will not be able to see router 124 (represented here
using dashed lines).
[0028] FIG. 2 is a flow chart illustrating an embodiment of a
process for communicating with a plurality of networks. In some
embodiments the process shown in FIG. 2 is performed by client 102.
As described in more detail below, in some embodiments agent 150
facilitates the process shown in FIG. 2. The process begins at 202
when one or more credentials are provided to a first gatekeeper.
For example, at 202 client 102 provides credentials to gatekeeper
110. In some embodiments, Alice provides credentials at 202 by
starting agent 150 on her laptop, and providing agent 150 with the
IP address of gatekeeper 110, and a username and password by which
gatekeeper 110 can authenticate her. In various embodiments other
authentication techniques are used instead of or in addition to
providing a name and a password, such as by requiring Alice to
provide a secondary authentication factor or a digital
certificate.
[0029] At 204, one or more credentials are provided to a second
gatekeeper. For example, at 204, client 102 provides credentials to
gatekeeper 112. In some embodiments Alice is prompted to provide
the addresses of all the gatekeepers she authorized to communicate
with along with the credentials needed to authenticate to those
gatekeepers. For example, when Alice first uses client 102 to
communicate with networks 106-109, as part of a setup phase, she
might be requested to provide the IP addresses of gatekeepers
110-114 and any logins/passwords associated with those
gatekeepers.
[0030] In some embodiments, the gatekeepers maintain lists of other
gatekeepers and the authorized users of those gatekeepers. When
Alice attempts to log in to a first gatekeeper, that gatekeeper may
be configured to automatically provide Alice's credentials to the
other gatekeepers in lieu of Alice providing it to each gatekeeper
herself.
[0031] At 206, a session is maintained with the first gatekeeper.
For example, after validating Alice's credentials, gatekeeper 110
determines the resources to which Alice should be granted access
and provides client 102 with instructions for reaching those
resources. As described in more detail below, gatekeeper 110
facilitates communication between Alice and the resources during
the session with gatekeeper 110.
[0032] At 208, a session is maintained with a second gatekeeper
while simultaneously maintaining a session with the first
gatekeeper. For example, at 208, Alice has two concurrent sessions
with two gatekeepers--gatekeeper 110 and gatekeeper 112. As
applicable, Alice can maintain more than two sessions. For example,
if Alice authenticates to gatekeeper 114, Alice can establish three
concurrent sessions, one each with gatekeepers 110-114, and is able
to simultaneously see resources 116-122 and 126-130.
[0033] FIG. 3 is a block diagram illustrating an embodiment of a
gatekeeper. In the example shown, gatekeeper 110 includes a user
database 302. User database 302 includes a list of users authorized
to access gatekeeper 110 and those users' credentials. For example,
user database 302 might include Alice's username (e.g.,
alice.jones) and information suitable to authenticate Alice (e.g.,
a hash of her passphrase, a digital certificate, etc.).
[0034] Device database 304 includes a list of all of the devices on
a network that can be made available to administrators via a
gatekeeper. For example, Windows server 116, router 118, and
database server 120 could be included in gatekeeper 110's device
database, along with information such as those nodes IP addresses
and, if applicable, network name.
[0035] Service database 306 includes a list of services provided by
the devices in device database 304. Examples of services include
FTP and SSH. In some embodiments the services listed in service
database 306 include all services listening on the ports of the
devices listed in device database 304.
[0036] Policy database 308 includes four dimensional policies that
govern the resources that client 102 is allowed to access. The
dimensions are user, time, service, and device. An example policy
could be represented in policy database 306 as a row entry of the
form (user,time,service,device). For example, suppose Alice is
permitted to connect to Windows server 116 nightly so that she can
perform integrity checks. User database 302 includes an entry for
Alice. Device database 304 includes an entry for Windows server 116
and its IP address. Service database 306 includes entries KVM_web
and RDP, the two connection methods that Windows server 302
supports. Suppose Alice is only permitted to connect using KVM_web.
A policy defining her access rights might be represented in policy
database 306 as (alice.jones,23:00,23:59, RDP, WindowsServer116),
where 23:00 indicates that she may start using the service at 23:00
and where 23:59 indicates that her authorization to use the service
ends at 23:59.
[0037] In some embodiments Alice receives permission to access a
bundle of services (e.g., FTP and SSH) across a bundle of devices
(e.g., nodes 116, 120, and 122) during certain time periods,
without being constrained to use, e.g., SSH on node 116 but not on
node 120. Similarly, Alice may be permitted to perform any of those
services on any of those devices during a time window (e.g., 8 am
to noon) rather than specifying precise times that specific tasks
may be performed. In various embodiments, policies may include
fewer or more dimensions. For example, Alice may not be constrained
by time in some actions, or the time constraints may be more
flexible.
[0038] In various embodiments, other data structures are used to
store and provide access to the information contained in databases
302-308 such as flat files. In the example shown, the contents of
each database is thin. For example, while there may be many
different versions of FTP offered across several different
platforms (e.g., FTP for Windows, FTP for Linux, and the assorted
versions thereof), there might be only a single "FTP" entry in the
services database that is used to indicate any and all of those
particular instances of FTP.
[0039] Enforcement module 312 provides agent 150 with instructions
based on applicable policies stored in policy database 308.
Gatekeeper 110 also includes a variety of applets 310 that can be
provided to client 102 as needed.
[0040] FIG. 4 is a flow chart illustrating an embodiment of a
process for enrolling a user with a gatekeeper. In some embodiments
the process shown in FIG. 4 is performed by client 102. The process
begins at 402 when an agent such as agent 150 is installed on a
client device such as client 102. Administrators often use multiple
clients, such as workstations during regular business hours,
laptops when at home, and PDAs or other portable devices when
mobile. Accordingly, the process performed at 402 may be repeated
for each of the clients the administrator intends to use to access
resources on the networks the administrator administers. Similarly,
the process performed at 402 may be repeated whenever Alice obtains
a new laptop or otherwise upgrades client 102. In some embodiments
the agent is a Java-based package and is cross-platform. In other
embodiments, platform specific agents are used at 402.
[0041] At 404, user credentials are provided, along with the
location of at least one gatekeeper. For example, at 404, Alice
starts agent 150 and is prompted to enter the location of at least
one gatekeeper and the credentials that she would like to use to
authenticate to that gatekeeper. If Alice has access to multiple
gateways, she may provide their information at 404 as well, or the
gatekeepers may communicate Alice's information amongst themselves
without her needing to enter more than one gatekeeper's information
into agent 150. In some embodiments, the agent itself requires
credentials to start, and Alice is prompted to provide those
credentials at startup.
[0042] FIG. 5 is a flow chart illustrating an embodiment of a
process for enrolling a user with a gatekeeper. In some embodiments
the process shown in FIG. 5 is performed by gatekeeper 110. The
process begins at 502 when an account for a user such as Alice is
established. One way of establishing an account is to create an
entry in the user database that specifies the user's credentials
and whether the user is subject to time based restrictions or may
always access authorized resources (an "always on" account). For
example, suppose another user, Bob, is hired to assist Alice on a
large project during an upcoming weekend. Bob's account can be
created at any time, but an indicator can be associated with his
account that his account should only be active between 17:00 on
Friday through 21:00 on Sunday.
[0043] At 504, the created user account is mapped or associated
with applicable policies, such as that the user may access FTP and
SSH on Linux server 122. In some embodiments, the policies
applicable to a particular user are based on the user's role. For
example, all database administrators may be given the same access
to the same resources. In such a case, templates or wizards may be
used by the entity configuring the gatekeeper. If the user should
be given access to resources on different networks, that access can
be specified at 504 by a single entity and propagated to the
corresponding gatekeepers of those networks, or the individual
gatekeepers can each be manually configured. In some embodiments
the credentials used by a user such as Alice may vary across
gatekeepers. For example, Alice may connect to gatekeeper 110 using
a name/password pair, and connect to gatekeeper 112 using a digital
certificate. In such case, the user and policy databases maintained
by those gateways may link Alice's accounts such as by associating
each of her accounts with a unique identifier.
[0044] FIG. 6 is a flow chart illustrating an embodiment of a
process for establishing a session with a gatekeeper. In some
embodiments the process is performed by client 102. The process
begins at 602 when agent 150 is started. In some embodiments agent
150 is configured to load whenever client 102 is booted or whenever
a user such as Alice logs into client 102. Agent 150 can also be
configured to load only when Alice takes an action such as clicking
on a program icon. In various embodiments, Alice is required to
provide credentials to agent 150 before she is granted access to
it.
[0045] At 604, the agent connects to the first preconfigured
gatekeeper (e.g., specified at 404 in the process shown in FIG. 4)
and performs a handshake.
[0046] At 606, the agent receives instructions that indicate how
authorized resources can be accessed. As described in more detail
below, the instructions might include information on port
binding/forwarding.
[0047] At 608, the agent follows the instructions received at 606
and awaits service connection requests. For example, at 608 the
agent might bind a service to localhost port 6000 and await the
user's use of that port.
[0048] FIG. 7 is a flow chart illustrating an embodiment of a
process for establishing a session with a client. In some
embodiments the process shown in FIG. 7 is performed by gatekeeper
110. The process begins at 702 when a client connection request is
received. For example, at 702 a connection request is received from
client 102. At 704, authentication is requested from the client. At
706, the received credentials are validated.
[0049] At 708, an on-demand access policy is compiled and sent to
the client. For example, at 708 each of the databases 302-308 is
queried for entries pertaining to the user of the client and
instructions are transmitted to the client that indicate how the
client may access the resources enumerated in the compiled access
policy.
[0050] Suppose, for example, that Alice is establishing a session
with gatekeeper 112. On network 108, Alice is authorized to access
Linux server 122 and switch 126 using the FTP, SSH, and telnet
services, but is not authorized to access router 124 at all, and is
not authorized to access any other services on nodes 122 or 126.
Also suppose that Linux server 122 supports all three services,
while router 124 only supports the telnet service. At 708, client
102 receives instructions to port forward 127.0.0.1 port 21 to
Linux server 122's FTP service, forward 127.0.0.1 port 22 to Linux
server 122's SSH service, forward 127.0.0.1 port 23 to Linux server
122's telnet service, and forward 127.0.0.2 port 123 to router
126's telnet service. Per the received instructions, agent 150 will
bind to the local port, set up a listener, and the listener will
port forward as appropriate.
[0051] In some embodiments, rather than forwarding directly to the
service, agent 150 is instructed to forward localhost to a port on
the gatekeeper, which in turn forwards to the appropriate resource.
In such a case, a unique identifier is used by the gatekeeper to
map the localhost and remote resource to one another. By using this
technique, encryption can be used in the communications between
client 102 and resources that might typically otherwise be sent in
the clear, such as communications sent to an ODBC port.
Additionally, the IP address of the resource need not be exposed to
client 102. If client 102 is lost or stolen, a nefarious individual
attempting to connect to remote resources will be thwarted
accordingly.
[0052] Suppose another administrator, Charlie, is in charge of
administering a subset of ten of the twenty five database servers
in the Denver office (network 106), and should be granted access to
the ODBC port (and nothing else) on each of those servers. If the
process shown in FIG. 7 were performed with respect to Charlie, at
708 Charlie's client might receive instructions that his agent 150
should port forward 127.0.0.1-127.0.0.10 to each of those
databases, respectively. Charlie's client may also be configured to
use a single address but different TCP port numbers for each of the
databases (e.g., 127.0.0.1:6000-127.0.0.1:6009) as applicable.
Typically, database servers offer many services. By using the
techniques described herein, administrators may only access those
services access to which they are authorized.
[0053] At 710, a session has been established and, as described in
more detail below, the gatekeeper can be configured to listen for
services to be used (e.g., connection requests to be made).
[0054] FIG. 8 is a flow chart illustrating an embodiment of a
process for communicating information across a plurality of
networks. The process shown in FIG. 8 can be used to perform cross
network, cross platform, and/or cross protocol exchanges. In some
embodiments the process shown is performed by client 102. The
process begins at 802 when information is accessed at a first
location. Suppose Alice wishes to copy a file from Windows server
116 in network 106 to Linux server 122 in network 108. Windows
server 116 supports SMB on port 139. Linux server 122 supports SSH
on port 22. At 802, Alice accesses the file by using native tools
on her laptop, such as by navigating to the directory in which the
file is located with the Windows file explorer. When Alice
navigates to \\localhost:139, a connection is made to an SMB mount
on Windows server 116.
[0055] At 804, the information is transferred from the first
network to the second network. For example, at 804 Alice might open
a tool such as an scp program, right click the file on Windows
server 116 as shown in the file explorer window, and copy and paste
it into the scp program. Agent 150 facilitates the copying of the
file from Windows server 116 to Linux server 122 in a manner
transparent to Alice. In various embodiments, a graphical user
interface (GUI) may also be provided to client 102 which shows a
list of the resources available via agent 150 and launches
applications, etc. as the user interacts with the GUI.
[0056] The techniques described herein also allow administrators to
run tools local to their clients against remote resources. For
example, suppose Charlie (a database administrator) has a set of
database diagnostic tools on his laptop that can be configured to
work against a local database. By port forwarding his localhost to
a remote database, Charlie is able to run his tools on the remote
database. Additionally, it is possible that Charlie's database
diagnostic tools may be buggy or otherwise harmful. Because he is
constrained to accessing a small subset of the network, his tools
are less likely to have catastrophic effects on the network at
large if they behave in an undesirable manner.
[0057] FIG. 9 is a flow chart illustrating an embodiment of a
process for communicating information across a plurality of
networks. In some embodiments the process shown in FIG. 9 is
performed by a gatekeeper such as gatekeeper 110. The process
begins at 902 when a request specific to a particular device and
service is received. For example, after portion 608 of the process
shown in FIG. 6 is performed, agent 150 may observe that a user is
attempting to communicate with a particular localhost port. At 902,
a connection request is received by gatekeeper 110 accordingly. As
applicable, decryption is performed and at 904, the requested
resource is mapped to the actual resource. For example, at 904
requests intended for the SSH port of Linux server 122 received by
gatekeeper 112 are mapped to the IP address of Linux server 122. At
906, information destined to/from client 102 and the intended
destination (e.g., Linux server 122) is bi-directionally
forwarded.
[0058] Auditing Communications
[0059] FIG. 10 is a block diagram illustrating an embodiment of an
environment having communication auditing. In the example shown,
client 1002 includes an agent 1008. An administrator would like to
execute two jobs (1010 and 1012) on a periodic basis, without
having to be logged into client 1002 at the time. Suppose the
administrator would like job 1010 to execute at midnight and the
administrator would like job 1012 to run at three in the morning
and that both jobs include transmitting information to server 1006.
In the example shown, server 1006 is a production server with
thousands of ports. In some embodiments client 1002 and server 1006
are members of disjoint networks, such as is the case with client
102 and Windows server 116 in FIG. 1. In some embodiments client
1002 and server 1006 are on two segments of an intranet.
[0060] In a traditional environment, end users might be permitted
to access server 1006 to perform assorted tasks and an
administrator might be permitted to make direct connections to
ports such as UDP port 1014 and TCP port 1016 (and any of the other
thousands of ports on server 1006). In such a scenario client 1002
would typically be permitted to access server 1006 at all
times--not just at midnight and three. In the example shown,
however, direct connections from client 1002 to administrative
ports 1014 and 1016 are not permitted, as indicated in FIG. 10 by
line 1018 being crossed out.
[0061] Using the techniques described herein, gatekeeper 1004 is
placed between client 1002 and server 1006. In some embodiments
client 1002 is client 102. In some embodiments client 1002 is a
server such as Linux server 122. Agent 1008 is configured to
emulate the actions a user might take if the user were actively
using client 1002. For example, and as described in more detail
below, agent 1008 can be configured to store credentials and
automatically provide them to gatekeeper 1004 upon request.
[0062] In the example shown, in order for jobs 1010 and 1012 to run
successfully, client 1002 must authenticate itself to gatekeeper
1004 and gatekeeper 1004 must confirm that the resources requested
by client 1002 are authorized for use by client 1002. Agent 1008 is
configured to port forward localhost ports on client 1002 to
gatekeeper 1004 as applicable. Jobs 1010 and 1012 are configured to
make use of resources by their local address. For example, suppose
job 1010 is a shell script. At the top of the file a list of
variables might be provided, one of which specifies the local
address and port (e.g., 127.0.0.1:25) that forwards to the desired
remote resource.
[0063] If the administrator attempts to run job 1010 before
midnight, gatekeeper 1004 will not forward information to server
1006. As a result, while the job may run locally, when it attempts
to access port 127.0.0.1:25, the connection attempt will fail. If
the administrator attempts to run job 1010 at midnight, however,
connection attempts to port 127.0.0.1:25 will succeed and the job
will be able to execute as planned.
[0064] FIG. 11 is a flow chart illustrating an embodiment of a
process for auditing a communication. In some embodiments the
process shown is performed by gatekeeper 1004. The process begins
at 1102 when credentials are received from a client such as client
1002. As described in more detail below, the credentials received
at 1102 may be automatically supplied by an agent such as agent
1008, without the intervention of a user.
[0065] At 1104 it is determined whether the client is authorized to
communicate with any remote resources. For example, at 1104 the
user credentials are verified and gatekeeper 1004 determines
whether the client (using the user's credentials) is authorized to
access any resources and if so, whether any time constraints
associated with use of those resources are satisfied.
[0066] If it is determined that the client is authorized to
communicate with resources, at 1106 communications are forwarded
from the client to the resource. In some embodiments communications
are forwarded bidirectionally. Gatekeeper 1004 can be configured to
cease performing the forwarding of 1106 for a variety of reasons.
For example, authorization may be granted based on a specified
session length--job 1010 may be permitted to run for a window of
time of up to an hour, at which point in time access by client 1002
of server 1006 is revoked. In other embodiments, if a process is
still running when the designated time limit is reached, a grace
period (e.g., of an additional 30 minutes) may be provided, or
additional steps may be taken such as paging the administrator
responsible for the job.
[0067] FIG. 12 is a flow chart illustrating an embodiment of a
process for auditing a communication. In some embodiments the
process shown is performed by client 1002. The process begins at
1202 when agent 1002 is started. In some embodiments agent 1202 is
configured to start at startup, such as by using/etc/init.d or
other startup script. In some embodiments the agent is configured
to start just prior to any jobs that make use of the script. For
example, if job 1010 is executed as a cron job, the cron entry may
include execution of the agent as the first command, with the
execution of the job listed as a second command, separated by a
semicolon.
[0068] At 1204, agent 1008 connects to the first preconfigured
gatekeeper (e.g., specified at 404 in the process shown in FIG. 4)
and performs a handshake. In the example shown, user credentials
are provided automatically. For example, during configuration of
agent 1002, a user might be presented with the option of checking a
box to save entered credentials and have them automatically
provided when needed.
[0069] At 1206, the agent receives instructions that indicate how
authorized resources can be accessed. At 1208, the agent follows
the instructions received at 1206 and awaits service connection
requests. For example, at 1208 the agent might bind a service to
localhost port 6000.
[0070] In some embodiments a user's access to a resource may be set
to always on (no time restriction). One scenario in which an always
on access level might be set is if a particular job makes frequent
regular use of a service (e.g., every hour). Nonetheless, it is
still possible to determine which user is responsible for the
recurring job, and the user is still confined to a specific port,
and security benefits are realized accordingly.
[0071] Automatic Intervention
[0072] FIG. 13A is a block diagram illustrating an embodiment of an
environment having network security. In the example shown, client
1302 is used by an administrator to configure and maintain router
1306. Router 1306 may be one of a variety of routers. For example,
router 1306 may be sophisticated and new, offering many of its own
security features. Router 1306 may also be ten years old. The
techniques described herein can be used to extend security features
to either such router.
[0073] As described in more detail below, gatekeeper 1304
facilitates communications between client 1302 and router 1306. For
example, in some embodiments gatekeeper 1304 serves a Java applet
to client 1302 configured such that a user can use the Java applet
to communicate with router 1306. Router 1306 is connected to
additional devices such as server 1308 and server 1310. By using
the techniques described herein, a user of client 1302 can be
prevented from roaming from router 1306 to those devices.
[0074] FIG. 13B is a block diagram illustrating an embodiment of an
environment having network security. In the example shown, client
1352 is used by an administrator to configure and maintain server
1356. Gatekeeper 1354 facilitates communications between client
1352 and server 1356. For example, in some embodiments gatekeeper
1354 serves a Java applet to client 1352 configured such that a
user can use the Java applet to communicate with server 1356. As
described in more detail below, in some embodiments an agent 1358
resident on server 1356 monitors for socket open attempts. Server
1356 is connected to additional devices such as servers 1360 and
1362. By using the techniques described herein, a user of client
1352 can be prevented from roaming from server 1356 to those
devices.
[0075] FIG. 14 is a flow chart illustrating an embodiment of a
process for detecting unauthorized commands. In some embodiments
the process shown in FIG. 14 is performed by gatekeeper 1304. The
process begins at 1402 when a monitored session between a client
and a network resource is provided. For example, at 1402 a client
such as client 1302 requesting access to router 1306 authenticates
itself to gatekeeper 1304. After verifying client 1302's
credentials, gatekeeper 1304 serves a Java applet to client 1302
that allows the user of client 1302 to communicate with router
1306. In various embodiments, the applet provided by gatekeeper
1304 supports common protocols (which can be used, e.g., if client
1302 doesn't have an appropriate native client) and is
preconfigured with the information needed for client 102 to
communicate with router 1306. In some embodiments the applet
provided is one of the applets 310 shown in FIG. 3.
[0076] Gatekeeper 1304 is able to monitor the bidirectional data
stream between client 1302 and router 1306 and can capture the
user's keystrokes as well as the output of the router during the
session. In some embodiments the data stream is logged to a syslog
server and can be subsequently used forensically and/or to diagnose
historical network problems. At 1404 gatekeeper 1304 monitors for
indications that a user is attempting to execute an unauthorized
command. For example, at 1404 gatekeeper 1304 determines whether a
user is attempting to roam from the router out to server 1308 or
1310.
[0077] A variety of techniques can be used to detect attempts at
unauthorized commands. In some embodiments a blacklist is used.
Routers typically have a finite set of commands that administrators
may use to manipulate the router. Commands that establish outgoing
connection attempts, such as SSH and telnet can be added to a
blacklist of commands for which gatekeeper 1304 monitors the
keystrokes sent by client 1302 to router 1306. If blacklisted
commands are detected, gatekeeper 1304 can intercept the command
before it is passed to router 1306 (1406).
[0078] When gatekeeper 1304 intervenes it can take a variety of
actions--for example, it can drop the command or replace the
command with a bogus command that is passed onto router 1306 as a
typo so that the router rejects it. In some embodiments gatekeeper
1304 echoes a warning back to client 1302 that an unauthorized
attempt to roam has been detected and logged and that any
additional attempts will trigger a call to law enforcement, result
in the locking of the user's account, etc. Irrespective of whether
law enforcement will actually be contacted, such warning messages
may discourage additional attempts at roaming on the part of a
curious or nefarious administrator. In various embodiments,
additional information such as the client's host name and local IP
address are collected in the event of an unauthorized command
attempt so that if the user is behind a NAT and/or shares login and
password information with other contractors, the user can be more
easily identified.
[0079] Gatekeeper 1304 can also take additional silent actions such
as sending an email to a supervisor or triggering a pager alert,
and locking a user's account after a certain number of unauthorized
attempts is received.
[0080] In some embodiments a whitelist is used to detect attempts
at unauthorized commands. In such a scenario, the set of commands
an administrator may send from client 1302 to router 1306 is
limited to a prespecified set. Any commands not on the whitelist
are intercepted by gatekeeper 1304.
[0081] In various embodiments different actions are taken by
gatekeeper 1304 based on which unauthorized command is detected.
For example, reboot-type commands (reboot, shutdown) might trigger
a warning, while roaming commands (telnet, ssh, rlogin, connect)
might be dropped. Additionally, which commands appear on a
blacklist or whitelist can be defined on the gatekeeper a per user
basis. Thus irrespective of whether the router supports
configurable logins, a user Alice can be restricted to using three
commands while a user Bob can be restricted to using five
commands.
[0082] Servers such as server 1356 typically support considerably
more commands than a router such as router 1306. As such, using the
blacklist and whitelist approaches may not be practical or
effective. For example, a user might author a script on server 1356
that calls telnet, or may rely on shell features such as tab
completion to provide the server with unauthorized commands without
explicitly typing them. Instead of relying on white and/or
blacklists, in some embodiments server 1356 is configured with an
agent that monitors for socket open attempts and kills them.
[0083] FIG. 15 is a flow chart illustrating an embodiment of a
process for detecting unauthorized commands. In some embodiments
the process shown in FIG. 15 is performed by server 1356. The
process begins at 1502 when a monitoring agent such as agent 1358
is started. In some embodiments monitoring agent 1358 is started at
server 1356's boot time.
[0084] At 1504, agent 1358 determines a list of active users such
as root, nobody, ftp, etc. Monitoring agent 1358 continually looks
for new logins to server 1356 and when one is detected (1506), at
1508 the monitoring agent asks gatekeeper 1354 whether the new
server user has been provided by gatekeeper 1354. If so, at 1510
the monitoring agent obtains information such as the pid and uid of
the new user. If any processes associated with the new user attempt
to open sockets, monitoring agent kills them. Additional
remediation, such as sending warning messages to the user or
contacting a supervisor can also be performed, as applicable.
[0085] Although the foregoing embodiments have been described in
some detail for purposes of clarity of understanding, the invention
is not limited to the details provided. There are many alternative
ways of implementing the invention. The disclosed embodiments are
illustrative and not restrictive.
* * * * *