Application_Firewall2

Verifying Application Firewall Configuration

To verify your policy configuration, you can send some traffic that should match your policy. You can use a network protocol analyzer such as Wireshark to view the packets. For information about using Wireshark, see “Wireshark” . Be sure to test for both included and excluded users and groups. You should also run tests according to the schedule that you configured, to determine that the policy is in effect when you want it to be. Check for log entries by using the Logging screen in the SonicOS Enhanced user interface.

You can view tooltips on the Policies page when you hover your cursor over each policy. The tooltips show details of the application objects and actions for the policy. Also, the bottom of the Policies page shows the total number of policies and the number of policies currently in use.

Useful Tools

This section describes two software tools that can help you use Application Firewall to the fullest extent. The following tools are described:

Wireshark

Wireshark is a network protocol analyzer that you can use to capture packets from applications on your network. You can examine the packets to determine the unique identifier for an application, which you can use to create an application object for use in an Application Firewall policy.

Wireshark is freely available at: http://www.wireshark.org

The process of finding the unique identifier or signature of a Web browser is illustrated in the following packet capture sequence.

As soon as the capture begins, start the browser and then stop the capture. In this example, Firefox is started.

Hex Editor

You can use a hexadecimal (hex) editor to view the hex representation of a file or a graphic image. One such hex editor is XVI32 , developed by Christian Maas and available at no cost at the following URL:

http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm

For example, if there is a certain graphic contained within all confidential company documents, you could use the hex editor to obtain a unique identifier for the graphic, and then use the identifying hex string to create an application object. You could reference the application object in a policy that blocks the transfer of files with content matching that graphic.

Using the SonicWALL graphic as an example, you would take the following steps:

Alternatively you can mark the block by using the following sequence:

To locate the character in position #49, click on a character in the right pane (the text pane) and then look at the bottom left corner for the decimal address. Try different characters until it shows Adr. dec: 49 . Note that you must click on the corresponding location in the left pane before you press Ctrl+B to mark the block.

When the block is marked, it changes to red font. To unmark a block of characters, press Ctrl+U .

This intermediary step is necessary to allow you to remove spaces from the hex string.

The hex string now has 50 hex characters with no spaces between them.

You now have an Application Object containing a unique identifier for the image. You can create a policy to block or log traffic that contains the image matched by this Application Object. For information about creating a policy, see “Configuring a Policy” .

Use Cases

Application Firewall provides the functionality to handle several types of access control very efficiently. The following use cases are presented in this section:

Policy-Based Intrusion Prevention

SonicWALL Intrusion Prevention Service (IPS) provides organizations with up-to-date signature databases, protecting users from application vulnerabilities as well as worms, Trojans, and peer-to-peer, spyware and backdoor exploits. The extensible signature language used in SonicWALL’s Deep Packet Inspection engine also provides proactive defense against newly discovered application and protocol vulnerabilities.

Although IPS is traditionally configured through the Security Services > Intrusion Prevention screen, when configured within the Application Firewall environment, the administrator is allowed far more granular control over the configuration and actions that can be applied to IPS signatures.

To create an IPS policy in Application Firewall, you must first create an application object of type Signature List or Signature Category List. These two types allow for selection of either individual IPS signatures or general IPS categories. The example below shows an application object targeted at LimeWire and Napster Peer to Peer sharing applications.

After creating a signature-based application object, create a new policy of type Dynamic Content that uses the application object. The example below shows a dynamic content Application Firewall policy which uses the newly created “IPS - Napster and LimeWire P2P” application object to drop all Napster and LimeWire traffic.

Logging IPS Signature-Based Policies

As with other application object policy types, logging can be enabled on dynamic content policies. By default, these logs are displayed in the standard format as shown below, showing the Application Firewall policy that triggered the alert/action.

To use IPS formatted logging, select the Log using IPS message format checkbox in the Application Firewall > Policies > Settings screen for that policy. A log entry using IPS message format is shown below:

Compliance Enforcement

Many businesses and organizations need to ensure compliance with their policies regarding outbound file transfer. Application Firewall provides this functionality in HTTP, FTP, POP3, and SMTP contexts. This can help companies meet regulatory requirements such as HIPPA, SOX, and PCI.

