Technical Field

The invention refers to a method and a server computer for controlling data traf fic addressed to a website and / or server destination .

Background Art

Cyberattacks are ubiquitous in today' s world . Cyberattacks may include various kinds of attacks , including but not limited to establishing a data connection with a target computing resource to upload malware or ransomware , spying on the target computing resource , capturing the target computing resource , etc .

Initiators of cyberattacks desire to remain concealed . Accordingly, attacking under a sender' s IP or MAC addresses is of little interest given that the location and/or identity of such sender is easily derivable from the corresponding IP and/or MAC addresses .

Accordingly, VPN connections (Virtual Private Network) are of more interest to initiators of cyberattacks given that it is a characteristic of VPN connections that the sending IP address visible to the receiver typically is an IP address used by a VPN provider for many di f ferent connections at the same time , and does not constantly represent a dedicated device . Instead, the real user' s IP address remains concealed to the receiver . In addition, a VPN connection typically makes use of encryption techniques . While VPN services originally were of fered to enhance privacy and security to users they may be abused by initiators of cyberattacks to hide their identity and/or location . Service providers such as online shops or online banks desire to protect their businesses , and, hence , their website or servers , from cyberattacks , and in particular from cyberattacks making use of VPN services or captured IP addresses , and/or disclose initiators of cyberattacks .

Disclosure of the Invention

This problem is solved by a method for controlling data traf fic addressed to a website and / or server destination according to claim 1 . Preferably, the method is a computer controlled method . Preferably, by means of the present method, data traf fic to a destination such as a server, a server farm or to a network of computing entities , a website or any other computing service or of fering is intercepted .

Preferably all the data traf fic addressed to this destination is intercepted and evaluated . The data traf fic comprises or consists of data packets . A data packet comprises a header section and a payload section . A data packet of the present invention is not restricted to data packets of OS I network layer 3 , but can be a data unit of any of the other OS I layers . A data packet referred to in this disclosure comprises at least a sender IP address and sender related data other than the sender IP address . The sender IP address represents the IP address of the sender of the data packet . IP addresses are assigned to network entities for identi fying these during transmission sessions . The IP address preferably is arranged in the header of the data packet .

The sender related data is information contained in the data packet , preferably in the header but possibly also at least in part in the payload . The sender related information provides information about the sender other than the IP address . The sender related data other than the sender IP address may be subject to the protocol used. In one example, the sender related data comprises or consists of data / information also known as browser fingerprint and hence represents data that indicates settings of the sender's browser and/or other sender's computing configuration. Preferably, such browser fingerprint includes or generates information from characteristics of the sender's device and/or the sender's user configuration. Hence, next to browser specific setting/s, the browser fingerprint may also include related hardware or software setting/s given that the browser relies on hardware and software of the sender's system. The sender related data preferably is assembled from or comprises information from a header of the OSI layer 7 protocol, such as from an HTTP header, and/or other layer/s used. Preferably, the browser fingerprint is extracted only in a passive manner from the data packet received. In a different embodiment, in addition to deriving the browser fingerprint from the received data packet, browser fingerprint data may also be requested from the sender on demand, preferably in a fully automated manner.

The sender related data other than the sender IP address preferably comprises one or more of: a) an identifier for a browser used by the sender, preferably including a version number; b) one or more time stamps and/or speed information allowing to identify a travel time between sender and destination and/or between nodes in the network the data packet passes ; c) social media account/s and/or log status; d) installed fonts; e) operating system or platform used; f) cookies settings, e.g. de-/activated; g) cookie/ s stored; h) email address/es; i) language setting/s, e.g. "accept language" protocol field in HTTP; j) user agent, e.g. "user agent" protocol field in HTTP; k) display setting/s, e.g. display size and/or display color depth; l) time zone setting/s, e.g. time zone and/or time zone shift with respect to UTC; m) browser plugin/s; and/or details of browser plugin/ s ; n) compression format/s; o) WebGL settings ("Web Graphics Library") , e.g. WebGL providers and/or renderers and/or settings and/or fingerprint, hashed or un-hashed; p) Canvas settings and/or fingerprint, hashed or un-hashed; q) server setting/s r) audio settings and/or fingerprint; s) HW parallelism; t) device storage.

