US20150058385A1 - Bilateral transfer system using multiple one-way data links - Google Patents

Bilateral transfer system using multiple one-way data links Download PDF

Info

Publication number
US20150058385A1
US20150058385A1 US14/508,188 US201414508188A US2015058385A1 US 20150058385 A1 US20150058385 A1 US 20150058385A1 US 201414508188 A US201414508188 A US 201414508188A US 2015058385 A1 US2015058385 A1 US 2015058385A1
Authority
US
United States
Prior art keywords
server
information
receive
network
communications interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US14/508,188
Inventor
Ronald Mraz
Kenneth Lerman
Gabriel Silberman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Owl Cyber Defense Solutions LLC
Original Assignee
OWL Computing Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by OWL Computing Technologies Inc filed Critical OWL Computing Technologies Inc
Priority to US14/508,188 priority Critical patent/US20150058385A1/en
Assigned to OWL COMPUTING TECHNOLOGIES, INC. reassignment OWL COMPUTING TECHNOLOGIES, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MRAZ, RONALD, LERMAN, KENNETH, SILBERMAN, GABRIEL
Publication of US20150058385A1 publication Critical patent/US20150058385A1/en
Assigned to OWL COMPUTING TECHNOLOGIES, LLC reassignment OWL COMPUTING TECHNOLOGIES, LLC MERGER (SEE DOCUMENT FOR DETAILS). Assignors: OWL COMPUTING TECHNOLOGIES, INC.
Assigned to OWL COMPUTING TECHNOLOGIES, LLC reassignment OWL COMPUTING TECHNOLOGIES, LLC CORRECTIVE ASSIGNMENT TO CORRECT TO REMOVE THIS DOCUMENT SERVES AS AN OATH/DECLARATION (37 CFR 1.63) FROM THE COVER SHEET PREVIOUSLY RECORDED AT REEL: 041765 FRAME: 0034. ASSIGNOR(S) HEREBY CONFIRMS THE MERGER EFFECTIVE DATE 02/03/2017. Assignors: OWL COMPUTING TECHNOLOGIES, INC.
Assigned to OWL CYBER DEFENSE SOLUTIONS, LLC reassignment OWL CYBER DEFENSE SOLUTIONS, LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: OWL COMPUTING TECHNOLOGIES, LLC
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33Querying
    • G06F16/335Filtering based on additional data, e.g. user or group profiles
    • G06F17/30699
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/02Capturing of monitoring data
    • H04L43/028Capturing of monitoring data by filtering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281Proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/18Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/28
    • H04L67/42
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105Multiple levels of security
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services