When you configure the policy or policies for this purpose, you can select Direction > Basic > Outgoing to specifically apply your file transfer restrictions to outbound traffic. Or, you can select Direction > Advanced and then specify the exact zones between which to prevent file transfer. For example, you can specify LAN to WAN, LAN to DMZ, or any other zones that you have defined.

Server Protection

Servers are typically accessed by many untrusted clients. For best protection of these valuable resources, you should have multiple lines of defense. With Application Firewall on your gateway, you can configure policies to protect your servers. For example, you can create a policy that blocks all FTP put commands to prevent anyone from writing a file to a server (see “Blocking FTP Commands” ). Even though the server itself may be configured as read-only, this adds a layer of security that is controlled by the firewall administrator. Your server will still be protected even if its configuration is changed by an error, a side-effect of a patch, or by someone with malicious intent. With Application Firewall, you can effectively control content upload for servers using HTTP, SMTP, POP3, and FTP.

An example of policies that affect servers might be a small ISP providing three levels of service to its customers, whose servers are sitting in its rack. At the gold level, a customer can host a Web server, Email server, and FTP server. At the silver level, a customer can host only a Web server and Email server. At the bronze level, the hosting package only allows a Web server. The ISP could use Application Firewall to enforce these restrictions, by creating a policy for each customer.

Hosted Email Environments

A hosted email environment is one in which email is available on a user’s Internet Service Provider (ISP). Typically, POP3 is the protocol used for email transfer in this environment. Many small-business owners use this model, and would like to control email content as well as email attachments. Running Application Firewall on the gateway provides a solution for controlling POP3-based as well as SMTP-based email.

Application Firewall can also scan HTTP, which is useful for email hosted by sites such as Yahoo or Hotmail. Note that when an attachment is blocked while using HTTP, Application Firewall does not provide the file name of the blocked file. You can also use Application Firewall to control FTP when accessing database servers.

If you want a dedicated SMTP solution, you can use SonicWALL Email Security. Email Security is used by many larger businesses for controlling SMTP-based email, but it does not support POP3. For controlling multiple email protocols, Application Firewall provides an excellent solution.

Email Control

Application Firewall can be very effective for certain types of email control, especially when a blanket policy is desired. For example, you can prevent sending attachments of a given type, such as .exe, on a per-user basis, or for an entire domain. Note that you can also do this on your email server if you have one. If not, then Application Firewall provides the functionality.

You can create an application object that scans for file content matching strings such as “confidential”, “internal use only” and “proprietary” to implement basic controls over the transfer of proprietary data.

You can also create a policy that prevents email to or from a specific domain or a specific user. You can use Application Firewall to limit email file size, but not to limit the number of attachments. Application Firewall can block files based on MIME type. It cannot block encrypted SSL or TLS traffic.

Application Firewall can scan email attachments that are text-based or are compressed, but not encrypted. The following table lists file formats that Application Firewall can scan for keywords. Other formats should be tested before you use them in a policy.

Web Browser Control

You can also use Application Firewall to protect your Web servers from undesirable browsers. Application Firewall supplies application object types for Netscape, MSIE, and Firefox. You can define an application object using one of these types, and reference it in a policy to block that browser.

You can also access browser version information by using an HTTP User Agent application object type. For example, older versions of various browsers can be susceptible to security problems. Using Application Firewall, you can create a policy that denies access by any problematic browser, such as Internet Explorer 5.0. You can also use negative matching to exclude all browsers except the one(s) you want. For example, you might want to allow Internet Explorer version 6 only, due to flaws in version 5, and because you haven’t tested version 7. To do this, you would use a network protocol analyzer such as Wireshark to determine the Web browser identifier for IEv6, which is “MSIE 6.0”. Then you could create an application object of type HTTP User Agent, with content “MSIE 6.0” and enable negative matching.

You can use this application object in a policy to block browsers that are not MSIE 6.0. For information about using Wireshark to find a Web browser identifier, see “Wireshark” . For information about negative matching, see “Negative Matching” on page 650 .

Another example of a use case for controlling Web browser access is a small e-commerce site that is selling discounted goods that are salvaged from an overseas source. If the terms of their agreement with the supplier is that they cannot sell to citizens of the source nation, they could configure Application Firewall to block access by the in-country versions of the major Web browsers.

Application Firewall supports a predefined selection of well-known browsers, and you can add others as custom application objects. Browser blocking is based on the HTTP User Agent reported by the browser. Your custom application object must contain content specific enough to identify the browser without creating false positives. You can use Wireshark or another network protocol analyzer to obtain a unique signature for the desired browser.

