Deployment Architectures for FireEye NX and EX

Version 1

    The following section provides information on the typical deployment architectures for FireEye Web, Email and Central Management. These are only presented as guidelines, FireEye offers both Professional Services as well as Technical Support in order to best support our Customers specific deployment needs.



    Typical Network Placement




    The following are general guidelines for a successful FireEye Deployment:


    •     Typically FireEye is deployed as the last layer of protection i.e. closest to the users


                             •     FireEye Web (NX) also needs to have visibility of the client IP Address


                             •     FireEye Email (EX) is deployed after the Email Hygiene layer, before the internal Mail Servers (e.g. Microsoft Exchange)


    •     FireEye NX Appliances can be deployed as Inline devices or in Out-of-Band(TAP/SPAN Port) mode



    •    FireEye EX Appliances can also be deployed either in Inline MTA mode or Out- of-Band mode (TAP or BCC)


    •     In order to do blocking or quarantining – deployment must be Inline (NX) or Inline MTA (EX)


    •     Central Management (CM) appliance only needs network connectivity and connectivity to the FireEye Dynamic Threat Intelligence Cloud (DTI)





    FireEye out-of-band deployment showing typical network placement







    Deployment Architectures for Web (NX)



    FireEye Web or NX Appliances can be deployed in one of three ways:


    1.  Inline Mode


                        a. The appliance is deployed physically inline and has the ability to monitor all traffic that pass through it



                        b. The appliance has the ability to Fail Open or Closed in the event of an issue c.  Allow for blocking of traffic deemed to be Malicious




    2.  Out-of-Band (TAP) Mode



                        a. The appliance is deployed passively out of the path of the monitored traffic


                        b. Traffic visibility is provided to the FireEye appliance via either a connection

    to a SPAN port or Network TAP


                        c.  All four of the NX monitoring ports (Pether3-6) can accept separate traffic feeds and aggregate them together for analysis



                        d. Blocking is not reliably possible in this deployment mode


                                            i.  TCP Resets can be used to provide a level of blocking – however this is not a reliable option



    3.  Hybrid Mode



    a. FireEye NX provides four monitoring ports, which in turn form two port pairs b. Separate deployment configuration can be configured on each Port Pair


    i.  This allows one Port Pair to be in Inline Mode and the other to either also be in Inline Mode, or it could be in TAP (out-of-band) Mode


    c.  Typically this could be used in a Proxy environment


                                   i.  Port Pair A would be physically inline before the Proxy



                                  ii.  Port Pair B could accept two separate traffic feeds



    1.  Typically this would be to provide visibility of other routes out of the network in the event that the Proxy is bypassed




    The following simplified network diagrams show these deployments in more detail.





    FireEye NX deployed Inline using Port Pair A only




    FireEye NX appliance deployed in TAP mode





    Hybrid deployment of FireEye NX with both Inline and TAP mode







    Deployment Architectures for EX



    The FireEye Email or EX appliances can also be deployed in one of three ways:


    1.  MTA Mode


    •    The EX Appliance is used as a Mail Transfer Agent (MTA) and is deployed logically Inline in terms of the flow of SMTP traffic


    •    The EX Appliance would receive SMTP traffic from the upstream mail servers –

    typically the Hygiene layer


    •    The EX Appliance would then analyse for malicious attachments, perform

    Dynamic Link Analysis and process static URLs


    •    The EX Appliance would then relay the SMTP traffic onto the next hop following all Analysis – typically this would be the Internal Mail Servers e.g. Microsoft Exchange


    •    Quarantine of emails with malicious content is possible in this deployment mode


    •    TLS Encrypted SMTP traffic can also be analysed in this deployment mode.



    2.  Monitor Only Mode (TAP)


    •    The EX Appliance is deployed passively out-of-path from the logical flow of

    SMTP traffic


    •    Visibility of SMTP traffic is provided via a SPAN port or a Network TAP


    •    TLS Encryption cannot be intercepted in this mode


    •    Quarantine is not available in this mode


    •    All non-malicious copies of SMTP traffic are discarded after analysis



              o A copy of Emails with security threats is kept and attached to the FireEye Alert for analysis by the System Admin.





    3.  BCC Mode



    •    The EX Appliance is deployed passively out-of-path from the logical flow of

    SMTP traffic



    •          A Rule is created in the upstream MTA to send a Blind Carbon Copy (BCC) of all or selected emails to the FireEye EX appliance for analysis



                        o This is typically created in the upstream Hygiene / Email Content Filtering solution




                             •    Quarantine is not available in this mode


                             •    TLS Encrypted mail can be analysed, as the Email is sent to the MTA on the FireEye EX appliance


                             •    All non-malicious copies of SMTP traffic are discarded after analysis






    The following simplistic diagrams illustrate these three deployment scenarios:




    FireEye EX deployment in Inline MTA mode








    FireEye EX deployment in TAP mode






    FireEye EX deployment in BCC mode







    General Considerations for EX Deployments



    General points to note for a successful EX deployment.




    The FireEye EX Appliance has the following interfaces:



    •    Ether1 – dedicated Management interface


    •    Ether2 – dedicated interface for Dynamic Link Analysis (DLA)


    •    Pether3 – MTA interface, can also be used for a SPAN or TAP Monitoring interface in non-MTA modes


    •    Pether4 – dedicated monitoring interface for SPAN/ TAP mode


    The Management (Ether1) and MTA interface (Pether3) should be located on separate subnets to avoid any routing issues.




    The following diagram shows an example of a typical network topology for a FireEye


    EX deployment.




    typical network topology for EX deployment