KR20100025801A - Spf system for blocking spam and method of querying in voip - Google Patents

Abstract

PURPOSE: An SPF spam blocking system and an SPF query method in a VoIP method using an SPF query/analysis are provided to accurately analyze a spammer through the SPF query/analysis in an SPF spam blocking system. CONSTITUTION: A caller information extractor(410) extracts sending domain information from the invite message received a message from originator. A domain identifying unit(420) uses the IP address and via field of the calling domain and decides the originator belongs to the same domain. An SPF(Sender Policy Framework) query/analysis device(430) questions to a DNS(Domain Name Service) server in the originator policy framework. According to the spam blocking device is result, the invite message is secluded.

Description

SPF System for Blocking Spam and Method of Querying in VoIP}

The present invention relates to a sender policy framework (hereinafter referred to as SPF) spam blocking system and an SPF query method in a voice over internet protocol (hereinafter referred to as VoIP). The present invention relates to a system and a method for effectively blocking spam by making an SPF query to a sending domain.

In the conventional spam response technology, the spam response technology for email spam can be blocked before receiving spam through content filtering because email spam is text-based.

However, in case of VoIP spam, it is difficult to pre-filter calls received from an unspecified number due to the characteristics of telephone service, and there is a vulnerability in the protocol itself that email sender identity can be manipulated in VoIP spam as email spam has anonymity vulnerability.

In addition, the VoIP environment may send spam when the Internet is available, and since it is difficult to find a geopolitical address only by a logical address such as an IP address, there is a problem that real-time tracking of spammers is practically impossible.

The present invention has been proposed to overcome the prior art as described above, SPF query / analysis can be applied not only in the receiving domain but also in the source domain in the VoIP environment, spam blocking system for accurately classifying spammers through SPF query / analysis and We want to provide an SPF query method used for it.

SPF spam blocking system according to an embodiment of the present invention for solving the above problems is a caller information extraction device for extracting the information of the originating domain from the invite message received from the sender; A domain identification device for determining whether the sender belongs to the same domain as the receiver by using the information of the originating domain; An SPF query / analysis apparatus for making an SPF query to a DNS server and analyzing the results; And a spam blocking device that blocks the invite message according to the result analyzed by the SPF query / analysis apparatus, wherein the SPF query / analysis apparatus performs SPF query and analysis using an IP address and a Via field.

SPF query method according to an embodiment of the present invention for achieving the above object comprises the steps of receiving an invite message from the sender and extracting information of the originating domain; Determining whether the sender belongs to the same domain as the receiver by using the information of the calling domain; If the sender and the receiver do not belong to the same domain, performing an SPF query and analysis with a DNS server; And blocking the invite message according to the result of the analysis in the step of performing the SPF query and analysis, wherein the step of performing the SPF query and analysis performs the SPF query and analysis using the IP address and the Via field.

In the VoIP environment according to the present invention, the SPF system and the SPF query method for blocking spam have an effect of reducing network traffic and computational resources necessary for checking whether or not forgery / falsification of originating domain information. In addition, the task of checking whether the originating domain information is forged / falsified is not only burdened with the receiving domain, but it is burdened and applied to all receivers, thereby extending the scope of application of the technology.

1 is a diagram illustrating an outgoing path authentication process according to the present invention.

VoIP authentication is only valid within a single domain. Therefore, since the information of the outgoing call including the sender information can be manipulated on the intermediate route, a technique for authenticating the route of the calling domain is required. In the VoIP service, the SPF query / verification process is mainly performed in the inbound domain, but in the present invention, the SPF query / verification is also performed in the inbound and outbound domains.

The SIP_Proxy_Out server 21 issues the SPF record shown in FIG. 2 to the DNS_O server 22.

