US11824831B2 - Hole punching abuse - Google Patents
Hole punching abuse Download PDFInfo
- Publication number
- US11824831B2 US11824831B2 US16/850,290 US202016850290A US11824831B2 US 11824831 B2 US11824831 B2 US 11824831B2 US 202016850290 A US202016850290 A US 202016850290A US 11824831 B2 US11824831 B2 US 11824831B2
- Authority
- US
- United States
- Prior art keywords
- payload
- packet
- address
- firewall
- port number
- 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.)
- Active, expires
Links
- 238000004080 punching Methods 0.000 title claims description 15
- 238000000034 method Methods 0.000 claims abstract description 32
- 238000012544 monitoring process Methods 0.000 claims abstract description 23
- 230000000903 blocking effect Effects 0.000 claims description 13
- 238000004590 computer program Methods 0.000 claims description 12
- 230000002401 inhibitory effect Effects 0.000 claims 3
- 230000005764 inhibitory process Effects 0.000 claims 1
- 238000004891 communication Methods 0.000 description 21
- 230000008901 benefit Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000008676 import Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000004224 protection Effects 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 102220124522 rs746215581 Human genes 0.000 description 1
- 102220029906 rs907610 Human genes 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
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/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
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5046—Resolving address allocation conflicts; Testing of addresses
-
- 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/0245—Filtering by information in the payload
-
- 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/029—Firewall traversal, e.g. tunnelling or, creating pinholes
-
- 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
-
- 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1425—Traffic logging, e.g. anomaly detection
-
- 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1458—Denial of Service
Definitions
- the present invention relates to hole punching abuse. In a particular case, it relates to detecting and preventing UDP hole punching abuse.
- UDP hole punching may cut down server costs and avoids GDPR issues since no information is stored at ISP's server.
- the ISP server just does introduction between the IOT device and the user's device.
- both the IOT device and the user's device communicate to a server.
- the server In the server, it is registered in advance which user's device is allowed to communicate with which IOT device.
- the server gives to the IOT device and to the user's device the public IP address and UDP port number of the other party such that they can send messages to each other.
- the devices When the devices first time send messages to each other, they will cause the respective firewalls to remember the UDP source and destination port and destination IP used, and when the other device responds using it's destination port as source and other devices source port as destination, the message will be routed through the firewall to the intended target.
- FIG. 1 shows a flowchart of UDP hole punching according to the prior art.
- UDP hole punching is used to set up a direct communication between a Device A (having IP address A and using port A for the direct communication) and a Sensor B (having IP address B and using port B for the direct communication).
- Device A is an example of a user's device
- sensor B is an example of an IOT device.
- Server S (having IP address S and using port S for the communication with sensor B) is used to set up the direct communication.
- Server S is aware that a direct communication is to be set up between Device A (IP A) and Sensor B (IP B), e.g. according to a table stored in server S.
- server S knows that Device A uses Port A for the direct communication, e.g. by a mechanism corresponding to that shown below in messages 1 and 3 for sensor B.
- the communication with sensor B goes through a firewall F.
- the firewall is closed such that communication from external cannot pass to sensor B.
- an apparatus comprising monitoring means configured to monitor if a firewall receives a first packet and a second packet, wherein the first packet is directed to a IP address and a first port number; the second packet is directed to the IP address and a second port number different from the first port number; a hole through a firewall is punched for the IP address such that the firewall passes packets directed to the IP address and a hole port number different from the first port number and the second port number; the first packet has a first payload; the second packet has a second payload; and the apparatus further comprises checking means configured to check if the first payload is the same or substantially the same as the second payload; blocking means configured to cause the firewall to block the first packet and the second packet if the firewall receives the first packet and the second packet and the first payload is the same or substantially the same as the second payload.
- an apparatus comprising obtaining means configured to obtain a server IP address and a server port number, wherein a server communicates with a device having a device IP number from the server IP address and the server port number; sending means configured to send a packet to the device, wherein the packet is addressed to the device IP address and a preliminary device port number and comprises the server IP address and the server port number as a source address; monitoring means configured to monitor if the packet to the device is blocked by a firewall; repeating means configured to repeat the sending and the monitoring until the respective packet to the device is not blocked, wherein each of the packets of the repetitions is addressed to the device IP address and a respective preliminary device port number and comprises the server IP address and the server port number as the source address; and the respective preliminary device port numbers of different repetitions are different from each other.
- a method comprising monitoring if a firewall receives a first packet and a second packet, wherein the first packet is directed to a IP address and a first port number; the second packet is directed to the IP address and a second port number different from the first port number; a hole through a firewall is punched for the IP address such that the firewall passes packets directed to the IP address and a hole port number different from the first port number and the second port number; the first packet has a first payload; the second packet has a second payload; and the method further comprises checking if the first payload is the same or substantially the same as the second payload; causing the firewall to block the first packet and the second packet if the firewall receives the first packet and the second packet and the first payload is the same or substantially the same as the second payload.
- a method comprising obtaining a server IP address and a server port number, wherein a server communicates with a device having a device IP number from the server IP address and the server port number; sending a packet to the device, wherein the packet is addressed to the device IP address and a preliminary device port number and comprises the server IP address and the server port number as a source address; monitoring if the packet to the device is blocked by a firewall; repeating the sending and the monitoring until the respective packet to the device is not blocked, wherein each of the packets of the repetitions is addressed to the device IP address and a respective preliminary device port number and comprises the server IP address and the server port number as the source address; and the respective preliminary device port numbers of different repetitions are different from each other.
- Each of the methods of the third and fourth aspects may be a method of hole punching.
- a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any of the third and fourth aspects.
- the computer program product may be embodied as a computer-readable medium or directly loadable into a computer.
- FIG. 1 shows a message flow according to the prior art
- FIG. 2 shows a message flow according to some embodiments of the invention
- FIG. 3 shows an apparatus according to an embodiment of the invention
- FIG. 4 shows a method according to an embodiment of the invention
- FIG. 5 shows an apparatus according to an embodiment of the invention
- FIG. 6 shows a method according to an embodiment of the invention.
- FIG. 7 shows an apparatus according to an embodiment of the invention.
- the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.
- an attacker may make an educated guess or traffic reverse engineering about the server IP address and server destination UDP port, and then, fake a response that looks exactly like as if it is coming from the server.
- traffic reverse engineering the attacker sets up a device that is identical or close enough to target records the traffic. From the recording, one can see to which server the device is communicating to, and what is the protocol structure of this communication.
- the attacker typically does not know the port that the IOT device is using for the server communication. According to some embodiments of the invention, the attacker mass spams UDP packets trying many possible UDP port number until one of them succeeds (i.e. passes through the firewall of the sensor).
- the firewall typically blocks such crude UDP port scan, except for the port number(s) that is already allowed and forwarded as UDP hole. This means that one can push hundreds of packets per second, and may get the UDP hole packet through the firewall when the port number is right.
- the packets sent by the attacker's server may be just a computer, server functionality is not required) comprise a forged source address (that of the “correct” server)
- mass spam of UDP packets may be performed from one or several devices. For example, in order to avoid that the ISP of the attacker gets suspicious, he may send the UDP packets from a botnet, or from many (e.g. hundreds) very cheap VMs in one or more cloud providers.
- the IP address where the IOT device is supposed to punch a hole is in the UDP packet payload data, so what device is sending the forged UDP messages does not matter.
- the ISP Even if the ISP starts filtering packets (like the firewall), the ISP has to allow already established connections, such as the one between the server S and the sensor B of FIG. 1 .
- FIG. 2 shows a message flow corresponding to that of FIG. 1 , but for an attack according to some embodiments of the invention.
- the server S of FIG. 1 is replaced by an attackers computer S′ and the Device A is replaced by an attacker's device A′.
- Attacker's computer S′ may comprise plural computers (e.g. a botnet) or virtual machines.
- Actions 1 to 3 are the same as those shown in FIG. 1 .
- Message 3 does not reach attacker's server S′ because attacker's server S′ has a different address (IP S′, port S′) than server S of FIG. 1 , to which message 3 is directed.
- Attacker's server S′ (or a user thereof) guesses by an educated guess or by traffic reverse engineering the address (IP S, port S) of server S.
- Attacker's server S′ sends a message 5′ corresponding to message 5 of FIG. 1 to sensor B.
- the source address of message 5′ is a forged one, namely IP S, port S of server S, taken from the educated guess or the traffic reverse engineering of action 4.
- IP B is known to the attacker as the target of the attack.
- the destination port is not known.
- attacker's server S′ may try an arbitrary port such as port B1. If this attempt is not successful, it may try further ports B2, . . . , Bn until one of these ports is port B, which is open for communication between sensor B and server S.
- the payload of message 5′ comprises IP A′, port A′, the address of the attacker's device A′.
- sensor B From message 6′, sensor B understands that the direct communication is to be set up to IP A′, Port A′. Thus, sensor B sends a message to device A′. This message has IP B, port B as source address and IP A′, port A′ as destination address.
- IP addresses IP A, IP A′ IP B, IP S, and IP S′ of FIGS. 1 and 2 are public IP addresses. If NAT is applied on the firewall F, the firewall may perform address translation, such that an internal IP address and an internal port number is used between the firewall and Sensor B. The same applies correspondingly to each of devices A, A′, server S, and computer S′ if NAT is used for it.
- Table 1 shows a simple proof of concept of the attack. It has been tested against multiple different firewalls. It spoofs UDP hole punch response for IP security cameras using P2PCam backend at IP 54.221.213.97 (Amazon AWS) and destination port 32100. The destination for spoofed UDP hole is fs044-104-175-095.freedome-vpn.net (95.175.104.44) port 21748.
- firewall cannot filter out the incoming UDP packet when the attacker gets the port number right. Otherwise, one would allow the attacker to do a DOS attack instead of firewall bypass attack.
- a mass spam of UDP packets from a same source IP with substantially or exactly identical payload is received.
- FIG. 3 shows an apparatus according to an example embodiment of the invention.
- the apparatus may be a firewall or an element thereof.
- FIG. 4 shows a method according to an example embodiment of the invention.
- the apparatus according to FIG. 3 may perform the method of FIG. 4 but is not limited to this method.
- the method of FIG. 4 may be performed by the apparatus of FIG. 3 but is not limited to being performed by this apparatus.
- the apparatus comprises monitoring means 10 , checking means 20 , and blocking means 30 .
- the monitoring means 10 , checking means 20 , and blocking means 30 may be a monitor, checker, and blocker, respectively.
- the monitoring means 10 , checking means 20 , and blocking means 30 may be a monitoring processor, checking processor, and blocking processor, respectively.
- the monitoring means 10 monitors if a firewall receives a first packet and a second packet (S 10 ).
- the first packet is directed to a IP address and a first port number.
- the second packet is directed to the IP address (i.e., the same IP address) and a second port number different from the first port number.
- a hole through a firewall is punched for the IP address (i.e., again the same IP address) such that the firewall passes packets directed to the IP address and a port number (“hole port number”) different from the first port number and the second port number.
- the first packet has a first payload; and the second packet has a second payload.
- the checking means 20 checks if the first payload is the same or substantially the same as the second payload (S 20 ).
- the first payload is substantially the same as the second payload if the first payload comprises a first numeric sequence corresponding to a first device IP address and the second payload comprises a second numeric sequence corresponding to a second device IP address, the first device IP address is the same as the second device IP address, and a size of the first numeric sequence is different from a size of the second numeric sequence.
- S 10 and S 20 may be performed in an arbitrary sequence. They may be performed fully or partly in parallel.
- the blocking means 30 causes the firewall to block the first packet and the second packet (S 30 ). In this case, it is assumed that the packets belong to an attack as described hereinabove.
- FIG. 5 shows an apparatus according to an example embodiment of the invention.
- the apparatus may be a computer such as an attacker's computer or an element thereof.
- FIG. 6 shows a method according to an example embodiment of the invention.
- the apparatus according to FIG. 5 may perform the method of FIG. 6 but is not limited to this method.
- the method of FIG. 6 may be performed by the apparatus of FIG. 5 but is not limited to being performed by this apparatus.
- the apparatus comprises obtaining means 110 , sending means 120 , monitoring means 130 , and repeating means 140 .
- the obtaining means 110 , sending means 120 , monitoring means 130 , and repeating means 140 may be an obtainer, sender, monitor, and repeater, respectively.
- the obtaining means 110 , sending means 120 , monitoring means 130 , and repeating means 140 may be a obtaining processor, sending processor, monitoring processor, and repeating processor, respectively.
- the obtaining means 110 obtains a server IP address and a server port number (S 110 ).
- a server communicates with a device having a device IP number from the server IP address and the server port number.
- the sending means 120 sends a packet to the device (S 120 ).
- the packet is addressed to the device IP address and a preliminary device port number and comprises the server IP address and the server port number as a source address.
- the monitoring means 130 monitors if the packet to the device is blocked by a firewall (S 130 ).
- the repeating means 140 repeats the sending and the monitoring until the respective packet to the device is not blocked (S 140 ).
- Each of the packets of the repetitions is addressed with the device IP address and a respective preliminary device port number and comprises the server IP address and the server port number as the source address.
- the respective preliminary device port numbers of different repetitions are different from each other.
- FIG. 7 shows an apparatus according to an example embodiment of the invention.
- the apparatus comprises at least one processor 810 and at least one memory 820 including computer program code, and the at least one processor 810 , with the at least one memory 820 and the computer program code, being arranged to cause the apparatus to at least perform at least one of the methods according to FIGS. 4 and 6 and related description.
- UDP is an example of a sessionless protocol. Some embodiments of the invention may be applied to other sessionless protocols than UDP.
- an IOT device such as a sensor.
- the invention is not limited to IoT devices but may be applied to arbitrary UDP devices (devices communicating via UDP, or more generally: communicating via a sessionless protocol).
- the attacker's device is not limited in any way except that it is capable of communicating in the sessionless protocol (e.g. UDP).
- the attacker's device and the attacker's computer of FIG. 2 may be a same device or different devices.
- the attacker may perform a potentially malicious attack.
- the invention is not limited to such malicious attacks.
- the “attack” may be used to enable lawful interception of the IoT device.
- the attack may be used if the authorized staff cannot access the IoT device anymore due to some misconfiguration.
- each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software.
- Each of the entities described in the present description may be embodied in the cloud.
- example embodiments of the present invention provide, for example, a firewall, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).
- example embodiments of the present invention provide, for example, a computer such as an attacker's computer, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).
- Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
-
- DOS Denial of Service
- GDPR General Data Protection Regulation
- IOT Internet of Things
- IP Internet Protocol
- ISP Internet Service Provider
- NAT Network Address Translation
- P2P Peer to peer
- UDP User Datagram Protocol
- VM Virtual Machine
-
- 1: Sensor B knows that the direct communication is to be set up via server S. In order to set up the direct communication, sensor B sends a UDP message to server S (source: IP B, Port B; Destination: IP S, Port S).
- 2: Due to message 1, the firewall opens for communication between sensor B and server S, i.e. between IP B, Port B and IP S, Port S.
- 3: Message 1 is passed through the firewall to Server S.
- 4: Server S checks its stored table and identifies that a direct connection is to be set up between IP A, port A, and IP B. It adds Port B to this entry.
- 5: Server S replies to
message 3 by a message comprising IP S, Port S as source address, IP B and Port B as destination address, and IP A and Port A as payload. - 6: Since the firewall is open for communication between server S and sensor B, the firewall passes
message 5 to sensor B. - 7: From
message 6, sensor B understands that the direct communication is to be set up to IP A, Port A. Thus, sensor B sends a message to device A. This message has IP B, port B as source address and IP A, port A as destination address. - 8: Due to
message 7, the firewall F opens for communication between Device A (IP A, port A) and sensor B (IP B, port B). Now, device A and sensor B can communicate directly with each other. For example, device A may read out the sensor B or may take control over it. - 9:
Message 7 is passed through the firewall F to Device A.
-
- Attacks based on UDP hole punching may be prevented;
- Access to the UDP device (such as a sensor) may be (re-)gained.
| TABLE 1 |
| Proof of concept of the attack according |
| to some embodiments of the invention |
| from scapy.all import * | ||
| import random | ||
| ports=list( ) | ||
| for i in range(10000,33000): | ||
| ports.append(i) | ||
| random.shuffle(ports) | ||
| counter=0 | ||
| for port in ports: | ||
| ip = IP(dst =“10.42.0.11”, src =‘54.221.213.97’) | ||
| udp = UDP(sport=32100, dport=port) | ||
| payload = | ||
| b‘\xf1\x40\x00\x10\x00\x02\xf4\x54\x2c\x68\xaf\x5f\x00\x00\x00\x | ||
| 00\x00\x00\x00\x00’ | ||
| packet = ip / udp / payload | ||
| send(packet) | ||
| counter+=1 | ||
| print(counter) | ||
-
- 1. Identify when a firewall receives UDP packets from a source IP address for which there is an UDP hole punched, wherein some of the received UDP packets comprise destination port numbers for which there is no active UDP hole.
- 2. Check if the payload of these UDP packets are identical or substantially identical (less than IP address size variance)
- 3. Optionally check if the payload comprises a numeric sequence that matches a possible IP address. The IP address may be public or private. If the payload does not comprise such a numeric sequence, the packet is blocked by the normal firewall rules.
- 4. Start blocking all UDP packets from source IP address that have payload identical or substantially identical to the payload used for UDP mass spam.
- 5. Still allow UDP packets which have non-identical payload. That is, pass packets indicating a different UDP hole destination address and port in the payload.
Claims (16)
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1905409.7 | 2019-04-17 | ||
| GB1905409 | 2019-04-17 | ||
| GB1905409.7A GB2583114B (en) | 2019-04-17 | 2019-04-17 | Preventing UDP hole punching abuse |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| US20200336460A1 US20200336460A1 (en) | 2020-10-22 |
| US11824831B2 true US11824831B2 (en) | 2023-11-21 |
Family
ID=66810029
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| US16/850,290 Active 2040-11-17 US11824831B2 (en) | 2019-04-17 | 2020-04-16 | Hole punching abuse |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US11824831B2 (en) |
| GB (1) | GB2583114B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20230379310A1 (en) * | 2017-07-06 | 2023-11-23 | Umbra Technologies Ltd. | System and method for neutral application programming interface |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2353449A (en) | 1999-08-18 | 2001-02-21 | Alma Baba Technical Res Lab Co | Monitoring a network gateway for cracker attacks |
| US20060018262A1 (en) * | 2004-07-22 | 2006-01-26 | International Business Machines Corporation | Method, system and program for automatically detecting distributed port scans in computer networks |
| WO2006008307A1 (en) | 2004-07-22 | 2006-01-26 | International Business Machines Corporation | Method, system and computer program for detecting unauthorised scanning on a network |
| US20060067220A1 (en) * | 2004-09-30 | 2006-03-30 | Mazu Networks, Inc. | Port tracking on dynamically negotiated ports |
| US20110055322A1 (en) * | 2008-02-20 | 2011-03-03 | Carsten Rhod Gregersen | Method and system for providing connectivity between clients connected to the internet |
| US20110088088A1 (en) * | 2009-10-08 | 2011-04-14 | Guo Yuan Wang | Method of frame blocking for wireless device |
| US20150365378A1 (en) * | 2014-06-11 | 2015-12-17 | Electronics And Telecommunications Research Institute | One-way data transmission and reception system and method |
| US20180255018A1 (en) * | 2015-11-11 | 2018-09-06 | Alibaba Group Holding Limited | Ip address acquisition method and apparatus |
| US20180262500A1 (en) * | 2015-10-22 | 2018-09-13 | Koninklijke Kpn N.V. | Method for Enabling Establishment of a Direct Connection |
| US20200059480A1 (en) * | 2016-11-04 | 2020-02-20 | Nagravision S.A. | Port Scanning |
| US20200244685A1 (en) * | 2019-01-30 | 2020-07-30 | Palo Alto Networks (Israel Analytics) Ltd. | Scanner probe detection |
-
2019
- 2019-04-17 GB GB1905409.7A patent/GB2583114B/en active Active
-
2020
- 2020-04-16 US US16/850,290 patent/US11824831B2/en active Active
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2353449A (en) | 1999-08-18 | 2001-02-21 | Alma Baba Technical Res Lab Co | Monitoring a network gateway for cracker attacks |
| US20060018262A1 (en) * | 2004-07-22 | 2006-01-26 | International Business Machines Corporation | Method, system and program for automatically detecting distributed port scans in computer networks |
| WO2006008307A1 (en) | 2004-07-22 | 2006-01-26 | International Business Machines Corporation | Method, system and computer program for detecting unauthorised scanning on a network |
| US20060067220A1 (en) * | 2004-09-30 | 2006-03-30 | Mazu Networks, Inc. | Port tracking on dynamically negotiated ports |
| US20110055322A1 (en) * | 2008-02-20 | 2011-03-03 | Carsten Rhod Gregersen | Method and system for providing connectivity between clients connected to the internet |
| US20110088088A1 (en) * | 2009-10-08 | 2011-04-14 | Guo Yuan Wang | Method of frame blocking for wireless device |
| US20150365378A1 (en) * | 2014-06-11 | 2015-12-17 | Electronics And Telecommunications Research Institute | One-way data transmission and reception system and method |
| US20180262500A1 (en) * | 2015-10-22 | 2018-09-13 | Koninklijke Kpn N.V. | Method for Enabling Establishment of a Direct Connection |
| US20180255018A1 (en) * | 2015-11-11 | 2018-09-06 | Alibaba Group Holding Limited | Ip address acquisition method and apparatus |
| US20200059480A1 (en) * | 2016-11-04 | 2020-02-20 | Nagravision S.A. | Port Scanning |
| US20200244685A1 (en) * | 2019-01-30 | 2020-07-30 | Palo Alto Networks (Israel Analytics) Ltd. | Scanner probe detection |
Non-Patent Citations (2)
| Title |
|---|
| Bryan Ford, et al, "Peer-to-Peer Communication Across Network Address Translators", USENIX Annual Technical Conference, https://www.usenix.org/legacy/event/usenix05/tech/general/full_papers/ford/ford_html/ (Year: 2005). * |
| Search Report completed by the Intellectual Property Office of the United Kingdom in Application No. GB1905409.7, dated Oct. 10, 2019. 1 page. |
Also Published As
| Publication number | Publication date |
|---|---|
| GB2583114B (en) | 2022-09-21 |
| GB2583114A (en) | 2020-10-21 |
| GB201905409D0 (en) | 2019-05-29 |
| US20200336460A1 (en) | 2020-10-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Izhikevich et al. | {LZR}: Identifying unexpected internet services | |
| EP4614885A2 (en) | Using a blockchain for distributed denial of service attack mitigation | |
| EP3635929B1 (en) | Defend against denial of service attack | |
| Gilad et al. | Off-Path Attacking the Web. | |
| Nasser et al. | Provably curb man-in-the-middle attack-based ARP spoofing in a local network | |
| Alqahtani et al. | TCP/IP attacks, defenses and security tools | |
| Dakhane et al. | Active warden for TCP sequence number base covert channel | |
| Mandal et al. | A survey on network security tools for open source | |
| Lee et al. | Study of detection method for spoofed IP against DDoS attacks | |
| KR20080028381A (en) | How to defend against denial of service attacks in IP networks by target victim self-identification and control | |
| KR101380015B1 (en) | Collaborative Protection Method and Apparatus for Distributed Denial of Service | |
| Feng et al. | Exploiting cross-layer vulnerabilities: Off-path attacks on the tcp/ip protocol suite | |
| Niknami et al. | Towards analysis of the performance of idss in software-defined networks | |
| JP4278593B2 (en) | Protection method against application denial of service attack and edge router | |
| US11824831B2 (en) | Hole punching abuse | |
| JP2006060599A (en) | Application service rejection attack prevention method, system, and program | |
| KR101593897B1 (en) | Network scan method for circumventing firewall, IDS or IPS | |
| KR100723864B1 (en) | Method and apparatus for preventing network attack using information contained in packet | |
| Hoffstadt et al. | SIP trace recorder: Monitor and analysis tool for threats in SIP-based networks | |
| Pandey et al. | Attacks & defense mechanisms for TCP/IP based protocols | |
| Sattar et al. | A delay-based countermeasure against the discovery of default rules in firewalls | |
| Jadhav et al. | Detection and mitigation of arp spoofing attack | |
| US20230370492A1 (en) | Identify and block domains used for nxns-based ddos attack | |
| Tsunoda et al. | Security by simple network traffic monitoring | |
| Pandey et al. | Comprehensive security mechanism for defending cyber attacks based upon spoofing and poisoning |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
| STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
| AS | Assignment |
Owner name: F-SECURE CORPORATION, FINLAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NIEMELAE, JARNO;REEL/FRAME:052806/0486 Effective date: 20200527 |
|
| STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
| STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
| AS | Assignment |
Owner name: WITHSECURE CORPORATION (A/K/A WITHSECURE OYJ), FINLAND Free format text: CHANGE OF NAME;ASSIGNOR:F-SECURE CORPORATION (A/K/A F-SECURE CORPORATION OYJ);REEL/FRAME:060302/0690 Effective date: 20220316 |
|
| STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
| STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
| STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
| STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
| STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT RECEIVED |
|
| STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
| STCF | Information on status: patent grant |
Free format text: PATENTED CASE |