Internet Service DB (ISDB) on Fortigate

A  feature called Internet service DB(ISDB) is introduce on ForitOS. Using this feature you could write firewall policy and Route and ask Fortigate to take Necessary action based on the Application IP DB it has.

This feature was introduced in FortiOS v5.4 and above. NOTE: ISDB updates require active FortiCare support contact, no FortiGuard subscription required.

During FortiOS v5.2 days  you could create a firewall policy with FQDN to Block/Allow users based  website Hostname. However that is no more an option from v5.4 and above(not supported)

Blocking/allowing user access based on Public Application IP address is not a easy task. There will be dozens of IP address “Ex: Facebook an Google” and its not easy to manage the IP DB by Every one, While new IP address’s will always get added to this list.

So , You could now take advantage of this feature ISDB and manage the Dynamic changes of IP address.

 

>While running the following command will show you the available and updated signature DB on fortigate. And you should see ISDB also showing up there.

# diagnose autoupdate versions

>Inorder to list out the IPs address on DB for a particular Application (or)  can see through GUI also.

# diagnose firewall internet-service list 3604481

‘3604481’ is application ID for Github-Web.

NOTE: I have chosen Application GitHub just for my examples.

>FortiOS also lets you to create your own custom ISDB, this helps customer to manage their own list on top of what FortiOS is offering. You could list your custom object after you create one like below.

# diagnose firewall internet-service-custom list

List internet service in kernel(custom):
name=Git-custom, id=4294901760 flags=0x0 protocol=6 port=80-65535 1-65535
addr ip range(1): 200.X.X.X-200.X.X.X

 

>You could also Add more IP address that you feel ISDB missing for an application by just creating a custom object mentioning the master-service-id

# config firewall internet-service-custom

(internet-service~tom) #

(internet-service~tom) # show
config firewall internet-service-custom
edit “Git-custom”
set master-service-id 3604481
set comment “git”
config entry
edit 1
set protocol 6
config port-range
edit 1
set start-port 80
next
edit 2
next
end
set dst “x.x.x.x”
next
end
next
end

 

>You could create a firewall policy with Existing Internet service DB available or customer Internet service DB created while also doing route control.

Advertisements

FortiGate on SIP/ALG/Session Helper

If you are looking for some idea on change/tweak on fortigate for SIP/VoIP traffic,  I believe the below details could give help you a bit of insight on configuring Fortinet for your SIP/VoIP design. I know there are other Fortinet Experts who already shared some idea related to this Topic. This is just my version of the same and with some add-ons!!

When to use”session helper” && “Voip-ALG(Kernel mode)” && “Voip-ALG(Proxy mode)”??

Type of SIP VoIP design:

Peer to peer configuration

SIP proxy server configuration

 

 

SIP redirect server configuration

 

SIP registrar configuration

SIP with a FortiGate running Transparent Mode

 

SIP network with FortiGate running NAT/Route Mode:

 

Tweaking your Fortigate  based on your design requirements for SIP VoIP Traffic :

*SIP sessions using port 5060 accepted by a security policy that does not include a VoIP profile are processed by the “SIP session helper”.

*Session helper + Fortigate VoIP ALG mode “Kernel Mode” = SIP session offload, SDP conversion happens with RTP session pin hole

*Fortigate VoIP ALG mode “Proxy Mode”(ALG)  = More SIP ALG features and RTP Session pin hole.

*Fortigate VoIP ALG mode “kernel Mode” + Disable Session Helper = no SIP ALG on fortigate.

 

By default FortiOS uses the Proxy Mode SIP ALG for SIP traffic. If you want to use the SIP session helper you need to enter the following command:

config system settings

set default-voip-alg-mode kernel-helper-based

end

NOTE: Also remove SIP session helper profile under”config system session-helper”

In most cases you would want to use the SIP ALG since the SIP session helper provides limited functionality. However, the SIP session helper is available and can be useful for high-performance solutions where a high level of SIP security is not a requirement.

 

#Key Things you should understand#

*Controlling NAT for addresses in SDP lines
You can use the no-sdp-fixup option to control whether the Fortigate performs NAT on addresses in SDP lines in the SIP message body.

The no-sdp-fixup option is disabled by default and the FortiGate performs NAT on addresses in SDP lines. Enable this option if you don’t want the FortiGate to perform NAT on the addresses in SDP lines.

config voip profile

edit VoIP_Pro_1

config sip

set no-sdp-fixup enable

end

end

 

*How the SIP ALG performs NAT :

I see this as an important portion to understand atleast while working with fortigate firewalls.

NAT with SIP gets bit complex because of IP and Port Number used in SIP message Header and Bodies. When a SIP caller on private network calls the phone server or SIP phone on internet, the SIP ALG must translate the private network addresses to internet valid IP and port numbers. And when receiving the response message to the caller, the SIP ALG must translate back to valid private network address.

Additionally, the media stream generated by SIP session are independent SIP message and use different port numbers during media session. Based on the information in the SIP message the SIP ALG opens pinholes to accept media stream and perform port translation on media stream.

When SIP ALG receives an INVITE message, fortigate extracts information like port number and IP address and stores it in SIP Dialog table. This is similar to IP session table and this data is used for subsequent SIP message that are part of same call.