The SIP_Proxy_Out server 21 forwards the invite message as shown in FIG. 3 to the Via domain (S2), and the caller information extraction device of the SIP_Proxy_Via server 31 belonging to the Via domain parses the Via field of the invite message. Parsing to get information of the originating domain. Since the Via field is a mandatory header in RFC3261, callers such as the SIP_Proxy_Out server 21 always insert their domain information into the Via field. In addition, the sender information extracting apparatus of the SIP_Proxy_Via server 31 parses the source IP address of the IP header to obtain the address of the sender (here outbound domain).

In order to compare the URI and the originating address of the byte message parsed through the above process, the SPF record for the originating URI must be obtained from the DNS server. Therefore, DNS server queries / analyzes the origin URI of the invite message and determines whether or not it is a normal sender.

The reason why the Via field is used can be seen by examining the case where the IP address and the From field are used for caller authentication. The SIP_Proxy_Via server 31 has the IP address "10.1.1.1" of the sender (here SIP_Proxy_Out server) recorded in the byte message on the DNS_O server 22 side and the From header "<sip: abc@outbound.org>" valid. Inquire about the sender's IP address and the From header. In response, the DNS_O server 22 confirms that the IP address and the From header are identical in the SPF record, and thus responds with "pass". Meanwhile, the SIP_Proxy_Via server 31 records the IP address of the IP header as its IP address, and then transfers the invite message to the inbound domain 400 (S5).

The SIP_Proxy_In (41) server of the inbound domain is assigned the IP address of the valid sender's IP address "10.1.2.1" and the From header "<sip: abc@outbound.org>" Run an SPF query to see if it is a From header.

The SPF query means that the proxy server sends a command to the domain server to determine whether the domain name stored in the Via field of the byte message and the IP address address match the SPF record issued by the SIP_Proxy_Out server mentioned above. The domain server determines whether the domain name stored in the Via field and the address value of the IP field match with the SPF query, and sends a response message to the proxy server.

The IP field is replaced with the IP address of the sender (sender) each time an invite message is delivered. Therefore, DNS_Via server 32 determines that the sender's IP address and the From header are different from those stored in the SPF record, and responds with "fail". Using the IP address and the From field, it is impossible to determine whether the sender is a valid sender when the bytes are transferred to another domain.

On the other hand, let's take a look at the case of SPF query using Via field instead of From header. Only the process of S5 described above will be described. The SIP_Proxy_Via server 31 transmits an invite message to the SIP_Proxy_In server 41 (S5). In the Via field, the sender (sender) SIP_Proxy_Via is recorded. The SIP_Proxy_In server 41 receiving the byte message checks whether the IP address "10.1.2.1" and the Via field "SIP_Proxy_Via" of the byte message received from the DNS_Via server 32 are valid sender's IP address and Via field. Do an SPF query. The DNS_Via server 32 responds with "pass" to the SIP_Proxy_In server 410 because the IP address and Via field of the byte message stored in the SPF record match. By using the IP address and the Via field, it is possible to accurately determine whether the sender is a valid sender even when the bytes are transferred to another domain.

In order to verify outbound domains in SIP-based SPF, whether or not to process the invite message is determined based on the result of SPF query / analysis. However, in all other cases except pass, it is desirable to process in conjunction with other spam blocking solutions rather than blocking the call immediately.

The result value of the SPF query can be arranged as shown in Table 1 below.

division Explanation Non The originating domain does not have an SPF record installed, or the domain information cannot be obtained from the provided sender information, indicating that the SPF verification apparatus cannot determine whether the originating domain is forged. Neutral Indicates that the outbound call server does not want to determine whether the call originated from a forgery. The treatment of a call that is determined to be "neutral" is treated the same as a "non" decision and this option is used during the SPF test run and so forth. Pass It determines that the message is legitimate and forwards the message to the next hop. Fail It determines that the message is not legitimate and works with other spam blocking solutions without forwarding the message to the next hop. Temperror As this is a temporary error during the DNS query process, the DNS query / analysis is once again performed. Tribal (Softfail) As with "failure," the outbound call server determines that it is not legitimate and links it with other spam blocking solutions. Permerror This is a result value when an unrecoverable error occurs during the query / analysis process of DNS. Therefore, the query / analysis process is not performed any more, and it is linked with other spam blocking solutions.