HTTP Post Control

You can enhance the security of public facing read-only HTTP servers by disallowing the HTTP POST method.

First, use Notepad or another text editor to create a new document called Post.htm that contains the HTML code below. Save the file to your desktop or a convenient location.

<FORM action="http://www.yahoo.com/" method="post">

<p>Please enter your name: <input type="Text" name="FullName"></p>

<input type="submit" value="Submit"> <INPUT type="reset">

Then open the Wireshark network analyzer and start a capture. For information about using Wireshark, see Wireshark, page 661 . In a browser, open the Post.htm form you just created and type in your name and then click Submit . Stop the capture.

Using the Wireshark Edit > Find Packet function, search for the string ‘POST’.

Wireshark will jump to the first frame that contains the requested data. You should see something like the screen shown below. This indicates that the HTTP POST method is transmitted immediately after the TCP header information and is comprised of the first four bytes (504f5354) of the TCP payload (HTTP application layer). You can use that information to create a custom application object that detects the HTTP POST method.

In the SonicOS management interface, navigate to Application Firewall > Application Objects, and then click Add New Object . Create an Application Object like the one shown below. Notice that in this particular application object you would use the Enable Settings feature to create an object that matches a specific part of the payload. The Offset field specifies which byte in the payload to begin matching and helps to minimize false positives by making the match more specific. The Depth field specifies at what byte to stop matching. The Min and Max fields allow you to specify a minimum and maximum payload size.

Next, navigate to Application Firewall > Policies and click Add New Policy . Create a policy like the one shown below.

To test, use a browser to open the Post.htm document you created earlier. Type in your name and then click Submit . The connection should be dropped this time and you should see an alert in the log similar to the one shown below.

Forbidden File Type Control

You can use Application Firewall to prevent risky or forbidden file types (e.g. exe, vbs, scr, dll, avi, mov, etc) from being uploaded or downloaded.

Navigate to Application Firewall > Application Objects and click Add New Object . Create an object like the one shown below.

Next, navigate to Application Firewall > Actions and click Add New Action . Create an action like the one shown below.

To create a policy that uses this object and action, navigate to Application Firewall > Policies and click Add New Policy . Create a policy like the one shown below.

To test this policy, you can open a Web browser and try to download any of the file types specified in the Application Object (exe, vbs, scr). Below are a few URLs that you can try:

http://download.skype.com/SkypeSetup.exe

http://us.dl1.yimg.com/download.yahoo.com/dl/msgr8/us/msgr8us.exe

http://g.msn.com/8reen_us/EN/INSTALL_MSN_MESSENGER_DL.EXE

You will see an alert similar to the one shown below.

ActiveX Control

One of the most useful capabilities of Application Firewall is the ability to distinguish between different types of ActiveX or Flash network traffic. This allows you to block games while permitting Windows updates. Prior to Application Firewall, you could configure SonicOS to block ActiveX with Security Services > Content Filter , but this blocked all ActiveX controls, including your software updates.

Application Firewall achieves this distinction by scanning for the value of classid in the HTML source. Each type of ActiveX has its own class ID, and the class ID can change for different versions of the same application.

Some ActiveX types and their classid’s are shown in the following table.

The screenshot below shows an ActiveX type application object that is using the Macromedia Shockwave class ID. You can create a policy that uses this application object to block online games or other Shockwave-based content.

You can look up the class ID for these Active X controls on the Internet, or you can view the source in your browser to find it. For example, the screenshot below shows a source file with the class ID for Macromedia Shockwave or Flash.

FTP Control

Application Firewall provides control over the FTP control channel, data channel, uploads, and downloads with four available application object types. Using these, you can regulate FTP usage very effectively. The following two use cases are described in this section:

Blocking Outbound Proprietary Files Over FTP

For example, to block outbound file transfers of proprietary files over FTP, you can create a policy based on keywords or patterns inside the files.

First, you would create an application object of type File Content that matches on keywords in files.

Optionally, you can create a customized FTP notification action that sends a message to the client.

Next, you would create a policy that references this application object and action. If you prefer to simply block the file transfer and reset the connection, you can select the Reset/Drop action when you create the policy.

Blocking Outbound UTF-8 / UTF-16 Encoded Files