ALG then using the information in SDP field helps reserve port number and IP address for media session and create NAT mapping between ports in the SDP field. Normally SDP uses sequential ports for the RTP and RTCP channels and ALG provides consecutive even-odd ports.

 

 

COA | Change Of Authorization

COA | Change of authorization
RFC 3576
UDP port 3766 | IEEE

>Change of authorization is used to ask NETWORK SWITCH/ROUTER/WIFI-CONTROLLER to disconnect-user, session timeout, bounce port of the existing user session on network.
>Mostly AAA server is user to record the user accounting information and based on the user activity or time the user is then disconnected from the network or session timed out.
>The Network device will send the accounting information to a AAA server.
>The AAA server keeps track of user information like Device MAC-ADDRESS, User SESSION-ID, USERNAME, FRAMED-IP-ADDRESS and more based on what it gets from accounting request.
>The radius accounting request traffic will be send only after a successful authentication.
>You could configure to send interim accounting update about the user to accounting server.This interim update can help in scenarios where you want to disconnect the user after usage of certain amount of bandwidth in network. Default time:300 Sec

#Things to remember while working on a COA setup:
>Make sure the network device is configured to accept the COA request from COA server on respected port.
>NAS devices wants to see particular attriutes in COA request to identify the user session and perform COA, So sending the right attributes on COA request is important and it depends on the NAS device vendor.
>The expected COA user identification attribute might be different for a Captive portal authenticated user and Dot1.x user.
>Some vendor ignote the unsupported or unknown attributes in COA request and still ACK your COA request. However some vendor devices dont like you sending a unsupported COA attributes, so they respond with disconnect-NAK
#Here in case of Fortigate Firewall you might need to send the right COA supported attribute to identify the user session.

*supported attributes: WPA-Enterprise&UserGroup and Captive Portal supports:
USER_NAME,
FRAMED_IP_ADDRESS,
EVENT_TIMESTAMP,
MESSAGE_AUTHENTICATOR,

*User-name” and “Frame-ip” were supported in DM request and both MUST be involved, other attributes like “Calling-Station-Id”, “Called-Station-Id” could not be supported and would cause 503 error message.
*The attributes “EVENT_TIMESTAMP” and “MESSAGE_AUTHENTICATOR” are options.
*Note: Supported attributes as on the latest firmware v5.4

#In case of ARUBA MOBILIY CONTROLLER:

The mobility controller supports the following attributes for identifying the users who authenticate with an RFC 3576 server:

* user-name: Name of the user to be authenticated.
* framed-ip-address: User’s IP address.
* calling-station-id: Phone number of a station that originated a call.
* accounting-session-id: Unique accounting ID for the user session

–> Other attribute might cause 503 error.

#Other ports to Remember:
*Radus Accounting request and Response is on UDP1813
*Radius Authentication is on UDP1812

#Some snapshots attached here to see what’s there inside Disconnect-request,Disconnect-,ACK,Disconnect-NAK.

Accounting Request:

Disconnect Request:

Disconnect-ACK:

Disconnect-NAK:

If would like to look at the entire pcap, let me know I can share with your guys.

 

Configuring your Fortigate for Higher cipher and SSL/TLS protocol

From version Fos 5.4 onwords you  can control on setting  Encryption and Decryption to Highest Cipher for SSLVPN

FG08XXXXXXXXXX # config vpn ssl settings

FG080XXXXXXXXX (settings) #

FG080XXXXXXXXX (settings) # set banned-cipher

RSA         Ban the use of cipher suites using RSA key.

DH          Ban the use of cipher suites using DH.

DHE         Ban the use of cipher suites using authenticated ephemeral DH key agreement.

ECDH        Ban the use of cipher suites using ECDH key exchange.

ECDHE       Ban the use of cipher suites using authenticated ephemeral ECDH key agreement.

DSS         Ban the use of cipher suites using DSS authentication.

ECDSA       Ban the use of cipher suites using ECDSA authentication.

AES         Ban the use of cipher suites using either 128 or 256 bit AES.

AESGCM      Ban the use of cipher suites AES in Galois Counter Mode (GCM).

CAMELLIA    Ban the use of cipher suites using either 128 or 256 bit CAMELLIA.

3DES        Ban the use of cipher suites using triple DES

SHA1        Ban the use of cipher suites using SHA1.

SHA256      Ban the use of cipher suites using SHA256.

SHA384      Ban the use of cipher suites using SHA384.

#To set the SSL/TLS protocol versions for ADMIN and SSL VPN

>>Allow only TLS 1.2:

       # config system global

       # set admin-https-ssl-versions tlsv1-2

       # end

>>Disable everything except TLS 1.2 as go to high algorithm:

       # config vpn ssl settings

       # set tlsv1-0 disable

       # set tlsv1-1 disable

       # set sslv3 disable

       # set algorithm high

       # end

>>Whats with setting the algorithm on HIGH/LOW/MEDIUM:

The default option of Medium at RC4 (128 bits) is acceptable, but the High option, AES (128/256 bits) and 3DES is more secure. The Low option, RC4 (64 bits), DES and higher does not meet PCI DSS requirements

>>Configure the system to use strong crypto:

   # config system global

       # set strong-crypto enable

       # end

Note: Enabling strong crypto will disable using SSLV3 and TLSv1.0. So its  TLSv1.1 and TLSv1.2