It is assumed that the sender related data or browser fingerprint makes senders / users distinguishable from each other, and may serve as a unique identifier for the sender. In this context, the following combinations out of the above set are preferably used as sender relevant data:

■ b) and c) and d) and i) and 1) and m) ;

■ b) and c) and d) and i) and 1) ;

■ b) and c) and d) and i) and m) ;

■ b) and c) and d) and 1) and m) ;

■ b) and c) and i) and 1) and m) ;

■ b) and d) and i) and 1) and m) ;

■ c) and d) and i) and 1) and m) . When it comes to storing sender related data, such as in a disconnect list or a VPN traffic database to be introduced later on, the sender related data can be stored in one of the following formats:

• the sender related data as is;

• a subset of the sender related data;

• a hash function of the sender related data .

In view of the mentioned problem that VPN connections conceal the real sender and its IP address the sender related data preferably is used instead to represent a sender, even if the sender makes use of different IP addresses through a VPN service provider. Instead, the sender related data is assumed to remain the same for the same sender. Accordingly, the sender related data preferably serves for identifying a sender, and assigning data packets to a common sender even if made use of different IP addresses.

Even if the payload is encrypted by way of using VPN services, in particular the application layer header (OSI layer 7) remains unencrypted also in VPN connections and therefore can serve to identify the true sender of a data packet.

A data packet received, i.e. intercepted on its way to its destination, and preferably all data packets are analysed and classified into at least two categories. The analysis and classification can be performed in two engines, i.e. an analysis engine and a classification engine. In another embodiment, the analysis and classification is performed in one engine with the data packet as input, and the assigned category as output. An engine preferably is implemented as processing unit with corresponding software.

A data packet received may be classified in exactly two categories, or in more than two categories. In any case, it is preferred to provide two categories, a first one of which represents a category for data packets that do not represent a safety risk for the destination when being processed there. A second one of the categories represents a category for data packets that do represent a safety risk for the destination when being processed there. The classification of a data packet is preferably based on the preceding analysis of the data packet, i.e. an analysis preferably of both, header and content / payload, and preferably an analysis not only of a single OSI layer, but preferably of multiple OSI layers. In a preferred embodiment, the OSI layers 2 to 4 are analysed. In a different embodiment, all OSI layers including and above 2 are analysed.

Analyzing a data packet preferably includes analyzing at least content of the data packet, and more preferably content, i.e. the payload of the data packet, and the header, as well as other protocol fields if any. Preferably, analyzing includes combining information from the header and the payload, and from data extracted from different OSI layers. In one example, the payload is detected to comprise a script while the header indicates a pdf document portion in the payload. By such means, viruses may be detected. More general, the analysis preferably contains logic to detect violations of data and / or communication protocols. Preferably, the analysis makes use of deep packet inspection.

In case the data packet is classified into the first category, the data packet is passed on to its destination, i.e. the receiver IP address which preferably is one of a website, a client computer or a server computer. In case the data packet is classified into the second category the data packet is rejected. Rejecting a data packet preferably includes one or both of not passing on the data packet to its destination and establishing means for preventing the data packet being passed on to its destination. Rejecting the data packet preferably additionally includes disconnecting the sender of the data packet, i.e. preferably notifying the sender that either an existing connection no longer is supported and is disconnected, or a requested connection is rejected, all in response to the analysis of the data packet.