Definitions

  • the present invention relates generally to a Network File System (NFS) storage device accessible via unidirectional data transfer.
  • NFS Network File System
  • firewall and anti-malware software have been developed to address security concerns for computers and networks connected to the Internet and to protect them from possible cyberattacks such as Trojan horse-type viruses or worms that may trigger undesired and unauthorized data disclosure by these computers and networks.
  • conventional network security devices such as firewalls may not provide sufficiently reliable protection from undesired data disclosure.
  • FIG. 1 schematically illustrates an example of one such one-way data transfer system 100 .
  • two computing platforms (or nodes) 101 and 102 (respectively, “the Send Node” and “the Receive Node”) are connected to the unsecured external network 104 (“the source network”) and the secure network 105 (“the destination network”), respectively.
  • the Send Node 101 is connected to the Receive Node 102 by a one-way data link 103 , which may be an optical link comprising, for example, a high-bandwidth optical fiber.
  • This one-way optical data link 103 may be configured to operate as a unidirectional data gateway from the source network 104 to the secure destination network 105 by having its ends connected to an optical transmitter on the Send Node and to an optical receiver on the Receive Node.
  • This configuration physically enforces one-way data transfer at both ends of the optical fiber connecting the Send Node 101 to the Receive Node 102 , thereby creating a truly unidirectional one-way data link between the source network 104 and the destination network 105 shown in FIG. 1 .
  • one-way data transfer systems based on a one-way data link are designed to transfer data or information only in one direction and it is physically impossible to transfer data or information of any kind in the reverse direction using that link.
  • No information or data of any kind including handshaking protocols such as those used in data transport protocols such as TCP/IP, SCSI, USB, Serial/Parallel Ports, etc., can travel in the reverse direction from the Receive Node back to the Send Node across the one-way data link.
  • the one-way data transfer system based on a one-way data link ensures that data residing on the isolated secure computer or network is maximally protected from any undesired and unauthorized disclosure.
  • the system 201 in the '209 patent comprises two computing platforms or nodes, Node A 202 and Node B 203 , interconnected by two separate, oppositely directed one-way communication channels, Link R 204 and Link L 205 .
  • These one-way communication channels are deployed in parallel to enable bilateral communications between Node A and Node B, wherein Link R 204 is for unidirectional data transfer from Node A to Node B, while Link L 205 is for unidirectional data transfer in the opposite direction, from Node B to Node A.
  • This arrangement forces all data traffic between Nodes A and B to flow unidirectionally through two entirely separate conduits, with each of the unidirectional data transfers across these conduits separately administered.
  • the two links are separately administered by employing separate data transfer applications, interfaces and configuration files solely for the unidirectional data transfer in each direction, each set configured to prevent any cross-talk with the one-way communication channel for the opposite direction.
  • Link R 204 is associated with data sending application 210 and interface 206 in Node A 202 and data receiving application 212 and interface 208 in Node B 203
  • Link L 205 is associated with data sending application 213 and interface 209 in Node B 203 and data receiving application 211 and interface 207 in Node A 202
  • the one-way data links used in Link R 204 and Link L 205 in FIG. 2 may be of any type of data transfer conduit that is capable of enforcing unidirectional data flow.
  • the data sending application 210 in Node A (or 213 in Node B) and data receiving application 212 in Node B (or 211 in Node A) in combination with proxy and session managing applications 220 , 218 and 221 , 219 respectively in Node A and Node B use Transmission Control Protocol/Internet Protocol (TCP/IP) as a user interface to the one-way data link in Link R 204 (or Link L 205 ).
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • the TCP proxy applications 220 and 221 are preferably TCP/IP socket-based proxy software, but may also be hardware-based or based on a suitable combination of software and hardware.
  • the TCP proxy application 220 residing in Node A 202 fully implements TCP/IP-based bilateral communications between Node A and an external platform communicatively coupled to Node A, such as a remote terminal client 222 shown in FIG. 2 .
  • the TCP proxy application 221 residing in Node B 203 fully implements TCP/IP-based bilateral communications between Node B and an external platform communicatively coupled to Node B, such as a remote terminal server 223 shown in FIG. 2 .
  • the TCP session managing applications 218 and 219 are software-based applications for maintaining one or more TCP sessions.
  • the session managing application 218 , 219 in each node 202 , 203 “splits” the bilateral communication channel between the node and corresponding remote terminal 222 , 223 into two unidirectional communication channels based by strictly enforcing a separation of data coming from the remote terminal client 222 , 223 and data coming via the data receiving application 211 , 212 .
  • the system shown in FIG. 2 simulates the TCP/IP protocol between the remote terminal client 222 and the remote terminal server 223 across the one-way data link in Link R 204 by replacing the IP information in the received data with pre-assigned channel numbers, so that no IP information is sent across the one-way data link.
  • IP routes are pre-defined in the form of complementary channel mapping tables associated respectively with the data sending application 210 in Node A and data receiving application 212 in Node B.
  • the data receiving application 212 then replaces the channel numbers in the received data with IP information from the channel mapping table and forwards the modified data to the TCP session managing application 219 .
  • the session managing application 219 maintains one or more TCP sessions and routes the received data packets or files from the data receiving application 212 to the proxy application 221 .
  • the TCP proxy application 221 in Node B fully implements the TCP/IP protocol in its bilateral communications with the remote terminal server 223 , requests a socket connection and delivers the data received from the remote terminal client 222 to the remote terminal server 223 .
  • the same process is used to transfer data from remote terminal server 223 to remote terminal client 222 , as discussed in further detail in the '209 patent, but using data sending and receiving applications, interfaces and configuration files that are entirely separate from those associated with the one-way data transfer from remote terminal client 222 to remote terminal server 223 .
  • the system shown in FIG. 2 and described above can support the inherently different security checks and restrictions required for transferring data from a lower security domain to a higher security domain and for transferring data from it (e.g., the situation where the client requesting data is in a lower security domain).
  • that system can also support the inherently different security checks and restrictions required for transferring data from a higher security domain to a lower security domain and for transferring data from it (e.g., the situation where the client requesting data is in a higher security domain).
  • the types of transfers allowed require some a priori knowledge of the information being requested.
  • the data being transferred from the client to the server is completely independent from the data being transferred from the server to the client and the data is transmitted in a raw byte stream without any indication of message boundaries. This makes it difficult to filter data, for example, based on message type.
  • the Network File System is a standard network client/server protocol used to allow computers to mount a remote disk partition and transparently access it as if it were a local disk.
  • NFS Network File System
  • An NFS client on a user computer communicates with a remote server where the remote disk is located using Remote Procedure Call (RPC) protocol in order to implement an access to files located on the remote disk.
  • RPC Remote Procedure Call
  • An RPC is an inter-process communication that allows a client to cause a subroutine or procedure to execute in another address space (e.g., on a known remote server) without the programmer explicitly coding the details for this remote interaction.
  • An RPC is initiated by the client, which sends a request message to the known remote server to execute a specified procedure with supplied parameters.
  • NFS operates based on matched RPC requests/replies, thus an implementation of NFS across the bilateral communication system of FIG. 2 would provide less than optimal results, for example due to a difficulty in filtering the raw message stream.
  • the system includes a first platform including first send server, a first one-way data link and a first receive server, and a second platform including a second send server, a second one-way data link and a second receive server.
  • the first send server has a data communications interface.
  • the first one-way data link has an input and an output.
  • the first receive server has a data communications interface.
  • the first send server is coupled to the input of the first one-way data link.
  • the first receive server is coupled to the output of the first one-way data link.
  • the first send server is configured to forward information received at the data communications interface to the input of the first one-way data link.
  • the first receive server is configured to forward information received from the output of the first one-way data link to the data communications interface
  • the second send server has a network connection and a data communications interface.
  • the second one-way data link has an input and an output.
  • the second receive server has a network connection and a data communications interface.
  • the second send server is coupled to the input of the second one-way data link.
  • the second receive server is coupled to the output of the second one-way data link.
  • the network connection of the second receive server is coupled to the first network and the data communications interface is coupled only to the data communications interface of the first send server.
  • the second send server is coupled to the second network via the network connection and the data communications interface is coupled only to the data communications interface of the first receive server.
  • the second receive server is configured to receive first information from the client via the first network and the network connection, to process the received first information and to forward the processed first information to the first send server via the data communications interface. Alternatively, the second receive server may forward the first information without processing.
  • the second send server is configured to receive the processed first information via the data communications interface and to forward the processed first information to the server via the network connection and second network.
  • the second send server is also configured to receive second information from the server via the second network and the network connection and to forward the second information to the second receive server via the second one-way data link. Alternatively, the second send server may process the second information before forwarding.
  • the second receive server is also configured to receive the second information from the second one-way data link and to forward the second information to the client via the network connection and first network.
  • the second receive server and the second send server are each also configured to maintain the first information completely separate from the second information.
  • the processing performed on the first information by the second receive server comprises filtering the information to remove a predetermined category of information.
  • the predetermined category of information may be identification information.
  • the identification information may be user credentials.
  • the first information is an NFS function call of a set of possible NFS function calls and the processing performed by the second receive server identifies a type of the NFS function call and blocks further transmission of the NFS function call if the identified type does not correspond to any one of a predetermined subset of possible NFS function calls.
  • the predetermined subset of possible NFS function calls may be any NFS commands except for NFS write commands or NFS commands having write permission.
  • the second receive server is configured to operate as an NFS server proxy and the second send server is configured to operate as an NFS client proxy.
  • the second send server is further configured to filter the second information prior to forwarding the information to the second receive server via the second one-way data link.
  • the present invention is a system for bilaterally transferring information between a client coupled to a first network and a server coupled to a second network.
  • the system includes a first platform having a first send server, a first one-way data link and a first receive server and a second platform having a second send server, a second one-way data link and a second receive server.
  • the first send server has a data communications interface.
  • the first one-way data link has an input and an output.
  • the first receive server has a network connection and a data communications interface.
  • the first send server is coupled to the input of the first one-way data link and the first receive server is coupled to the output of the first one-way data link.
  • the first send server is configured to forward information received at the data communications interface to the input of the first one-way data link.
  • the network connection of the first receive server is coupled to the second network.
  • the second send server has a data communications interface coupled only to the data communications interface of the first receive server.
  • the second one-way data link has an input and an output.
  • the second receive server has a network connection and a data communications interface.
  • the second send server is coupled to the input of the second one-way data link and the second receive server is coupled to the output of the second one-way data link.
  • the network connection of the second receive server is coupled to the first network and the data communications interface of the second receive server is coupled only to the data communications interface of the first send server.
  • the second receive server is configured to receive first information from the client via the first network and network connection, to process the received first information and to forward the processed first information to the first send server via the data communications interface. Alternatively, the second receive server may forward the first information without processing.
  • the first receive server is configured to receive the processed first information via the first one-way data link and to forward the processed first information to the server via the network connection and second network.
  • the first receive server is also configured to receive second information from the server via the second network and the network connection and to forward the second information to the second send server via the data communications interface. Alternatively, the first receive server may process the second information before forwarding.
  • the second receive server is also configured to receive the second information from the second one-way data link and to forward the second information to the client via the network connection and first network.
  • the second receive server and the first receive server are each also configured to maintain the first information completely separate from the second information.
  • a first client/server replaces the client coupled to the first network and a second client/server replaces the server coupled to the second network.
  • FIG. 1 schematically illustrates an example of a secure one-way data transfer system based on a one-way data link
  • FIG. 2 is a functional block diagram of an example of a system for bilateral communication using two one-way data links
  • FIG. 3 is a functional block diagram of a first embodiment of the present invention.
  • FIG. 4 is a flow diagram demonstrating how CDS system 300 operates.
  • FIG. 5 is a functional block diagram of a second embodiment of the present invention.
  • Cross Domain Solution (CDS) system 300 provides a seamless NFS proxy service across a pair of transfer platforms 301 , 302 .
  • a client 310 in a first security domain i.e., the area 371 on the left side of dotted line 370 —the “left-side security domain”
  • a NFS server 380 in a second security domain i.e., the area 372 to the right of dotted line 370 —the “right-side security domain”
  • Platform 301 includes a send server 350 (Send Server A), a one-way data link 345 and a receive server 340 (Receive Server A).
  • platform 302 includes a send server 320 (Send Server B), a one-way data link 325 and a receive server 330 (Receive Server B).
  • Each one-way data link 325 , 345 may be, for example, a set of Owl one-way DualDiode Communication Cards coupled via an optical fiber.
  • CDS system 300 enables integrated dual data paths in a single CDS instance. Users of client 310 are able to perform normal NFS mount operations and access files from that mount point.
  • Client 310 is coupled to a first network 303 in the first security domain 371 .
  • Receive server 340 is also coupled to the first network 303 (via network interface controller 343 ).
  • Receive server 340 is coupled to send server 320 via a first dedicated data path (link) 305 (also in the first security domain 371 ) and associated network interface controllers 341 , 321 (data communications interfaces).
  • Send server 350 is coupled to receive server 330 via a second data path (link) 306 (in the second security domain 372 ) and associated network interface controllers 352 , 331 (data communications interfaces).
  • the two data paths 305 , 306 may each be, preferably, a single Ethernet cable (i.e., a dedicated network connection).
  • Send server 350 is coupled to a second network 304 in the second security domain 372 via a network interface controller 351 .
  • NFS server 380 is also coupled to the second network 304 .
  • Each send server 320 , 350 includes an associated send application 322 , 354 which receives packets and forwards them to the respective associated one-way data link 325 , 345 .
  • the send applications 322 , 354 can each act as a multiplexer, combining information from separate sources for transmission across the one-way data link.
  • Each receive server 330 , 340 includes an associated receive application 332 , 344 which receives packets from the respective associated one-way data link 325 , 345 .
  • Receive application 332 forwards packets to network interface controller 331 , while receive application 344 forwards packets to NFS server proxy 342 , discussed in detail below.
  • the receive applications 332 , 344 can each act as a demultiplexer, separating the combined information for transmission to different preconfigured destinations.
  • NFS server proxy 342 enables the transfer of requests between client 310 and NFS server 380 .
  • client 310 and single NFS server 380 are shown in FIG. 3 , as one of ordinary skill in the art will readily recognize, more than one client-server pair can be configured.
  • client 310 accesses the NFS server proxy 342 based on a preconfigured IP address for network interface controller 343 .
  • the NFS client proxy 353 access to the NFS server is based on a mapping of the IP address of the NFS server 380 in the NFS client proxy 353 .
  • NFS server 380 Although only a single NFS server 380 is shown, in the presently preferred embodiment, up to eight IP addresses can be configured for mapping to eight separate NFS servers. Additionally, there may be multiple server proxies for each IP address so that multiple clients may be served at the same time. In the presently preferred embodiment, up to eight servers may be configured for each IP address.
  • Transfer platform 301 maintains the NFS source and destination proxies.
  • the NFS server proxy 342 runs on receive server 340 .
  • the NFS client proxy 353 runs on the send server 350 .
  • Receive server 340 and send server 350 comprise the secure NFS response path.
  • Transfer platform 302 provides the secure request path.
  • Send server 320 receives NFS query/requests (via link 305 ) from NFS server proxy 342 as packets.
  • Send application 322 forwards the received query/request to one-way link 325 .
  • Receive application 332 in receive server 330 receives the query/request and forwards it to NFS client proxy 353 on send server 350 (via link 306 ).
  • the NFS client proxy 353 transfers the query/request to NFS server 380 , as discussed below.
  • platform 302 provides the path over which RPC function calls are made from client 310 to NFS server 380
  • platform 301 provides the path over which the RPC functions return values are transferred from NFS server 380 to client 310 .
  • the communication path carrying them consisting of network interface controller 341 , link 305 , network interface controller 321 , one-way link 325 , network interface controller 331 , link 306 , and network interface controller 352 , may be implemented by lower bandwidth components as compared to the path carrying the return values consisting of network interface controller 351 , one-way link 345 , and network interface controller 343 .
  • NFS server proxy 342 is configured to act like an NFS server in the first security domain 371
  • NFS client proxy 353 is configured to act like an NFS client in the second security domain 372
  • NFS server proxy 342 and NFS client proxy 353 are processes that are distinct from the associated send and receive applications 354 , 344 , and can be considered as a pair of processes that are connected over a pair (at each end) of sockets.
  • each NFS server proxy process 342 acts as a single NFS server and accepts requests from client 310
  • each NFS client proxy process 353 acts as an NFS client and makes requests to a single NFS server 380 .
  • NFS server proxy process 342 (each process operates identically) operates in conjunction with a portmapper process 444 (shown in FIG. 4 ).
  • NFS server proxy 342 registers itself with portmapper 444 (step 401 ) and then waits for a Remote Procedure Call (RPC) from client 310 .
  • RPC Remote Procedure Call
  • client 310 first issues an RPC to the portmapper process 444 requesting the port for the NFS server (step 404 ), the portmapper 444 responds with the port number (step 405 ).
  • Client 310 then issues an RPC call for the desired NFS function (step 406 ).
  • NFS server proxy 342 (step 407 ) examines the received NFS function to determine if it is a permitted function. For example, in the preferred embodiment, client 310 is provided with only read access, and any NFS write function is not allowed (in particular, any NFS command having write access or write permission). If the requested NFS function is not allowed (e.g., a write is requested), the function is blocked (step 407 ) and an authorization error is returned to client 310 (step 408 ). All NFS functions are predefined as either allowed or not allowed, but in the event that an NFS function is received which is not predefined, it is also blocked. If the function is permitted (step 409 ), the arguments are filtered (not shown in FIG.
  • NFS client proxy 353 deserializes the arguments based on XDR standard (step 412 ) and then simulates an RPC call (using the received arguments) to NFS server 380 (step 413 ). NFS client proxy 353 then waits for a corresponding response from NFS server 380 (step 414 ). The received response may be filtered, if desired, and then serialized using the XDR standard (step 415 ) and forwarded to NFS server proxy 342 (step 416 ).
  • XDR eXternal Data Representation
  • NFS server proxy 342 deserializes the arguments based on XDR standard (step 417 ), and then forwards an appropriate response back to client 310 based on the received response (step 418 ).
  • NFS server proxy 342 and NFS client proxy 353 are each configured to strictly maintain data passing in one direction (e.g., from client 310 to server 380 ) completely separate from data passing in the opposite direction (e.g., from server 380 to client 310 ).
  • every NFS request contains a set of user credentials with a user identification number (UID) and group identification number (GID) to which the user belongs.
  • NFS credentials are the same as those used for accessing local files, i.e., if a user belong to five groups, the user's NFS credentials contain the UID and five GIDs.
  • these credentials may be used to perform the permission checks that are part of a UNIX file access, e.g., to verify write permission to remove or alter a file or to execute permission to search directories.
  • CDS system 300 FIG.
  • the user is at client 310 located in a first security domain and the NFS server 380 is located in a second security domain, different from the first security domain.
  • the NFS server 380 is located in a second security domain, different from the first security domain.
  • the first security domain is a top secret domain and the second security domain is lower level domain, e.g., secret
  • the credential information may be deleted (if allowed under the particular NFS protocol), generalized (so that a single set of non-specific credentials are used for accessing NFS server 380 ) or spoofed (so that NFS server 380 believes that a local user within the same security domain is accessing the files). This is an important advantage over prior art CDS systems, which do not address the matter of verifying credentials to confirm the request is made with appropriate permissions, but then manipulating the credentials to hide the identity of the requester.
  • NFS server proxy 342 may be configured to filter other information, in addition to credential information, included within an allowed NFS function call, if necessary. For example, information about the physical or logical origin of the request may also be filtered.
  • NFS client proxy 353 may be configured to filter some or all of the information provided in response to the most recent NFS function call. For example, information about the origin of information (e.g., satellite ID) or labels, time stamps and map coordinates contained therein may be filtered by NFS client proxy 353 .
  • information about the origin of information e.g., satellite ID
  • time stamps and map coordinates contained therein may be filtered by NFS client proxy 353 .
  • the use of two separate platforms 301 , 302 for receiving and transmitting information between the left-side security domain 371 and the right-side security domain 372 provides isolation between such information.
  • the NFS server proxy 342 in receive server 340 , it is ensured that only filtered information is provided to send server 320 (i.e., via link 305 ) and that information that should not be provided from the left-side security domain 371 to the right side security domain 372 (e.g., credential information for a user at client 310 ) is never present within send server 320 . Since such information is never present in send server 320 , such information will never be passed across the boundary into the right-side security domain.
  • FIG. 5 an alternative embodiment is shown of a Cross Domain Solution system which isolates information passing from the left-side security domain to the right-side security domain and information passing from the right-side security domain to the left-side security domain.
  • a Cross Domain Solution system which isolates information passing from the left-side security domain to the right-side security domain and information passing from the right-side security domain to the left-side security domain.
  • information passing from the left to right security domains is filtered before being provided to send server 320
  • information passing from the right to left security domains is filtered after being provided to send server 350 .
  • the proxy in the right-hand security domain (the area to the right of dotted line 570 ), i.e., right proxy 533 , is moved to receive server 530 in the upper platform 502 in FIG. 5 (NFS client proxy 353 is in the lower platform 301 in FIG. 3 ).
  • CDS system 500 allows communication between a left client/server 510 coupled to a first network 503 in the left-side security domain and a right client/server 580 coupled to a second network 504 in the right-side security domain where communications may be initiated by the left client/server 510 (acting as a client) and responses come from the right client/server 580 (acting as a server); or communications may be initiated by the right client/server 580 (acting as a client) and responses come from the left client/server 510 (acting as a server).
  • CDS system 500 includes two sets of transmission platforms 501 , 502 .
  • Transfer platform 501 provides for transmission of information only from the right-side security domain to the left-side security domain and includes receive server 540 (Receive Server A), send server 550 (Send Server A) and one-way data link 545 .
  • Receive server 540 is coupled to first network 503 via network interface controller 543 .
  • receive server 540 is coupled to send server 520 via network interface controller 541 (data communications interface), a first data path (link) 505 , and network interface controller 521 (data communications interface).
  • receive server 540 is coupled to send server 550 via one-way link 545 .
  • Send server 550 is coupled to receive server 530 via network interface card 551 (data communications interface), a second data path (link) 506 and network interface card 531 (data communications interface).
  • the two data paths 505 , 506 may each be, preferably, a single Ethernet cable (i.e., a dedicated network connection). However, as one of ordinary skill in the art will readily recognize, other types of data paths may be used, e.g., a single point to point connection.
  • point to point connections When point to point connections are used, the associated network interface controllers 521 , 541 , 534 , 551 are replaced by the appropriate controller for the type of point to point connection to be used.
  • respective USB controllers replace each of the network interface controllers.
  • a send application 554 running on send server 550 receives information via the network interface card 551 and sends it via one-way data link 545 to receive application 544 running on receive server 540 .
  • Receive application 544 forwards received information to left proxy 542 for further processing as discussed below.
  • Transfer platform 502 provides for transmission of information only from the left-side security domain to the right-side security domain and includes receive server 530 (Receive Server B), send server 520 (Send Server B) and one-way data link 525 .
  • Receive server 530 is coupled to second network 504 via network interface controller 534 .
  • receive server 530 is coupled to send server 550 via network interface controller 531 , second dedicated network connection 506 , and network interface controller 551 .
  • receive server 530 is coupled to send server 520 via one-way link 525 .
  • Send server 520 is coupled to receive server 540 via network interface card 521 , first dedicated network connection 505 and network interface card 541 .
  • a send application 522 running on send server 520 receives information via the network interface card 521 and sends it via one-way data link 525 to receive application 532 running on receive server 530 .
  • Receive application 532 forwards received information to right proxy 533 for further processing as discussed below.
  • Right proxy 533 and left proxy 542 operate in similar ways.
  • Left proxy 542 receives information from left client/server 510 via network 503 , processes the information if necessary, and forwards the information (which may be processed) to send server 520 .
  • some received information may be blocked during processing, such as an NFS write command.
  • the processing may involve filtering, either on message content or on associated information (e.g., credentials) sent with the message content.
  • Send application 522 in send server 520 receives the information and forwards it across one-way link 525 to receive application 532 in receive server 530 .
  • Receive application 532 transfers the received information to right proxy 533 , which in turn forwards the information to right client/server 580 via network 504 .
  • the transmission of the information from send application 522 to right client/server 580 operates in a manner identical to that of the system shown in FIG. 2 (as described above and in greater detail in the '209 patent).
  • right proxy 533 mirrors that of left proxy 542 .
  • Right proxy 533 receives information from right client/server 580 via network 504 , processes the information if necessary, and forwards the information (which may be processed) to send server 550 .
  • some received information may be blocked during processing, such as an NFS write command.
  • the processing may involve filtering, either on message content or on associated information (e.g., credentials) sent with the message content.
  • Send application 554 in send server 550 receives the information and forwards it across one-way link 545 to receive application 544 in receive server 540 .
  • Receive application 544 transfers the received information to left proxy 542 , which in turn forwards the information to left client/server 510 via network 503 .
  • the transmission of the information from send application 554 to left client/server 510 operates in a manner identical to that of the system shown in FIG. 2 (as described above and in greater detail in the '209 patent).
  • left proxy 542 may be an NFS server proxy and right proxy 533 may be an NFS client proxy, with the NFS client at left client/server 510 and the NFS server at right client/server 580 .
  • right proxy 533 may be an NFS server proxy and left proxy 542 may be an NFS client proxy, with the NFS client at right client/server 580 and the NFS server at left client/server 510 .
  • System 500 provides an additional security level over the system shown in FIG. 3 because each send server 520 , 550 only receives information to be transferred that has been already been processed (e.g., filtered or checked to be an authorized NFS command). This provides additional assurance that the desired processing is not bypassed, while maintaining separate one-way transmission paths.
  • An additional advantage of system 500 is the physical placement of left proxy 542 and right proxy 533 in separate transfer platforms 501 and 502 , respectively. This separation mitigates security risks since now an attacker would have to gain access to both transfer platforms to access information about the end-to-end routing of messages between the right-side security domain and the left-side security domain across dotted line 570 in FIG. 5 .

Abstract

A system for bilaterally transferring information between a client and a remote server. The client is coupled with a server proxy running on a second receive server via a first network and communicates thereon. Processed first information is passed to a first send server via a dedicated network connection. The first send server causes the first information to be transmitted to the remote server, via a first one-way data link, a first receive server, a second dedicated network connection and a client proxy running on a second send server. The remote server is coupled to the client proxy via a second network. The client proxy forwards information received from the server to the client via a second one-way link, the server proxy running on the second receive server, and the first network.

Description

    FIELD OF INVENTION
  • The present invention relates generally to a Network File System (NFS) storage device accessible via unidirectional data transfer.
  • BACKGROUND OF THE INVENTION
  • Protection of a computer or data network from undesired and unauthorized data disclosure, interception or alteration has been a perennial concern in the field of computer and network security. For example, firewall and anti-malware software have been developed to address security concerns for computers and networks connected to the Internet and to protect them from possible cyberattacks such as Trojan horse-type viruses or worms that may trigger undesired and unauthorized data disclosure by these computers and networks. However, for high security computer networks such as those used by government agencies and intelligence communities and certain commercial applications, conventional network security devices such as firewalls may not provide sufficiently reliable protection from undesired data disclosure.
  • Alternative network security methods and devices based on unidirectional data transfer have been devised to address the network security concern. For example, U.S. Pat. No. 5,703,562 to Nilsen (“the '562 patent”), the content of which is hereby incorporated by reference in its entirety, provides an alternative way to address the network security concern. The '562 patent discloses a method of transferring data from an unsecured computer to a secured computer over a one-way optical data link comprising an optical transmitter on the sending side and an optical receiver on the receiving side. By providing such an inherently unidirectional data link to a computer/data network to be protected, one can eliminate any possibility of unintended data leakage out of the computer/data network over the same link.
  • One-way data transfer systems based on such one-way data links provide network security to data networks by isolating the networks from potential security breaches (i.e., undesired and unauthorized data flow out of the secure network) while still allowing them to import data from the external source in a controlled fashion. FIG. 1 schematically illustrates an example of one such one-way data transfer system 100. In the one-way data transfer system shown in FIG. 1, two computing platforms (or nodes) 101 and 102 (respectively, “the Send Node” and “the Receive Node”) are connected to the unsecured external network 104 (“the source network”) and the secure network 105 (“the destination network”), respectively. The Send Node 101 is connected to the Receive Node 102 by a one-way data link 103, which may be an optical link comprising, for example, a high-bandwidth optical fiber. This one-way optical data link 103 may be configured to operate as a unidirectional data gateway from the source network 104 to the secure destination network 105 by having its ends connected to an optical transmitter on the Send Node and to an optical receiver on the Receive Node.
  • This configuration physically enforces one-way data transfer at both ends of the optical fiber connecting the Send Node 101 to the Receive Node 102, thereby creating a truly unidirectional one-way data link between the source network 104 and the destination network 105 shown in FIG. 1. Unlike the conventional firewalls, one-way data transfer systems based on a one-way data link are designed to transfer data or information only in one direction and it is physically impossible to transfer data or information of any kind in the reverse direction using that link. No information or data of any kind, including handshaking protocols such as those used in data transport protocols such as TCP/IP, SCSI, USB, Serial/Parallel Ports, etc., can travel in the reverse direction from the Receive Node back to the Send Node across the one-way data link. Such physically imposed unidirectionality in data flow cannot be hacked by a programmer, as is often done with firewalls. Accordingly, the one-way data transfer system based on a one-way data link ensures that data residing on the isolated secure computer or network is maximally protected from any undesired and unauthorized disclosure.
  • When two different network security domains need to communicate bilaterally, it is often desirable and necessary to apply different security policies or protocols to data flows in different directions. Preferably, data transfers from a low security domain to a high security domain are subject to fewer security restrictions, while a high security domain has a need to protect its data from the low security domain by carefully configured security protocols. For example, U.S. Pat. No. 7,992,209 to Menoher, et al., (“the '209 patent”), the content of which is hereby incorporated by reference in its entirety, discloses a system for bilateral communication using two one-way data links. Referring to FIG. 2, the system 201 in the '209 patent comprises two computing platforms or nodes, Node A 202 and Node B 203, interconnected by two separate, oppositely directed one-way communication channels, Link R 204 and Link L 205. These one-way communication channels are deployed in parallel to enable bilateral communications between Node A and Node B, wherein Link R 204 is for unidirectional data transfer from Node A to Node B, while Link L 205 is for unidirectional data transfer in the opposite direction, from Node B to Node A. This arrangement forces all data traffic between Nodes A and B to flow unidirectionally through two entirely separate conduits, with each of the unidirectional data transfers across these conduits separately administered. The two links are separately administered by employing separate data transfer applications, interfaces and configuration files solely for the unidirectional data transfer in each direction, each set configured to prevent any cross-talk with the one-way communication channel for the opposite direction. In particular, in FIG. 2, Link R 204 is associated with data sending application 210 and interface 206 in Node A 202 and data receiving application 212 and interface 208 in Node B 203, while Link L 205 is associated with data sending application 213 and interface 209 in Node B 203 and data receiving application 211 and interface 207 in Node A 202. The one-way data links used in Link R 204 and Link L 205 in FIG. 2 may be of any type of data transfer conduit that is capable of enforcing unidirectional data flow. Examples of one-way data links and the corresponding network interface circuitry for enforcing unidirectional data flow through the links are disclosed in U.S. Pat. No. 8,068,415 to Mraz (“the '415 patent”), the content of which is incorporated herein by reference in its entirety.
  • In FIG. 2, the data sending application 210 in Node A (or 213 in Node B) and data receiving application 212 in Node B (or 211 in Node A) in combination with proxy and session managing applications 220, 218 and 221, 219 respectively in Node A and Node B use Transmission Control Protocol/Internet Protocol (TCP/IP) as a user interface to the one-way data link in Link R 204 (or Link L 205). Examples of TCP-based one-way data transfer system are disclosed in U.S. Pat. No. 8,139,581 to Mraz et al. (“the '581 patent”), the content of which is incorporated herein by reference in its entirety. The TCP proxy applications 220 and 221 are preferably TCP/IP socket-based proxy software, but may also be hardware-based or based on a suitable combination of software and hardware. The TCP proxy application 220 residing in Node A 202 fully implements TCP/IP-based bilateral communications between Node A and an external platform communicatively coupled to Node A, such as a remote terminal client 222 shown in FIG. 2. Likewise, the TCP proxy application 221 residing in Node B 203 fully implements TCP/IP-based bilateral communications between Node B and an external platform communicatively coupled to Node B, such as a remote terminal server 223 shown in FIG. 2.
  • The TCP session managing applications 218 and 219 are software-based applications for maintaining one or more TCP sessions. The session managing application 218, 219 in each node 202, 203 “splits” the bilateral communication channel between the node and corresponding remote terminal 222, 223 into two unidirectional communication channels based by strictly enforcing a separation of data coming from the remote terminal client 222, 223 and data coming via the data receiving application 211, 212.
  • The system shown in FIG. 2 simulates the TCP/IP protocol between the remote terminal client 222 and the remote terminal server 223 across the one-way data link in Link R 204 by replacing the IP information in the received data with pre-assigned channel numbers, so that no IP information is sent across the one-way data link. IP routes are pre-defined in the form of complementary channel mapping tables associated respectively with the data sending application 210 in Node A and data receiving application 212 in Node B. The data receiving application 212 then replaces the channel numbers in the received data with IP information from the channel mapping table and forwards the modified data to the TCP session managing application 219. The session managing application 219 maintains one or more TCP sessions and routes the received data packets or files from the data receiving application 212 to the proxy application 221. The TCP proxy application 221 in Node B fully implements the TCP/IP protocol in its bilateral communications with the remote terminal server 223, requests a socket connection and delivers the data received from the remote terminal client 222 to the remote terminal server 223. The same process is used to transfer data from remote terminal server 223 to remote terminal client 222, as discussed in further detail in the '209 patent, but using data sending and receiving applications, interfaces and configuration files that are entirely separate from those associated with the one-way data transfer from remote terminal client 222 to remote terminal server 223.
  • The system shown in FIG. 2 and described above can support the inherently different security checks and restrictions required for transferring data from a lower security domain to a higher security domain and for transferring data from it (e.g., the situation where the client requesting data is in a lower security domain). In addition, that system can also support the inherently different security checks and restrictions required for transferring data from a higher security domain to a lower security domain and for transferring data from it (e.g., the situation where the client requesting data is in a higher security domain). However, the types of transfers allowed require some a priori knowledge of the information being requested. In addition, the data being transferred from the client to the server is completely independent from the data being transferred from the server to the client and the data is transmitted in a raw byte stream without any indication of message boundaries. This makes it difficult to filter data, for example, based on message type.
  • The Network File System (NFS) is a standard network client/server protocol used to allow computers to mount a remote disk partition and transparently access it as if it were a local disk. In operation, an NFS client on a user computer communicates with a remote server where the remote disk is located using Remote Procedure Call (RPC) protocol in order to implement an access to files located on the remote disk. An RPC is an inter-process communication that allows a client to cause a subroutine or procedure to execute in another address space (e.g., on a known remote server) without the programmer explicitly coding the details for this remote interaction. An RPC is initiated by the client, which sends a request message to the known remote server to execute a specified procedure with supplied parameters. The remote server sends a response to the client, and the application continues its process. NFS operates based on matched RPC requests/replies, thus an implementation of NFS across the bilateral communication system of FIG. 2 would provide less than optimal results, for example due to a difficulty in filtering the raw message stream.
  • Hence, it is an object of the present invention to overcome the problems with the prior art and to provide an NFS implementation over a bilateral data transfer system comprising two or more one-way data links.
  • SUMMARY OF THE INVENTION
  • It has now been found that the above and related objects of the present invention are obtained in the form of several related aspects, including a secure system for bilaterally transferring information between a client coupled to a first network and a server coupled to a second network. The system includes a first platform including first send server, a first one-way data link and a first receive server, and a second platform including a second send server, a second one-way data link and a second receive server.
  • The first send server has a data communications interface. The first one-way data link has an input and an output. The first receive server has a data communications interface. The first send server is coupled to the input of the first one-way data link. The first receive server is coupled to the output of the first one-way data link. The first send server is configured to forward information received at the data communications interface to the input of the first one-way data link. The first receive server is configured to forward information received from the output of the first one-way data link to the data communications interface
  • The second send server has a network connection and a data communications interface. The second one-way data link has an input and an output. The second receive server has a network connection and a data communications interface. The second send server is coupled to the input of the second one-way data link. The second receive server is coupled to the output of the second one-way data link. The network connection of the second receive server is coupled to the first network and the data communications interface is coupled only to the data communications interface of the first send server. The second send server is coupled to the second network via the network connection and the data communications interface is coupled only to the data communications interface of the first receive server.
  • The second receive server is configured to receive first information from the client via the first network and the network connection, to process the received first information and to forward the processed first information to the first send server via the data communications interface. Alternatively, the second receive server may forward the first information without processing. The second send server is configured to receive the processed first information via the data communications interface and to forward the processed first information to the server via the network connection and second network. The second send server is also configured to receive second information from the server via the second network and the network connection and to forward the second information to the second receive server via the second one-way data link. Alternatively, the second send server may process the second information before forwarding. The second receive server is also configured to receive the second information from the second one-way data link and to forward the second information to the client via the network connection and first network. The second receive server and the second send server are each also configured to maintain the first information completely separate from the second information.
  • In a further embodiment, the processing performed on the first information by the second receive server comprises filtering the information to remove a predetermined category of information. Further, the predetermined category of information may be identification information. Still further, the identification information may be user credentials.
  • In an embodiment, the first information is an NFS function call of a set of possible NFS function calls and the processing performed by the second receive server identifies a type of the NFS function call and blocks further transmission of the NFS function call if the identified type does not correspond to any one of a predetermined subset of possible NFS function calls. The predetermined subset of possible NFS function calls may be any NFS commands except for NFS write commands or NFS commands having write permission.
  • In a preferred embodiment, the second receive server is configured to operate as an NFS server proxy and the second send server is configured to operate as an NFS client proxy.
  • In a further embodiment, the second send server is further configured to filter the second information prior to forwarding the information to the second receive server via the second one-way data link.
  • In an alternative embodiment, the present invention is a system for bilaterally transferring information between a client coupled to a first network and a server coupled to a second network. The system includes a first platform having a first send server, a first one-way data link and a first receive server and a second platform having a second send server, a second one-way data link and a second receive server.
  • The first send server has a data communications interface. The first one-way data link has an input and an output. The first receive server has a network connection and a data communications interface. The first send server is coupled to the input of the first one-way data link and the first receive server is coupled to the output of the first one-way data link. The first send server is configured to forward information received at the data communications interface to the input of the first one-way data link. The network connection of the first receive server is coupled to the second network.
  • The second send server has a data communications interface coupled only to the data communications interface of the first receive server. The second one-way data link has an input and an output. The second receive server has a network connection and a data communications interface. The second send server is coupled to the input of the second one-way data link and the second receive server is coupled to the output of the second one-way data link. The network connection of the second receive server is coupled to the first network and the data communications interface of the second receive server is coupled only to the data communications interface of the first send server.
  • The second receive server is configured to receive first information from the client via the first network and network connection, to process the received first information and to forward the processed first information to the first send server via the data communications interface. Alternatively, the second receive server may forward the first information without processing. The first receive server is configured to receive the processed first information via the first one-way data link and to forward the processed first information to the server via the network connection and second network. The first receive server is also configured to receive second information from the server via the second network and the network connection and to forward the second information to the second send server via the data communications interface. Alternatively, the first receive server may process the second information before forwarding. The second receive server is also configured to receive the second information from the second one-way data link and to forward the second information to the client via the network connection and first network. The second receive server and the first receive server are each also configured to maintain the first information completely separate from the second information. In a further alternative embodiment, a first client/server replaces the client coupled to the first network and a second client/server replaces the server coupled to the second network.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The above and related objects, features and advantages of the present invention will be more fully understood by reference to the following, detailed description of the preferred, albeit illustrative, embodiment of the present invention when taken in conjunction with the accompanying figures, wherein:
  • FIG. 1 schematically illustrates an example of a secure one-way data transfer system based on a one-way data link;
  • FIG. 2 is a functional block diagram of an example of a system for bilateral communication using two one-way data links;
  • FIG. 3 is a functional block diagram of a first embodiment of the present invention;
  • FIG. 4 is a flow diagram demonstrating how CDS system 300 operates; and
  • FIG. 5 is a functional block diagram of a second embodiment of the present invention.
  • DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
  • Referring now to the drawings and in particular to FIG. 3, Cross Domain Solution (CDS) system 300 provides a seamless NFS proxy service across a pair of transfer platforms 301, 302. In particular, a client 310 in a first security domain (i.e., the area 371 on the left side of dotted line 370—the “left-side security domain”) is able to access a NFS server 380 in a second security domain (i.e., the area 372 to the right of dotted line 370—the “right-side security domain”) using CDS system 300. Platform 301 includes a send server 350 (Send Server A), a one-way data link 345 and a receive server 340 (Receive Server A). Likewise, platform 302 includes a send server 320 (Send Server B), a one-way data link 325 and a receive server 330 (Receive Server B). Each one-way data link 325, 345 may be, for example, a set of Owl one-way DualDiode Communication Cards coupled via an optical fiber. CDS system 300 enables integrated dual data paths in a single CDS instance. Users of client 310 are able to perform normal NFS mount operations and access files from that mount point.
  • Client 310 is coupled to a first network 303 in the first security domain 371. Receive server 340 is also coupled to the first network 303 (via network interface controller 343). Receive server 340 is coupled to send server 320 via a first dedicated data path (link) 305 (also in the first security domain 371) and associated network interface controllers 341, 321 (data communications interfaces). Send server 350 is coupled to receive server 330 via a second data path (link) 306 (in the second security domain 372) and associated network interface controllers 352, 331 (data communications interfaces). The two data paths 305, 306 may each be, preferably, a single Ethernet cable (i.e., a dedicated network connection). However, as one of ordinary skill in the art will readily recognize, other types of data paths may be used, e.g., a single point to point connection. When point to point connections are used, the associated network interface controllers 321, 341, 331, 352 are replaced by the appropriate controller for the type of point to point connection to be used. For example, when data paths 305 and 306 constitute a USB line, respective USB controllers replace each of the network interface controllers. Send server 350 is coupled to a second network 304 in the second security domain 372 via a network interface controller 351. NFS server 380 is also coupled to the second network 304.
  • Each send server 320, 350 includes an associated send application 322, 354 which receives packets and forwards them to the respective associated one-way data link 325, 345. The send applications 322, 354 can each act as a multiplexer, combining information from separate sources for transmission across the one-way data link. Each receive server 330, 340 includes an associated receive application 332, 344 which receives packets from the respective associated one-way data link 325, 345. Receive application 332 forwards packets to network interface controller 331, while receive application 344 forwards packets to NFS server proxy 342, discussed in detail below. The receive applications 332, 344 can each act as a demultiplexer, separating the combined information for transmission to different preconfigured destinations.
  • NFS server proxy 342 enables the transfer of requests between client 310 and NFS server 380. Although only a single client 310 and single NFS server 380 are shown in FIG. 3, as one of ordinary skill in the art will readily recognize, more than one client-server pair can be configured. For example, in a presently preferred embodiment, up to eight NFS client-server pairs may be configured. Client 310 accesses the NFS server proxy 342 based on a preconfigured IP address for network interface controller 343. Similarly, the NFS client proxy 353 access to the NFS server is based on a mapping of the IP address of the NFS server 380 in the NFS client proxy 353. Although only a single NFS server 380 is shown, in the presently preferred embodiment, up to eight IP addresses can be configured for mapping to eight separate NFS servers. Additionally, there may be multiple server proxies for each IP address so that multiple clients may be served at the same time. In the presently preferred embodiment, up to eight servers may be configured for each IP address.
  • Transfer platform 301 maintains the NFS source and destination proxies. The NFS server proxy 342 runs on receive server 340. The NFS client proxy 353 runs on the send server 350. Receive server 340 and send server 350 comprise the secure NFS response path.
  • Transfer platform 302 provides the secure request path. Send server 320 receives NFS query/requests (via link 305) from NFS server proxy 342 as packets. Send application 322 forwards the received query/request to one-way link 325. Receive application 332 in receive server 330 receives the query/request and forwards it to NFS client proxy 353 on send server 350 (via link 306). The NFS client proxy 353, in turn, transfers the query/request to NFS server 380, as discussed below.
  • In operation, platform 302 provides the path over which RPC function calls are made from client 310 to NFS server 380, while platform 301 provides the path over which the RPC functions return values are transferred from NFS server 380 to client 310. Because RPC function calls are usually shorter than responses, the communication path carrying them consisting of network interface controller 341, link 305, network interface controller 321, one-way link 325, network interface controller 331, link 306, and network interface controller 352, may be implemented by lower bandwidth components as compared to the path carrying the return values consisting of network interface controller 351, one-way link 345, and network interface controller 343.
  • Two processes are the key part of CDS system 300: (1) the NFS server proxy process 342 and (2) the NFS client proxy process 353. NFS server proxy 342 is configured to act like an NFS server in the first security domain 371, while NFS client proxy 353 is configured to act like an NFS client in the second security domain 372. NFS server proxy 342 and NFS client proxy 353 are processes that are distinct from the associated send and receive applications 354, 344, and can be considered as a pair of processes that are connected over a pair (at each end) of sockets. In overview, each NFS server proxy process 342 (there may be up to eight separate processes 342 running at once in the presently preferred embodiment per IP address) acts as a single NFS server and accepts requests from client 310, while each NFS client proxy process 353 (one for each of the running NFS server proxy processes) acts as an NFS client and makes requests to a single NFS server 380.
  • Referring now to FIG. 4, in operation, NFS server proxy process 342 (each process operates identically) operates in conjunction with a portmapper process 444 (shown in FIG. 4). At startup, NFS server proxy 342 registers itself with portmapper 444 (step 401) and then waits for a Remote Procedure Call (RPC) from client 310. To initiate an RPC function call, client 310 first issues an RPC to the portmapper process 444 requesting the port for the NFS server (step 404), the portmapper 444 responds with the port number (step 405). Client 310 then issues an RPC call for the desired NFS function (step 406). NFS server proxy 342 (step 407) examines the received NFS function to determine if it is a permitted function. For example, in the preferred embodiment, client 310 is provided with only read access, and any NFS write function is not allowed (in particular, any NFS command having write access or write permission). If the requested NFS function is not allowed (e.g., a write is requested), the function is blocked (step 407) and an authorization error is returned to client 310 (step 408). All NFS functions are predefined as either allowed or not allowed, but in the event that an NFS function is received which is not predefined, it is also blocked. If the function is permitted (step 409), the arguments are filtered (not shown in FIG. 4, discussed below), serialized according to the eXternal Data Representation (XDR) standard (step 410) and then forwarded to the corresponding NFS client proxy process 353 (step 411) via platform 302 (as shown in FIG. 3). NFS client proxy 353 deserializes the arguments based on XDR standard (step 412) and then simulates an RPC call (using the received arguments) to NFS server 380 (step 413). NFS client proxy 353 then waits for a corresponding response from NFS server 380 (step 414). The received response may be filtered, if desired, and then serialized using the XDR standard (step 415) and forwarded to NFS server proxy 342 (step 416). NFS server proxy 342 deserializes the arguments based on XDR standard (step 417), and then forwards an appropriate response back to client 310 based on the received response (step 418). Notably, NFS server proxy 342 and NFS client proxy 353 are each configured to strictly maintain data passing in one direction (e.g., from client 310 to server 380) completely separate from data passing in the opposite direction (e.g., from server 380 to client 310).
  • Under the default RPC security mechanism, every NFS request, including mount requests, contains a set of user credentials with a user identification number (UID) and group identification number (GID) to which the user belongs. NFS credentials are the same as those used for accessing local files, i.e., if a user belong to five groups, the user's NFS credentials contain the UID and five GIDs. On a typical NFS server, these credentials may be used to perform the permission checks that are part of a UNIX file access, e.g., to verify write permission to remove or alter a file or to execute permission to search directories. However, in the present embodiment of CDS system 300 (FIG. 3), the user is at client 310 located in a first security domain and the NFS server 380 is located in a second security domain, different from the first security domain. In this situation, it is often desirable to prevent anyone present in the second security domain from knowing who is accessing the files at NFS server 380. For example, when the first security domain is a top secret domain and the second security domain is lower level domain, e.g., secret, it may be desirable to prevent any identification information from passing from the top secret domain into the secret domain. This is done in CDS system 300 by filtering out, at NFS server proxy 342, all credential information passed as part of an RPC sent from client 310 (and intended for NFS server 380). The credential information may be deleted (if allowed under the particular NFS protocol), generalized (so that a single set of non-specific credentials are used for accessing NFS server 380) or spoofed (so that NFS server 380 believes that a local user within the same security domain is accessing the files). This is an important advantage over prior art CDS systems, which do not address the matter of verifying credentials to confirm the request is made with appropriate permissions, but then manipulating the credentials to hide the identity of the requester.
  • NFS server proxy 342 may be configured to filter other information, in addition to credential information, included within an allowed NFS function call, if necessary. For example, information about the physical or logical origin of the request may also be filtered.
  • NFS client proxy 353 may be configured to filter some or all of the information provided in response to the most recent NFS function call. For example, information about the origin of information (e.g., satellite ID) or labels, time stamps and map coordinates contained therein may be filtered by NFS client proxy 353.
  • Referring back to FIG. 3, the use of two separate platforms 301, 302 for receiving and transmitting information between the left-side security domain 371 and the right-side security domain 372 provides isolation between such information. In particular, by placing the NFS server proxy 342 in receive server 340, it is ensured that only filtered information is provided to send server 320 (i.e., via link 305) and that information that should not be provided from the left-side security domain 371 to the right side security domain 372 (e.g., credential information for a user at client 310) is never present within send server 320. Since such information is never present in send server 320, such information will never be passed across the boundary into the right-side security domain.
  • Referring now to FIG. 5, an alternative embodiment is shown of a Cross Domain Solution system which isolates information passing from the left-side security domain to the right-side security domain and information passing from the right-side security domain to the left-side security domain. In the embodiment shown in FIG. 3, although information passing from the left to right security domains is filtered before being provided to send server 320, information passing from the right to left security domains is filtered after being provided to send server 350. In some circumstances, this could lead to a security breach, e.g., if transfer platform 301 is physically compromised and an attacker has access to the information on send server 350 and receive server 340, in particular information used for routing of messages by NFS server proxy 342 and NFS client proxy 353, as the filtering is performed by the same server performing the transfer across the one-way link 345. To overcome this problem, the proxy in the right-hand security domain (the area to the right of dotted line 570), i.e., right proxy 533, is moved to receive server 530 in the upper platform 502 in FIG. 5 (NFS client proxy 353 is in the lower platform 301 in FIG. 3).
  • In particular, CDS system 500 allows communication between a left client/server 510 coupled to a first network 503 in the left-side security domain and a right client/server 580 coupled to a second network 504 in the right-side security domain where communications may be initiated by the left client/server 510 (acting as a client) and responses come from the right client/server 580 (acting as a server); or communications may be initiated by the right client/server 580 (acting as a client) and responses come from the left client/server 510 (acting as a server). CDS system 500 includes two sets of transmission platforms 501, 502.
  • Transfer platform 501 provides for transmission of information only from the right-side security domain to the left-side security domain and includes receive server 540 (Receive Server A), send server 550 (Send Server A) and one-way data link 545. Receive server 540 is coupled to first network 503 via network interface controller 543. Separately, receive server 540 is coupled to send server 520 via network interface controller 541 (data communications interface), a first data path (link) 505, and network interface controller 521 (data communications interface). Finally, receive server 540 is coupled to send server 550 via one-way link 545. Send server 550 is coupled to receive server 530 via network interface card 551 (data communications interface), a second data path (link) 506 and network interface card 531 (data communications interface). The two data paths 505, 506 may each be, preferably, a single Ethernet cable (i.e., a dedicated network connection). However, as one of ordinary skill in the art will readily recognize, other types of data paths may be used, e.g., a single point to point connection. When point to point connections are used, the associated network interface controllers 521, 541, 534, 551 are replaced by the appropriate controller for the type of point to point connection to be used. For example, when data paths 505 and 506 constitute a USB line, respective USB controllers replace each of the network interface controllers. A send application 554 running on send server 550 receives information via the network interface card 551 and sends it via one-way data link 545 to receive application 544 running on receive server 540. Receive application 544 forwards received information to left proxy 542 for further processing as discussed below.
  • Transfer platform 502 provides for transmission of information only from the left-side security domain to the right-side security domain and includes receive server 530 (Receive Server B), send server 520 (Send Server B) and one-way data link 525. Receive server 530 is coupled to second network 504 via network interface controller 534. Separately, receive server 530 is coupled to send server 550 via network interface controller 531, second dedicated network connection 506, and network interface controller 551. Finally, receive server 530 is coupled to send server 520 via one-way link 525. Send server 520 is coupled to receive server 540 via network interface card 521, first dedicated network connection 505 and network interface card 541. A send application 522 running on send server 520 receives information via the network interface card 521 and sends it via one-way data link 525 to receive application 532 running on receive server 530. Receive application 532 forwards received information to right proxy 533 for further processing as discussed below.
  • Right proxy 533 and left proxy 542 operate in similar ways. Left proxy 542 receives information from left client/server 510 via network 503, processes the information if necessary, and forwards the information (which may be processed) to send server 520. As discussed above with respect to NFS server proxy 342, some received information may be blocked during processing, such as an NFS write command. In addition, the processing may involve filtering, either on message content or on associated information (e.g., credentials) sent with the message content. Send application 522 in send server 520 receives the information and forwards it across one-way link 525 to receive application 532 in receive server 530. Receive application 532 transfers the received information to right proxy 533, which in turn forwards the information to right client/server 580 via network 504. The transmission of the information from send application 522 to right client/server 580 operates in a manner identical to that of the system shown in FIG. 2 (as described above and in greater detail in the '209 patent).
  • The operation of right proxy 533 mirrors that of left proxy 542. Right proxy 533 receives information from right client/server 580 via network 504, processes the information if necessary, and forwards the information (which may be processed) to send server 550. As discussed above, some received information may be blocked during processing, such as an NFS write command. In addition, the processing may involve filtering, either on message content or on associated information (e.g., credentials) sent with the message content. Send application 554 in send server 550 receives the information and forwards it across one-way link 545 to receive application 544 in receive server 540. Receive application 544 transfers the received information to left proxy 542, which in turn forwards the information to left client/server 510 via network 503. The transmission of the information from send application 554 to left client/server 510 operates in a manner identical to that of the system shown in FIG. 2 (as described above and in greater detail in the '209 patent).
  • In an embodiment of system 500, left proxy 542 may be an NFS server proxy and right proxy 533 may be an NFS client proxy, with the NFS client at left client/server 510 and the NFS server at right client/server 580. Because of its symmetrical structure, in a further embodiment of system 500, right proxy 533 may be an NFS server proxy and left proxy 542 may be an NFS client proxy, with the NFS client at right client/server 580 and the NFS server at left client/server 510.
  • System 500 provides an additional security level over the system shown in FIG. 3 because each send server 520, 550 only receives information to be transferred that has been already been processed (e.g., filtered or checked to be an authorized NFS command). This provides additional assurance that the desired processing is not bypassed, while maintaining separate one-way transmission paths. An additional advantage of system 500 is the physical placement of left proxy 542 and right proxy 533 in separate transfer platforms 501 and 502, respectively. This separation mitigates security risks since now an attacker would have to gain access to both transfer platforms to access information about the end-to-end routing of messages between the right-side security domain and the left-side security domain across dotted line 570 in FIG. 5.
  • While this invention has been described in conjunction with exemplary embodiments outlined above and illustrated in the drawings, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, the exemplary embodiments of the invention, as set forth above, are intended to be illustrative, not limiting, and the spirit and scope of the present invention is to be construed broadly and limited only by the appended claims, and not by the foregoing specification.

Claims (36)

What is claimed is:
1. A secure system for bilaterally transferring information between a client coupled to a first network and a server coupled to a second network, comprising:
a first platform comprising a first send server having a data communications interface, a first one-way data link having an input and an output, and a first receive server having a data communications interface, the first send server coupled to the input of the first one-way data link and the first receive server coupled to the output of the first one-way data link, the first send server configured to forward information received at the data communications interface to the input of the first one-way data link, the first receive server configured to forward information received from the output of the first one-way data link to the data communications interface;
a second platform comprising a second send server having a network connection and a data communications interface, a second one-way data link having an input and an output, and a second receive server having a network connection and a data communications interface, the second send server coupled to the input of the second one-way data link and the second receive server coupled to the output of the second one-way data link, the second receive server coupled to the first network via the network connection, the data communications interface of the second receive server coupled only to the data communications interface of the first send server, the second send server coupled to the second network via the network connection and the data communications interface of the second send server coupled only to the data communications interface of the first receive server;
wherein the second receive server is configured to receive first information from the client via the first network and the network connection, to process the received first information and to forward the processed first information to the first send server via the data communications interface;
wherein the second send server is configured to receive the processed first information via the data communications interface and to forward the processed first information to the server via the network connection and second network;
wherein the second send server is also configured to receive second information from the server via the second network and the network connection and to forward the second information to the second receive server via the second one-way data link, and
wherein the second receive server is also configured to receive the second information from the second one-way data link and to forward the second information to the client via the network connection and first network.
2. The system of claim 1, wherein the second receive server and the second send server are each also configured to maintain the first information and the processed first information completely separate from the second information.
3. The system of claim 1, wherein the processing performed by the second receive server comprises filtering the first information to remove a predetermined category of information.
4. The system of claim 3, wherein the predetermined category of information comprises identification information.
5. The system of claim 4, wherein the identification information comprises user credentials.
6. The system of claim 1, wherein the second receive server is configured to operate as an NFS server proxy.
7. The system of claim 1, wherein the second send server is configured to operate as an NFS client proxy.
8. The system of claim 1, wherein the second send server is further configured to filter the second information prior to forwarding the information to the second receive server via the second one-way data link.
9. A secure system for bilaterally transferring information between a client coupled to a first network and a server coupled to a second network, comprising:
a first platform comprising a first send server having a data communications interface, a first one-way data link having an input and an output, and a first receive server having a network connection and a data communications interface, the first send server coupled to the input of the first one-way data link and the first receive server coupled to the output of the first one-way data link, the first send server configured to forward information received at the data communications interface to the input of the first one-way data link, the network connection of the first receive server coupled to the second network;
a second platform comprising a second send server having a data communications interface coupled only to the data communications interface of the first receive server, a second one-way data link having an input and an output, and a second receive server having a data communications interface and a network connection, the second send server coupled to the input of the second one-way data link and the second receive server coupled to the output of the second one-way data link, the second send server configured to forward information received at data communications interface to the input of the second one-way data link, the network connection of the second receive server coupled to the first network and the data communications interface of the second receive server coupled only to the data communications interface of the first send server,
wherein the second receive server is configured to receive first information from the client via the first network and the network connection, to process the received first information and to forward the processed first information to the first send server via the data communications interface of the second receive server;
wherein the first receive server is configured to receive the processed first information via the first one-way data link and to forward the processed first information to the server via the network connection and second network;
wherein the first receive server is also configured to receive second information from the server via the second network and the network connection and to forward the second information to the second send server via the data communications interface; and
wherein the second receive server is also configured to receive the second information from the second one-way data link and to forward the second information to the client via the network connection and first network.
10. The system of claim 9, wherein the second receive server and the first receive server are each also configured to maintain the first information and the processed first information completely separate from the second information.
11. The system of claim 9, wherein the processing performed by the second receive server comprises filtering the first information to remove a predetermined category of information.
12. The system of claim 11, wherein the predetermined category of information comprises identification information.
13. The system of claim 12, wherein the identification information comprises user credentials.
14. The system of claim 9, wherein the second receive server is configured to operate as an NFS server proxy.
15. The system of claim 9, wherein the first receive server is configured to operate as an NFS client proxy.
16. The system of claim 9, wherein the first receive server is further configured to filter the second information prior to forwarding the information to the second send server via the network connection.
17. A secure system for bilaterally transferring information between a client coupled to a first network and a server coupled to a second network, comprising:
a first platform comprising a first send server having a data communications interface, a first one-way data link having an input and an output, and a first receive server having a data communications interface, the first send server coupled to the input of the first one-way data link and the first receive server coupled to the output of the first one-way data link, the first send server configured to forward information received at the data communications interface to the input of the first one-way data link, the first receive server configured to forward information received from the output of the first one-way data link to the data communications interface;
a second platform comprising a second send server having a network connection and a data communications interface, a second one-way data link having an input and an output, and a second receive server having at least two network connections, the second send server coupled to the input of the second one-way data link and the second receive server coupled to the output of the second one-way data link, the second receive server coupled to the first network via the network connection, the data communications interface of the second receive server coupled only to the data communications interface of the first send server, the second send server coupled to the second network via the network connection, the data communications interface of the second send server coupled only to the data communications interface of the first receive server;
wherein the second receive server is configured to receive first information from the client via the first network and the network connection and to forward the first information to the first send server via the data communications interface;
wherein the second send server is configured to receive the first information via the data communications interface and to forward the first information to the server via the network connection and second network;
wherein the second send server is also configured to receive second information from the server via the second network and the network connection, to process the received second information and to forward the processed second information to the second receive server via the second one-way data link, and
wherein the second receive server is also configured to receive the processed second information from the second one-way data link and to forward the processed second information to the client via the network connection and first network.
18. The system of claim 17, wherein the second receive server and the second send server are each also configured to maintain the first information completely separate from the second information and the processed second information.
19. The system of claim 17, wherein the processing performed by the second receive server comprises filtering the second information to remove a predetermined category of information.
20. The system of claim 19, wherein the predetermined category of information comprises identification information.
21. The system of claim 20, wherein the identification information comprises user credentials.
22. The system of claim 17, wherein the second receive server is configured to operate as an NFS server proxy.
23. The system of claim 17, wherein the second send server is configured to operate as an NFS client proxy.
24. A secure system for bilaterally transferring information between a client coupled to a first network and a server coupled to a second network, comprising:
a first platform comprising a first send server having a data communications interface, a first one-way data link having an input and an output, and a first receive server having a network connection and a data communications interface, the first send server coupled to the input of the first one-way data link and the first receive server coupled to the output of the first one-way data link, the first send server configured to forward information received at the data communications interface to the input of the first one-way data link, the network connection of the first receive server coupled to the second network;
a second platform comprising a second send server having a data communications interface coupled only to the data communications interface of the first receive server, a second one-way data link having an input and an output, and a second receive server having a data communications interface and a network connections, the second send server coupled to the input of the second one-way data link and the second receive server coupled to the output of the second one-way data link, the second send server configured to forward information received at the data communications interface to the input of the second one-way data link, the network connection of the second receive server coupled to the first network and the data communications interface of the second receive server coupled only to the data communications interface of the first send server,
wherein the second receive server is configured to receive first information from the client via the first network and the network connection and to forward the first information to the first send server via the data communications interface of the second receive server;
wherein the first receive server is configured to receive the first information via the first one-way data link and to forward the first information to the server via the network connection and second network;
wherein the first receive server is also configured to receive second information from the server via the second network and the network connection, to process the received second information and to forward the processed second information to the second send server via the data communications interface; and
wherein the second receive server is also configured to receive the processed second information from the second one-way data link and to forward the processed second information to the client via the network connection and first network.
25. The system of claim 24, wherein the second receive server and the first receive server are each also configured to maintain the first information completely separate from the second information and the processed second information.
26. The system of claim 24, wherein the processing performed by the second receive server comprises filtering the information to remove a predetermined category of information.
27. The system of claim 26, wherein the predetermined category of information comprises identification information.
28. The system of claim 27, wherein the identification information comprises user credentials.
29. The system of claim 24, wherein the second receive server is configured to operate as an NFS server proxy.
30. The system of claim 24, wherein the first receive server is configured to operate as an NFS client proxy.
31. The system of claim 24, wherein the second receive server is further configured to filter the first information prior to forwarding the first information to the second send server via the network connection.
32. A secure system for bilaterally transferring information between a first client/server coupled to a first network and a second client/server coupled to a second network, comprising:
a first platform comprising a first send server having a data communications interface, a first one-way data link having an input and an output, and a first receive server having a network connection and a data communications interface, the first send server coupled to the input of the first one-way data link and the first receive server coupled to the output of the first one-way data link, the first send server configured to forward information received at the data communications interface to the input of the first one-way data link, the network connection of the first receive server coupled to the second network;
a second platform comprising a second send server having a data communications interface coupled only to the data communications interface of the first receive server, a second one-way data link having an input and an output, and a second receive server having a network connection and a data communications interface, the second send server coupled to the input of the second one-way data link and the second receive server coupled to the output of the second one-way data link, the second send server configured to forward information received at the data communications interface to the input of the second one-way data link, the network connection of the second receive server coupled to the first network and the data communications interface of the second receive server coupled only to the data communications interface of the first send server,
wherein the second receive server is configured to receive first information from the first client/server via the first network and the network connection and to forward the first information to the first send server via the data communications interface of the second receive server;
wherein the first receive server is configured to receive the first information via the first one-way data link and to forward the first information to the server via the network connection and second network;
wherein the first receive server is also configured to receive second information from the second client/server via the second network and the network connection and to forward the second information to the second send server via the data communications interface; and
wherein the second receive server is also configured to receive the second information from the second one-way data link and to forward the second information to the client via the network connection and first network.
33. The system of claim 32, wherein the second receive server and the first receive server are each also configured to maintain the first information completely separate from the second information.
34. The system of claim 32, wherein the second receive server is configured to process the first information prior to forwarding the first information to the first send server.
35. The system of claim 32, wherein the first receive server is configured to process the second information prior to forwarding the second information to the second send server.
36. The system of claim 32, wherein the second receive server is configured to process the first information prior to forwarding the first information to the first send server and wherein the first receive server is configured to process the second information prior to forwarding the second information to the second send server.
US14/508,188 2013-05-10 2014-10-07 Bilateral transfer system using multiple one-way data links Abandoned US20150058385A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/508,188 US20150058385A1 (en) 2013-05-10 2014-10-07 Bilateral transfer system using multiple one-way data links

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/892,099 US8898227B1 (en) 2013-05-10 2013-05-10 NFS storage via multiple one-way data links
US14/508,188 US20150058385A1 (en) 2013-05-10 2014-10-07 Bilateral transfer system using multiple one-way data links

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US13/892,099 Continuation US8898227B1 (en) 2013-05-10 2013-05-10 NFS storage via multiple one-way data links

Publications (1)

Publication Number Publication Date
US20150058385A1 true US20150058385A1 (en) 2015-02-26

Family

ID=51865634

Family Applications (2)

Application Number Title Priority Date Filing Date
US13/892,099 Active 2033-08-07 US8898227B1 (en) 2013-05-10 2013-05-10 NFS storage via multiple one-way data links
US14/508,188 Abandoned US20150058385A1 (en) 2013-05-10 2014-10-07 Bilateral transfer system using multiple one-way data links

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US13/892,099 Active 2033-08-07 US8898227B1 (en) 2013-05-10 2013-05-10 NFS storage via multiple one-way data links

Country Status (1)

Country Link
US (2) US8898227B1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9880869B2 (en) 2015-01-13 2018-01-30 Owl Cyber Defense Solutions, Llc Single computer-based virtual cross-domain solutions

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10637724B2 (en) 2006-09-25 2020-04-28 Remot3.It, Inc. Managing network connected devices
US11184224B2 (en) 2006-09-25 2021-11-23 Remot3.It, Inc. System, method and compute program product for accessing a device on a network
US9231904B2 (en) 2006-09-25 2016-01-05 Weaved, Inc. Deploying and managing networked devices
US9712486B2 (en) 2006-09-25 2017-07-18 Weaved, Inc. Techniques for the deployment and management of network connected devices
US8447843B2 (en) 2006-09-25 2013-05-21 Yoics, Inc. System, method and computer program product for identifying, configuring and accessing a device on a network
WO2013188835A2 (en) * 2012-06-15 2013-12-19 Yoics, Inc. Networking systems
US10250579B2 (en) * 2013-08-13 2019-04-02 Alcatel Lucent Secure file transfers within network-based storage
EP2916511B1 (en) * 2014-03-07 2020-02-12 Airbus Opérations SAS High assurance security gateway interconnecting different domains
KR101593168B1 (en) * 2014-09-11 2016-02-18 한국전자통신연구원 Physical one direction communication device and method thereof
US9853918B2 (en) 2015-03-24 2017-12-26 Owl Cyber Defense Solutions, Llc One-way network interface
US10021072B2 (en) 2015-08-20 2018-07-10 Mitsubishi Hitachi Power Systems, Ltd. Security system and communication control method
US10171422B2 (en) 2016-04-14 2019-01-01 Owl Cyber Defense Solutions, Llc Dynamically configurable packet filter
CN105721509B (en) * 2016-04-28 2019-03-01 上海趣医网络科技有限公司 A kind of server system
US9985872B2 (en) * 2016-10-03 2018-05-29 128 Technology, Inc. Router with bilateral TCP session monitoring
GB2559431B (en) * 2017-06-01 2020-09-02 Garrison Tech Ltd Web server security
US20190044809A1 (en) * 2017-08-30 2019-02-07 Intel Corporation Technologies for managing a flexible host interface of a network interface controller
CN109510794A (en) * 2017-09-14 2019-03-22 蓝盾信息安全技术股份有限公司 A kind of intelligent file scanning technique based on data unidirectional introducing equipment
EP3506587A1 (en) * 2017-12-29 2019-07-03 Nagravision S.A. Integrated circuit
US10142289B1 (en) 2018-03-27 2018-11-27 Owl Cyber Defense Solutions, Llc Secure interface for a mobile communications device
CN108881158A (en) * 2018-05-04 2018-11-23 北京明朝万达科技股份有限公司 Data interaction system and method
CN109299049B (en) * 2018-10-11 2022-03-22 郑州云海信息技术有限公司 Method and device for processing file access request
US10990737B2 (en) 2019-04-23 2021-04-27 Owl Cyber Defense Solutions, Llc Secure one-way network gateway
US11095649B2 (en) * 2019-06-27 2021-08-17 Saudi Arabian Oil Company Uni-directional and bi-directional cross-domain (secure exchange gateway) design
US11349872B2 (en) * 2019-11-26 2022-05-31 General Electric Company Provably secure application-specific cross-domain solutions
CN112217883B (en) * 2020-09-25 2023-01-10 苏州浪潮智能科技有限公司 Multi-channel construction method, device and system based on NFS protocol
CN112751870B (en) * 2020-12-30 2022-11-11 湖南麒麟信安科技股份有限公司 NFS (network file system) safety transmission device and method based on proxy forwarding

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050166261A1 (en) * 2004-01-23 2005-07-28 Sbc Knowledge Ventures, L.P. System and method for network authentication of a data service offering
US20060014532A1 (en) * 2004-07-15 2006-01-19 Seligmann Doree D Proximity-based authorization
US20110078108A1 (en) * 2009-09-29 2011-03-31 Oracle International Corporation Agentless data collection
US20110145433A1 (en) * 2009-10-08 2011-06-16 Nxp B.V. Ethernet network component
US7992209B1 (en) * 2007-07-19 2011-08-02 Owl Computing Technologies, Inc. Bilateral communication using multiple one-way data links
US20140068712A1 (en) * 2012-09-06 2014-03-06 Waterfall Security Solutions Ltd. Remote control of secure installations

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5703562A (en) 1996-11-20 1997-12-30 Sandia Corporation Method for transferring data from an unsecured computer to a secured computer
US6894505B2 (en) * 2002-08-01 2005-05-17 Teradyne, Inc. Flexible interface for universal bus test instrument
US7103638B1 (en) 2002-09-04 2006-09-05 Veritas Operating Corporation Mechanism to re-export NFS client mount points from nodes in a cluster
JP4371321B2 (en) 2006-03-10 2009-11-25 富士通株式会社 NFS server, NFS server control program, and NFS server control method
US8068415B2 (en) 2007-04-18 2011-11-29 Owl Computing Technologies, Inc. Secure one-way data transfer using communication interface circuitry
US8139581B1 (en) 2007-04-19 2012-03-20 Owl Computing Technologies, Inc. Concurrent data transfer involving two or more transport layer protocols over a single one-way data link
US8171067B2 (en) 2009-06-11 2012-05-01 International Business Machines Corporation Implementing an ephemeral file system backed by a NFS server
US8095628B2 (en) 2009-10-26 2012-01-10 International Business Machines Corporation Consolidated notifications to NFS clients

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050166261A1 (en) * 2004-01-23 2005-07-28 Sbc Knowledge Ventures, L.P. System and method for network authentication of a data service offering
US20060014532A1 (en) * 2004-07-15 2006-01-19 Seligmann Doree D Proximity-based authorization
US7992209B1 (en) * 2007-07-19 2011-08-02 Owl Computing Technologies, Inc. Bilateral communication using multiple one-way data links
US20110078108A1 (en) * 2009-09-29 2011-03-31 Oracle International Corporation Agentless data collection
US20110145433A1 (en) * 2009-10-08 2011-06-16 Nxp B.V. Ethernet network component
US20140068712A1 (en) * 2012-09-06 2014-03-06 Waterfall Security Solutions Ltd. Remote control of secure installations

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9880869B2 (en) 2015-01-13 2018-01-30 Owl Cyber Defense Solutions, Llc Single computer-based virtual cross-domain solutions

Also Published As

Publication number Publication date
US20140337407A1 (en) 2014-11-13
US8898227B1 (en) 2014-11-25

Similar Documents

Publication Publication Date Title
US8898227B1 (en) NFS storage via multiple one-way data links
US7992209B1 (en) Bilateral communication using multiple one-way data links
US10771435B2 (en) Zero trust and zero knowledge application access system
US11178104B2 (en) Network isolation with cloud networks
KR100680626B1 (en) Secure system and method for san management in a non-trusted server environment
US8335915B2 (en) Encryption based security system for network storage
US7913077B2 (en) Preventing IP spoofing and facilitating parsing of private data areas in system area network connection requests
US20020162026A1 (en) Apparatus and method for providing secure network communication
KR101531472B1 (en) Application state sharing in a firewall cluster
EP2754266B1 (en) Authentication sharing in a firewall cluster
US11546296B2 (en) Cloud computing architecture with secure multi-cloud integration
US11595410B2 (en) Fragmented cross-domain solution
CN111628960B (en) Method and apparatus for connecting to network services on a private network
KR102167575B1 (en) Method for blocking loop around connection between servers utilizing imaginary accoun
KR102584579B1 (en) Database access control gateway service system based on software as a service and method thereof
EP4323898A1 (en) Computer-implemented methods and systems for establishing and/or controlling network connectivity
JP2020031293A (en) Network cooperation system and network cooperation method
Prasetijo et al. Firewalling a Secure Shell Service
KR20180050952A (en) Method and apparatus for transceiving data based on multiple channels
Gandhi An approach to secure storage area networks using Diffie Hellman Challenge Handshake Authentication Protocol and PCI express host bus adapter
WO2016192765A1 (en) Authentication and authorization based on credentials and ticket

Legal Events

Date Code Title Description
AS Assignment

Owner name: OWL COMPUTING TECHNOLOGIES, INC., CONNECTICUT

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MRAZ, RONALD;LERMAN, KENNETH;SILBERMAN, GABRIEL;SIGNING DATES FROM 20140911 TO 20141007;REEL/FRAME:033902/0162

AS Assignment

Owner name: OWL COMPUTING TECHNOLOGIES, LLC, CONNECTICUT

Free format text: MERGER;ASSIGNOR:OWL COMPUTING TECHNOLOGIES, INC.;REEL/FRAME:041765/0034

Effective date: 20170203

AS Assignment

Owner name: OWL COMPUTING TECHNOLOGIES, LLC, CONNECTICUT

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT TO REMOVE THIS DOCUMENT SERVES AS AN OATH/DECLARATION (37 CFR 1.63) FROM THE COVER SHEET PREVIOUSLY RECORDED AT REEL: 041765 FRAME: 0034. ASSIGNOR(S) HEREBY CONFIRMS THE MERGER EFFECTIVE DATE 02/03/2017;ASSIGNOR:OWL COMPUTING TECHNOLOGIES, INC.;REEL/FRAME:042344/0033

Effective date: 20170203

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: OWL CYBER DEFENSE SOLUTIONS, LLC, CONNECTICUT

Free format text: CHANGE OF NAME;ASSIGNOR:OWL COMPUTING TECHNOLOGIES, LLC;REEL/FRAME:042902/0582

Effective date: 20170602