Native Unicode UTF-8 and UTF-16 support by Application Firewall allows encoded multi-byte characters, such as Chinese or Japanese characters, to be entered as application object content keywords using the alphanumeric input type. Application Firewall supports keyword matching of UTF-8 encoded content typically found in Web pages and email applications, and UTF-16 encoded content typically found in Windows OS / Microsoft Office based documents.

Blocking outbound file transfers of proprietary Unicode files over FTP is handled in the same way as blocking other confidential file transfers. First, create an application object that matches on UTF-8 or UTF-16 encoded keywords in files. Next, create a policy that references the application object and blocks transfer of matching files.

The example shown below uses an application object type of File Content with a UTF-16 encoded Chinese keyword that translates as “confidential document.”

Next, create a policy that references the application object, as shown below. This policy blocks the file transfer and resets the connection. Enable Logging is selected so that any attempt to transfer a file containing the UTF-16 encoded keyword is logged.

A log entry is generated after a connection Reset/Drop. An example of a log entry is shown below, including the Message stating that it is an Application Firewall Alert, displaying the Policy name and the Action Type of Reset/Drop.

Blocking FTP Commands

You can use Application Firewall to ensure that your FTP server is read-only by blocking commands such as put , mput , rename_to , rename_from , rmdir , and mkdir . This use case shows an application object containing only the put command, but you could include all of these commands in the same application object.

The first step is to create an application object that matches on the put command. Because the mput command is a variation of the put command, an application object that matches on the put command will also match on the mput command.

Optionally, you can create a customized FTP notification action that sends a message to the client. A customized action is shown in the screenshot below.

Next, you would create a policy that references this application object and action. If you prefer to simply block the put command and reset the connection, you can select the Reset/Drop action when you create the policy.

Bandwidth Management

You can use application layer bandwidth management to control the amount of network bandwidth that can be used to transfer certain file types. This allows you to discourage non-productive traffic and encourage productive traffic on your network.

For example, you can limit the bandwidth used to download MP3 files over FTP to no more than 400 kilobits per second (kbps). Whether one user or 100 users are downloading MP3 files, this policy will limit their aggregate bandwidth to 400 kbps.

The first step is to enable bandwidth management on the interface that will handle the traffic. You can access this setting on the Network > Interfaces screen of the SonicOS management interface, shown below. For complete instructions, see “Configuring Application Layer Bandwidth Management” .

Next, define an application object of type File Extension for the MP3 file extension.

Next, you can create an application layer bandwidth management action that limits inbound transfers to 400 kbps.

Now you are ready to create a policy that applies the bandwidth management action to the MP3 file extension object.

Bandwidth Management Using IPS Signatures

You can use SonicWALL Intrusion Prevention signatures to create a bandwidth management policy for P2P downloads, rather than matching on filename extensions as in the previous example in the “Bandwidth Management” section .

This use case is also similar to that provided in “Policy-Based Intrusion Prevention” . You must first create an application object of type Signature List or Signature Category List. These two types allow for selection of either individual IPS signatures or general IPS categories.

The example below shows an application object targeted at LimeWire and Napster Peer to Peer sharing applications.

Next, create an application layer bandwidth management action that limits inbound transfers to 1 Mbps. Before you can create this bandwidth management action, you must enable bandwidth management on the interface that will handle the traffic. You can access this setting on the Network > Interfaces screen of the SonicOS management interface. In the example shown below, incoming bandwidth is limited to 1 Mbps on the WAN interface. For configuration instructions, see “Configuring Application Layer Bandwidth Management” .

Next, create an application layer bandwidth management action that limits inbound transfers to 1 Mbps.

Finally, create a new policy of type Dynamic Content that uses the application object. When creating the policy, select your bandwidth management action from the Action drop-down list.

The example below shows a dynamic content Application Firewall policy which uses the “IPS - Napster and LimeWire P2P” application object and the “BWM - 1 Mbps” action to limit the bandwidth to 1 Mbps for incoming Napster and LimeWire traffic.

Bypass DPI

You can use the Bypass DPI action to increase performance over the network if you know that the content being accessed is safe. For example, this might be the case if your company has a corporate video that you want to stream to company employees over HTTP by having them access a URL on a Web server. Since you know that the content is safe, you can create an Application Firewall policy that applies the Bypass DPI action to every access of this video. This will ensure the fastest streaming speeds and the best viewing quality for employees accessing the video.

