Application layer gateways (ALGs) are advanced application-inspecting features available on the SRX that serve two primary purposes. The first is to dynamically pinhole traffic for applications allowing return inbound packets (e.g., for FTP there may be multiple sessions for control and data for the same data connection between the source and destination). The second role of an ALG is to provide a deeper layer of inspection and a more granular layer of application security. ALGs can be better described as extra intelligence built to assist with certain applications that have problems with stateful firewalls.
This type of extra security and inspection is possible because an ALG understands the application protocol and how it is supposed to function. The SRX can prevent many types of SCCP DoS attacks, such as call flooding, from taking place on the network. We will cover these configurable application screens in detail in Chapter 7, but in a nutshell, ALGs are application (Layer 7)-aware packet processing (Layer 4).
It’s worth noting that not all ALGs are available in the higher-end SRX models. For example, at the time of this writing, SCCP and H323 are not available on the high-end SRX devices, while the branch SRX Series has full support for all listed ALGs.
Here is a list of ALGs currently built into the SRX, along with a brief explanation of what each one does:
RealAudio/RealVideo are proprietary formats developed by RealNetworks and they use what is called Progressive Network Audio (PNA) or Progressive Network Media (PNM) to send streaming audio data. PNA packets are sent over a TCP connection and act like a control channel. The audio data itself is sent over a UDP connection. The ALG dynamically allows these UDP data connections and performs any NAT that needs to take place.
Real-Time Streaming Protocol is used to establish and control media connections between end hosts. RTSP handles all client-to-media server requests such as play and pause, and is used to control real-time playback of the media files from the server. RTSP does not, however, stream any media data. Commonly, that is left to Real-time Transport Protocol (RTP), and the two are used in combination to deliver media to the clients.
The Domain Name System ALG monitors DNS queries and
response packets. Since DNS is UDP and is a simple request-response
type of flow, the DNS ALG monitors for the
response flag and then closes down the UDP
session. This is very useful; otherwise, the SRX would wait two
minutes before timing out the session, which is the default for
The File Transfer Protocol ALG monitors the FTP connection for PORT, PASV, and 227 commands. The ALG will handle all NAT functions and pinholing of any additional ports necessary. Additional security options can be leveraged by configuring the FTP ALG to block specific FTP functions, such as FTP put or FTP get.
TALK is a legacy chat-type application for Unix platforms developed in the early 1980s. TALK communicates on UDP port 517/518 for control-channel-type functions. The TALK ALG will handle all NAT functions in addition to any pinholing that needs to take place.
RSH stands for Remote Shell. RSH is a Unix-type program that can execute commands across a network. RSH typically uses TCP port 514. RSH has largely been replaced by SSH as RSH communicates unencrypted. The RSH ALG handles all NAT functions as well as any pinholing that needs to take place.
Point-to-Point Tunneling Protocol is a Layer 2 protocol used for tunneling PPP over an IP network. PPTP is often used as a way to implement virtual private networks (VPNs) and is tunneled over TCP and a Generic Route Encapsulation (GRE) tunnel encapsulating the PPP packets. The PPTP ALG handles all NAT functions and pinholing for functions of PPTP, such as Call IDs of PAC and PNS.
The Structured Query Language ALG handles SQL TNS response frames and then evaluates the packet for IP address and port information. The SQL ALG handles all NAT functions and pinholing for the TCP data channel.
This is a suite of protocols that provides audio-visual communication sessions over an IP network. The H.323 standard includes call signaling, call control, multimedia transport, multimedia control, and bandwidth control. The H323 ALG handles all NAT functions in addition to gatekeeper discovery, endpoint registration/admission/status, and call control/call setup. The H323 ALG also has many application screens that provide additional protections at an application level.
Session Initiation Protocol is a signaling protocol used for initiating, modifying, and terminating multimedia sessions such as voice and video calls over IP. The SIP ALG on the SRX only supports Session Description Protocol (SDP), even though SIP can use a variety of different description protocols to describe the session. The SIP ALG monitors SIP connections and dynamically pinholes for the SIP traffic.
Skinny Client Control Protocol is a Cisco protocol for VoIP call signaling to the Cisco CallManager. The SCCP ALG will look within the control packets and allow the RTP port number and IP address of the media termination, dynamically pinholing for the RTP flows. In addition to pinholing, the SCCP ALG also handles all NAT functions and application layer protections.
Media Gateway Control Protocol is a signaling and call control protocol used in VoIP between the media gateway and media controller. The MGCP ALG handles the dynamic pinholing for any additional connections needed, as well as handling all NAT functions. The MGCP ALG also inspects the VoIP signaling data and ensures that it complains to RFC standards blocking any malformed packets or attacks. Additional application layer protections are also configurable within the ALG.
Remote Procedure Call is a secure interprocess communication that handles data exchange and invocation to a different process, typically to a machine on the local network or across the Internet. The RPC ALG handles dynamic port negotiation and pinholing as well as all NAT functions.
IKE (Internet Key Exchange) and ESP (Encapsulating Security Payload) are a part of the IP Security (IPsec) protocol. In situations where the SRX is inline and an IPsec VPN passes through the SRX and NAT is enabled, IPsec VPNs can have issues. This is a common problem with IPsec and address translation. The IKE/ESP ALG should help with that problem, enabling the SRX to go inline and not interfere with VPN flows.
ALGs all perform the same type of function: they inspect the applications control channel and handle either NAT, dynamic pinholing of ports, or both. The ALG process does not inspect or monitor the actual data channel, something to keep in mind when working with ALGs.
To view which ALGs are currently enabled on the SRX, use the
show security alg status command to
display the ALGs:
show security alg statusALG Status : DNS : Enabled FTP : Enabled H323 : Enabled MGCP : Enabled MSRPC : Enabled PPTP : Enabled RSH : Enabled RTSP : Enabled SCCP : Enabled SIP : Enabled SQL : Enabled SUNRPC : Enabled TALK : Enabled TFTP : Enabled
From the trust network the web administrators are now requesting FTP access to the web1 server so that files can be uploaded to the server. In a secured network, their request should be denied because FTP transmits everything in clear text as it is an insecure protocol. The web administrators should be told to use SFTP. However, for this example, let’s assume that SFTP is not available and FTP must be used. Sadly, cases such as this widely exist due to many legacy platforms and applications.
Enabling the FTP ALG is simple, since there is already a policy that allows the web administrators to connect to the web-dmz:
show security policies from-zone trust to-zone web-dmzFrom zone: trust, To zone: web-dmz Policy: webdmz_mgt, State: enabled, Index: 8, Sequence number: 1 Source addresses: any Destination addresses: web-servers Applications: web_mgt Action: permit, log Policy: web_deny, State: enabled, Index: 9, Sequence number: 2 Source addresses: any Destination addresses: any Applications: any Action: deny, log
All we need to do is add the Junos-FTP service to the
set applications application-set web_mgt application junos-ftp juniper@SRX5800#
commit and-quitcommit complete Exiting configuration mode
Look at the applications the Junos-FTP service shows under
show configuration applications application-set web_mgtapplication junos-ssh; application junos-ping; application junos-pc-anywhere; application windows_rdp; application junos-http; application junos-ftp;
A more detailed look at the
webdmz_mgt policy shows the new ALG
show security policies from-zone trust to-zone web-dmzpolicy-name webdmz_mgt detail Policy: webdmz_mgt, action-type: permit, State: enabled, Index: 8 Sequence number: 1 From zone: trust, To zone: web-dmz Source addresses: any: 0.0.0.0/0 Destination addresses: web2: 10.2.0.2/32 web1: 172.31.100.60/32 Application: web_mgt IP protocol: tcp, ALG: 0, Inactivity timeout: 1800 Source port range: [0-0] Destination port range: [22-22] IP protocol: 1, ALG: 0, Inactivity timeout: 60 ICMP Information: type=255, code=0 IP protocol: udp, ALG: 0, Inactivity timeout: 60 Source port range: [0-0] Destination port range: [5632-5632] IP protocol: tcp, ALG: 0, Inactivity timeout: 1800 Source port range: [1024-65535] Destination port range: [3389-3389] IP protocol: tcp, ALG: 0, Inactivity timeout: 1800 Source port range: [0-0] Destination port range: [80-80] IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800 Source port range: [0-0] Destination port range: [21-21] Session log: at-create, at-close
Let’s confirm that FTP does work to the server and that the web administrators can now upload their files as needed:
open 172.31.100.60Connected to 172.31.100.60. 220-FileZilla Server version 0.9.34 beta 220-written by Tim Kosse (Tim.Kosse@gmx.de) 220 Please visit http://sourceforge.net/projects/filezilla/ Name (172.31.100.60:tle4729): 331 Password required for tle4729 Password:
Now view this connection on the SRX:
show security flow session application ftpSession ID: 11663, Policy name: webdmz_mgt/8, Timeout: 788 In: 10.1.1.100/59832 --> 172.31.100.60/21;tcp, If: ge-0/0/0.0 Out: 172.31.100.60/21 --> 10.1.1.100/59832;tcp, If: fe-0/0/2.0 Session ID: 11664, Policy name: webdmz_mgt/8, Timeout: 790 In: 10.1.1.100/59834 --> 172.31.100.60/21;tcp, If: ge-0/0/0.0 Out: 172.31.100.60/21 --> 10.1.1.100/59834;tcp, If: fe-0/0/2.0 2 sessions displayed
Voilà! Some ALGs are simple to set up, as easy as using the prebuilt Junos application. ALGs such as FTP, TFTP, and DNS are perfect examples of this type of ALG. Other, more complex ALGs have more optional configuration knobs.
Our second ALG configuration example concerns the SIP ALG. The SIP ALG has a lot more configuration options than the FTP ALG, but the SIP ALG is applied in the same way the FTP ALG is applied: via security policy and Junos-SIP as the application.
Although SIP has various configuration knobs under the
security alg sip stanza, I’ll cover just a few
here. First, set the SIP ALG
maximum-call-duration setting to 1,000 minutes
(that’s more than 15 hours!):
set security alg sip maximum-call-duration 1000
The next optional configuration is the timeout value (this value is in seconds):
set security alg sip inactive-media-timeout 60
Overall, the SIP ALG is pretty easy to set up and configure.
Problems arise when vendors do not follow RFC guidelines or they write
their own one-off SIP implementations. If issues start after the SIP ALG
is configured, the primary things to check are the SIP counters for
errors. For inoperability issues, one possible workaround is to enable
unknown-message option; by
default, the SRX’s SIP ALG drops all unsupported messages for security
purposes. Note that this disables that security feature:
set security alg sip application-screen unknown-messagepermit-routed
Another common issue is when vendors implement proprietary headers into their SIP packets. Per standards, the call-id header should contain a hostname or source IP address, and in some cases, vendors adjust or change this. To disable the call-id enforcement use the following:
set security alg sip disable-call-id-hidingjuniper@SRX5800#
edit security policies from-zone trust to-zone voip-dmz
Once that has been applied, the base SIP configuration is
finished. SIP calls can be made and should have no problems going
through. Let’s verify the SIP stats by using the
show security alg sip counters command to view
the counters, including errors on decoding packets:
show security alg sip countersMethod T 1xx 2xx 3xx 4xx 5xx 6xx RT RT RT RT RT RT RT INVITE 2 1 0 0 2 0 0 0 0 0 0 0 0 0 CANCEL 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ACK 2 0 0 0 0 0 0 0 0 0 0 0 0 0 BYE 0 0 0 0 0 0 0 0 0 0 0 0 0 0 REGISTER 28 0 8 0 20 0 0 0 0 0 0 0 0 0 OPTIONS 0 0 0 0 0 0 0 0 0 0 0 0 0 0 INFO 0 0 0 0 0 0 0 0 0 0 0 0 0 0 MESSAGE 0 0 0 0 0 0 0 0 0 0 0 0 0 0 NOTIFY 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PRACK 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PUBLISH 0 0 0 0 0 0 0 0 0 0 0 0 0 0 REFER 0 0 0 0 0 0 0 0 0 0 0 0 0 0 SUBSCRIBE 0 0 0 0 0 0 0 0 0 0 0 0 0 0 UPDATE 0 0 0 0 0 0 0 0 0 0 0 0 0 0 BENOTIFY 0 0 0 0 0 0 0 0 0 0 0 0 0 0 SERVICE 0 0 0 0 0 0 0 0 0 0 0 0 0 0 OTHER 0 0 0 0 0 0 0 0 0 0 0 0 0 0 SIP Error Counters: Total Pkt-in : 76 Total Pkt dropped on error : 13 Transaction error : 0 Call error : 0 IP resolve error : 0 NAT error : 0 Resource manager error : 0 RR header exceeded max : 0 Contact header exceeded max : 0 Call Dropped due to limit : 0 SIP stack error : 0 SIP decode error : 13 SIP unknown method error : 0 RTO message sent : 0 RTO message received : 0 RTO buffer allocation failure : 0 RTO buffer transmit failure : 0 RTO send processing error : 0 RTO receive processing error : 0 RTO receive invalid length : 0
To view a higher-level overview of calls, use the
show security alg sip calls command as the
optional detail flag at the end to display even more information about
show security alg sip callsTotal number of calls: 2 (# of call legs 4) Call leg1: zone 3 UAS callid:firstname.lastname@example.org (pending tsx 1) Local tag Remote tag: 120ed748111212e264b0a951-5cbb0a95 State: STATE_DISCONNECTED Call leg2: zone 2 UAC callid:email@example.com (pending tsx 1) Local tag: 120ed748111212e264b0a951-5cbb0a95 Remote tag State: STATE_DISCONNECTED Call leg1: zone 3 UAS callid:firstname.lastname@example.org (pending tsx 1) Local tag: 120f90542e7e64cd724880f5-65db2f99 Remote tag: 120ed748111212e264b0a951-5cbb0a95 State: STATE_ESTABLISHED Call leg2: zone 2 UAC callid:email@example.com (pending tsx 1) Local tag: 120ed748111212e264b0a951-5cbb0a95 Remote tag: 120f90542e7e64cd724880f5-65db2f99
To view transactions, use the
security alg sip transaction command:
show security alg sip transactionTotal number of transactions: 1 Transaction Name Method CSeq State Timeout VIA RSC ID UAS:gsn0x5a06ddf1 BYE 101 Proceeding −1 - UAC:gsn0x5a06f615 BYE 101 Calling 25 8184
And to view the overall health of the SIP ALG, use
show security alg sip rate:
show security alg sip rateCPU ticks per microseconds is 3735928559 Time taken for the last message is 0 microseconds Total time taken for 0 messages is 0 microseconds(in less than 10 minutes) Rate: 3735928559 messages/second
ALGs provide an additional layer of security and handle NAT as well as dynamic pinholing when needed. With that deeper layer of inspection come more processing and additional potential problems. Oftentimes when Juniper writes ALGs, they are written to follow and enforce RFC specifications. The problem most commonly comes when vendors write one-off applications or their own additions to the protocol, or to the service, and the ALG doesn’t know how to properly handle it.
Juniper has incorporated as many workarounds as possible, such as
unknown-message, in the SIP ALG. However,
sometimes issues still occur. In these events, the only option may be to
open more port ranges than the vendor has provided.