SIP-based SPFs, unlike email-based SPFs, do not process the SPF processing result values later in the header information, but instead drive virtual spam blocking solutions for calls that do not turn out to be "passed" when an incoming message is received. The spam information device does not design a solution for the actual spam blocking, but merely allows the SPF result value to be linked with other spam blocking solutions in the future and records the result in a log file.

2 is a diagram illustrating an example of issuing an SPF record, and FIG. 3 is a diagram illustrating an example of an invite message.

4 is a diagram illustrating an SPF system according to the present invention. SPF spam blocking system 400 of the present invention comprises a caller information extraction device 410 for extracting the sender information from the invite message received from the sender; A domain identification device (420) for determining whether the sender belongs to the same domain as the receiver by using the sender's information; An SPF query / analysis apparatus 430 for making an SPF query to a DNS server and analyzing the result; And a spam blocking device 440 blocking the invite message according to the result analyzed by the SPF query / analysis apparatus. This SPF spam blocking system is a system for performing the sender authentication described above, and may be included in each proxy server.

As described above, the SPF spam blocking system 400 makes an SPF query using the IP address and the Via field to confirm whether the originating domain information is forged or forged. The reason why the Via field is used for verifying outgoing domain information is that replacing the Via field is a simple process, the Via field is an essential header in the RFC 3261 specification. Because you can check.

The spam blocking device 440 may block the invite message when the result of the SPF query is inconsistent. Of course, the results can be stored in the spam information device in order to interoperate with other spam solutions without blocking.

The SPF spam blocking system 400 may further include an authentication device for proxy authentication of the invite message between the sender and the receiver belonging to the same domain. After proxy authentication, the call is forwarded to the destination proxy server.

The SPF spam blocking system 400 may further include a spam information device that stores the result analyzed by the SPF query / response device in the form of a log file. As mentioned above, SIP-based SPFs, unlike email-based SPFs, do not process SPF processing result values later in the header information, but rather SPF result values for calls that do not turn out to be "passed" when an incoming message is received. The result can be recorded in the form of a log file so that it can be linked with other anti-spam solutions later.

The SPF query / analysis apparatus 430 of the SPF spam blocking system 400 includes: a parser for parsing a sender's IP address and a Via field from the invite message; An SPF query / response unit for making an SPF query to a DNS server and receiving a corresponding response message; And it may include an analysis unit for analyzing the response message received by the SPF query / response unit.

SPF query means to check the DNS server to see if the IP address and Via field of the byte message match the SPF record. In the conventional email-based service, since the Via field does not exist in the invite message, the response of the SPF query is "fail" when the message is delivered to another domain as described above. Therefore, in the present invention, the SPF query / analysis is performed using the Via field in the VoIP environment.

5 is a flow chart showing the process of the SPF query method according to the present invention. SPF query method according to the present invention comprises the steps of receiving an invite message from the sender and extracting the sender's information (S510); Determining whether the sender belongs to the same domain as the receiver (S520); Performing a SPF query and analysis with a DNS server (S530); And blocking the invite message according to the result of the analysis in the step of performing the SPF query and analysis (S540). The steps for querying and analyzing the SPF use the IP address and Via fields of the invite message as mentioned above.

If the sender and receiver belong to the same domain, the SPF system replaces the sender verification with proxy authentication because it is a message paper in the same domain. On the other hand, if the sender does not belong to the same domain as the receiver, the message is delivered from another domain, so the SPF query / analyze process determines whether the sender has forged / modulated the message.