Only two steps are needed to create the policy. First, you can define an application object for the corporate video using an application object type of HTTP URI Content :

Note that the leading slash (/) of the URL should always be included for Exact Match and Prefix Match types for URI Content application objects. You do not need to include the host header, such as “www.company.com”, in the Content field.

Next, create a policy that uses the Corporate Video application object, and also uses the Bypass DPI action:

Custom Signature

You can create a custom application object that matches any part of a packet if you want to control traffic that does not have a predefined object type in Application Firewall. This allows you to create a custom signature for any network protocol.

For instance, you can create a custom signature to match HTTP GET request packets. You might use this if you want to prevent Web browsing from your local area network.

To determine a unique identifier for a HTTP GET packet, you can use the Wireshark network protocol analyzer to view the packet header. For more information about using Wireshark, see “Wireshark” . In Wireshark, capture some packets that include the traffic you are interested in. In this case, you want to capture a HTTP GET request packet. You can use any Web browser to generate the HTTP GET request . The following image shows a HTTP GET request packet displayed by Wireshark.

In the top pane of Wireshark, scroll down to find the HTTP GET packet, and click on that line. The packet is displayed in the two lower panes. For a SYN packet, the center pane provides a human-readable interpretation of the packet header, and the actual header bytes are displayed in hexadecimal in the lower pane.

In the center pane, expand the Hypertext Transfer Protocol section to see the packet payload and click on the identifier that you want to reference in Application Firewall. In this case, the identifier is the GET command in the first three bytes. Click on this to highlight the corresponding bytes in the lower pane.

You can determine the offset and the depth of the highlighted bytes in the lower pane. Offset and depth are terms used by Application Firewall. Offset indicates which byte in the packet to start matching against, and depth indicates the last byte to match. Using an offset allows very specific matching and minimizes false positives. When you calculate offset and depth, note that the first byte in the packet is counted as number one (not zero). Decimal numbers are used rather than hexadecimal to calculate offset and depth. Offset and depth associated with a custom application object are calculated starting from the packet payload (the beginning of the TCP or UDP payload). In this case, the offset is 1 and the depth is 3.

Now you can create a custom application object that uses this information.

In the Application Object Settings dialog box, type a descriptive name for the object and then select Custom Object from the Type drop-down list. Select the Enable Settings check box. In the Offset text box, type 1 (the starting byte of the identifier). In the Depth text box, type 3 (the last byte of the identifier). You can leave the Payload Size set to the default. The Payload Size is used to indicate the amount of data in the packet, but in this case we are only concerned with the packet header.

For Input Representation, click Hexadecimal . In the Content text box, type the bytes as shown by Wireshark: 474554 . Do not use spaces in hexadecimal content.

The next step is to use this application object in a policy. In the Application Firewall Policy Settings dialog box, type a descriptive policy name and select HTTP Client for the policy type. In the Application Object drop-down list, select the application object that you just defined. Select a custom action or a default action such as Reset/Drop . For the Connection Side, select Client Side . You can also modify other settings. For more information about creating a policy, see “Configuring a Policy” .

Reverse Shell Exploit Prevention

The reverse shell exploit is an attack that you can prevent by using Application Firewall’s custom signature capability (See “Custom Signature” ). A reverse shell exploit could be used by an attacker if he or she is successful in gaining access to your system by means of a Zero-day exploit. A Zero-day exploit refers to an attack whose signature is not yet recognized by security software.

In an early stage while still unknown, malicious payloads can pass through the first line of defense which is the IPS and Gateway Anti-Virus (GAV) running at the Internet gateway, and even the second line of defense represented by the host-based Anti-Virus software, allowing arbitrary code execution on the target system.

In many cases, the executed code contains the minimal amount of instructions needed for the attacker to remotely obtain a command prompt window (with the privileges of the exploited service or logged on user) and proceed with the penetration from there.

As a common means to circumvent NAT/firewall issues, which might prevent their ability to actively connect to an exploited system, attackers will make the vulnerable system execute a reverse shell. In a reverse shell, the connection is initiated by the target host to the attacker address, using well known TCP/UDP ports for better avoidance of strict outbound policies.

This use case is applicable to environments hosting Windows systems and will intercept unencrypted connections over all TCP/UDP ports.

