WO2019059754A9 - Método y sistema de comunicación segura por proxificación de sockets de red - Google Patents

Método y sistema de comunicación segura por proxificación de sockets de red Download PDF

Info

Publication number
WO2019059754A9
WO2019059754A9 PCT/MX2018/050013 MX2018050013W WO2019059754A9 WO 2019059754 A9 WO2019059754 A9 WO 2019059754A9 MX 2018050013 W MX2018050013 W MX 2018050013W WO 2019059754 A9 WO2019059754 A9 WO 2019059754A9
Authority
WO
WIPO (PCT)
Prior art keywords
socket
proxy
access
user
protected
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.)
Ceased
Application number
PCT/MX2018/050013
Other languages
English (en)
French (fr)
Other versions
WO2019059754A1 (es
Inventor
Jorge David DE HOZ DIEGO
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to MX2020012311A priority Critical patent/MX2020012311A/es
Priority to EP18857521.1A priority patent/EP3800564B1/en
Priority to PCT/MX2018/050013 priority patent/WO2019059754A1/es
Priority to US15/734,167 priority patent/US11050716B1/en
Priority to ES201990044A priority patent/ES2794723B2/es
Publication of WO2019059754A1 publication Critical patent/WO2019059754A1/es
Publication of WO2019059754A9 publication Critical patent/WO2019059754A9/es
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network 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

Definitions

  • the present invention refers to the telecommunications sector and particularly to the telematic area.
  • Security in communications in the loT is generally considered as a feature that must be provided by the software / firmware of each device in conjunction with the software platform that is responsible for managing them, administering them and from which resources and services derive.
  • the current solution used involves embedding the communications authentication and encryption software in the device's own firmware or in the main application it uses. Said software provides cryptographic protection of the communication channel to avoid security attacks somewhere in the middle, avoiding, among others:
  • the present invention is characterized by the independent claims and the dependent claims set forth exemplary embodiments of different aspects of the invention.
  • the present method and system presented provide solutions to the problems of the state of the art by proposing a secure communication system based on proxification that allows device applications to delegate security functionalities in independent and stand-alone software modules that can be updated without affecting the rest of the software of the devices.
  • This objective is achieved by combining a secure communication based on proxifications between devices together with a control of local communications, using for the latter security contexts that allow access to said proxifications to be restricted depending on the origin of the communication.
  • This strategy allows to greatly simplify the development of applications and the maintenance of security in the medium and long term, even when the support of these applications is no longer carried out. This is possible thanks to the fact that the system described in the invention is not part of the applications and can be updated without affecting them.
  • Proxify Action to offer the service or resource provided by a network socket in a different network socket, this socket can be located in a remote device.
  • Proxy or socket-proxy Result of the action of proxifying in which a new network socket is defined, through which it is possible to access the source socket of the proxy transparently and obtain the resources or services offered by it. .
  • Proxy-firewall server (1 11) A software module that is configured to:
  • Direct proxy (114) A type of proxy that occurs when the socket-proxy resulting from it is generated in the device that initiates the session for it, and that socket-proxy offers resources or services of a device socket to where the session establishment is directed.
  • Reverse Proxy (115) A type of proxification that occurs when the socket-proxy resulting from it is generated in the device where the session establishment is directed to, and this socket-proxy offers resources or services of a socket of the device initiating session establishment.
  • Kernel space (419) Memo area where exclusively the operating system kernel processes operate.
  • User environment Environment of the operating system in which the settings and privileges associated with the user of said environment apply or take effect.
  • Network framework (107) (420) Set of tools that interact with or are part of the operating system and that allow configuring the treatment that packets receive from communications that are carried from the user space to the kernel space and vice versa.
  • Protected socket Local network socket whose access is restricted based on filtering rules of the network framework of the device's operating system.
  • Security context Local network environment characterized by access permissions to certain protected network sockets.
  • Strict security context Security context applied between a protected socket and the user space of a specific user of the same operating system.
  • a strict security context is generated when an au_permission is applied to a socket-proxy of device_A by means of network framework rules. They are also generated on device_B when the rules described in profile_B A apply.
  • Wide security context Security context applied between a protected socket and the user space of multiple users of the same operating system belonging to the same group.
  • a broad security context is generated when an AC_permission is applied on a protected socket.
  • Agent a software module that acts as agent of the proxy-firewall server from a remote device. This software is configured to:
  • Agent_A (408) if it is on device_A. Only required on device_A if it requires proxying with other devices_A.
  • Agent_AF if it is in an device_AF.
  • Agent_B (109) if it is in a device device_B.
  • Proxy client (112) (409) Complementary software module of any agent that implements the secure communications protocol that is used to establish the communications session and to carry out proxifications, both direct and reverse.
  • Proxy server (113) (422) Complementary software module of the proxy-firewall server that implements the secure communication protocol used for session establishment and that receives and processes requests for proxies; both direct and reverse.
  • Connection-broker (121) (415) Software module used to keep a record and control over the proxifications made and access to them in device_A. It also takes care of periodically closing inactive accesses.
  • Device_A (106) (405) Hardware element that houses at least: a proxy-firewall server, a connection-broker, a network framework, a database, a profile_A and optionally an agent_A.
  • the device on which the main procedure is described is constituted as device_A and the other as device_AF.
  • AF_device Hardware element equivalent in functionalities to an A_device. The reason for differentiating it as device_AF aims to facilitate the explanation of the communications that may occur between two devices_A.
  • Device_B (101) Hardware element that houses at least one network framework, an agent_B and a profile_BA.
  • the operation configuration of this software module is also included in the profile_BA, since this proxy-firewall server will have reduced functions and aimed at extending the control that the proxy-firewall server of device_A has of the software modules of device_B, particularly for update processes.
  • Database (122) (414) Software module configured to save and consult different types of records used in the invention, among which are: record_socket, record_access, record_access_A, permission_Au and permission_Ac.
  • Profile_B A Agent configuration profile of device_B to configure the connection session to the proxy-firewall server of device_A.
  • This profile also contains the credentials to connect to device_A using the user account user_A B of the operating system of device_A. Likewise, it also includes information related to the capacity of user_A B to request proxies on device_A, said capacity being validated by the proxy-firewall server after each proxification request.
  • Profile_A Configuration profile of the proxy-firewall server and the connection-broker of device_A.
  • UAAF_Profile Configuration profile for the agent of device_A to configure the connection session to the proxy-firewall of device_AF.
  • This profile belongs to user_A and it also contains the credentials to connect to device_AF using the user account user_AAF of the operating system of device_AF.
  • This profile also contains information regarding the ability of the user_AAF to request proxies on the device_AF, this capacity being validated by the proxy-firewall server of the device_AF after each request for proxification.
  • User_AB User of the operating system of device_A that is used by agent_B when it connects to device_A using the credentials defined in profile_BA.
  • User_AAF User of the operating system of device_AF that is used by agent_A when it connects to device_AF using the credentials defined in the profile_UAAF.
  • Socket_A (123) Protected socket of device_A that offers resources or services to local processes and remote devices through direct or reverse proxifications.
  • Socket_B (118) Protected socket of device_B that offers resources or services to remote devices through a reverse socket-proxy on device_A.
  • Socket_AF Protected socket of the device_AF that offers resources or services to local processes and remote devices through direct or reverse proxifications.
  • Alias identifier referring to a specific socket that is used to name the socket of a device. It is important to note that the alias refers to the original socket that offers a service or resource. All your proxifications will inherit this alias, which can be of several types:
  • o Alias_B if the alias refers to a socket_B of a process of device_B.
  • o Alias_A if the alias refers to a socket_A of a process of device_A.
  • ld_DispProxy Variable relative to the socket_register of a protected socket that identifies the id of the device with which a session is maintained to be able to access the socket referred to by the alias and the id_DispSocket of the registry.
  • the Socket_Disp_id will refer to the device id of the second socket-proxy.
  • Socket_Type Variable relative to the socket_register of a protected socket that identifies the type of socket referred to by said register, which can be reverse socket-proxy, direct socket-proxy or socket_A. Reverse and direct socket-proxies in turn can also be of type socket_A, socket_B and socket-proxy, the latter indicating that the protected socket is a proxy for another socket-proxy.
  • Socket_Register A record type of device_A relative to a protected socket. It is stored in the connection-broker database and comprises of:
  • socket_register A variable named socket, which stores the protected socket referred to in this socket_register.
  • Con_ld Identifier of the marking carried out in the network traffic related to the communication with a protected socket. This id determines the user account or group of users that is the source of said communication, registered in the connection-broker database with the destination of that specific protected socket.
  • ld_User Identifier of a user or the account related to it in the operating system of device_A. This identifier uniquely represents the user and their user account, and these two concepts can be used interchangeably in scenarios related to the security contexts of device_A.
  • Last_activity Variable relative to an access_log of a user_A to a socket-proxy that defines the last moment in which there was activity related to the protected socket referred to in the access_log.
  • Access_Record a type of record related to a user account of the operating system of device_A and that is generated for each access granted to a direct or reverse socket-proxy type protected socket, which includes:
  • Access_Record_A A type of record related to a group of users of the operating system of device_A, which is generated for each access granted to a protected socket of type socket_A, and which includes:
  • a group_id which stores the group id of the user to whom access is granted.
  • Access monitor Software module used to keep a record and control over the proxifications made and the accesses to them in device_A. This can work in two ways:
  • the access_logs it was in charge of are no longer updated. This causes the inactivity of those access_logs to increase and eventually to be closed by the connection-broker.
  • the proxy-firewall server is notified to delete the relevant dialing rules and close the accesses related to the deleted access_logs. If the deleted access_logs were referring to a proxification between an A_device and an AF_device, the connection-broker also removes the socket_register and Au_permission for each access_register.
  • Au_permission This type of permission is used to grant access to user_A to a protected socket that is a socket-proxy through a strict security context. It is saved as a record in the connection-broker's database and said record comprises the following variables:
  • user_id which stores the user id of the operating system of device_A.
  • alias which stores the alias of the protected socket that is proxied as socket-proxy on device_A.
  • o id_DispSocket which stores the device id with socket_B or socket_A relative to the alias of the socket that offers the resource through socket-proxy.
  • alias which stores the alias for socket_A.
  • socket_A which stores the value of socket_A.
  • Sandbox-jail Set of packet filtering rules that configure access protection to the protected sockets. It also restricts the destinations of communications.
  • Access granted to a protected socket This is called access granted to a protected socket, or simply "access granted" to the configuration of a security context that enables an operating system user to access a local protected socket. A single granted access is applicable to any number of concurrent connections made from that user's account to the protected socket that such access refers to.
  • End application Application used by an end user.
  • End user A natural person who requires a resource through a final application or requests a service from a platform.
  • Platform (105) (413) Software module that allows monitoring and managing the information and services that are offered by other devices on the network. This information and services offered by the platform are mainly obtained from B-devices. The main function of the platform is to process this data and services to make them available to end users in the form of own resources. On the other hand, it can also act directly on the elements of the network it manages to modify its configuration or require actions from them using the local protected sockets to which it has access.
  • Host Physical or virtual machine with a multi-user operating system that houses one or more platforms.
  • Proxy (410) (423) Software module used by each type of protocol used by communication requests directed to a protected socket that does not use the same type of communication protocol as that used by the request originating process.
  • the proxy works as a translator between protocols to make communication transparent and its functions include the following:
  • This invention allows processes to establish communication between them using proxifications without having to depend directly on security protocols. In this way, the two processes that require communication with each other can carry out said communication locally in a security context that allows said communication to be also transparent thanks to proxification.
  • Security contexts :
  • Communication between processes through proxification between two devices consists of three segments: The intermediate segment, which communicates both devices and is protected by the communication session between the agent and the proxy-firewall server; and the two local segments, which communicate each end of the proxification with the respective processes.
  • Each of these two segments are vulnerable if a security context is not applied, since any process can access the ports that are listening, which is insecure since the communicating applications delegated all security responsibility to the agent and proxy-firewall server. For this reason, the present invention defines the concept of protected socket and security context.
  • Security contexts consist of rules applied by means of the network framework of two types: dialing rules and network traffic filtering rules.
  • the rules in turn, can be general or priority and their combination allows protecting local communications between processes and proxifications.
  • These contexts are a type of sandbox-jail that prevent communications from being processed with sockets other than those found within it.
  • the definition of the dialing and filtering rules that configure the protected sockets and the security contexts use two elements: The local socket, destination of the communication, and the user or group whose process is the source of the communication of the network packets. This last data must be inserted in the network traffic by marking the packets since, in most network protocols, there is no translation of this data to it. Therefore, it is necessary to use a network framework that configures the operating system to enter this data in the form of a markup.
  • clarifying that trying to identify the origin of the communication by the originating socket is generally complicated because applications use a different socket each time they request to establish a communication.
  • the security context is therefore defined with the destination socket and the source user id or the source user group of the communication. This information is translated into a destination socket connection identifier that is added to each packet of network traffic in order to identify the communication flow.
  • the filtering procedure is simple: the protected sockets should only be accessible by communications dialed by the operating system based on network framework rules and such communications can only be local and belonging to a reserved and protected local address range.
  • the vulnerability of communications is restricted to the possibility that a user or process can obtain elevated privileges that allow them to control the network framework.
  • a pool of local addresses for device_A is reserved on profile_A specifically for this system. These addresses are protected when starting the operating system of device_A by the network framework at the instance of the proxy-firewall server by means of the following general rules:
  • a general packet marking rule that determines to eliminate any possible network packet marking in any communication, produced between local sockets of device_A, with local addresses belonging to the reserved local address pool.
  • a general packet filtering rule that determines to drop any packet with source and destination a local socket of device_A that does not have a mark as long as one of the sockets uses a local network address belonging to the reserved local address pool.
  • a general packet filtering rule that determines to drop any packet with origin or destination a local address from the local address pool reserved for this method that has as origin or destination a non-local address.
  • each database_access and permission_Au of the database relative to each registry_socket whose socket_type is socket-proxy, and the deletion of the registry_socket itself must be performed; since those access_registers and socket_registers are relative to proxifications between devices_A and are considered temporary.
  • the following is the method that allows secure communications between processes using network socket proxifications.
  • the protected sockets are initially established on device_B and device_A and all this includes the following actions:
  • the proxy-firewall server enters dialing and filtering rules through the network framework into the operating system of device_A to protect the address pool assigned in profile_A.
  • These general rules include:
  • agent_B enters at least one rule into the network framework of the operating system of device_B to protect each socket_B defined in profile_BA. This general rule is to drop any network packet that has a non-local source address and the destination is one of the sockets_B.
  • o Enter, during the boot sequence of the operating system of device_A and through a network framework of the latter, a general rule of packet filtering by the proxy-firewall server that determines to discard any packet with origin or destination a local address from the local address pool reserved for this method that has a non-local address as its source or destination.
  • sockets_A are registered in the database that are not yet registered and the relevant dialing rules that define the corresponding broad security contexts are applied in the device_A to grant permanent access to the user groups of device_A defined in profile_A. All this includes the following actions:
  • each socket_register containing information that includes:
  • the id_DispSocket which in this case would be the id_A.
  • id_DispProxy which in this case would also be equal to id_A.
  • the socket which in this case would be equal to the local socket used by process_A for socket_A defined in profile l_A.
  • the proxy-firewall server verifies through the connection-broker that there are no valid accesses in the database related to socket_proxy-type socket_registers. If it exists, it will delete each access_register associated with said socket_register including the socket_register itself. These records are relative to proxifications between device_A and AF_devices are considered temporary and should be removed during device OS startup.
  • proxy-firewall server of device_A receives a session establishment request from agent_B to perform proxifications, all of which include the following actions:
  • proxifications are requested by agent_B according to profile_B A and are protected by the secure protocol used in the communication session between agent_B and the socket-proxy server.
  • each socket_B • Establish reverse proxifications. These allow each socket_B to be accessible by the applications of device_A locally as long as the user of the operating system that runs them has permission to do so. Each socket_B to be proxied is also defined in profile_B A.
  • processes on device_B can access each locally proxied socket_A and processes on device_A that have UA_permission can access reverse socket-proxies once they request resolution from the proxy-firewall server on device_A and configure the relevant strict security contexts.
  • Figure 1 Example of realization of a device_B and a device_A in which agent_A and the socket-proxy server maintain a session for which proxifications are made. Through these proxifications, process_B and the platform can communicate with each other.
  • Figure 2 Example of establishing a direct proxy of a socket_A in a device_B and a reverse proxy of a socket_B in a device_A.
  • Figure 4 Example of realization of a device_A.
  • Figure 5 Example of URL used in requesting a protected socket resource through a proxy of device_A.
  • FIG. 1 An example of the embodiment of the invention can be found in Figure 1.
  • This embodiment is oriented to a loT ecosystem.
  • an example of device_B (101) would correspond to all those loT devices of the ecosystem that are considered nodes of it.
  • devices can work with POSIX (Portable Operating System Interface) firmwares or operating systems (102).
  • An example of this type of operating systems are those of the Linux family or some of its variants.
  • they have a kernel that can make use of a network framework such as Netfilter, which can be in the Kernel or be loadable through external modules and through which dial and filter rules are entered (103).
  • This device_B has at least one process_B (104) that develops the main functionality of the device and that requires communication with management software such as a platform (105) of device_A (106).
  • device_A In the loT ecosystem presented, an example of device_A would correspond to the loT host to which the loT nodes connect.
  • device_A has an operating system also type POSIX and also of the Linux family, but this is something that is not essential, since being POSIX type operating systems, interoperability between them is feasible.
  • the operating system of device_A being also the Linux family in this example, also has a kernel with Netfilter framework (107) through which dial and filter rules are also entered (108).
  • the operating system of device_A when used on a loT host, must be multi-user and capable of separating privileges. That way, each device_B that connects to it will be able to use a different operating system account on device_A. This allows Netfilter to differentiate communication flows and create security contexts that extend the protection of communications in the local area for each device.
  • Security in communications between device_A and device_B is provided by an agent_B (109) of device_B that establishes a secure session (1 10) with a proxy-firewall server (11) of device_A.
  • This secure session uses a security protocol that it runs between a stand-alone proxy client (112) and a stand-alone proxy server (1 13). The first is part of agent_B and the second is part of the proxy-firewall server. The session established between them allows proxifications between the two devices.
  • An example of this type of protocol is SSH, which has implementations that work as a stand-alone proxy client and stand-alone proxy server as required in this example. Some examples of these implementations are OpenSSH and Dropbear.
  • Agent_B uses the established session to proxify connections between both devices as specified in the profile_BA that agent uses to establish the session. In this way, and based on the information contained in said profile, agent_B creates the corresponding socket-proxies (114) in device_B and reverse socket-proxies (115) in device_A. Proxy setting, therefore, can be done both ways, even if the session between the agent and the proxy-firewall is started by agent_B.
  • both the process_B and the loT platform can communicate using the socket-proxies. If communication is initiated by process_B, it will use the local direct socket-proxy (1 14) generated by agent_B to communicate with socket_A (123).
  • Such secure communication has three parts:
  • the first (116) is a local segment that includes the communication between process_B and the direct socket-proxy of agent_B. This communication segment is protected by the strict security context configured by agent_B when booting the operating system of device_B through Netfilter.
  • the loT platform When the loT platform requires to initiate communication with socket_B (118) of the process of device_B then it uses one of the reverse socket-proxies (115) generated in device_A; the one corresponding to the alias of socket_B and the id_B of device_B (id_DispSocket) to which the loT platform intends to access.
  • This communication also has three parts: the first (119), between the loT platform and the reverse socket-proxy, is protected by a strict security context configured by Netfilter on device_A. The second, between device_B and device_A is protected by the secure session (110) and finally the third (120), between the agent and socket_B (1 18) of the process_B of device_B is protected by another strict security context device_B.
  • the management of all established sessions, assigned socket-proxies and access permissions to them for users of the operating system of device_A are handled by the connection-broker (121) and its database (122) at the instances of the proxy server -firewall.
  • Access to the sockets_B on device_B or to the protected sockets of device_A is facilitated by priority dialing rules that define the respective strict security contexts.
  • the dialing rules in this example are applied by including the conjd in the TOS field of the IP protocol. Traffic marking using this strategy facilitates Netfilter operation and the implementation of the proxy-firewall server, but limits to 255 different security contexts applicable to each protected socket.
  • This figure, in the case of reverse socket proxies, is sufficient because loT devices are usually limited resource devices that are not usually prepared to allow multiple simultaneous connections: the information and services it offers are presented to the user or to the final application through the resources of the platform to which they are connected.
  • the sockets_A are also protected sockets and also require access permissions for the accounts of each device_B with processes that require connecting.
  • the number of strict security contexts required in this case for each socket_A would be as large as the number of devices_B that require communication for that socket, and in most loT projects it exceeds 255. Therefore, in this case, applies a single broad security context to a whole group of users on device_A, so that the user accounts on device_A that each device_B uses when connecting share the permission_Ac; for which those user accounts are included in the same group with said permission.
  • Example 1 Establishing a direct socket A socket proxying on device B and a socket B reverse proxying on device A
  • FIG 2 a sequence diagram is described in which, in an embodiment of the invention, device_B requires proxying two ports: a socket_A directly and a socket_B reverse.
  • This example involves a device_B with an agent_B (201) and a device_A with a proxy-firewall server (202), a connection-broker (203) and a database (204).
  • This example is generalizable to establish any number of direct and / or reverse proxifications in the same session without the need to perform them repeatedly.
  • agent_B logs in (205) to the proxy-firewall server using the settings defined in profile_B A.
  • the proxy-firewall server determines what type and number of proxifications are those that agent_B can make from the profile_B A used in the session establishment.
  • the proxy-firewall server forks itself (207) in the account user_A B.
  • a new instance of the proxy-firewall server is generated. like fork (208) on that account, allowing for separation of privileges.
  • This fork requests (209) the connection-broker to reserve a free socket to establish the reverse socket-proxy for socket_B.
  • said request also contains a resolution request for socket_A to obtain the protected socket assigned to said socket_A.
  • the connection-broker queries (210) in the database if the ac_permission exists for socket_A and inserts or updates the socket_register for socket_B based on profile_B A. If this socket_register previously existed, it is checked whether there is also an access_log in force relative to that socket_log. If it exists, the assigned socket value is maintained in the socket_register. If it does not exist, the socket value for the socket_register is updated with a new one that is local; always and in any case belonging to the pool of addresses reserved for this method and that the socket is available. If the socket_register does not exist or if a complete access_log must be generated, the socket is chosen at random from among those that are free in the reserved address pool.
  • This response includes the resolution of the socket_proxy (the value of the socket assigned in the socket_register for socket_B) and the resolution of the socket_A (the value assigned in the socket_register relative to the socket_A) in the form of socket_registers.
  • the fork is notified of it (212) and this in turn does the same with agent_B (213).
  • the latter sends a request (214) to the fork to start a protected socket listening that corresponds to the reverse socket-proxy (215) previously assigned.
  • agent_B listens for a protected local socket of device_B that corresponds to the direct socket-proxy (216).
  • Example 2 Request a resource from a protected socket of device A by process A
  • Process_A makes a request (305) to the proxy-firewall server (306) to proceed with the resolution of the protected socket from the alias of the socket and its id_DispSocket and thus know to which local socket to direct the request of the resource.
  • Said request (305) is produced in this example by a system call. The The origin of this call does not require the handling of credentials of user_A before the proxy-firewall server in the request itself, since the privilege separation of the POSIX-type system is used, through which the proxy-firewall server can uniquely identify the source account of said call.
  • connection-broker This request is validated (307) by the connection-broker, which initially makes a query (308) in the database to verify with its response (309) if user_A has permission. If the permission is of type ac_permission, granting of access is not required and proceeds with the response (310) to the proxy-firewall server indicating that access is available and what is the protected socket. However, if the permission is of type au_permission, the connection-broker must first grant access for user_A to the protected socket. To do this, the connection-broker generates an access_log (31 1) and records it in the database (312). Once the confirmation (313) has been received from the database that the registry was saved correctly and that there was no previous one, the proxy-firewall server is informed (314) of the need to configure the strict security context for user_A .
  • the proxy-firewall server uses the information in the access_log to define the required dialing rule to grant access of user_A communications to the protected socket. These dialing rules are inserted (315) into the operating system by means of the network framework (316). If there was a valid previous registration, it is not necessary to generate another access_log for user_A because user_A already has access. After receiving confirmation (317) of the insertion of the rules (if necessary), the proxy-firewall server instantiates an access monitor (318) to periodically update the status of the last_activity variable of the access_log. In this example, monitoring is done at 5 minute intervals. This access monitor, like dialing rules and that access_log is only carried out if there was no other valid previous access_log.
  • the proxy-firewall server notifies (319) process_A of the protected socket that it requires access to so that it can send the request (320) of the resource to the protected socket and Receive your reply (321).
  • Example 3 Accessing a reverse socket-proxy by a remote process through a local proxy on device A that converts https application protocol requests to http requests transparently
  • Figure 4 shows an example of embodiment of device_A that allows access (401) (402) (403) to socket-proxies (404) on device_A (405) from a process on a device other than device_A through proxied connections (406) in sessions (407) established with remote devices.
  • the first case (401) is an example of this type of communication in which applications using HTTPS access resources on socket_B, but without requiring that the process of the socket_B of this device_B have to have support for HTTPS or authentication scheme. This access is done through a reverse socket-proxy on device_A of a socket_B of a device_B that has a session established with device_A.
  • Communication as such between the application and the process of device_B is transparent and is carried out through an intermediate proxy (410) that also converts communications that use HTTPS into HTTP communications.
  • the end application requests a resource from device_B offered by a proxied socket_B in device_A and routes this request (401) to the intermediate proxy.
  • This software which converts the request (501) from HTTPS to HTTP, can be implemented in many server-side programming languages (41 1); such as PHP, Node.js, Go, Python, etc.
  • the proxy receives the communication destination information through subdomains (502) and also receives the credentials that the final application uses to obtain access to the proxy socket; the latter included in petition headings.
  • the web server (412) must be configured to redirect all requests on all possible proxy subdomains to the primary URL of the intermediate proxy, including the subdomains as parameters. From the headers, the intermediate proxy gets the credential that the end application attaches and that allow the intermediate proxy to validate the request and request access to the socket_proxy. The credentials are protected by HTTPS by being in the headers.
  • the request received by the intermediate proxy has the following elements:
  • the id_DispSocket which in this case corresponds to the id_B (503) of the socket_B to which the reverse socket-proxy leads, and which allows it to be identified together with the alias.
  • the credentials that go in the headers are used by the intermediate proxy to validate access to the socket-proxy for the user account in which the intermediate proxy is running according to the permissions in database (414) for that account. user.
  • This access can be requested directly from the connection-broker (415) through the proxy-firewall server (416) or before requiring a prior validation of the platform.
  • This request when going from the user space (418) to the kernel space (419) is checked by the network framework (420) if the access was granted correctly and the corresponding dialing rule was inserted. Subsequently, this request is routed and directed (421) to the socket-proxy and will be processed or discarded according to the filtering rules, being able to only enter the user space again if it has valid marking.
  • Both the dialing and filtering rules are entered into the network framework of the operating system at the initiative of the proxy-firewall server following the indications described in examples 1 and 2. Finally, the request is received by the proxy server's socket-proxy stand-alone (422) and transmitted as proxied communication to device_B.
  • Example 4 Access to a socket-proxy by a remote process through an intermediate proxy of device A in which the proxy converts incoming requests from the secure version of an application protocol to its insecure version:
  • Example 3 can be applied to other application-level protocols used by B-device programs that require security but do not implement it.
  • Some examples of these protocols can be HTTP / 2, MQTT and COAP. All of them also have a secure version of themselves, and with a proxy that transparently converts secure requests to insecure requests, it is feasible for B-devices to use the insecure version of the protocol together with the system described in the present invention to achieve secure communication. end to end.
  • Example 5 Access to socket-proxies by a platform that collects information from them, processes it, stores it and then offers it to the final applications in the form of its own resources
  • Communication (424) represents a very common mode of operation in loT ecosystems.
  • the final application does not require “direct access” to the resources of the proxied sockets, but to the information and services that the platform produces from those resources that it obtains autonomously.
  • the platform does this by establishing regular communications with the protected sockets to which it has access permission and from which it collects information with which it then prepares its own resources and services, which it could continue to offer even when all sessions (407) were temporarily down.
  • the mode of operation of the system proposed by the present invention in this case is analogous to that of Example 2.
  • process_A (302) is that which the platform executes to communicate with the local socket that it requires at any time.
  • the platform must have an account for this user of device_A with sufficient UA_permissions to be able to access all the socket-proxies related to the devices configured on the platform and from which it periodically obtains resources.
  • the platform can also offer necessary information to other devices through protected sockets of type socket_A (425).
  • Example 6 Requesting access to protected sockets of an AF device by means of direct proxies and instances of process A
  • process_A requests through the proxy-firewall server (602) and agent_A (603) a direct proxy (604), (426) of some protected sockets of an device_AF ( 605).
  • process_A requests (606) from the proxy-firewall server a resolution of remote sockets supplying the alias, the id_DispSocket and the id_DispProxy of each protected socket that you want to access.
  • the proxy-firewall server determines that these proxies need to be proxied directly from other AF_devices.
  • all the sockets to be proxied come from the same device, but this does not necessarily have to be the case in other cases.
  • the direct proxy request made by process_A to the proxy-firewall server is made by a system call that instantiates the proxy-firewall server as a process of that user environment.
  • the proxy-firewall server initially requests (607) from the connection broker (608) to reserve and register (609) in the database (610), some free local sockets that belong to the address pool. protected to assign direct socket-proxies.
  • the reservation of these sockets also implies the insertion of a socket-proxy type socket_register, and an access_register for each reserved socket if it has Au_permissions for each one of them.
  • the proxy-firewall server receives in response (612) from the connection-broker the reserved sockets and requests (613) from agent_A to establish (614) a session with the AF_device to resolve the protected sockets that need to be proxied.
  • Agent_A will use a profile_UAAF relative to user_A that authenticates against the account user_AAF of device_AF and that is provided by the proxy-firewall server.
  • the AF_device performs the pertinent actions (615) described in Example 7 to process the received proxy request.
  • agent_A responds (616) to agent_A with protected sockets resolved
  • agent_A notifies (617) the proxy-firewall server and proceeds to establish direct proxies (604).
  • direct socket-proxies are already established, access to them is not possible since they are protected sockets.
  • Example 7 Communication example in which an AF device gains access to protected sockets of device A by direct proxification
  • Example 6 an_A device connected to an AF_device to require direct proxies, and this example illustrates what happens on that AF_device.
  • device_AF will be referred to as device_A
  • device_AF the device that connects to device_A
  • the first part of the process is similar to that described in Example 1, with the exception that the device that initiates the session this time is an AF_device (instead of being a B_device) and that the request consists only of direct proxifications.
  • Device_AF has an agent_AF and a connection profile to connect to device_A that allows it to establish a session in which the resolution of the protected sockets required by device_AF is requested.
  • Said device_AF uses its credentials from the profile_UAAF to connect to the account of user_AAF in the operating system of device_A. This account must have access permission to the protected sockets to be proxied. Once the credentials are authenticated by the proxy-firewall server of device_A, this software instantiates itself with a fork under the user_AAF account.
  • the fork of the proxy-firewall server must evaluate whether the user_AAF of device_A has the necessary permissions to access the protected sockets required by agent_AF.
  • the procedure for checking, marking and assigning each access_register is the same as that described in Example 2 and comprising the sequence diagram of Figure 3 from (307) to (319).
  • Example 8 Proxy setting of protected sockets from one device A to another AF device in reverse at instances of process A on device A
  • device_A that maintains session with devices_B, takes the initiative and initiates a process of reverse proxification of local protected ports towards device_AF; either by instances of some process or by some type of established network configuration that indicates so.
  • device_A makes the protected sockets it proxies available to device_AF.
  • agent_A establishes a communication session with device_AF using a profile_UAAF supplied by the proxy-firewall server at the instance of process_A.
  • process_A requests reverse proxying to the proxy-firewall server of device_A.
  • the proxy-firewall server of device_A ensure that user_A running process_A has the necessary permissions to be able to access the protected sockets that it requests to proxy and, where appropriate, grant and record the relevant accesses and prepare and insert the appropriate dialing rules.
  • the procedure is identical to that described in Example 2 in the sequence diagram that ranges from (307) to (319).
  • the proxy-firewall server is also required to install an access monitor that verifies that the accesses remain open while process_A is running, periodically updating the status of each access_log to prevent them from being automatically closed due to inactivity.
  • the proxy-firewall server communicates to the process_A the resolved protected sockets so that any process of the user_AAF of the device_AF can access the protected sockets of the device_A through the established reverse socket-proxies.
  • the proxy-firewall server has been instantiated from the user_A account, and therefore can launch agent_A using the UAAF_profile that initiates the reverse proxification procedure of the protected sockets already accessible.
  • Example 9 Proxying protected sockets from an AF device to a device A in reverse to instances of the AF agent of the AF device:
  • the proxy-firewall server on device_A receives a session establishment request from an_AF device using an UAAF_profile requesting to perform reverse proxying of certain protected sockets from device_AF to device_A.
  • This request forces the proxy-firewall server to instantiate itself as fork_AAF in the user_AAF account of device_A whose credentials the agent_AF of device_AF used to connect to device_A.
  • the fork_AAF requires requesting the connection-broker to reserve local protected sockets on device_A in order to perform the reverse proxification.
  • the proxy-firewall server instantiates an access monitor to ensure that the access_logs related to each proxy maintain low inactivity, preventing it from closing automatically while process_A is still running.
  • the proxy-firewall server being instantiated from the account of the user_AAF, is part of the security context configured when inserting the dialing rules and, therefore, this instance has access to the protected sockets reserved in this example for reverse proxification . Once these actions are completed, the proxy-firewall server proceeds with the reverse proxying requested by the AF_Agent using the sockets reserved for it.
  • One of the main advantages of the present invention is the decoupling of the security functionalities of the applications of the B-devices and its corresponding simplification in its design and maintenance.
  • devices_A the processes that make use of the system proposed by the invention do not require security frameworks either, but they must incorporate in their programming the method described in this document in order to communicate with protected sockets.
  • the communication interface is based on system calls and packet tagging, so it is independent of security protocols and, therefore, it is feasible to update the device described in the present invention in device_A without affecting applications on device_A.
  • device_B has a simplified version of the proxy-firewall that has the stand-alone proxy server and adequate configuration in the profile_BA that allows device_A to use a reverse socket-proxy to update the agent of device_B.
  • This strategy can be generalized to provide update services to other software elements outside the system described by the invention.
  • the process includes:
  • agent_B the new version of the proxy client with the updated_BA profile establishing a new communication session.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Bioethics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

La presente invención se aplica al sector de las telecomunicaciones y está relacionada particularmente con el campo de la telemática. De forma más específica, la invención describe un método y sistema para definir una tecnología de red mejorada que permite comunicar y operar comunicaciones seguras entre procesos basándose en la utilización de proxificación segura de sockets de red locales que pueden ser entre diferentes dispositivos. Particularmente, el sistema y método presentados describen cómo establecer y gestionar proxificaciones entre dispositivos y cómo ampliar y administrar la seguridad de esas proxificaciones en el ámbito local de los mismos mediante contextos de seguridad. Estos contextos se configuran a partir de la separación de privilegios, marcado y filtrado de paquetes locales y permiten que las aplicaciones puedan delegar todos los aspectos relativos a la seguridad de las comunicaciones en la presente invención.

Description

DESCRIPCIÓN
Título de la invención: Método y sistema de comunicación segura por
proxificación de sockets de red
Sector técnico
La presente invención se refiere al sector de las telecomunicaciones y particularmente al área telemática.
Técnica anterior
El constante y creciente número de dispositivos y automatismos derivados del auge del Internet de las Cosas (loT), junto con el despegue de la Industria 4.0, ponen de manifiesto la importancia de simplificar el control de las comunicaciones y la gestión de su seguridad. Anteriormente, el número de dispositivos desatendidos en cualquier tipo de proyecto era sensiblemente inferior, lo que presuponía una interacción directa entre los dispositivos con el usuario final o el operador de red en mayor o menor grado. Sin embargo, el elevado número de elementos que conforman estas redes y su previsión de crecimiento exponencial en el tiempo modifica este tipo de interacción directa, ya que resultaría inviable en la mayoría de las ocasiones y va en contra de una tendencia de automatización generalizada. Por ese motivo, se requiere que determinados aspectos de seguridad funcionen de forma sólida, estandarizada y confiable para evitar que, por ejemplo, un supervisor de red tenga que analizar continuamente elemento a elemento el estatus de cada dispositivo; a la par que se favorezca la escalabilidad e interconectividad, potenciando las funcionalidades de esta tecnología.
La seguridad en las comunicaciones en el loT, particularmente en dispositivos de alto nivel con capacidad de ser actualizados, generalmente se plantea como una prestación que debe proporcionar el software/firmware de cada dispositivo en conjunción con la plataforma software que se encargue de gestionarlos, administrarlos y de la que deriven recursos y servicios. Independientemente del protocolo de comunicaciones empleado para ello, la solución actual utilizada implica embeber el software de autenticación y encriptación de las comunicaciones en el propio firmware del dispositivo o en la aplicación principal que éste utiliza. Dicho software proporciona una protección criptográfica del canal de comunicaciones para evitar ataques a la seguridad en algún punto intermedio de la misma evitando, entre otros:
• Que la información que se intercambia pueda ser escuchada (eavesdropping).
• Que la información intercambiada pueda modificarse, replicarse, alterarse su orden o falsificarse sin que este hecho sea detectado por el receptor de la comunicación (tampering). • Que el receptor con el que se comunica el emisor de la comunicación suplante la identidad del auténtico receptor de la misma, y este agente usurpador, a su vez, se haga pasar por el emisor de la comunicación de cara al receptor (man in the middle).
Este tipo de protección criptográfica se consigue, en la mayoría de las ocasiones, utilizando un framework de seguridad en el desarrollo de las aplicaciones que utilice Transport Layer Security (TLS) o algún protocolo de seguridad propietario. En ambos casos, una modificación que requiera actualizar algoritmos o determinadas configuraciones de los aspectos de seguridad suele requerir actualizar la aplicación completa y, en muchos casos, también el firmware del dispositivo. Algunos ejemplos de este tipo de implementaciones se encuentran en dispositivos que utilicen COAP, MQTT, HTTP o HTTP/2 con seguridad.
Este tipo de diseños, en los que el protocolo de seguridad se encuentra integrado en el software, conduce a la necesidad de mantener activos los equipos de desarrollo de ese software para todas sus versiones y para cada modelo de dispositivo que actualmente haga uso de ello; por lo que las empresas fabricantes tienden a limitar en el tiempo el soporte que dan a los productos que comercializan animando a sustituir el dispositivo completo por su nueva versión en caso de quedarse obsoleto su firmware o la seguridad de la aplicación. En el medio plazo, esta idea frecuentemente no representa una alternativa real para el consumidor final; ya que debe contemplar como coste, no sólo el importe de los nuevos dispositivos, sino la sustitución de los antiguos por los nuevos, formación para los empleados y actualización de sus procesos internos entre otros.
La falta de previsión en estos costes por parte de las empresas fabricantes de tecnología loT conduce a que los consumidores opten por seguir trabajando con dispositivos obsoletos en aspectos relativos a su seguridad. En muchas ocasiones, estos dispositivos no requieren manejar información sensible (ciertas redes de sensores) por lo que, aún en el caso de reconocerse esos dispositivos como vulnerables, el usuario final opta por mantenerlos ya que no le suponen ningún riesgo real. Todo esto, conduce a un escenario en el que infraestructuras críticas ajenas acaban corriendo el riesgo de ser amenazadas (comúnmente a través de ataques de denegación de servicio o DoS) por botnets creadas a raíz precisamente de estos dispositivos loT vulnerables que han logrado ser infectados con código malicioso, pero que aparentemente continúan funcionando con normalidad.
Resumen de la invención
La presente invención queda caracterizada por las reivindicaciones independientes y las reivindicaciones dependientes exponen ejemplos de realización de distintos aspectos de la invención. El presente método y sistema presentados aportan soluciones para los problemas del estado del arte proponiendo un sistema de comunicación segura basado en proxificación que permita a las aplicaciones de los dispositivos delegar las funcionalidades de seguridad en módulos de software independientes y stand-alone que se puedan actualizar sin afectar al resto del software de los dispositivos. Este objetivo, se consigue combinando una comunicación segura basada en proxificaciones entre dispositivos junto con un control de las comunicaciones locales, empleando para esto último contextos de seguridad que permiten restringir el acceso a dichas proxificaciones en función del origen de la comunicación. Esta estrategia permite simplificar enormemente el desarrollo de las aplicaciones y el mantenimiento de la seguridad a medio y largo plazo, aun cuando el soporte de dichas aplicaciones deje de realizarse. Esto es posible gracias a que el sistema descrito en la invención no forma parte de las aplicaciones y puede actualizarse sin afectarlas.
En los dibujos y diagramas que se acompañan, se ilustran a modo de ejemplo distintos aspectos de posibles realizaciones de la presente invención. Para facilitar la comprensión de la invención, se adjunta la interpretación de los conceptos más relevantes utilizados en este documento:
• Proxificar: Acción de ofrecer el servicio o recurso provisto por un socket de red en otro socket de red diferente, pudiendo este socket ubicarse en un dispositivo remoto.
• Proxificación o socket-proxy: Resultado de la acción de proxificar en el que se define un nuevo socket de red, por medio del cual es posible acceder al socket origen de la proxificación de forma transparente y obtener los recursos o servicios ofrecidos por el mismo.
• Servidor proxy-firewall: (1 11) Un módulo software que está configurado para:
o Recibir las solicitudes de establecimiento de sesión de otros dispositivos a través de un protocolo seguro por medio de un servidor proxy stand-alone
o Configurar contextos de seguridad estrictos y amplios mediante llamadas al sistema (427) al framework de red del sistema operativo del dispositivo_A.
o Procesar solicitudes de proxificación denominadas“socket-proxy” a través de sesiones establecidas o llamadas al sistema de procesos locales
o Monitorizar los accesos a sockets locales mediante monitores de acceso
o Gestionar las actualizaciones de seguridad de los dispositivos con los que mantenga una conexión.
o Establecer, mediante llamadas al sistema hacia el framework de red, la protección de los sockets locales utilizados en las proxificaciones en el dispositivo_A.
• Proxificación directa: (114) Un tipo de proxificación que se produce cuando el socket-proxy resultado de la misma se genera en el dispositivo que inicia la sesión para ello, y ese socket-proxy ofrece recursos o servicios de un socket del dispositivo a donde se dirige el establecimiento de sesión. • Proxificación reversa: (115) Un tipo de proxificación que se produce cuando el socket-proxy resultado de la misma se genera en el dispositivo a donde se dirige el establecimiento de sesión para ello, y este socket-proxy ofrece recursos o servicios de un socket del dispositivo que inicia el establecimiento de sesión.
• Espacio del usuario: (418) Área de memoria donde operan los procesos de los usuarios del sistema operativo.
• Espacio del kernel: (419) Área de memora donde operan exclusivamente los procesos del núcleo del sistema operativo.
• Entorno del usuario: Entorno del sistema operativo en el que aplican o tienen efecto las configuraciones y privilegios asociados al usuario de dicho entorno.
• Framework de red: (107) (420) Conjunto de herramientas que interactúan con el sistema operativo o que forman parte de él y que permiten configurar el tratamiento que reciben los paquetes de las comunicaciones que se cursan del espacio usuario al espacio del kernel y viceversa.
• Socket protegido: Socket de red local cuyo acceso se encuentra restringido en base a reglas de filtrado del framework de red del sistema operativo del dispositivo.
• Contexto de seguridad: Entorno de red local caracterizado por unos permisos de acceso a ciertos sockets de red protegidos.
• Contexto de seguridad estricto: Contexto de seguridad aplicado entre un socket protegido y el espacio usuario de un usuario concreto del mismo sistema operativo. En la presente invención, se genera un contexto de seguridad estricto cuando se aplica un permiso_Au en un socket-proxy del dispositivo_A por medio de reglas del framework de red. También se generan en el dispositivo_B cuando se aplican las reglas descritas en el pefil_BA.
• Contexto de seguridad amplio: Contexto de seguridad aplicado entre un socket protegido y el espacio usuario de múltiples usuarios del mismo sistema operativo pertenecientes a un mismo grupo. En la presente invención, se genera un contexto de seguridad amplio cuando se aplica un permiso_Ac en un socket protegido.
• Agente: un módulo software que actúa como agente del servidor proxy-firewall desde un dispositivo remoto. Este software está configurado para:
o Iniciar las solicitudes de establecimiento de sesión de comunicación hacia el servidor proxy-firewall a través de un protocolo seguro
o Realizar solicitudes de proxificación de sockets de forma directa y reversa
o Establecer, mediante llamadas al sistema hacia el framework de red, la protección de los sockets locales utilizados en las proxificaciones en el dispositivo_B.
El agente se denomina de distintas maneras según sea el dispositivo en el que se encuentre: o Agente_A: (408) si se encuentra en un dispositivo_A. Sólo es necesario en el dispositivo_A si éste requiere realizar proxificaciones con otros dispositivos_A.
o Agente_AF, si se encuentra en un dispositivo_AF. o Agente_B: (109) si se encuentra en un dispositivo dispositivo_B.
• Cliente proxy: (112) (409) Módulo software complementario de cualquier agente que implementa el protocolo de comunicaciones seguro que se usa para el establecimiento de la sesión de comunicaciones y para realizar las proxificaciones, tanto directas como reversas.
• Servidor proxy: (113) (422) Módulo software complementario del servidor proxy-firewall que implementa el protocolo de comunicación seguro que se usa para el establecimiento de sesión y que recibe y procesa las solicitudes de proxificaciones; tanto directas como reversas.
• Connection-broker: (121) (415) Módulo software empleado para mantener un registro y control sobre las proxificaciones realizadas y los accesos a las mismas en el dispositivo_A. También se ocupa de cerrar periódicamente los accesos inactivos.
• Dispositivo_A: (106) (405) Elemento hardware que alberga al menos: un servidor proxy-firewall, un connection-broker, un framework de red, una base de datos, un perfil_A y opcionalmente un agente_A. En la presente invención, si algún proceso requiere de dos dispositivos_A, el dispositivo sobre el que se describe el procedimiento principal se constituye como el dispositivo_A y el otro como dispositivo_AF.
• Dispositivo_AF: Elemento hardware equivalente en funcionalidades a un dispositivo_A. La razón de diferenciarlo como dispositivo_AF persigue el facilitar la explicación de las comunicaciones que se puedan producir entre dos dispositivos_A.
• Dispositivo_B: (101) Elemento hardware que alberga al menos un framework de red, un agente_B y un perfil_BA. En caso de albergar también un servidor proxy-firewall, la configuración de operación de este módulo software se incluye también en el perfil_BA, pues este servidor proxy-firewall tendrá funciones reducidas y orientadas a extender el control que el servidor proxy-firewall del dispositivo_A dispone de los módulos software del dispositivo_B, particularmente para procesos de actualización.
• Base de datos: (122) (414) Módulo software configurado para guardar y consultar distintos tipos de registros utilizados en la invención, entre los cuales se encuentran: registro_socket, registro_acceso, registro_acceso_A, permiso_Au y el permiso_Ac.
• Perfil_BA: Perfil de configuración del agente del dispositivo_B para configurar la sesión de conexión al servidor proxy-firewall del dispositivo_A. En este perfil también se encuentran las credenciales para conectarse al dispositivo_A utilizando la cuenta de usuario usuario_AB del sistema operativo del dispositivo_A. Así mismo, también incluye información relativa a la capacidad del usuario_AB de solicitar proxificaciones en el dispositivo_A, siendo dicha capacidad validada por el servidor proxy-firewall tras cada solicitud de proxificación.
• Perfil_A: Perfil de configuración del servidor proxy-firewall y del connection-broker del dispositivo_A. • Perfil_UAAF: Perfil de configuración para el agente del dispositivo_A para configurar la sesión de conexión al proxy-firewall del dispositivo_AF. Este perfil pertenece al usuario_A y en él, también se encuentran las credenciales para conectarse al dispositivo_AF utilizando la cuenta de usuario usuario_AAF del sistema operativo del dispositivo_AF. En este perfil también se encuentra información relativa a la capacidad del usuario_AAF de solicitar proxificaciones en el dispositivo_AF, siendo dicha capacidad validada por el servidor proxy- firewall del dispositivo_AF tras cada solicitud de proxificación.
• Usuario_AB: Usuario del sistema operativo del dispositivo_A que es utilizado por el agente_B cuando éste se conecta al dispositivo_A utilizando las credenciales definidas en el perfil_BA.
• Usuario_AAF: Usuario del sistema operativo del dispositivo_AF que es utilizado por el agente_A cuando éste se conecta al dispositivo_AF utilizando las credenciales definidas en el perfil_UAAF.
• Socket_A: (123) Socket protegido del dispositivo_A que ofrece recursos o servicios a procesos locales y dispositivos remotos por medio de proxificaciones directas o reversas.
• Socket_B: (118) Socket protegido del dispositivo_B que ofrece recursos o servicios a dispositivos remotos a través de un socket-proxy reverso en el dispositivo_A.
• Socket_AF: Socket protegido del dispositivo_AF que ofrece recursos o servicios a procesos locales y dispositivos remotos por medio de proxificaciones directas o reversas.
• Alias: identificador referido a un socket concreto que sirve para nombrar el socket de un dispositivo. Es importante remarcar que el alias hace referencia al socket original que ofrece un servicio o recurso. Todas sus proxificaciones heredarán este alias, el cual puede ser de varios tipos:
o Alias_B: si el alias hace referencia a un socket_B de un proceso del dispositivo_B. o Alias_A: si el alias hace referencia a un socket_A de un proceso del dispositivo_A.
• ld_DispSocket: Variable relativa al registro_socket de un socket protegido que identifica, junto con el alias del socket de dicho registro, el socket protegido del dispositivo. Esta variable hace referencia al id del dispositivo con el proceso que originó el socket que ofrece el recurso o servicio y puede almacenar tres tipos de identificadores:
o Un id_B, si el alias del registro_acceso refiere a un socket_B.
o Un id_AF, si el socket del registro_acceso comunica con un socket_proxy.
o Un id_A, si el alias del registro_acceso refiere a un socket_A.
• ld_DispProxy: Variable relativa al registro_socket de un socket protegido que identifica el id del dispositivo con el que se mantiene una sesión para poder acceder al socket referido por el alias y el id_DispSocket del registro. En el caso particular de que el registro_socket se refiera a un socket-proxy de otro socket-proxy, el id_DispSocket se referirá al id del dispositivo del segundo socket-proxy. • Tipo_socket: Variable relativa al registro_socket de un socket protegido que identifica el tipo de socket al que hace referencia dicho registro pudiendo ser socket-proxy reverso, socket-proxy directo o socket_A. Los socket-proxy reversos y directos a su vez pueden ser también de tipo socket_A, socket_B y socket-proxy, indicando este último que el socket protegido es una proxificación de otro socket-proxy.
• Registro_socket: un tipo de registro del dispositivo_A relativo a un socket protegido. Se guarda en la base de datos del connection-broker y comprende de:
o Una variable denominada socket, que guarda el socket protegido al que hace referencia el presente registro_socket.
o Un alias del socket al que hace referencia el presente registro_socket.
o Un id_DispSocket relativo al dispositivo con el socket al que hace referencia el alias o Un id_DispProxy que identifica el dispositivo al que conduce la sesión en la que se genera el socket protegido
o Un tipo_socket.
• Con_ld: Identificador del macado realizado en el tráfico de red relativo a la comunicación con un socket protegido. Este id determina la cuenta de usuario o el grupo de usuarios fuente de dicha comunicación, registrada en la base de datos del connection-broker con destino ese socket protegido específico.
• ld_Usuario: Identificador de un usuario o de la cuenta relativa al mismo en el sistema operativo del dispositivo_A. Este identificador representa unívocamente al usuario y su cuenta de usuario, pudiéndose utilizar estos dos conceptos de forma indistinta en escenarios relativos a los contextos de seguridad del dispositivo_A.
• Última_actividad: Variable relativa a un registro_acceso de un usuario_A a un socket-proxy que define el último momento en el que hubo actividad relacionada con el socket protegido al que se hace referencia en el registro_acceso.
• Registro_acceso: un tipo de registro relativo a una cuenta de usuario del sistema operativo del dispositivo_A y que se genera por cada acceso concedido a un socket protegido de tipo socket-proxy directo o reverso, el cual comprende:
o Un conjd, que guarda el id del acceso relativo a este registro.
o Una variable denominada“socket” que almacena el socket protegido al que se concede acceso y está formado por la dirección de red local y puerto
o Un id_Usuario, que guarda el id del usuario al que se concede el acceso
o Una última_actividad que inicialmente guarda el momento en el que se crea el registro y posteriormente se actualiza periódicamente (si procede) por el monitor de accesos.
• Registro_acceso_A: un tipo de registro relativo a un grupo de usuarios del sistema operativo del dispositivo_A, que se genera por cada acceso concedido a un socket protegido de tipo socket_A, y el cual comprende:
o Un conjd, que guarda el id del acceso relativo a este registro. o Una variable denominada“socket” que almacena el socket_A.
o Un id_Grupo, que guarda el id del grupo del usuario al que se concede el acceso.
• Monitor de accesos: Módulo software empleado para mantener un registro y control sobre las proxificaciones realizadas y los accesos a las mismas en el dispositivo_A. Éste puede funcionar de dos maneras:
o Verificando periódicamente si existe tráfico relativo a un socket protegido, y en cuyo caso, actualiza el estatus de última_actividad del registro_acceso pertinente
o Actualizando periódicamente el estatus de última_actividad del registro_acceso de los accesos que monitoriza para garantizar la accesibilidad a los sockets protegidos respectivos mientras el proceso que solicitó los accesos siga en ejecución.
Cuando un monitor de accesos termina, bien al no haber actividad a lo largo de un periodo de tiempo determinado o porque el proceso responsable de las proxificaciones ha terminado, se dejan de actualizar los registros_acceso de los que se encargaba. Esto provoca que la inactividad de esos registros_acceso se incremente y eventualmente sean cerrados por el connection-broker. Cuando esto ocurre, el servidor proxy-firewall es notificado para que borre las reglas de marcado pertinentes y cierre los accesos relativos a los registros_acceso borrados. Si los registros_acceso borrados se referían a una proxificación entre un dispositivo_A y un dispositivo_AF, el connection-broker también elimina el registro_socket y el permiso_Au relativo a cada registro_acceso.
• Permiso_Au: Este tipo de permiso sirve para otorgar acceso al usuario_A a un socket protegido que sea un socket-proxy a través de un contexto de seguridad estricto. Se guarda como registro en la base de datos del connection-broker y dicho registro comprende las siguientes variables:
o id_Usuario, que guarda el id del usuario del sistema operativo del dispositivo_A.
o alias, que almacena el alias del socket protegido que se proxifica como socket-proxy en el dispositivo_A.
o id_DispSocket, que almacena el id del dispositivo con el socket_B o socket_A relativo al alias del socket que ofrece el recurso a través del socket-proxy.
• Permiso_Ac: Este tipo de permiso sirve para otorgar el acceso de un grupo de usuarios del dispositivo_A a un socket_A a través de un contexto de seguridad amplio y comprende las siguientes variables:
o id_Grupo, que almacena el id del grupo de usuarios del sistema operativo del dispositivo_A al que se le otorga el permiso de acceso
o alias, que almacena el alias del socket_A.
o socket, que guarda el valor del socket_A.
• Sandbox-jail: Conjunto de reglas de filtrado de paquetes que configuran una protección de acceso a los sockets protegidos. También restringe los destinos de las comunicaciones. • Acceso concedido a un socket protegido: se denomina acceso concedido a un socket protegido, o simplemente“acceso concedido” a la configuración de un contexto de seguridad que habilite a un usuario de un sistema operativo para acceder a un socket protegido local. Un solo acceso concedido es aplicable a cualquier número de conexiones concurrentes realizadas desde la cuenta de ese usuario al socket protegido al que hace referencia dicho acceso.
• Aplicación final: Aplicación utilizada por un usuario final.
• Usuario final: Persona física que requiere a través de una aplicación final un recurso o solicita un servicio de una plataforma.
• Plataforma: (105) (413) Módulo software que permite monitorizar y administrar la información y servicios que son ofrecidos por otros dispositivos de la red. Esta información y servicios que ofrece la plataforma, principalmente se obtienen a partir de los dispositivos_B. La función principal de la plataforma consiste en procesar estos datos y servicios para ponerlos a disposición de los usuarios finales en forma de recursos propios. Por otro lado, también puede actuar de forma directa sobre los elementos de la red que gestione para modificar su configuración o requerir actuaciones de los mismos utilizando los sockets protegidos locales a los que tenga acceso.
• Host: Máquina física o virtual con sistema operativo multiusuario que alberga una o varias plataformas.
• Proxy: (410) (423) Módulo software utilizado por cada tipo de protocolo empleado por las solicitudes de comunicación dirigidas a un socket protegido que no emplee el mismo tipo de protocolo de comunicación que el utilizado por el proceso origen de la solicitud. El proxy funciona como traductor entre protocolos para hacer la comunicación transparente y entre sus funciones figuran las siguientes:
o Autenticar las solicitudes de comunicación con credenciales de algún usuario del sistema operativo del dispositivo_A que disponga de permiso_Au o que pertenezca a un grupo con permiso_Ac que le permita acceder al socket protegido
o Habilitar un registro_acceso en caso de ser necesario mediante llamadas al sistema o Retirar las credenciales de autenticación de la comunicación para que ésta pueda enviarse al socket protegido y dicho proceso de autenticación sea transparente a este último;
Esta invención permite que los procesos establezcan comunicación entre ellos utilizando proxificaciones sin tener que depender directamente de protocolos de seguridad. De este modo, los dos procesos que requieren comunicarse entre sí pueden realizar dicha comunicación de forma local en un contexto de seguridad que permite que dicha comunicación sea además transparente gracias a la proxificación. Contextos de seguridad:
La comunicación entre los procesos mediante proxificación entre dos dispositivos consta de tres segmentos: El segmento intermedio, que comunica ambos dispositivos y queda protegido por la sesión de comunicación entre el agente y el servidor proxy-firewall; y los dos segmentos locales, que comunican cada extremo de la proxificación con los procesos respectivos. Cada uno de estos dos segmentos, son vulnerables si no se aplica un contexto de seguridad, puesto que cualquier proceso puede acceder a los puertos que estén en escucha, lo cual resulta inseguro ya que las aplicaciones que se comunican delegaron toda responsabilidad de seguridad en el agente y el servidor proxy-firewall. Por ese motivo, la presente invención define el concepto de socket protegido y de contexto de seguridad.
Los contextos de seguridad consisten en reglas aplicadas por medio del framework de red de dos tipos: Reglas de marcado y reglas de filtrado de tráfico de red. Las reglas, a su vez, pueden ser generales o prioritarias y su combinación permite proteger las comunicaciones locales entre procesos y proxificaciones. Estos contextos son un tipo de sandbox-jail que impiden que se procesen las comunicaciones con sockets ajenos a los encontrados dentro del mismo.
La definición de las reglas de marcado y filtrado que configuran los sockets protegidos y los contextos de seguridad utilizan dos elementos: El socket local destino de la comunicación y el usuario o grupo cuyo proceso es origen de la comunicación de los paquetes de red. Este último dato se debe insertar en el tráfico de red mediante el marcado de los paquetes ya que, en la mayoría de los protocolos de red, no existe una traslación de este dato al mismo. Por consiguiente, es necesario utilizar un framework de red que configure el sistema operativo para que introduzca ese dato en forma de marcado. Por otro lado, aclarar que el intentar identificar el origen de la comunicación por el socket origen resulta generalmente complicado debido a que las aplicaciones utilizan un socket diferente cada vez que solicitan establecer una comunicación. El contexto de seguridad, se define por tanto con el socket destino y el id de usuario origen o del grupo de usuarios origen de la comunicación. Esa información se traduce a un identificador de conexión al socket destino que se añade a cada paquete de tráfico de red para poder identificar el flujo de comunicación.
Una vez queda definido el procedimiento de marcado para las comunicaciones permitidas, el procedimiento de filtrado es sencillo: los sockets protegidos deben ser únicamente accesibles por comunicaciones marcadas por el sistema operativo en base a reglas del framework de red y dichas comunicaciones sólo pueden ser locales y pertenecientes a un rango de direcciones locales reservado y protegido. En este escenario, la vulnerabilidad de las comunicaciones queda restringida a la posibilidad de que un usuario o proceso pueda obtener privilegios elevados que le permitan controlar el framework de red.
Protección del pool de direcciones reservadas: Un pool de direcciones locales del dispositivo_A queda reservado en el perfi l_A específicamente para este sistema. Estas direcciones son protegidas al arrancar el sistema operativo del dispositivo_A por el framework de red a instancias del servidor proxy-firewall por medio de las siguientes reglas generales:
• Una regla general de marcado de paquetes que determine eliminar cualquier posible marcado de paquetes de red en cualquier comunicación, producida entre sockets locales del dispositivo_A, con direcciones locales pertenecientes al pool de direcciones locales reservado.
• Una regla general de filtrado de paquetes que determine descartar cualquier paquete con origen y destino un socket local del dispositivo_A que carezca de un marcado siempre y cuando alguno de los sockets utilice una dirección de red local perteneciente al pool de direcciones locales reservado.
• Una regla general de filtrado de paquetes que determine descartar cualquier paquete con origen o destino una dirección local del pool de direcciones locales reservado para este método que tenga como origen o destino una dirección no local.
Además, se debe realizar la supresión, durante la secuencia de arranque del sistema operativo del dispositivo_A, de cada registro_acceso y permiso_Au de la base de datos relativo a cada registro_socket cuyo tipo_socket sea socket-proxy, y la supresión del propio registro_socket; ya que esos registros_acceso y registros_socket son relativos a proxificaciones entre dispositivos_A y son considerados temporales.
Método de comunicación segura por proxificación de sockets de red:
A continuación, se expone el método que permite realizar comunicaciones seguras entre procesos por medio de proxificaciones de sockets de red. Para ello, inicialmente se establecen los sockets protegidos en el dispositivo_B y en el dispositivo_A y todo ello comprende las siguientes acciones:
• Durante el arranque del dispositivo_A, el servidor proxy-firewall ingresa unas reglas de marcado y filtrado a través del framework de red al sistema operativo del dispositivo_A para proteger el pool de direcciones asignado en el perfil_A. Estas reglas de carácter general comprenden:
o Eliminar cualquier posible marcado de paquetes de red generado por los procesos en cualquier comunicación, producida entre sockets del dispositivo_A, con direcciones de red pertenecientes al pool de direcciones locales reservado para este método
o Descartar cualquier paquete con origen y destino un socket local del dispositivo_A que carezca de un marcado, siempre y cuando alguno de los sockets utilice una dirección de red local perteneciente al pool de direcciones reservado para este método. o Durante el arranque del dispositivo_B, el agente_B ingresa al menos, una regla al framework de red del sistema operativo del dispositivo_B para proteger cada socket_B definido en el perfil_BA. Esta regla de carácter general consiste en descartar cualquier paquete de red que tenga una dirección origen no local y el destino sea alguno de los sockets_B.
o Ingresar, durante la secuencia de arranque del sistema operativo del dispositivo_A y a través de un framework de red de este último, una regla general de filtrado de paquetes por parte del servidor proxy-firewall que determine descartar cualquier paquete con origen o destino una dirección local del pool de direcciones locales reservado para este método que tenga como origen o destino una dirección no local.
Una vez se han establecido las reglas de protección del pool de direcciones en el dispositivo_A, se registran los sockets_A en la base de datos que aún no lo estén y se aplican las reglas de marcado pertinentes que definan los contextos de seguridad amplios que correspondan en el dispositivo_A para conceder acceso permanente a los grupos de usuario del dispositivo_A que se definan en el perfil_A. Todo ello comprende de las siguientes acciones:
• El ingreso, si no existe, durante la secuencia de arranque del sistema operativo del dispositivo_A de un registro_socket en la base de datos del dispositivo_A relativo a cada socket_A del dispositivo_A recogido en el perfi l_A conteniendo cada registro_socket información que comprende:
o El id_DispSocket, que en este caso sería el id_A.
o El id_DispProxy, que en este caso sería también igual al id_A.
o El alias, que en este caso sería igual al empleado por el socket_A a registrar
o El socket, que en este caso sería igual al socket local utilizado por el proceso_A para el socket_A definido en el perfi l_A.
o El tipo_socket, que en este caso sería igual a“socket_A”.
• El ingreso, si no existen, de los permisos_AG y de cada registro_acceso_A tal y como se contemplen en el perfi l_A.
• El ingreso de unas reglas de marcado prioritarias respectivas a cada registro_acceso_A de cada socket_A concedidas permanentemente a los grupos de usuarios del dispositivo_A según esté definida cada una en forma de permiso en la base de datos del connection- broker.
Tras esto, el servidor proxy-firewall verifica a través del connection-broker que en la base de datos no existan accesos en vigor relativos a registros_socket de tipo socket_proxy. En caso de existir, borrará cada registro_acceso asociado a dicho registro_socket incluyendo el propio registro_socket. Estos registros son relativos a proxificaciones entre el dispositivo_A y dispositivos_AF son consideradas temporales y durante el inicio del sistema operativo del dispositivo_A deben suprimirse.
El proceso continúa cuando el servidor proxy-firewall del dispositivo_A recibe una petición de establecimiento de sesión del agente_B para realizar unas proxificaciones, todo lo cual comprende las siguientes acciones:
• Establecer una sesión de comunicaciones segura que permita efectuar proxificaciones de sockets entre el dispositivo_A y el dispositivo_B, donde el primero utilice para ello un servidor proxy-firewall que alberge y el segundo utilice un agente_B que inicie el establecimiento de dicha sesión empleando un cliente proxy stand-alone que implemente un protocolo de comunicación segura usando unos datos de configuración y credenciales del usuario_AB definidos por su perfil_BA. De este modo, el dispositivo_B establece la sesión con el dispositivo_A utilizando la cuenta usuario_AB.
• Posteriormente, proceder con el establecimiento de las proxificaciones directas. Éstas, permiten acceder a cada socket_A requerido desde el dispositivo_B. Dichas proxificaciones las solicita el agente_B según el perfil_BA y quedan protegidas por el protocolo seguro utilizado en la sesión de comunicaciones entre el agente_B y el servidor socket-proxy.
• Establecer las proxificaciones reversas. Éstas, permiten que cada socket_B sea accesible por las aplicaciones del dispositivo_A de forma local siempre y cuando el usuario del sistema operativo que las ejecuta tenga permiso para ello. Cada socket_B que debe proxificarse está definido también en el perfil_BA.
• Registrar las proxificaciones reversas en una base de datos de un connection-broker del dispositivo_A generando un registro_socket por cada una de ellas.
Una vez seguido este método, los procesos del dispositivo_B pueden acceder a cada socket_A proxificado de forma local y los procesos del dispositivo_A que dispongan de permiso_AU pueden acceder a los socket-proxy reversos una vez soliciten la resolución al servidor proxy-firewall del dispositivo_A y se configuren los contextos de seguridad estrictos pertinentes.
Breve descripción de las figuras:
• Figura 1 : Ejemplo de realización de un dispositivo_B y un dispositivo_A en el que el agente_A y el servidor socket-proxy mantienen una sesión por la que se efectúan proxificaciones. A través de estas proxificaciones, el proceso_B y la plataforma pueden comunicarse entre sí.
• Figura 2: Ejemplo de establecimiento de una proxificación directa de un socket_A en un dispositivo_B y de una proxificación reversa de un socket_B en un dispositivo_A.
• Figura 3: Ejemplo de comunicación del proceso_A con un socket de red protegido.
• Figura 4: Ejemplo de realización de un dispositivo_A. • Figura 5: Ejemplo de URL usada en la petición de un recurso de un socket protegido a través de un proxy del dispositivo_A.
• Figura 6: Ejemplo de solicitud de proxificación directa de sockets protegidos de un dispositivo_AF por parte de un proceso_A de un dispositivo_A.
Descripción detallada de la invención
A continuación, se describe la realización preferente y varios ejemplos de la realización de distintos aspectos de la presente invención haciendo referencia a las figuras adjuntas para ilustrar su funcionamiento en diferentes escenarios.
Realización preferente de la invención:
Un ejemplo de la realización de la invención puede encontrarse en la Figura 1. Esta realización está orientada a un ecosistema loT. En este escenario, un ejemplo de dispositivo_B (101) correspondería con todos aquellos dispositivos loT del ecosistema que sean considerados nodos del mismo. En este ejemplo, los dispositivos pueden funcionar con firmwares o sistemas operativos (102) de tipo POSIX (Portable Operating System Interface). Un ejemplo de este tipo de sistemas operativos son los de la familia Linux o alguna de sus variantes. En todo caso, disponen de un kernel que puede hacer uso de un framework de red como Netfilter, que puede estar en el Kernel o ser cargable mediante módulos externos y a través del cual se ingresan reglas de marcado y filtrado (103). Este dispositivo_B posee al menos un proceso_B (104) que desarrolla la funcionalidad principal del dispositivo y que requiere de comunicación con un software de gestión como lo puede ser una plataforma (105) de un dispositivo_A (106).
En el ecosistema loT que se presenta, un ejemplo de dispositivo_A correspondería con el host loT al que se conectan los nodos loT. En este ejemplo, el dispositivo_A cuenta con un sistema operativo también tipo POSIX y también de la familia Linux, pero esto es algo que no resulta imprescindible, ya que al ser sistemas operativos de tipo POSIX, la interoperabilidad entre ellos es factible. En todo caso, el sistema operativo del dispositivo_A, al ser también de la familia Linux en este ejemplo, también cuenta con un kernel con framework Netfilter (107) mediante el que también se ingresan reglas de marcado y filtrado (108). El sistema operativo del dispositivo_A, al ser utilizado en un host loT, es necesario que sea multiusuario y con capacidad de separación de privilegios. De ese modo, cada dispositivo_B que se conecte al mismo podrá utilizar una cuenta de sistema operativo diferente en el dispositivo_A. Esto permite a Netfilter diferenciar los flujos de comunicación y crear contextos de seguridad que extiendan la protección de las comunicaciones en el área local para cada dispositivo.
La seguridad en las comunicaciones entre el dispositivo_A y el dispositivo_B la proporciona un agente_B (109) del dispositivo_B que establece una sesión segura (1 10) con un servidor proxy-firewall (1 11) del dispositivo_A. Esta sesión segura, utiliza un protocolo de seguridad que se ejecuta entre un cliente proxy stand-alone (112) y un servidor proxy stand-alone (1 13). El primero forma parte del agente_B y el segundo, del servidor proxy-firewall. La sesión que establecen entre ellos permite realizar proxificaciones entre los dos dispositivos. Un ejemplo de este tipo de protocolos es SSH, el cual dispone de implementaciones que funcionan como cliente proxy stand-alone y servidor proxy stand-alone como las requeridas en este ejemplo. Algunos ejemplos de estas implementaciones son las de OpenSSH y Dropbear.
El agente_B, utiliza la sesión establecida para proxificar conexiones entre ambos dispositivos según esté especificado en el perfil_BA que utilice dicho agente para establecer la sesión. De este modo, y según la información contenida en dicho perfil, el agente_B crea los socket-proxies directos (114) en el dispositivo_B y socket-proxies reversos (115) en el dispositivo_A que correspondan. El establecimiento de proxificaciones, por tanto, puede realizarse en ambos sentidos, aunque la sesión entre el agente y el servidor proxy-firewall la inicie el agente_B.
Una vez establecidas las proxificaciones, tanto el proceso_B como la plataforma loT pueden comunicarse utilizando los socket-proxies. Si la comunicación la inicia el proceso_B, utilizará el socket-proxy directo local (1 14) que genera el agente_B para comunicarse con el socket_A (123). Dicha comunicación segura tiene tres partes:
• La primera (116), es un segmento local que comprende la comunicación entre el proceso_B y el socket-proxy directo del agente_B. Este segmento de comunicación queda protegido por el contexto de seguridad estricto configurado por el agente_B al arrancar el sistema operativo del dispositivo_B por medio de Netfilter.
• La segunda, entre el dispositivo_B y el dispositivo_A, está encriptada por la sesión SSH (110).
• La tercera (1 17), entre el servidor proxy-firewall y el socket_A de la plataforma queda protegida por un contexto de seguridad amplio configurado por el servidor proxy-firewall a través del Netfilter (107) del dispositivo_A.
Cuando la plataforma loT requiere iniciar una comunicación con el socket_B(118) del proceso del dispositivo_B entonces utiliza uno de los socket-proxies reversos (115) generados en el dispositivo_A; el correspondiente al alias del socket_B y al id_B del dispositivo_B (id_DispSocket) al que pretende acceder la plataforma loT. Esta comunicación también consta de tres partes: la primera (119), entre la plataforma loT y el socket-proxy reverso, queda protegida por un contexto de seguridad estricto configurado por Netfilter en el dispositivo_A. La segunda, entre el dispositivo_B y el dispositivo_A se encuentra protegida por la sesión segura (110) y finalmente la tercera (120), entre el agente y el socket_B (1 18) del proceso_B del dispositivo_B se encuentra protegida por otro contexto de seguridad estricto del dispositivo_B. La gestión de todas las sesiones establecidas, socket-proxies asignados y permisos de acceso a los mismos para usuarios del sistema operativo del dispositivo_A, son manejados por el connection-broker (121) y su base de datos (122) a instancias del servidor proxy-firewall.
El acceso a los sockets_B en el dispositivo_B o a los sockets protegidos del dispositivo_A se facilita mediante unas reglas de marcado prioritarias que definen los respectivos contextos de seguridad estrictos. Las reglas de marcado en este ejemplo se aplican incluyendo el conjd en el campo TOS del protocolo IP. El marcado de tráfico siguiendo esta estrategia facilita la operación de Netfilter y la implementación del servidor proxy-firewall, pero limita a 255 contextos de seguridad distintos aplicables a cada socket protegido. Esta cifra, en el caso de los socket- proxies reversos, es suficiente debido a que los dispositivos loT, suelen ser dispositivos de recursos limitados que no suelen estar preparados para permitir múltiples conexiones simultaneas: la información y los servicios que ofrece se presentan al usuario final o a la aplicación final a través de recursos propios de la plataforma a la que se conectan.
Los sockets_A, son también sockets protegidos y también requieren de permisos de acceso para las cuentas de cada dispositivo_B con procesos que requieran conectarse. El número de contextos estrictos de seguridad necesario en este caso por cada socket_A sería tan grande como el número de dispositivos_B que requieran comunicación dicho socket, y en la mayoría de los proyectos loT sí se superan los 255. Por ello, en este caso, se aplica un solo contexto de seguridad amplio a todo un grupo de usuarios del dispositivo_A, de modo que las cuentas de usuario del dispositivo_A que utiliza cada dispositivo_B al conectarse, compartan el permiso_Ac; para lo cual se incluyen esas cuentas de usuario en un mismo grupo con dicho permiso.
Ejemplo 1 : Establecimiento de una proxificación directa de un socket A en un dispositivo B y de una proxificación reversa de un socket B en un dispositivo A
En la figura 2, se describe un diagrama de secuencia en el que, en una realización de la invención, el dispositivo_B requiere proxificar dos puertos: un socket_A de forma directa y un socket_B de forma reversa. En este ejemplo intervienen un dispositivo_B con un agente_B (201) y un dispositivo_A con un servidor proxy-firewall (202), un connection-broker (203) y una base de datos (204). Este ejemplo es generalizable para establecer cualquier número de proxificaciones directas y/o reversas en la misma sesión sin necesidad de realizarse recurrentemente.
En primer lugar, el agente_B inicia la sesión (205) en el servidor proxy-firewall utilizando la configuración definida en un perfil_BA. Durante el proceso de autenticación (206), el servidor proxy-firewall determina qué tipo y número de proxificaciones son las que el agente_B puede realizar a partir del perfil_BA usado en el establecimiento de sesión. Una vez se realiza la autenticación y se establece la sesión, el servidor proxy-firewall realiza un fork de sí mismo (207) en la cuenta usuario_AB. De este modo, se genera una nueva instancia del servidor proxy-firewall como fork (208) en esa cuenta, lo que permite una separación de privilegios. Este fork solicita (209) al connection-broker la reserva de un socket libre para establecer el socket-proxy reverso para el socket_B. Así mismo, dicha solicitud también contiene un requerimiento de resolución del socket_A para obtener el socket protegido asignado a dicho socket_A. El connection-broker consulta (210) en la base de datos si existe el permiso_Ac para el socket_A e inserta o actualiza el registro_socket para el socket_B según el perfil_BA. Si este registro_socket existía previamente, se verifica si también existe algún registro_acceso en vigor relativo a ese registro_socket. En caso de existir, se mantiene el valor de socket asignado en el registro_socket. Si no existe, el valor de socket para el registro_socket se actualiza con otro nuevo que sea local; perteneciente siempre y en todo caso al pool de direcciones reservadas para este método y que el socket se encuentre disponible. En caso de no existir el registro_socket o en el caso de tener que generar un registro_acceso completo, el socket se elige aleatoriamente entre los que se encuentren libres en el pool de direcciones reservadas.
Una vez terminadas estas acciones, se procede con la respuesta (211). Esta respuesta incluye la resolución del socket_proxy (el valor del socket asignado en el registro_socket para el socket_B) y la resolución del socket_A (el valor asignado en el registro_socket relativo al socket_A) en forma de registros_socket. Tras esto, se notifica al fork de ello (212) y éste a su vez hace lo propio con el agente_B (213). Éste último, cursa una solicitud (214) al fork para que inicie un socket protegido en escucha que corresponda al socket-proxy reverso (215) previamente asignado. Así mismo, el agente_B inicia en escucha un socket local protegido del dispositivo_B que corresponde al socket-proxy directo (216).
Ejemplo 2: Solicitud de un recurso de un socket protegido del dispositivo A por un proceso A
A continuación, se describe a modo de ejemplo un procedimiento por el que se concede un acceso a un socket protegido del dispositivo_A al usuario del proceso_A para que éste pueda comunicarse con dicho socket protegido. Este procedimiento se ilustra con un diagrama de secuencia representado en la Figura 3. El registro_acceso y el contexto de seguridad se aplican en la cuenta de usuario local del dispositivo_A relativo al usuario_A. Los sockets protegidos nunca pueden ser accesibles directamente desde máquinas remotas y sus accesos siempre son locales y por usuarios dentro del contexto de seguridad. Esto es posible gracias a la separación de privilegios de sistemas POSIX que permite configurar los contextos de seguridad.
Para poder acceder al socket protegido (301), la cuenta usuario_A en la que se ejecuta el proceso_A (302) que requiere el acceso, debe disponer del permiso de usuario para ello en la base de datos (303) del connection-broker (304). El proceso_A realiza una solicitud (305) al servidor proxy-firewall (306) para proceder con la resolución del socket protegido a partir del alias del socket y de su id_DispSocket y de ese modo saber a qué socket local dirigir la petición del recurso. Dicha solicitud (305) se produce en este ejemplo mediante una llamada al sistema. El origen de esta llamada no requiere del manejo de credenciales de usuario_A ante el servidor proxy-firewall en la propia solicitud ya que se aprovecha la separación de privilegios del sistema tipo POSIX mediante la cual, el servidor proxy-firewall puede identificar unívocamente la cuenta de procedencia de dicha llamada.
Esta solicitud se valida (307) por el connection-broker, el cual inicialmente realiza una consulta (308) en la base de datos para verificar con su respuesta (309) si el usuario_A tiene permiso. Si el permiso es de tipo permiso_Ac no se requiere de la concesión de un acceso y se procede con la respuesta (310) al servidor proxy-firewall en la que se indica que se dispone de acceso y cuál es el socket protegido. Sin embargo, si el permiso es de tipo permiso_Au, el connection-broker debe de conceder antes el acceso para el usuario_A al socket protegido. Para ello, el connection-broker genera un registro_acceso (31 1) y lo registra en la base de datos (312). Una vez recibida la confirmación (313) de la base de datos de que el registro se guardó correctamente y de que no existía uno previo, se comunica (314) al servidor proxy-firewall la necesidad de configurar el contexto de seguridad estricto para el usuario_A.
El servidor proxy-firewall utiliza la información del registro_acceso para definir la regla de marcado necesaria que conceda el acceso de las comunicaciones del usuario_A al socket protegido. Estas reglas de marcado se insertan (315) en el sistema operativo por medio del framework de red (316). Si hubiese un registro previo válido, no es necesario generar otro registro_acceso para el usuario_A porque el usuario_A ya dispone de acceso. Tras recibir confirmación (317) de la inserción de las reglas (en caso de haber sido necesario), el servidor proxy-firewall instancia un monitor de acceso (318) para actualizar periódicamente el estatus de la variable última_actividad del registro_acceso. En este ejemplo, la monitorización se hace a intervalos de 5 minutos. Este monitor de acceso, al igual que las reglas de marcado y que el registro_acceso sólo se lleva a cabo si no existía otro registro_acceso válido anterior.
Una vez se confirma que el usuario_A dispone de un acceso al socket protegido, el servidor proxy-firewall notifica (319) al proceso_A cuál es el socket protegido al que requiere acceder para que pueda enviar la solicitud (320) del recurso al socket protegido y recibir su respuesta (321).
Ejemplo 3: Acceso a un socket-proxy reverso por un proceso remoto a través de un proxy local del dispositivo A que convierte peticiones del protocolo de aplicación https a peticiones http de forma transparente
En la figura 4 se muestra un ejemplo de realización del dispositivo_A que permite poder acceder (401) (402) (403) a los socket-proxies (404) en el dispositivo_A (405) desde un proceso en un dispositivo diferente al dispositivo_A a través de conexiones proxificadas (406) en sesiones (407) establecidas con dispositivos remotos. El primer caso (401) es un ejemplo de este tipo de comunicación en el que las aplicaciones que utilizan HTTPS acceden a recursos del socket_B, pero sin requerir que el proceso del socket_B de este dispositivo_B tenga que contar con soporte para HTTPS ni esquema de autenticación. Este acceso se realiza a través de un socket-proxy reverso en el dispositivo_A de un socket_B de un dispositivo_B que tiene una sesión establecida con el dispositivo_A.
La comunicación como tal entre la aplicación y el proceso del dispositivo_B es transparente y se efectúa a través de un proxy intermedio (410) que además convierte comunicaciones que utilizan HTTPS en comunicaciones HTTP. En primer lugar, la aplicación final solicita un recurso del dispositivo_B ofrecido por un socket_B proxificado en el dispositivo_A y dirige esta petición (401) hacia el proxy intermedio. Este software, que convierte la petición (501) de HTTPS a HTTP, puede estar implementado en multitud de lenguajes de programación del lado del servidor (41 1); como son por ejemplo PHP, Node.js, Go, Python, etc. Para posibilitar un acceso al socket-proxy correspondiente, el proxy recibe la información del destino de la comunicación por medio de subdominios (502) y también recibe las credenciales que use la aplicación final para conseguir un acceso al socket proxy; estas últimas incluidas en encabezados de la petición.
El servidor web (412) debe estar configurado para redireccionar todas las peticiones en todos los subdominios posibles del proxy hacia la URL principal del proxy intermedio, incluyendo los subdominios como parámetros. De los encabezados, el proxy intermedio obtiene la credencial que la aplicación final adjunta y que permiten al proxy intermedio validar la petición y solicitar acceso al socket_proxy. Las credenciales van protegidas por HTTPS al estar en los encabezados. La petición que recibe el proxy intermedio cuenta con los siguientes elementos:
• El id_DispSocket, que en este caso corresponde con el id_B (503) del socket_B al que conduce el socket-proxy reverso, y que permite identificarlo junto al alias.
• El alias (504) del socket_B que permite identificar el socket-proxy junto al id_DispSocket.
• El dominio (505) del proxy.
• El recurso (506) que se solicita al socket_B.
La protección de las comunicaciones en cualquiera de los subdominios dinámicos que se requieran es posible con un único certificado wildcard SSL basado en certificados X.509 que habilita la protección de HTTPS para el dominio principal del proxy y de todos los subdominios posibles. Por otro lado, la comunicación extremo a extremo también es transparente e independiente de otras comunicaciones que pueda tener la aplicación final con otros socket-proxy al necesitar cada uno un subdominio diferente.
Las credenciales que van en los encabezados, son utilizadas por el proxy intermedio para validar el acceso al socket-proxy para la cuenta de usuario en la que se ejecuta el proxy intermedio según los permisos en la base de datos (414) para esa cuenta de usuario. Este acceso se puede solicitar directamente al connection-broker (415) a través del servidor proxy-firewall (416) o requerir antes una validación previa de la plataforma. Una vez realizada la conversión de HTTPS a HTTP y haberse habilitado el acceso al socket-proxy para la cuenta de usuario que ejecuta el proxy intermedio, éste suprime los encabezados con las credenciales para hacer transparente el proceso de autenticación y envía la petición web HTTP (417) hacia el socket-proxy que corresponda. Esta petición, al pasar del espacio de usuario (418) al espacio del kernel (419) es marcada por el framework de red (420) si el acceso se concedió correctamente y se insertó la regla de marcado correspondiente. Posteriormente, esta petición es enrutada y dirigida (421) hacia el socket-proxy y será cursada o descartada según las reglas de filtrado, pudiendo únicamente ingresar de nuevo al espacio usuario si posee un marcado válido.
Tanto las reglas de marcado como de filtrado se introducen en el framework de red del sistema operativo por iniciativa del servidor proxy-firewall siguiendo las indicaciones descritas en los ejemplos 1 y 2. Finalmente, la petición es recibida por el socket-proxy del servidor proxy stand-alone (422) y transmitida como comunicación proxificada hacia el dispositivo_B.
Ejemplo 4: Acceso a un socket-proxy por un proceso remoto a través de un proxy intermedio del dispositivo A en el que el proxy convierte las peticiones entrantes de la versión segura de un protocolo de aplicación a la versión insegura del mismo:
En este ejemplo, se generaliza el ejemplo anterior. Siguiendo el mismo esquema, el ejemplo 3 se puede aplicar a otros protocolos del nivel de aplicación utilizados por programas de dispositivos_B que requieren de seguridad pero que no la implementan. Algunos ejemplos de estos protocolos pueden ser HTTP/2, MQTT y COAP. Todos ellos tienen también una versión segura de sí mismos, y con un proxy que convierta de forma transparente peticiones seguras a peticiones inseguras resulta factible que los dispositivos_B utilicen la versión insegura del protocolo junto con el sistema expuesto en la presente invención para conseguir una comunicación segura extremo a extremo.
Ejemplo 5: Acceso a socket-proxies por una plataforma que recopila información de ellos, la procesa, almacena y luego la ofrece a las aplicaciones finales en forma de recursos propios
La comunicación (424) representa una modalidad de operación muy común en ecosistemas loT. En este caso, la aplicación final no requiere un“acceso directo” a los recursos de los sockets proxificados, sino a la información y servicios que la plataforma elabora a partir de esos recursos que obtiene de forma autónoma. La plataforma, para ello sí establece comunicaciones periódicas con los sockets protegidos a los que tiene permiso de acceso y de los que recopila información con la que luego elabora sus recursos y servicios propios, los cuales podría seguir ofreciendo aun cuando todas las sesiones (407) estuviesen caídas temporalmente. El modo de operar del sistema propuesto por la presente invención en este caso es análogo al del ejemplo 2. En particular, el proceso_A (302) es aquél que ejecute la plataforma para comunicarse con el socket local que requiera en cada momento. La plataforma debe de disponer para ello de una cuenta de usuario del dispositivo_A con permisos_AU suficientes para poder acceder a todos los socket-proxy relativos a los dispositivos configurados en la plataforma y de los que obtiene los recursos periódicamente. Por otro lado, la plataforma también puede ofrecer información necesaria a otros dispositivos por medio de sockets protegidos de tipo socket_A (425).
Ejemplo 6: Solicitud de acceso a sockets protegidos de un dispositivo AF por medio de proxificaciones directas y a instancias de un proceso A
Este ejemplo ilustra cómo el dispositivo_A, a instancias del proceso_A (601), solicita por medio del servidor proxy-firewall (602) y del agente_A (603) una proxificación directa (604), (426) de unos sockets protegidos de un dispositivo_AF (605). Esto permite que el proceso_A pueda acceder de forma segura a recursos de sockets protegidos en ese dispositivo remoto. Para ello, el proceso_A solicita (606) al servidor proxy-firewall una resolución de sockets remotos suministrando el alias, el id_DispSocket y el id_DispProxy de cada socket protegido al que se desea acceder. En este caso, el id_DispSocket es distinto al id_DispProxy y por ese motivo, el servidor proxy-firewall determina que se requieren proxificar de forma directa esos proxies desde otros dispositivos_AF. En el ejemplo, todos los sockets a proxificar provienen del mismo dispositivo, pero no necesariamente tiene por qué ser así en otros casos.
La solicitud de proxificación directa realizada por el proceso_A al servidor proxy-firewall se realiza mediante una llamada al sistema que instancia el servidor proxy-firewall como proceso de ese entorno de usuario. Para proceder con la proxificación directa, el servidor proxy-firewall inicialmente solicita (607) al connection-broker (608) que reserve y registre (609) en la base de datos (610), unos sockets locales libres que pertenezcan al pool de direcciones protegido para asignar los socket-proxy directos. La reserva de estos sockets implica además la inserción de un registro_socket de tipo socket-proxy, y un registro_acceso por cada socket reservado si dispone de permisos_Au para cada uno de ellos.
Una vez se confirma la reserva (611) de esos sockets locales, el servidor proxy-firewall recibe en la respuesta (612) del connection-broker los sockets reservados y solicita (613) al agente_A el establecimiento (614) de una sesión con el dispositivo_AF para resolver los sockets protegidos que se requieren proxificar. El agente_A utilizará un perfil_UAAF relativo al usuario_A que se autentica en la cuenta usuario_AAF del dispositivo_AF y que es suministrado por el servidor proxy-firewall.
Una vez se establece la sesión usando dichas credenciales, el dispositivo_AF realiza las acciones pertinentes (615) descritas en el ejemplo 7 para procesar la solicitud de proxificación recibida. Cuando el dispositivo_AF responde (616) al agente_A con los sockets protegidos resueltos, el agente_A notifica (617) al servidor proxy-firewall y procede a establecer las proxificaciones directas (604). Aunque los socket-proxy directos ya se encuentran establecidos, el acceso a los mismos no es posible al ser sockets protegidos. Para poder conceder acceso al usuario_A del proceso_A es necesario aplicar los permisos_Au respectivos de la base de datos. Estos permisos, son traducidos por el servidor proxy-firewall en reglas de marcado que se insertan (618) a través del framework de red. Una vez se confirma (619) este ingreso, el servidor proxy-firewall responde
(620) la petición del proceso_A con los sockets-proxy directos resueltos para que pueda conectarse a ellos. Paralelamente, el servidor proxy-firewall instancia un monitor de accesos
(621) que mantiene activos los accesos mientras esté funcionando el proceso_A.
Ejemplo 7: Ejemplo de comunicación en el que un dispositivo AF consigue acceso a unos sockets protegidos de un dispositivo A por proxificación directa
Este ejemplo está vinculado con el anterior: en el ejemplo 6, un dispositivo_A se conectaba con un dispositivo_AF para requerir proxificaciones directas y este ejemplo ilustra lo que ocurre en ese dispositivo_AF. Sin embargo, para mantener la coherencia descriptiva, en el presente ejemplo ese dispositivo_AF será referido como dispositivo_A y el dispositivo que se conecta al dispositivo_A será referido como dispositivo_AF. Una vez aclarado este detalle, se procede a exponer cómo se concede en este ejemplo la proxificación directa de sockets protegidos a un dispositivo_AF.
La primera parte del proceso es similar a la descrita en el ejemplo 1 , con la salvedad de que el dispositivo que inicia la sesión esta vez es un dispositivo_AF (en vez de ser un dispositivo_B) y que la solicitud consiste únicamente en proxificaciones directas. Para ello, El dispositivo_AF dispone de un agente_AF y de un perfil de conexión para conectarse al dispositivo_A que le permite establecer una sesión en la que se solicita la resolución de los sockets protegidos requeridos por el dispositivo_AF. Dicho dispositivo_AF utiliza sus credenciales del perfil_UAAF para conectarse a la cuenta del usuario_AAF en el sistema operativo del dispositivo_A. Esta cuenta debe tener permiso de acceso a los sockets protegidos que se quieren proxificar. Una vez autenticadas las credenciales por el servidor proxy-firewall del dispositivo_A, este software se instancia con un fork de sí mismo bajo la cuenta de usuario_AAF.
Una vez llegado a este punto, el fork del servidor proxy-firewall debe evaluar si el usuario_AAF del dispositivo_A dispone de los permisos necesarios para acceder a los sockets protegidos requeridos por el agente_AF. En el dispositivo_A, el procedimiento de comprobación, marcado y asignación de cada registro_acceso es igual al descrito en el ejemplo 2 y que comprende el diagrama de secuencia de la figura 3 desde (307) hasta (319). Una vez confirmados los permisos y en su caso, concedidos los accesos a los socket-proxies requeridos y definidas e insertadas las reglas de marcado pertinentes, se devuelven los sockes resueltos al agente_AF para que pueda proceder con el inicio de la proxificación directa. Para garantizar que la cuenta de usuario_AAF del dispositivo_A disponga del acceso constantemente mientras dure la sesión, se instancia un monitor de accesos que periódicamente actualice todos los accesos a los sockets- proxy aun si no ha habido tráfico. Esto lo realizará mientras dure la sesión entre el dispositivo_AF y el dispositivo_A.
Ejemplo 8: Establecimiento de una proxificación de sockets protegidos desde un dispositivo A hacia otro dispositivo AF de forma reversa a instancias del proceso A del dispositivo A
Existe la posibilidad de que una plataforma de un dispositivo_AF requiera el acceso a recursos proxificados de dispositivos_B con los que no mantiene sesión, o que esos dispositivos_B requieran de recursos de un dispositivo_A foráneo con el que tampoco mantienen sesión. En este caso, el dispositivo_A que mantiene sesión con los dispositivos_B, toma la iniciativa e inicia un proceso de proxificación reversa de puertos protegidos locales hacia el dispositivo_AF; bien por instancias de algún proceso o por algún tipo de configuración de red establecido que así lo indique. Con la proxificación reversa, el dispositivo_A pone a disposición del dispositivo_AF los sockets protegidos que proxifique. Para ello, el agente_A establece una sesión de comunicación con el dispositivo_AF utilizando un perfil_UAAF suministrado por el servidor proxy-firewall a instancias de un proceso_A.
En este ejemplo, el proceso_A solicita la proxificación reversa al servidor proxy-firewall del dispositivo_A. Al igual que en el ejemplo 2, es imprescindible que el servidor proxy-firewall del dispositivo_A se asegure de que el usuario_A que ejecuta el proceso_A cuente con los permisos necesarios para poder acceder a los sockets protegidos que solicita proxificar y que, cuando corresponda, conceda y registre los accesos pertinentes y elabore e inserte las reglas de marcado oportunas. El procedimiento es idéntico al descrito en el ejemplo 2 en el diagrama de secuencias que comprende desde el (307) hasta el (319). También se requiere que el servidor proxy-firewall instancie un monitor de accesos que verifique que los accesos permanezcan abiertos mientras se esté ejecutando el proceso_A, actualizando periódicamente el estatus de cada registro_acceso para evitar que se cierren automáticamente por inactividad. Tras esto, el servidor proxy-firewall comunica al proceso_A los sockets protegidos resueltos de modo que, cualquier proceso del usuario_AAF del dispositivo_AF pueda acceder a los sockets protegidos del dispositivo_A a través de los socket-proxy reversos establecidos. Para ello, el servidor proxy-firewall se ha instanciado desde la cuenta de usuario_A, y por tanto puede lanzar el agente_A utilizando el perfil_UAAF que inicie el procedimiento de proxificación reversa de los sockets protegidos ya accesibles.
Ejemplo 9: Proxificación de sockets protegidos desde un dispositivo AF hacia un dispositivo A de forma reversa a instancias del agente AF del dispositivo AF:
Este ejemplo 9 está muy vinculado con el ejemplo anterior, el 8. En dicho ejemplo, un dispositivo_A a instancias de un proceso_A inicia el establecimiento de proxificaciones reversas hacia un dispositivo_AF. En el presente ejemplo, se muestra lo que ocurre en ese dispositivo_AF, en el que de nuevo, y en aras de conservar la coherencia descriptiva, ese dispositivo_AF será referido como dispositivo_A y viceversa.
Por consiguiente, el servidor proxy-firewall del dispositivo_A recibe una solicitud de establecimiento de sesión de un dispositivo_AF que utiliza un perfil_UAAF por la que se solicita la realización de una proxificación reversa de determinados sockets protegidos del dispositivo_AF hacia el dispositivo_A. Esta solicitud fuerza al servidor proxy-firewall a instanciarse como fork_AAF en la cuenta de usuario_AAF del dispositivo_A cuyas credenciales utilizó el agente_AF del dispositivo_AF para conectarse en el dispositivo_A. El fork_AAF requiere solicitar al connection-broker la reserva de sockets protegidos locales en el dispositivo_A para poder realizar la proxificación reversa.
Este procedimiento es similar al seguido en el ejemplo 1 por el dispositivo_A en el que el dispositivo_A debe reservar unos sockets locales para las proxificaciones reversas que solicita realizar el dispositivo_B. La principal diferencia, es que estos sockets locales protegidos resultado de la proxificación son nuevos y no existen permisos relativos en la base de datos que den acceso a ellos de algún modo. Por ello, el connection-broker, además de reservar esos sockets, debe insertar registros_socket y permisos_Au por cada socket-proxy reverso que habiliten al usuario_AAF del dispositivo_A de acceso a cada socket resultado de la proxificación de forma similar a como se realiza en el ejemplo 6 (607), (609), (61 1) y (612). Esta reserva, no obstante, se realiza únicamente para socket-proxies reversos.
Una vez reservados los sockets e insertados los permisos correspondientes, se deben generar las reglas de marcado pertinentes e insertarlas en el sistema para que el usuario_AAF tenga acceso a esos sockets protegidos. El servidor proxy-firewall instancia un monitor de accesos para garantizar que los registros_acceso relativos a cada proxificación mantengan una inactividad baja que impida su cierre automático mientras el proceso_A siga en ejecución. El servidor proxy-firewall, al estar instanciado desde la cuenta del usuario_AAF, forma parte del contexto de seguridad configurado al insertar las reglas de marcado y, por tanto, esta instancia dispone de acceso a los sockets protegidos reservados en este ejemplo para la proxificación reversa. Una vez terminadas estas acciones, el servidor proxy-firewall procede con la proxificación reversa solicitada por el agente_AF utilizando los sockets reservados para ello.
Ejemplo 10: Actualización remota de elementos software:
Una de las principales ventajas de la presente invención es el desacoplo de las funcionalidades de seguridad de las aplicaciones de los dispositivos_B y su correspondiente simplificación en su diseño y mantenimiento. En los dispositivos_A, los procesos que hacen uso del sistema propuesto por la invención, no requieren tampoco de frameworks de seguridad, pero sí deben incorporar en su programación el método descrito en este documento para poder comunicarse con los sockets protegidos. No obstante, la interfaz de comunicación se basa en llamadas al sistema y mareaje de paquetes, por lo que es independiente de los protocolos de seguridad y, por consiguiente, es factible actualizar en el dispositivo_A el sistema descrito en la presente invención también sin afectar a las aplicaciones del dispositivo_A.
En dispositivos_A y dispositivos_B similares a los propuestos en la realización preferente de la invención, es posible actualizar el agente del dispositivo_B desde el dispositivo_A sin afectar al resto del software. Para ello, es necesario que el dispositivo_B cuente con una versión simplificada del proxy-firewall que disponga del servidor proxy stand-alone y de una configuración adecuada en el perfil_BA que permita al dispositivo_A utilizar un socket-proxy reverso para actualizar el agente del dispositivo_B. Esta estrategia puede generalizarse para proporcionar servicios de actualización a otros elementos software ajenos al sistema descrito por la invención. En el caso particular de la actualización del cliente proxy stand-alone, el proceso comprende:
• Solicitar, a través de la sesión de comunicaciones establecida entre el agente_B y el servidor proxy-firewall el inicio de un procedimiento de la actualización del cliente proxy stand-alone del agente_B por iniciativa del servidor proxy-firewall.
• Recibir, por parte del agente_B, la nueva versión del cliente proxy y actualizar el perfil_BA.
• Probar, por parte del agente_B, la nueva versión del cliente proxy con el perfil_BA actualizado estableciendo una nueva sesión de comunicaciones.
• En caso de establecerse correctamente esta nueva sesión, eliminar la versión anterior del cliente proxy y reemplazarlo con la nueva versión.

Claims

REIVINDICACIONES
[Reivindicación 1] Un método de comunicación segura por proxificación de sockets de red que comprende:
• establecer una sesión (110) de comunicaciones seguras que permita efectuar proxificaciones de sockets entre dos dispositivos denominados “dispositivo_A” (106) y “dispositivo_B” (101), donde el primero utilice para ello un servidor proxy-firewall (111) que albergue y el segundo utilice un agente del servidor proxy-firewall denominado“agente_B” (109) que inicie el establecimiento de dicha sesión, empleando un cliente proxy stand-alone (112) que implemente un protocolo de comunicación segura usando unos datos de configuración y credenciales de una cuenta de usuario denominada“usuario_AB” definidos por un perfil de configuración del dispositivo_B denominado“perfil_BA” que le permiten conectarse a la cuenta del usuario_A del dispositivo_A;
• establecer unas proxificaciones denominadas“proxificaciones directas” (114) si estas se producen desde los sockets de aplicaciones que se encuentran escuchando en el dispositivo_A, como lo son los denominados“socket_A” (123), y según se describa en el perfil_BA;
• establecer unas proxificaciones denominadas“proxificaciones reversas” (115) si estas se producen desde los sockets de las aplicaciones que se encuentran escuchando en el dispositivo_B denominados“socket_B” (118) y según se describa en el perfil_BA;
• proteger a instancias del servidor proxy-firewall del dispositivo_A las comunicaciones de los sockets_A y las proxificaciones reversas en el dispositivo_A mediante la configuración de contextos de seguridad configurados con reglas de marcado y filtrado de paquetes de red de esas comunicaciones locales, utilizando como parámetro delimitador del contexto el usuario del proceso del sistema operativo del dispositivo_A origen de cada comunicación local; y
• proteger a instancias del agente del dispositivo_B las comunicaciones de los sockets_B y las proxificaciones directas en el dispositivo_B mediante la configuración de contextos de seguridad configurados con reglas de marcado y filtrado de paquetes de red de esas comunicaciones locales, utilizando como parámetro delimitador de dichos contextos el usuario del proceso del sistema operativo del dispositivo_B origen de cada comunicación local.
[Reivindicación 2] El método según la reivindicación 1 , donde se establecen unos contextos de seguridad para las proxificaciones directas y las reversas, además comprende: • registrar las proxificaciones reversas en una base de datos (122) de un connection-broker (121) del dispositivo_A como un registro denominado“registro_socket” donde se guarda la información relativa de cada proxificación reversa que comprende:
o una variable denominada“id_DispSocket” que almacena el id de dispositivo con el socket a proxificar, y que según esta reivindicación correspondería con el id del dispositivo_B denominado“id_B”;
o una variable denominada “id_DispProxy”, que identifica el dispositivo con el que mantiene la sesión que habilita el socket protegido al que hace referencia este registro_socket, y que según esta reivindicación correspondería con el id_B;
o una variable denominada“alias”, que en esta reivindicación guardaría el alias del socket a proxificar del id_DispSocket;
o una variable denominada“socket” que según esta reivindicación guardaría el socket local libre, reservado por el sistema operativo del dispositivo_A para la proxificación y que dispone de un valor de dirección de red perteneciente a un pool de direcciones de red locales del dispositivo_A reservadas para este método; y
o una variable denominada“tipo_socket” que determina la clase de socket a la que hace referencia este registro, y que según esta reivindicación sería“socket_B”;
• el ingreso, durante la secuencia de arranque del sistema operativo del dispositivo_A, de una regla general de marcado de paquetes a través de su framework de red (107) por parte del servidor proxy-firewall que determine eliminar cualquier posible marcado de paquetes de red en cualquier comunicación, producida entre sockets locales del dispositivo_A, con direcciones locales pertenecientes al pool de direcciones locales reservado para este método;
• el ingreso, durante la secuencia de arranque del sistema operativo del dispositivo_A, de una regla general de filtrado de paquetes por parte del servidor proxy-firewall que determine descartar cualquier paquete con origen y destino un socket local del dispositivo_A que carezca de un marcado, siempre y cuando alguno de los sockets utilice una dirección de red local perteneciente al pool de direcciones locales reservado para este método;
• el ingreso, durante la secuencia de arranque del sistema operativo (102) del dispositivo_B y a través del framework de red de este último, de una regla general de filtrado por cada socket_B y proxificación directa en el dispositivo_B que determine el descarte de paquetes entrantes con ese destino y con origen una dirección de red no local;
• el ingreso, durante la secuencia de arranque del sistema operativo del dispositivo_A y a través de un framework de red (107) de este último, de una regla general de filtrado de paquetes por parte del servidor proxy-firewall que determine descartar cualquier paquete con origen o destino una dirección local del pool de direcciones locales reservado para este método que tenga como origen o destino una dirección no local; • el ingreso, si no existe, durante la secuencia de arranque del sistema operativo del dispositivo_A, de un registro_socket en la base de datos del dispositivo_A relativo a cada socket_A del dispositivo_A recogido en el perfil de configuración denominado“perfi l_A”, conteniendo cada registro_socket información que comprende:
o el id_DispSocket, que en esta reivindicación sería igual al id del dispositivo_A denominado“id_A”;
o el id_DispProxy, que en esta reivindicación sería también igual al id_A;
o el alias, que en esta reivindicación sería igual al empleado por el socket_A a registrar; o el socket, que en esta reivindicación sería igual al es igual al socket local utilizado por el proceso_A para el socket_A definido en el perfil_A; y
o el tipo_socket, que en esta reivindicación sería igual a“socket_A”;
• el ingreso, si no existe, durante la secuencia de arranque del sistema operativo del dispositivo_A, de al menos un registro denominado“registro_acceso_A” en la base de datos del dispositivo_A relativo a cada socket_A del dispositivo_A recogido en el perfi l_A, conteniendo cada registro_acceso_A información que comprende:
o una variable denominada“conjd” que almacena el identificador del acceso con el mismo nombre,
o una variable denominada“socket” que almacena el socket_A, y
o una variable denominada “id_Grupo” que almacena el id del grupo del usuario del sistema operativo del dispositivo_A correspondiente al usuario_A del proceso_A origen de la petición de comunicación al que se le ha concedido acceso;
• el ingreso, durante la secuencia de arranque del sistema operativo del dispositivo_A, a través del connection-broker (121), a instancias del servidor proxy-firewall y según la configuración marcada en el perfi l_A, de unos permisos_Ac en la base de datos (122) que comprenden: o el id_Grupo, que almacena el id del grupo de usuarios del sistema operativo del dispositivo_A al que se otorga el permiso de acceso;
o el alias, que almacena el alias del socket_A;
o el socket, que almacena el valor del socket_A;
• el ingreso, durante la secuencia de arranque del sistema operativo del dispositivo_A, a través del framework de red (107) y a instancias del servidor proxy-firewall de unas reglas de marcado prioritarias sobre las generales y que son respectivas a los permisos_Ac registrados en esta reivindicación para cada socket_A para conceder accesos permanentemente a los grupos de usuarios del dispositivo_A relativos a los anteriores permisos según se defina en el perfi l_A; y
• la supresión, durante la secuencia de arranque del sistema operativo del dispositivo_A, de cada registro_acceso, de sus permisos respectivos de la base de datos relativos a los registros_socket cuyo tipo_socket sea “socket-proxy” y la supresión del propio registro_socket.
[Reivindicación 3] El método según las reivindicaciones anteriores, donde se establece una comunicación segura entre sockets de red, en la que un recurso de red que es ofrecido por el socket_B de un proceso denominado“proceso_B” (118) del dispositivo_B es solicitado por un proceso denominado“proceso_A” (302) de un usuario denominado“usuario_A” del sistema operativo del dispositivo_A y cuyo recurso es accesible a través de un socket-proxy reverso (301), además comprende:
• solicitar (305) por parte del proceso_A al servidor proxy-firewall mediante una llamada al sistema la resolución del socket protegido a partir del id_B y del alias del socket_B para obtener el socket-proxy reverso local por el que poder acceder al socket_B;
• solicitar (307) al connection-broker de parte del servidor proxy-firewall la comprobación de existencia de un permiso de acceso del usuario_A denominado“permiso_Au” que lo habilite para acceder al socket-proxy reverso requerido, la solicitud de resolución del socket-proxy reverso y la concesión de un acceso al socket-proxy reverso denominado“registro_acceso”;
• comprobar (308) por parte del connection-broker en la base de datos la existencia del permiso_Au y realizar la resolución del socket-proxy reverso;
• generar (311) el registro_acceso, si aún no existe en la base de datos, en el que se asigna por parte del connection-broker un identificador de acceso de comunicación al socket-proxy reverso denominado“conjd” relativo al usuario_A y al socket protegido;
• guardar (312), o actualizar si procede, en la base de datos por parte de connection-broker el registro_acceso generado, el cual comprende:
o el conjd relativo del acceso concedido,
o el socket al que se concede el acceso y que está formado por la dirección de red local y el puerto,
o una variable denominada“id_Usuario” que almacena el id del usuario del sistema operativo del dispositivo_A correspondiente al usuario_A del proceso_A origen de la petición de comunicación al que se le ha concedido acceso; y
o una variable denominada“última_actividad” que guarda el momento en el que se le ha concedido el acceso que se actualizará por un monitor de accesos reflejando su estatus de actividad;
• habilitar (315) una regla específica prioritaria sobre las reglas generales de marcado de paquetes para el sistema operativo del dispositivo_A por parte del servidor proxy-firewall, que determine que a todos paquetes de comunicaciones locales entre el usuario_A que ejecuta el proceso_A y el socket-proxy reverso, se les incluya el identificador del acceso asignado conjd definido en el registro_acceso correspondiente al socket-proxy reverso y al usuario_A; • instanciar (318) por parte del servidor proxy-firewall un monitor de accesos que verifique si hay tráfico por el acceso hacia el socket-proxy reverso periódicamente y actualice el valor de última_actividad; y
• proceder con la comunicación (320) entre proceso_A y el socket_B que ofrece el recurso a través del socket-proxy reverso existente en el dispositivo_A;
[Reivindicación 4] El método según las reivindicaciones anteriores, donde el proceso_A del usuario_A en el dispositivo_A solicita la proxificación de forma directa en el dispositivo_A de varios sockets protegidos de un dispositivo_A foráneo denominado“dispositivo_AF”, además comprende:
• solicitar (606) por parte del proceso_A al servidor proxy-firewall una resolución de las proxificaciones directas a realizar, requiriendo una respuesta con los sockets locales asignados;
• solicitar (607) al connection-broker por parte del servidor proxy-firewall una reserva de sockets locales sin usar para utilizarlos como socket-proxies directos, una vez se resuelvan los sockets protegidos del dispositivo_AF que se requieren proxificar de forma directa por medio del agente_A;
• registrar (609) en la base de datos, por parte del connection-broker, los permisos_Au y registros_acceso pertinentes que permitan al usuario_A acceder a los socket-proxies directos;
• registrar (609) en la base de datos cada registro_socket generado por cada reserva de socket a proxificar de forma directa, y el cual comprende:
o el id_DispSocket, que en esta reivindicación guardaría el id del dispositivo del socket protegido correspondiente y que conoce el proceso_A;
o el id_DispProxy, que en esta reivindicación guardaría el id del dispositivo_AF denominado“id_AF”;
o el alias, que en esta reivindicación guardaría el alias del socket que el proceso_A desea proxificar y que también conoce el proceso_A;
o el socket, que en esta reivindicación guardaría el socket local libre que queda asignado para realizar cada proxificación directa y que dispone de un valor de dirección de red perteneciente al pool de direcciones de red locales del dispositivo_A reservados para este método; y
o el tipo_socket, que en esta reivindicación sería igual a‘socket_proxy’;
• solicitar (613) al agente_A el establecimiento de una sesión de comunicaciones con el dispositivo_AF utilizando unas credenciales de acceso al dispositivo_AF del usuario_A provistas por el servidor proxy-firewall, sesión a través de la cual se realice la resolución de los sockets protegidos del dispositivo_AF a proxificar de forma directa en el dispositivo_A; • solicitar (614) al dispositivo_AF a través de la sesión establecida en esta reivindicación la resolución y el establecimiento de los accesos para los sockets protegidos requeridos del dispositivo_AF indicados en la solicitud;
• establecer (618) por parte del servidor proxy-firewall la regla de marcado pertinente a cada permiso_Au por medio del framework de red que permitan al usuario_A acceder a los socket-proxies directos;
• solicitar el establecimiento de cada proxificación directa (604) en el dispositivo_A hacia cada socket protegido correspondiente del dispositivo_AF tal y como requiere el proceso_A;
• responder (620) al proceso_A por parte del servidor proxy-firewall con la resolución de sockets solicitada; y
• instanciar, por parte del servidor proxy-firewall, un monitor de accesos (621) que actualice periódicamente el valor última_actividad de cada registro_acceso insertado en la base de datos en esta reivindicación.
[Reivindicación 5] El método según las reivindicaciones anteriores, donde varios sockets protegidos del dispositivo_A son a su vez proxificados de forma directa hacia un dispositivo_AF por un agente del dispositivo_AF denominado“agente_AF” usando unos datos de configuración y credenciales de una cuenta de usuario denominada“usuario_AAF” definidos por un perfil de configuración del dispositivo_A denominado“perfil_UAAF” que le permiten a dicho agente_AF conectarse a la cuenta del usuario_AAF del dispositivo_A, además comprende:
• establecer una sesión segura entre el agente_AF y el servidor proxy-firewall del dispositivo_A por iniciativa del agente_AF;
• solicitar en el establecimiento de dicha sesión una resolución de cada socket protegido del dispositivo_A que sea requerido por el agente_AF;
• instanciar un fork del servidor proxy-firewall en la cuenta usuario_AAF denominado“fork_AAF”;
• solicitar al connection-broker por parte del fork_AAF una resolución de los sockets protegidos a partir del alias y del id_A de cada socket_A, y del alias y del id_B de cada socket_B indicados por el agente_AF;
• verificar por parte del connection-broker del dispositivo_A la existencia de permisos suficientes para el usuario_AAF en la base de datos para poder acceder a los sockets protegidos;
• solicitar al connection-broker por parte del fork_AAF un acceso de comunicación por cada socket protegido para la cuenta del usuario_AAF del sistema operativo del dispositivo_A para todos aquellos sockets protegidos requeridos por el agente_AF con los que el usuario_AAF aún no cuente con acceso;
• registrar cada registro_acceso de cada acceso concedido en la base de datos del connection-broker; • establecer por parte del fork_AAF la regla de marcado relativa a cada registro_acceso por medio del framework de red del sistema operativo del dispositivo_A que permitan al usuario_AF acceder a cada socket protegido;
• responder al agente_AF con el valor de cada socket protegido requerido para que posteriormente, el agente_AF pueda efectuar las proxificaciones directas; e
• instanciar un monitor de accesos por parte del fork_AAF para actualizar periódicamente el valor última_actividad de cada registro_acceso insertado en la base de datos en esta reivindicación.
[Reivindicación 6] El método según las reivindicaciones 1-3, donde varios sockets protegidos del dispositivo_A son proxificados de forma reversa en el dispositivo_AF por requerimiento del proceso_A del usuario_A del dispositivo_A a través del agente_A, además comprende:
• solicitar por parte del proceso_A al servidor proxy-firewall la realización de una proxificación reversa de unos sockets locales protegidos a los que tiene acceso;
• solicitar al connection-broker la resolución de los sockets locales requeridos en la proxificación solicitada por el proceso_A;
• comprobar, por parte del connection-broker, si el usuario_A dispone de los permisos necesarios para acceder a los sockets locales protegidos requeridos en la solicitud de proxificación;
• insertar en la base de datos, por parte del connection-broker, unos accesos de comunicación a los sockets protegidos para la cuenta del usuario_A por todos aquellos sockets protegidos con los que aún no cuente con un acceso;
• registrar los accesos de comunicación en la base de datos del connection-broker como registro_accesos;
• establecer, por parte del servidor proxy-firewall, la regla de marcado pertinente a cada registro_acceso insertado en la base de datos en esta reivindicación que permita al usuario_A acceder a todos los sockets fuente de las proxificaciones reversas;
• solicitar al agente_A, por parte del servidor proxy-firewall, el establecimiento de una sesión de comunicaciones con el dispositivo_AF utilizando unas credenciales de acceso al dispositivo_AF del proceso_A provistas por el servidor proxy-firewall;
• solicitar, por parte del agente_A en el establecimiento de dicha sesión, una reserva de un socket protegido del dispositivo_AF por cada socket a proxificar de forma reversa hacia ese dispositivo;
• instanciar, por parte del servidor proxy-firewall, un monitor de accesos para actualizar periódicamente el valor última_actividad de todos los registros_acceso del usuario_A necesarios en este método; y • enviar al dispositivo_AF por parte del agente_A la solicitud de establecimiento de las proxificaciones reversas.
[Reivindicación 7] El método según las reivindicaciones 1-3 y 6 donde varios sockets protegidos del dispositivo_AF son proxificados de forma reversa en el dispositivo_A por acción del agente_AF usando unos datos de configuración y credenciales de una cuenta“usuario_AAF” definidos por un “perfil_UAAF” que le permiten conectarse a la cuenta del usuario_AAF del dispositivo_A, además comprende:
• establecer una sesión segura entre el agente_AF y el servidor proxy-firewall del dispositivo_A por iniciativa del agente_AF;
• solicitar en el establecimiento de dicha sesión la reserva de sockets locales protegidos del dispositivo_A para la realización de una proxificación reversa en el dispositivo_A de sockets del dispositivo_AF;
• instanciar un fork_AAF del servidor proxy-firewall en la cuenta de usuario_AAF;
• solicitar al connection-broker, por parte del fork_AAF, una reserva de sockets locales sin usar para utilizarlos como los socket-proxies reversos indicados en la solicitud recibida;
• registrar en la base de datos, por parte del connection-broker, los registros_socket y registros_acceso relativos a los sockets reservados para cada proxificación reversa;
• agregar, por parte del connection-broker, un permiso_Au a la base de datos por cada socket reservado para el usuario_AAF;
• insertar en el sistema, por parte del fork_AAF, una regla de marcado por cada permiso_Au por medio del framework de red;
• instanciar, por parte del fork_AAF, un monitor de accesos para mantener los accesos activos relativos a la proxificación reversa; y
• establecer las proxificaciones reversas, por parte del fork_AAF, empleando los sockets reservados.
[Reivindicación 8] El método según las reivindicaciones 3-7, además comprende la actualización de la variable última_actividad a instancias del monitor de accesos en cada registro_acceso involucrado en el método en diferentes escenarios:
• si el registro_acceso se crea según la reivindicación 3, la variable última_actividad del registro_acceso se actualizará a instancias del monitor de accesos instanciado por el servidor proxy-firewall siempre que haya tráfico de la cuenta del usuario_A hacia el socket- proxy; y
• si el registro_acceso se crea según la reivindicación 4,5,6 o 7, la variable última_actividad de cada registro_acceso se actualizará a instancias del monitor de accesos instanciado por el servidor proxy-firewall siempre que se mantenga en ejecución el proceso que solicitó la proxificación que causó la creación de cada registro_acceso en la base de datos.
[Reivindicación 9] El método de las reivindicaciones 1-3, donde un proceso denominado “proceso_C” de un dispositivo denominado“dispositivo_C” cursa una petición segura del recurso ofrecido por el socket_B del dispositivo_B a un proxy ejecutado por el usuario_A, además comprende:
• La utilización de subdominios de red del dominio principal del proxy como parámetros de la petición que requiere el proxy para poder solicitar la resolución del socket protegido por medio del connection-broker;
• un certificado wildcard X.509 configurado adecuadamente para ofrecer seguridad a los subdominios del proxy;
• recibir las credenciales del proceso_C en los encabezados de la petición que permiten al proxy verificar la identidad del proceso_C y comprobar si dispone del permiso_Au requerido para cursar la petición;
• establecer una comunicación segura entre el proceso_C y el proxy empleando un protocolo de comunicaciones seguro conocido por el proceso_C y el proxy;
• suprimir los encabezados de la petición; y
• establecer una comunicación entre el proxy y el socket protegido que comunique con el socket_B según la reivindicación 3.
[Reivindicación 10] El método según las reivindicaciones 3-9, donde se cierra el acceso de comunicación relativo al registro_acceso cuando la inactividad supera un umbral denominado “umbraljnactividad” en el perfil_A, además comprende:
• eliminación de la regla de marcado del sistema operativo del dispositivo_A relativa al registro_acceso;
• eliminación del registro_acceso de la base de datos del connection-broker del dispositivo_A; y
• eliminación del permiso_Au relativo al registro_acceso en caso de que éste sea relativo a un socket-proxy directo.
[Reivindicación 11] El método según la reivindicación 3, donde se requiere actualizar la seguridad en las comunicaciones entre el cliente proxy stand-alone y el servidor proxy stand-alone, además comprende:
• solicitar, a través de la sesión de comunicaciones establecida entre el agente_B y el servidor proxy-firewall, el inicio de un procedimiento de la actualización del cliente proxy del agente_B por iniciativa del servidor proxy-firewall;
• recibir, por parte del agente_B, la nueva versión del cliente proxy y actualizar el perfil_BA; • probar, por parte del agente_B, la nueva versión del cliente proxy con el perfil_BA actualizado estableciendo una nueva sesión de comunicaciones; y
• en caso de establecerse correctamente esta nueva sesión, eliminar la versión anterior del cliente proxy y reemplazarlo con la nueva versión.
[Reivindicación 12] Un sistema para comunicar de forma segura sockets de red que comprende:
• un módulo software denominado “servidor proxy-firewall” albergado en un dispositivo denominado“dispositivo_A” y que está configurado para:
o recibir las solicitudes de establecimiento de sesión de otros dispositivos a través de un protocolo seguro por medio de un servidor proxy stand-alone,
o configurar contextos de seguridad estrictos y amplios mediante llamadas al sistema al framework de red del sistema operativo del dispositivo_A,
o procesar solicitudes de proxificación o“socket-proxy” a través de sesiones establecidas o de llamadas al sistema de procesos locales,
o monitorizar los accesos a sockets locales mediante monitores de acceso,
o gestionar las actualizaciones de seguridad de los dispositivos con los que mantenga una conexión, y
o establecer, mediante llamadas al sistema hacia el framework de red, la protección de los sockets locales utilizados en las proxificaciones en el dispositivo_A;
• un tipo de perfil de configuración del servidor proxy-firewall para definir los aspectos relativos al funcionamiento del servidor proxy-firewall y al connection-broker denominado“perfi l_A”;
• un módulo software, que funciona como agente del servidor proxy-firewall, configurado para:
o iniciar las solicitudes de establecimiento de sesión hacia el servidor proxy-firewall a través de un módulo software denominado“cliente proxy stand-alone” y que implementa un protocolo seguro,
o realizar solicitudes de proxificación de sockets de forma directa y reversa, y
o establecer la protección de los sockets locales;
siendo este software denominado como:
o agente_A, si se encuentra en un dispositivo_A;
o agente_AF, si se encuentra en un dispositivo_A foráneo denominado a si vez dispositivo_AF;
o agente_B, si se encuentra en un dispositivo denominado“dispositivo_B”;
• un tipo de perfil de configuración del agente denominado:
o perfi I_BA, si el perfil es para configurar la sesión que el agente del dispositivo_B realiza en el dispositivo_A o
o perfil_UAAF, si el perfil es para configurar la sesión que el agente del dispositivo_A realiza con el dispositivo_AF a instancias del usuario_A; • un módulo software denominado“monitor de accesos” empleado para mantener un registro y control sobre las proxificaciones realizadas y los accesos a las mismas en el dispositivo_A;
• un tipo de registro del dispositivo_A denominado“registro_socket” relativo a un socket protegido y el cual comprende:
o una variable denominada“socket” que guarda el socket protegido al que hace referencia el presente registro_socket y que puede ser de tres tipos:
- socket_B, si el socket a registrar es un socket-proxy que ofrece un recurso de un dispositivo_B;
- socket_A, si el socket a registrar ofrece un recurso de un proceso del propio dispositivo_A y no es resultado de ningún tipo de proxificación;
- socket-proxy;
o una variable denominada“alias” que guarda el alias del socket protegido, el cual puede ser de dos tipos:
- el alias de un socket_B denominado“alias_B”, y
- el alias de un socket_A denominado“alias_A”;
o una variable denominada“id_DispSocket” que guarda el id del dispositivo que tiene el socket local protegido y que puede ser de tres tipos:
- el id de un dispositivo_B denominado“id_B” si el registro_socket es de tipo socket_B,
- el id de un dispositivo_AF denominado“id_AF” si el registro_socket es de tipo socket-proxy, y
- el id de un dispositivo_A denominado “id_A” si el registro_socket es de tipo socket_A;
o una variable denominada“id_DispProxy” que identifica el id del dispositivo al que conduce el socket protegido; y
o una variable denominada“tipo_socket” que determina el tipo de socket protegido al que hace referencia este registro pudiendo encontrarse entre: socket_A, socket_B y socket-proxy.
• un tipo de registro denominado“registro_acceso” de un usuario del sistema operativo del dispositivo_A generado por cada acceso concedido a un socket protegido de tipo socket- proxy directo o reverso, el cual comprende:
o una variable denominada “conjd” que guarda el identificador del acceso de comunicación al socket-proxy de un usuario_A,
o una variable denominada“socket” que almacena el socket protegido al que se concede el acceso que está formado por la dirección de red local y el puerto,
o una variable denominada“id_Usuario” que almacena el identificador del usuario_A del proceso_A origen de la petición de comunicación al que se le ha concedido acceso, y o una variable denominada“última_actividad” que guarda el momento en el que se le ha concedido el acceso y que se actualizará por un monitor de accesos reflejando su estatus de actividad;
• un tipo de registro denominado“registro_acceso_A” de un grupo de usuarios del sistema operativo del dispositivo_A generado por cada acceso concedido a un socket protegido de tipo socket_A, el cual comprende:
o una variable denominada“conjd” que almacena el identificador del acceso con el mismo nombre,
o una variable denominada“socket” que almacena el socket_A, y
o una variable denominada“id_Grupo” que almacena el id del grupo del usuario del sistema operativo del dispositivo_A correspondiente al usuario_A del proceso_A origen de la petición de comunicación al que se le ha concedido acceso;
• un tipo de registro para definir el permiso de acceso denominado“permiso_Au”, que define un contexto de seguridad estricto al otorgar al usuario_A del dispositivo_A la posibilidad de acceder a un socket protegido de tipo socket-proxy directo o reverso, el cual comprende: o una variable denominada“id_Usuario” que guarda el id del usuario_A del sistema operativo del dispositivo_A,
o una variable denominada“alias” que almacena el alias del socket protegido de otro dispositivo que se proxifica como socket-proxy en el dispositivo_A, y
o una variable denominada“id_DispSocket” que almacena el id del dispositivo con el socket_B o socket_A relativo al alias del socket que ofrece el recurso a través del socket-proxy;
• un tipo de registro para definir el permiso de acceso denominado“permiso_AG” que define un contexto de seguridad amplio al otorgar la posibilidad de acceso de un grupo de usuarios del dispositivo_A a un socket_A y que comprende:
o una variable denominada“id_Grupo” que almacena el id del grupo de usuarios del sistema operativo del dispositivo_A,
o una variable denominada“alias” que almacena el alias del socket_A, y
o una variable denominada“socket” que guarda el valor del socket_A;
• un módulo software denominado connection-broker empleado para mantener un registro y control sobre las proxificaciones realizadas y los accesos a las mismas en el dispositivo_A pudiendo cerrarlas si se encuentran inactivas;
• un pool de direcciones locales del dispositivo_A reservadas específicamente para este sistema y que son protegidas al arrancar el sistema operativo del dispositivo_A por el framework de red a instancias del servidor proxy-firewall por medio de las siguientes reglas generales:
o una regla general de marcado de paquetes que determine eliminar cualquier posible marcado de paquetes de red en cualquier comunicación, producida entre sockets locales del dispositivo_A, con direcciones locales pertenecientes al pool de direcciones locales reservado;
o una regla general de filtrado de paquetes que determine descartar cualquier paquete con origen y destino un socket local del dispositivo_A que carezca de un marcado, siempre y cuando alguno de los sockets utilice una dirección de red local perteneciente al pool de direcciones locales reservado; y
o una regla general de filtrado de paquetes que determine descartar cualquier paquete con origen o destino una dirección local del pool de direcciones locales reservado para este método que tenga como origen o destino una dirección no local;
• un tipo de contexto de seguridad denominado“contexto de seguridad estricto” llevado a cabo por una configuración del framework de red que realiza un marcado en los paquetes del tráfico utilizando el conjd asignado en el registro_acceso relativo al socket protegido destino del dispositivo_A, el usuario origen de la comunicación también del dispositivo_A y el permiso_Au que habilita el registro_acceso;
• un tipo de contexto de seguridad denominado“contexto de seguridad amplio” llevado a cabo por una configuración del framework de red que realiza un marcado en los paquetes del tráfico utilizando el conjd asignado en el registro_acceso relativo al socket protegido destino del dispositivo_A, y el grupo del usuario origen de la comunicación también del dispositivo_A y el permiso_Ac que habilita el acceso; y
• una base de datos del connection-broker configurada para almacenar distintos tipos de registros que comprenden: registro_socket, registro_acceso, registro_acceso_A, permiso_Au y permiso_AG.
[Reivindicación 13] El sistema de la reivindicación 12, en donde los dispositivos utilizan un sistema operativo de tipo POSIX, además emplea un cliente proxy y un servidor proxy stand-alone basado en el protocolo seguro SSH y donde Netfilter, el framework de red utilizado, realiza el marcado y filtrado de paquetes utilizando el campo TOS del protocolo IP.
[Reivindicación 14] El sistema de la reivindicación 12 y 13, en donde un dispositivo_B también dispone de un servidor proxy-firewall que permite incluir en el perfil_BA aspectos de configuración que extienden el control que dispone el servidor proxy-firewall del dispositivo_A sobre todos los módulos software del dispositivo_B para facilitar el desarrollo de servicios que impliquen llamadas al sistema, como es la actualización de módulos software del dispositivo_B.
[Reivindicación 15] El sistema de las reivindicaciones 12 y 13, en el que el socket_B del dispositivo_B ofrece un recurso utilizando el protocolo HTTP y el dispositivo_A utiliza un proxy como módulo software de tipo HTTPS-HTTP para poder aceptar y procesar las solicitudes externas de comunicación hacia el socket protegido que se cursen en HTTPS, además comprende:
• la configuración de un certificado SSL wildcard para proteger el dominio principal del proxy HTTPS-HTTP del dispositivo_A y todos sus subdominios posibles;
« la configuración de un servidor web en el dispositivo_A para poder redirigir la petición de comunicación del recurso del socket_B de forma transparente a la URL principal del proxy HTTPS-HTTP aprovechando los subdominios como campos para identificar el socket-proxy destino de dicha petición y utilizando como subdominios el alias del socket_B y el identificador del dispositivo_B; y
· una configuración adecuada del proxy HTTPS-HTTP que permita obtener de los encabezados de la petición las credenciales requeridas para validarla y eliminarlos de la misma antes de transmitirla hacia el socket-proxy.
PCT/MX2018/050013 2018-06-03 2018-06-03 Método y sistema de comunicación segura por proxificación de sockets de red Ceased WO2019059754A1 (es)

Priority Applications (5)

Application Number Priority Date Filing Date Title
MX2020012311A MX2020012311A (es) 2018-06-03 2018-06-03 Metodo y sistema de comunicacion segura por proxificacion de sockets de red.
EP18857521.1A EP3800564B1 (en) 2018-06-03 2018-06-03 Secure communication method and system using network socket proxying
PCT/MX2018/050013 WO2019059754A1 (es) 2018-06-03 2018-06-03 Método y sistema de comunicación segura por proxificación de sockets de red
US15/734,167 US11050716B1 (en) 2018-06-03 2018-06-03 Secure communication method and system using network socket proxying
ES201990044A ES2794723B2 (es) 2018-06-03 2018-06-03 Metodo y sistema de comunicacion segura por proxificacion de sockets de red

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/MX2018/050013 WO2019059754A1 (es) 2018-06-03 2018-06-03 Método y sistema de comunicación segura por proxificación de sockets de red

Publications (2)

Publication Number Publication Date
WO2019059754A1 WO2019059754A1 (es) 2019-03-28
WO2019059754A9 true WO2019059754A9 (es) 2020-05-22

Family

ID=65811486

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/MX2018/050013 Ceased WO2019059754A1 (es) 2018-06-03 2018-06-03 Método y sistema de comunicación segura por proxificación de sockets de red

Country Status (5)

Country Link
US (1) US11050716B1 (es)
EP (1) EP3800564B1 (es)
ES (1) ES2794723B2 (es)
MX (1) MX2020012311A (es)
WO (1) WO2019059754A1 (es)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3086821A1 (fr) * 2018-09-28 2020-04-03 Orange Procedes de collaboration et de demande de collaboration entre services de protection associes a au moins un domaine, agents et programme d’ordinateur correspondants.
EP4420300B1 (en) 2021-10-18 2025-05-07 Sophos Limited Network appliances for secure enterprise resources
US11373000B1 (en) 2021-10-22 2022-06-28 Akoya LLC Systems and methods for managing tokens and filtering data to control data access
US11641357B1 (en) 2021-10-22 2023-05-02 Akoya LLC Systems and methods for managing tokens and filtering data to control data access
WO2023069624A1 (en) * 2021-10-22 2023-04-27 Akoya LLC Systems and methods for managing tokens and filtering data to control data access
US20240031334A1 (en) * 2022-07-19 2024-01-25 Vmware, Inc. Identity firewall with context information tracking
CN115914340B (zh) * 2022-11-04 2025-05-02 山东云海国创云计算装备产业创新中心有限公司 一种bmc通信方法、系统、设备以及存储介质
CN115623079B (zh) * 2022-12-19 2023-06-02 中科政汇(北京)科技有限公司 一种数据访问处理方法
US20250124092A1 (en) * 2023-10-17 2025-04-17 MOLAR SOLUTIONS, INC. d/b/a COUNTER HEALTH Systems and methods for querying databases of claims
CN117914935B (zh) * 2024-03-05 2024-05-28 北京长亭科技有限公司 一种基于重路由技术的隐蔽通信方法及系统
CN118449783B (zh) * 2024-07-05 2024-10-29 支付宝(杭州)信息技术有限公司 一种账户操作控制方法、装置、介质及设备

Family Cites Families (5)

* 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
US9350644B2 (en) * 2012-04-13 2016-05-24 Zscaler. Inc. Secure and lightweight traffic forwarding systems and methods to cloud based network security systems
EP3094283A4 (en) 2013-12-20 2018-01-24 Biomet 3i, LLC Dental system for developing custom prostheses through scanning of coded members
US9985930B2 (en) * 2016-09-14 2018-05-29 Wanpath, LLC Reverse proxy for accessing local network over the internet
US10659433B2 (en) * 2016-11-30 2020-05-19 Salesforce.Com, Inc. Encrypting and securing data with reverse proxies across frames in an on-demand services environment

Also Published As

Publication number Publication date
US20210218708A1 (en) 2021-07-15
ES2794723B2 (es) 2022-04-21
EP3800564A4 (en) 2021-06-02
EP3800564B1 (en) 2023-06-21
EP3800564A1 (en) 2021-04-07
MX2020012311A (es) 2021-03-25
US11050716B1 (en) 2021-06-29
ES2794723A1 (es) 2020-11-18
WO2019059754A1 (es) 2019-03-28
EP3800564C0 (en) 2023-06-21

Similar Documents

Publication Publication Date Title
ES2794723B2 (es) Metodo y sistema de comunicacion segura por proxificacion de sockets de red
KR101164680B1 (ko) 가전제품들의 커뮤니티를 보호하는 방화벽 시스템, 그시스템에 참여하는 가전제품 및 그 시스템 내의 방화벽규칙들을 업데이트하는 방법
ES2673938T3 (es) Procedimiento y elemento de red para acceso mejorado a redes de comunicación
ES2844248T3 (es) Método y dispositivo para procesamiento de datos y sistema de comunicación que comprende tal dispositivo
US9331998B2 (en) Dynamic secured network in a cloud environment
US7886335B1 (en) Reconciliation of multiple sets of network access control policies
ES2337437B2 (es) S de red seguros basado en el contextoprocedimiento y sistema para controlar el acceso inalambrico a recurso.
ES2376143T3 (es) Marco de distribución de clave simétrica para internet.
ES2768049T3 (es) Procedimientos y sistemas para asegurar y proteger repositorios y directorios
CN106878161B (zh) 用于解析域名系统请求的方法和系统
JP2016530814A (ja) 大量のｖｐｎ接続を遮断するためのゲートウェイデバイス
US20190207784A1 (en) Establishing a secure connection between separated networks
US20240195795A1 (en) Computer-implemented methods and systems for establishing and/or controlling network connectivity
ES2318879T3 (es) Gestion de una red de comunicacion y migracion de agentes moviles.
El Jaouhari et al. Security issues of the web of things
BR112020006080A2 (pt) método e servidor de comunicações para identificação e autenticação segura de um dispositivo para uma plataforma de internet
Chifor et al. IoT Cloud Security Design Patterns
EP3512231B1 (en) Method for providing an enhanced level of authentication related to distribution of a secure software client application; as well as corresponding system and computer program product.
Carrozzo et al. Interoperation of IoT platforms in confined smart spaces: the SymbIoTe smart space architecture
Sahare et al. A survey paper: Data security in local networks using distributed firewalls
US20250097198A1 (en) Zero-trust packet routing
ES2411579B1 (es) Sistema y procedimiento de control de credenciales de usuario para el acceso a servicios de terceras partes en redes móviles
Sharma Security model of ad hoc cloud computing
JP2004297749A (ja) Ｖｐｎ装置
Djin Managing Access Control in Virtual Private Networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18857521

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018857521

Country of ref document: EP

Effective date: 20210101