Subsequent to such a rejection, in case another data packet is received from the same sender IP address and / or comprising the same sender related data as the rejected data packet, such other data packet is rejected, too. Preferably, one of the criteria sender IP address and sender related data is sufficient for rejecting the other data packet. In many instances, both criteria are fulfilled given that a data packet classified once as malicious may be resent and, thus, contains the same sender IP address and the same sender related data. However, as indicated above there may be scenarios where an attacker may switch to a different IP address, however, the sender related data remains the same. Accordingly, it preferably is sufficient if subsequent to a rejection of a data packet the same sender related data appears again in another data packet, even if the sender IP address is a different one.

In such a way, the server or website can be efficiently protected from cyberattacks, even if the attacker switches between different IP addresses, or if the attacker makes use of a VPN service that switches between different IP addresses, in particular after a first attempt of the attacker is rejected by the present method / server .

Operators of servers of websites that are exposed to cyberattacks may be, for example, online shops, online banks, streaming services, or other websites. These destinations may efficiently be protected, even if the attacker makes use of different IP addresses. The method may also be applied in a simulation environment in which a target computing infrastructure may be attacked in a planned scenario in order to detect weaknesses of the target, i.e. the destination. Not only the operator of such target may be interested in the results, but also insurance companies offering insurances against cyberattacks .

In one embodiment of the present invention, a disconnect memory is maintained. The term memory is used because the data stored in this memory temporarily, i.e. for a limited period of time, such as hours or few days, in particular between 12 and 25 hours. Accordingly, the hardware for storing the disconnect information preferably is a memory, such as an electronic storage, however, in a different embodiment, it may be a storage used for a longer term storage, such as an HDD etc. It is preferred to have a reject or disconnect event stored in the disconnect memory, and preferably have it time stamped. Given that a disconnect action is based on a received data packet, in one embodiment, the entire data packet may be stored in the disconnect memory, e.g. in combination with a time stamp of the time the data packet was received or the time the connection was disconnected. In a preferred embodiment, however, at least the sender IP address and the sender related data of the respective data packet, in particular a hash of, is stored in the disconnect memory. Preferably, the disconnect memory is organized in a way to store an entry per rejected data packet, the entry including multiple fields such as at least the IP sender address, the sender related data, and the rejection time. A data base may support the storage of such entries, for example.

Accordingly, a rejected data packet - in different words a data packet classified into the second category - is recorded in one of the suggested ways in the disconnect memory.

However, as indicated above, after a data packet has been rejected and another data packet is received with the same or similar sender related data and/or with the same sender IP address, and preferably within a given time, such other data packet is rejected, too , preferably even without analysis and classi fication of the data packet other than extraction of the sender IP address and the sender related data .

In a preferred embodiment , the incoming data packets are compared to the entries in the disconnect memory, preferably upfront to any analysis and classi fication . Accordingly, it is preferred that for an incoming data packet the sender IP address and the sender related data are extracted and are compared with the disconnect memory i f already existent therein . In one embodiment , the sender IP address may first be compared to the sender IP addresses stored in the disconnect memory . In case of a match, the data packet can be rej ected without further analysis . In case of no match, the sender related data may be compared to the sender related data existent in the disconnect memory . In case of a match, the data packet can also be rej ected without further analysis of the payload etc . , and even without the sender IP address matching . In such scenario , it can be assumed that an attacker proves to be the same entity since he/ she is assigned the same or similar sender related data, even i f the IP address may have changed . Preferably, both di f ferent sender IP addresses are added to a list of VPN addresses and/or to a VPB traf fic database explained later on . Accordingly, it is preferred that all received data packets are compared to the entries in the disconnect memory .