Tables 2 and 3 are tables showing experimental examples of the SPF spam blocking system. In the experiment, 28 normal callers and 2 spammers made the call. 28 normal callers each make 100 calls. Two spammers fake 100-byte messages and each send 100 spam calls. Tables 2 and 3 compare and compare the features of the SPF query with and without. If no SPF query is made, half of the spam calls are considered normal. In contrast, SPF queries correctly classify spam calls. As shown in Table 2 and Table 3, applying the SPF query to the spam blocking system shows that the spam blocking ability is improved.

characteristic If you did not query the SPF If you query SPF Normal arc 2,800 2,800 Spam issue 100 200 Misjudged by a normal call 0 0 Incorrectly determined to be spam 100 0 Spam Call Count (Actual) 200 200 Normal number of arcs (actual) 2,800 2,800

characteristic If you did not query the SPF If you query SPF Error positive rate 0% 0% Error negative rate 50% 0% Error rate 3% 0% accuracy 97% 100% Recall 50% 100% Precision 100% 100%

The present invention described above is limited to the above-described embodiments and the accompanying drawings as various changes and modifications can be made within the scope without departing from the technical spirit of the present invention for those skilled in the art. It doesn't happen.

1 is a diagram showing an SPF spam blocking system according to an embodiment of the present invention.

2 illustrates an SPF record according to an embodiment of the present invention.

3 is a diagram illustrating an invite message according to an exemplary embodiment of the present invention.

4 is a diagram illustrating a configuration of an SPF spam blocking system according to an embodiment of the present invention.

5 illustrates an SPF query method according to an embodiment of the present invention.

Claims (10)

A sender information extraction device for extracting information of the originating domain from the invite message received from the sender; A domain identification device for determining whether the sender belongs to the same domain as the receiver by using the information of the originating domain; A sender policy framework query / analysis apparatus for making a sender policy framework query to a DNS server and analyzing the result; And And a spam blocking device to block an invite message according to a result analyzed by the sender policy framework query / analysis device. And the sender policy framework query / analysis apparatus performs a caller policy framework query and analysis using an IP address and a Via field. The method of claim 1, The sender policy framework spam blocking system further comprises an authentication device for proxy authentication to the invite message if the sender and the receiver belong to the same domain. The method of claim 1, Sender policy framework spam blocking system further comprises a spam information device for storing the results analyzed by the sender policy framework query / analysis device in the form of a log file. The method of claim 1, The sender policy framework query / analysis device, A parsing unit for parsing an IP address and a Via field of an originating domain from the invite message; A sender policy framework query / responder that queries the DNS server for a sender policy framework and receives a corresponding response message; And An analysis unit for analyzing a response message received by the sender policy framework query / response unit; And the sender policy framework query verifies the DNS server whether the IP address and Via field of the invite message match the sender policy framework record. The method of claim 4, wherein The spam blocking device, And if the IP address and the Via field of the invite message and the sender policy framework record do not match, blocking the invite message. Receiving an invite message from the sender and extracting information of the originating domain; Determining whether the sender belongs to the same domain as the receiver by using the information of the calling domain; If it is determined in the determining step that the sender does not belong to the same domain as the receiver, performing a query and analysis of the sender policy framework to a DNS server; And Blocking the invite message according to the result of the analysis in the step of querying and analyzing the sender policy framework; The step of querying and analyzing the sender policy framework comprises: calling and analyzing the sender policy framework using an IP address and a Via field. The method of claim 6, And if the sender is determined to belong to the same domain as the receiver, performing the proxy authentication. The method of claim 6, And storing the results of the analysis in the form of a log file in the step of querying and analyzing the sender policy framework. The method of claim 6, The querying and analyzing the sender policy framework may include: Querying the DNS server for the sender policy framework; Receiving a response of a sender policy framework query from the DNS server; And Analyzing the results of the sender policy framework query and response, And the calling party policy framework query checks the DNS server whether the IP address and the Via field of the invite message match the calling party policy framework record. The method of claim 9, Blocking the invite message, And if the IP address and the Via field of the invite message and the sender policy framework record do not match, block the invite message.

Images