While this use case refers to the specific case of reverse shell payloads (outbound connections), it is more secure to configure the policy to be effective also for inbound connections. This protects against a case where the executed payload spawns a listening shell onto the vulnerable host and the attacker connects to that service across misconfigured firewalls.

The actual configuration requires the following:

Generating the Network Activity

The netcat tool offers – among other features – the ability to bind a program’s output to an outbound or a listening connection. The following usage examples show how to setup a listening “Command Prompt Daemon” or how to connect to a remote endpoint and provide an interactive command prompt:

A Windows prompt will be available to hosts connecting to port 23 (the -l option stands for listen mode as opposed to the default, implicit, connect mode ).

A Windows prompt will be available to host 44.44.44.44 if host 44.44.44.44 is listening on port 23 using the netcat command:

nc -l -p 23

Capturing and Exporting the Payload to a Text File, Using Wireshark

To capture the data, launch Wireshark and click Capture > Interfaces to open a capture dialog. Start a capture on the interface with the netcat traffic. As soon as the capture begins, run the netcat command and then stop the capture.

The following image shows the data flow through the network during such a connection (Vista Enterprise, June 2007):

The hexadecimal data can be exported to a text file for trimming off the packet header, unneeded or variable parts and spaces. The relevant portion here is “Microsoft… reserved.” You can use the Wireshark hexadecimal payload export capability for this. For information about Wireshark, see “Wireshark” .

Creating an Application Object

The following hexadecimal characters are entered as the Object Content of the Application Object representing the Vista command prompt banner:

4D6963726F736F66742057696E646F7773205B56657273696F6E20362E302E363030305D0 D0A436F70797269676874202863292032303036204D6963726F73667420436F72706F726174696F6E2E

Note that fingerprint export and the Application Object definition do not really need to use hexadecimal notation here (the actual signature is ASCII text in this case). Hexadecimal is only required for binary signatures.

Similar entries are obtained in the same manner from Windows 2000 and Windows XP hosts and used to create other Application Objects, resulting in the three Application Objects shown below:

Other examples for Windows Server 2003 or any other Windows version may be easily obtained using the described method.

Linux/Unix administrators will need to customize the default environment variable in order to take advantage of this signature based defense, as the default prompt is typically not sufficiently specific or unique to be used as described above.

Defining the Policy

After creating the Application Objects, you can define a Policy that uses them. The image below shows the other Policy settings. This example as shown is specific for reverse shells in both the Policy Name and the Direction settings. As mentioned, it may also be tailored for a wider scope with the Direction setting changed to Both and a more generic name.

A log entry with a Category of Network Access is generated after a connection Reset/Drop. The screenshot below shows the log entry, including the Message stating that it is an Application Firewall Alert and displaying the Policy name:

As experience suggests, appropriate security measures would include several layers of intelligence and no single approach can be considered a definitive defense against hostile code.

Glossary

Application layer: The seventh level of the 7-layer OSI model; examples of application layer protocols are AIM, DNS, FTP, HTTP, IMAP, MSN Messenger, POP3, SMTP, SNMP, TELNET, and Yahoo Messenger

Client: Typically, the client (in a client-server architecture) is an application that runs on a personal computer or workstation, and relies on a server to perform some operations

Digital rights management: Technology used by publishers or copyright owners to control access to and usage of digital data

FTP : File Transfer Protocol, a protocol for exchanging files over the Internet

Gateway : A computer that serves as an entry point for a network; often acts as a firewall or a proxy server

Granular control : The ability to control separate components of a system

Hexadecimal : Refers to the base-16 number system

HTTP : Hyper Text Transfer Protocol, the underlying protocol used by the World Wide Web

HTTP redirection : Also known as URL redirection, a technique on the Web for making a Web page available under many URLs

IPS : Intrusion Prevention Service

MIME : Multipurpose Internet Mail Extensions, a specification for formatting non-ASCII messages such as graphics, audio, or video, so that they can be sent over the Internet

POP3 : Post Office Protocol, a protocol used to retrieve email from a mail server; can be used with or without SMTP

Proxy : A computer that operates a network service that allows clients to make indirect network connections to other network services

SMTP : Simple Mail Transfer Protocol, a protocol used for sending email messages between servers

UDP : User Datagram Protocol, a connectionless protocol that runs on top of IP networks