In case an attacking entity conducts multiple subsequent attempts to engage with the destination protected by the method as suggested, a number of rej ections is counted per sender, either by one counter per combination of sender IP address and sender related data, or by separate counters for sender IP address and sender related data, or by a counter for the sender related data only . The counter may be initiali zed, e . g . set to one , in response to the sender IP address or the sender related data being stored in the disconnect memory for the first time within the interval the disconnect memory covers . In case of a subsequent reappearance of same sender IP address and/or the same sender related data, the counter is increased by one . A threshold may be assigned to each counter . In case the threshold is exceeded by the counter value , the data packet from this sender IP address and/or this sender related data is blocked instead of only be rej ected . Blocking preferably is implemented for a defined period in time , such as between 12 and 25 hours , preferably for 24 hours . Blocking a sender IP address preferably includes flagging and / or storing the IP address and / or the sender related data as blocked and discarding any further incoming data packets with the blocked sender IP address and / or the blocked sender related data . In addition, the data packet resulting in blocking the sender preferably is forwarded to a server / entity that further analyzes content and header of the data packet on an even deeper level for gaining information as to the identity and location of the sender, e . g . by way of analyzing cookies . In addition, the intercepting service or may disclose its existence to the sender and communicate to the sender that the sender is blocked for a limited period in time .

The threshold preferably is set to one of two , three and four, indicating the number of attempts allowed to the suspicious sender to approach the destination . The threshold preferably is set such that additional information may be derived from the additional attempts allowed . These additional attempts are in particular helpful in case an attacker / its VPN service provider switches between di f ferent sender IP address in response to each disconnect from the present service / server . In such scenario , it is assumed that using di fferent sender IP addresses result in di f ferent routing paths through the network, and as such in di f ferent times to destination, or di f ferent times between network nodes . Preferably, this information is stored either within a fingerprint or outside in the entry in the disconnect memory for each rej ected data packet . From these travel times / the corresponding time stamps , a location, or an area of the attacker may be derived which may help in identi fying the attacker . Such location analysis and/or sender identi fication may be performed either e . g . after having blocked the alleged sender, or at any time later on . This analysis may be performed on the server or remote elsewhere , in particular also disconnected to the monitoring operations .

When it comes to comparing existing sender related data, e . g . in form of entries in the disconnect memory or in the to be introduced VPN traf fic database , a match may be achieved not only i f the compared sender related data is identical , but also in case it is suf ficiently similar . Similarity may be defined e . g . by fulfilling at least a certain number of identical data items relative to the overall data items defining the sender related data . For example , an 80% or 90% conformance may be considered and coded as suf ficient for a match, and hence , for considering the senders of two data packets as being the same entity, but not necessarily acting under the same IP address .

In a preferred embodiment of the present invention, a list is maintained comprising sender IP addresses assigned to VPN services .

VPN services are characteri zed as follows : In a connection between a user and the VPN service the IP address of the user is transparent , while in a connection between the VPN service and the destination the user IP address is concealed since the VPN service makes use of di f ferent IP addresses not assignable to users . Preferably, the connection between the user and the VPN service is not encrypted, while the connection between the VPN service and the destination is encrypted . While in non- critical scenarios users legitimately use VPN services in order to protect and hide communication, VPN connections are also used in attacks for the same reason, i . e . operating in a concealed manner . The pool of IP addresses VPN services make use of is typically not available . Some VPN providers , however, even disclose IP addresses used for VPN connections . The above list may contain such VPN addresses made available by VPN providers . In addition, the web may be crawled for other VPN addresses known or detected by the community . Such IP addresses may also be available and added to the list . And last but not least , it is envisaged, by an embodiment of the present method, to detect IP addresses suspicious for being used in VPN services and add these IP addresses as new VPN addresses to the list , and compare future data traf fic to such extended and/or up-to-date list . Hence , the list preferably is maintained and updated to compare the sender IP addresses of incoming data packets to known and suggested VPN addresses . Preferably, this list is stored in a memory or storage , it may be organi zed as a data base , and it preferably has no time limit in existence or availability .

In addition, it is preferred to maintain a VPN traffic database . This VPN traf fic database preferably comprises entries for VPN traf fic, and preferably for all traf fic identi fied by means of the list as VPN traffic addressed to the destination . Accordingly, it is preferred that a data packet identi fied as belonging to a VPN connection and/or stemming from a VPN address is stored in the database . Preferably, such entry comprises at least the sender IP address and the sender related data, as well as a time stamp as to when the data packet was received and/or identi fied as a VPN data packet .

Hence , in a preferred embodiment , the sender IP address of a data packet received is compared with the sender IP addresses stored in the list of IP addresses assigned to VPN services . In case the sender IP address of the received data packet is retrieved in the list a corresponding entry is recorded in the VPN traffic database. The entry preferably comprises at least the sender IP address and the sender related data of the data packet received .

In case such data packet was identified as VPN data packet, it may be of further interest, if previous data packets with the same sender IP address were detected and added to the VPN traffic database, however, in particular if such previous data packets have different sender related data than the present data packet. This may hint towards malicious operations, the sender operating with a VPN address but different sender related data. Hence, in case an entry is identified in the VPN traffic database matching in the sender IP address but not matching in the sender related data, the identified entry/en- tries and the new recorded entry are linked in the VPN traffic database.

However, there are other scenarios making use of the VPN traffic database and identifying sender IP addresses as belonging to VPN service providers. If the sender IP address of a data packet is not found in the list of VPN addresses, the sender related data of the data packet is preferably compared with the entries in the VPN traffic database. Hence, it is desired to identify previous data packets that have the same sender related data even if not the same sender (VPN) IP address. In such a case, i.e. in case of a match with the sender related data of an entry of the VPN traffic database and a concurrent mismatch of the sender IP addresses, it can safely be assumed that the sender IP address is a VPN address given that the sender related data is identified as one being used by a VPN service. Accordingly, the sender IP address of the received data packet is added to the list of VPN addresses. And, a corresponding entry is recorded in the VPN traffic database for the data packet re- ceived, and preferably the recorded entry and the matching entry in the VPN traf fic database are linked to each other .

Preferably, the sender related data of all data packets received is compared with the sender related data stored in the VPN traf fic database . This ensures detecting as many VPN addresses as possible in the above manner .

In a preferred embodiment , the above two processes , i . e . controlling disconnecting operations and identi fying VPN addresses benefit from each other by way of sharing information . For example , in the analysis of the data packet the sender IP address may be veri fied against the list of VPN addresses . In case of being a VPN address , a threshold or criteria for assigning the data packet into the second, allegedly malicious category may be lowered . And/or the sender related data of the data packet received may be veri fied to entries in the VPN traf fic database . In case of the sender related data being detected in the list of VPN addresses , a threshold or criteria for assigning the data packet into the second, allegedly malicious category may also be lowered .

According to another aspect of the present invention, a computer program product is provided comprising computer code means for implementing a method according to any of the preceding embodiments when executed on a processing unit of a computing device such as a server or a network of computing devices .

According to another aspect of the present invention, a server computer - in short server - is provided for controlling data traf fic addressed to a website and / or server destination . The server comprises an analysing engine configured to analyse data packets of the data traf fic received . A data packet comprises at least a sender IP address and sender related data other than the sender IP address . A classi fication engine is configured to classi fy the analysed data packets into at least two categories . A control engine is configured to pass on the data packet to the website and / or server destination in case of the data packet being classi fied into a first of the at least two categories . The control engine is further configured to rej ect the data packet in case of the data packet being classi fied into a second of the at least two categories . The control engine is further configured to , subsequent to the rej ection, in response to receiving another data packet from the same sender IP address ( and / or comprising the same sender related data, rej ect the other data packet .

In a preferred embodiment , the server comprises a VPN detection engine ( configured to identi fy sender IP addresses of received data packets as sender IP addresses of a VPN service .

It is noted that embodiments disclosed in connection with the method shall be regarded as disclosed also in connection with the computer program product and with the server .

Other advantageous embodiments are listed in the dependent claims as well as in the description below .

Brief Description of the Drawings

Embodiments of the invention will be better understood and obj ects other than those set forth above will become apparent from the following detailed description thereof . Such description makes reference to the annexed drawings , wherein :

Figure 1 illustrates a block diagram of a server computer according to an embodiment of the present invention;

Figure 2 illustrates a schematic data packet as used in embodiments of the present invention;

Figure 3 illustrates a flow chart of a method for controlling data traf fic addressed to a website and / or server destination according an embodiment of the present invention; and

Figure 4 illustrates a flow chart of a method for controlling data traf fic addressed to a website and / or server destination according an embodiment of the present invention .

Detailed Description of the Drawings

Figure 1 illustrates a block diagram of a server 1 according to an embodiment of the present invention . The server 1 precedes a website and / or server destination 2 in a way that all data traf fic DT addressed to the website and / or server destination 2 passes the server 1 , which server 1 may also be referred to as screening server 1 . In this regard, data traf fic DT addressed to the website and / or server destination 2 is received by the server 1 . The data traf fic DT is represented by a multitude of data packets DP . The server 1 passes on only selected ones of the received data packets DP to the website and / or server destination 2 .

A control engine 13 is responsible for controlling the data traf fic DT to the website and / or server destination 2 . The control engine 13 may also generate data traf fic DT and send data packets DP to senders of the data packets DP received, as is indicated by the (back) arrow .

An incoming data packet DP is received by an analysing engine 11 of the server 1 on the one hand, and by a VPN detection engine 14 of the server 1 on the other hand . The analysing engine is followed by a classi fying engine 12 , which classi fying engine 12 is connected to the control engine 13 . A disconnect memory 18 is provided in the server 1 and is explained later on . In the context of the VPN detection engine 14 , a list 16 of sender IP addresses assigned to VPN services is provided as well as a VPN traf fic database 17 . Preferably, the list 18 as well as the VPN traf fic database 17 are maintained and updated by the VPN detection engine 14 , whereas the disconnect memory 18 is maintained and updated by the analysing engine 11 .

Figure 2 illustrates a schematic data packet DP as used in embodiments of the present invention . As noted above , the term data packet is not limited to an OS I layer three data packet , but instead can be a data unit according to any OS I layer . Preferably, the data packet is a data unit of an application layer according to the OS I layered model . All three rows in Figure 2 represent the same data packet DP .

The data packet DP comprises a header section HD and a payload section PL . The header section HD preferably comprises multiple pieces of information for one or more of routing, requesting and / or sending information . At least a subset of the information included in the header section HD is referred to as sender related data SDR since it provides information related to the sender which is the entity having sent the data packet DP to the website and/or server destination 2 . Such sender related information SDR includes information other than an IP address IP of the sender, which typically has its own designated field in the data packet DP . In the present example , the IP address IP is part of the payload section PL of the data packet DP . This may be the case i f the data packet DB represents an application layer data packet , while the IP address IP may be part of a header section of a lower OS I layer data packet .

The analysing engine 11 of Figure 1 preferably is configured to extract the sender related data SDR of incoming data packets DP, as well as the sender IP address IP, preferably for all data packets received . Preferably, the analysing engine 11 is embodied to scan and analyse the information contained in the data packet from the top OS I layer, down to OS I layer 2 , more preferably from the OS I layers 2 , 3 and 4 , preferably for both, the header section HD and the payload section PL in each layer .

The analysing engine 11 aims to investigate the data packet DP as to the safety or risk when passing the data packet on to the website or server destination 2 . For this purpose , the analysing engine preferably analyses one or more of

■ I f the payload section PL comprises malware ;

■ I f the payload section PL comprises executable code ;

■ I f the code format in the payload section PL matches the code format indicated in the header section HD for the payload section PL ;

■ I f the payload section is encrypted .

In a preferred embodiment , the analysing engine 11 comprises a deep packet inspection tool or software , configured to analyse not only the application layer of the data packets , but lower layers , according to the OS I layered model .

In a preferred embodiment , the analysing engine provides its results to a classi fication engine 12 . The classi fication engine 12 classi fies the investigated data packet DP into two categories . A first of the two categories is a category that allows the data packet to be passed on to the website and/or server destination 2 . Whereas a second of the two categories is a category that leads to rej ecting the data packet , and, hence , considers the data packet as suf ficient risky not to be passed on to the website and/or server destination 2 . By means of the classi fication engine 12 , the website and/or server destination 2 can be prevented from an undesired hack, an undesired attack, etc . The control engine 13 executes the classi fied data packets DP .

Figure 3 illustrates a flow chart of a method for controlling data traf fic addressed to a website and / or server destination according an embodiment of the present invention. The method preferably is implemented on a server as shown in Fig. 1.

In step slO, a data packet is received by the server such that the data packet flow to the website and / or server destination is intercepted by the server. As indicated above, in step sll, a header and a payload section of the data packet are scanned. Preferably, the header and payload sections of many or all OSI layers down to layer two are scanned. Scanning in this context refers to extracting information contained in the data packet. In next step sl2, the information extracted in step sll is analysed, preferably as to its safety risk for the website and/or server destination. Based on the analysis in step sl2, the data packet is classified in step sl3 into one of the two categories introduces above, i.e. sufficiently safe to be passed on to the destination, or considered as sufficiently risky not to be passed on to the destination 2. In case, the data packet is classified into the first, i.e. the safe category in step sl4 (y) , the data packet is passed on to the destination in step sl5, and the handling of this data packet by the server is terminated ("End") .

However, in case the data packet is classified into the second, i.e. the risky category in step sl4 (n) , the data packet is rejected in step sl6. The rejection in step sl6 may encompass not forwarding the data packet and / or preventing the data packet from being forwarded to the destination in step sl61. In addition, rejecting a data packet preferably additionally includes in step sl62 disconnecting from the sender of the data packet. This may include sending a message to the sender IP address that the connection requested to be established between the sender and the destination or already established is not accepted, i.e. is disconnected.

In one or both of steps sll and sl2 sender related data other than the sender IP address may already be extracted from the data packet. If not yet extracted, such sender related data preferably is extracted in step sl7 subsequent to rejecting step sl6. In step sl8, it is verified if the extracted sender related data and / or the sender IP address are already present in a disconnect memory. The disconnect memory preferably is the disconnect memory 18 of the server of Fig. 1 and contains entries for rejected data packets preferably of the last x hours, e.g. the last x = 24 hours.

If the disconnect memory does not yet contain the sender IP address and / or the sender related data of the data packet received in step sll, preferably both, i.e. path (n) , both the IP address and the sender related data of this data packet considered as malicious are recorded in the disconnect memory in step sl9. This information serves to evaluate future data packets against.

On the other hand, if one or both of the sender IP address and the sender related data are already stored in the disconnect memory (y) , a counter, preferably a counter for each of the sender IP address and the sender related data, is increased in step s20. Preferably a threshold is stored in the server for a maximum value the counter is allowed to achieve. For example, the threshold is set to two, or to three. In case the threshold is not yet reached by the counter, see step s21 (n) , the handling of this data packet is terminated ("End") . In case the threshold is yet reached by the counter value, see step s21 (y) , the sender IP address and / or the sender related data is blocked in step s22.

While the above illustrated embodiment illustrates a certain order of steps, the order of steps can be exchanged where appropriate. Accordingly, a second alternative path is illustrated initiated by the dashed arrow emanating from step slO of receiving a data packet.

In the previous embodiment, the data packet is first analysed and classified in steps sll ff. and only then it is checked against the disconnect memory if a data packet with this sender IP address and/or sender related data already was rejected in the past.

In the present alternate embodiment, it is first checked, if the disconnect memory already contains one or more entry/entries with the same sender IP address and/or sender related data. A rationale behind this approach may be that if a data packet from such sender was rejected in the past, the present data packet is also going to be rejected without having to run the analysis and classification steps sll ff.

In this embodiment, sender related data is extracted in step s30 and is evaluated in step s31. In case the sender IP address and / or this sender related data is not yet recorded in the disconnect memory (n) , the data packet needs to be fully scanned, analysed and classified in steps sll ff. However, if so (y) , then the counter for this sender IP address and/or sender related data is increased in step s32, and it is verified in step s33 if the counter exceeds the threshold. If yes (y) , this sender IP address and / or this sender related data is blocked in step s22. If not (n) , the data packet is rejected in step sl6. However, since the counter verification already was executed in step s33, steps sl7 to s22 no longer need to be implemented such that these steps of the previous embodiment can be bypassed, as is indicated by the dashed arrow emanating from si 6.

Figure 4 illustrates a flow chart of a method for controlling data traffic addressed to a website and / or server destination according an embodiment of the present invention. The method preferably is implemented on a server as shown in Fig. 1. The method preferably is executed in parallel or quasi-parallel to the method illustrated in Fig. 3, i.e. the data packet received undergoes the method illustrated in Fig. 3 and the method illustrated in Fig. 4. In its preferred, that the two methods are entangled in that e.g. results from calculations, comparisons, determinations, actions such extraction from information from a data packet, etc. are exchanged between the methods at defined synchronization points or on-demand, such that duplicate efforts can be avoided.

After having received a data packet in step slO, sender related data is extracted from the data packet in step s40. For example, the result may in addition be transferred to the method of Fig. 3 and be used there from the beginning, and e.g. replace steps sl7 and s30. Or any such results may be transferred from step s30, for example, to the method of Fig. 4 and replace step s40.

Presently, a list of VPN addresses is maintained. In step s41, it is verified if the sender IP address from the data packet is existent in the list of VPN addresses. If so (y) a new entry is generated in step s42 in a VPN traffic database. The entry comprises at least the sender IP address and the sender related data, and preferably a time stamp of the recording. This VPN traffic database, hence, aims to comprise all data packets of the data traffic received that can be assigned to VPN connections, because of the knowledge of VPN addresses manifested in the list of sender IP addresses assigned to VPN services.

In such scenario, it may be of interest if there are other entries in the VPN traffic data base from the past with the same sender IP address but different sender related data. This is verified in step s43. In case of previous entries in the VPN traffic database with the same sender IP address and the same sender related data (n) , then the VPN related handling of this data packet is Terminated ("End") . If, on the other hand, previous entries in the VPN traffic database exist with the same sender IP address but different sender related data these one or more entries are linked in step s44 with new entry recorded based on the analysis of the present data packet . I f the answer to step s41 is no (n) , the present data packet does not stem from a known VPN address . Accordingly, the sender IP address will not also be found in the VPN traf fic database . However, it may be of interest in step s45 , it the same or similar sender related data can be found in the VPN traf fic database . I f no (n) , the process is terminated ("End" ) , and the data packet is assumed to belong to a non-VPN connection .

However, in case the answer is yes ( y) , the situation is as follows : There are two data packets existent with the same sender related data but di f ferent sender IP addresses , one of them being known as IP address used by a VPN service . The conclusion is , that the second IP address is also an IP address used by a VPN service given that the sender related data is the same . The assumption made is that the IP address is a VPN address used but not known so far to the public and/or the operator of the present service , such that by way of having identi fied a data packet with the same sender related data that previously were used in combination with a VPN address , the IP address of the present data packet is also a VPN address . For this reason, this address is then added to the list of VPN addresses in step s46 . In addition, in view of classi fying this IP address as VPN address , an entry is generated in the VPN traf fic database in step s47 , and the entries with the same sender related data are linked therein in step s48 .