Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
1324 Views 8 Replies Latest reply: Aug 16, 2013 12:24 PM by hschupp RSS
saumyapillai Newcomer 5 posts since
Jun 27, 2013
Currently Being Moderated

Jun 27, 2013 7:31 AM

McAfee M-2950 IPS

Hi,

 

Iam using Mcafee M-2950 IPS for the first time.  I wanted to know ,how to install the manager in windows server. I didnt get any CD along with the appliance, do i need to download the manager file from internet? Please help me out

  • gene33 Newcomer 35 posts since
    Jun 15, 2012
    Currently Being Moderated
    1. Jun 27, 2013 8:45 AM (in response to saumyapillai)
    Re: McAfee M-2950 IPS

    You will want to access the McAfee support portal and login with your support account:

     

    https://mysupport.mcafee.com/Eservice/Default.aspx

     

    And download from the McAfee Network Security Platform category (you will need to provide a grant number)

     

    Download the McAfee NSP Manager Software applicable to your version.

  • codeserp Newcomer 1 posts since
    Jun 27, 2013
    Currently Being Moderated
    2. Jun 27, 2013 7:17 PM (in response to saumyapillai)
    Re: McAfee M-2950 IPS

    The easiest place to get all NSP software is McAfee's menshen site.    https://menshen1.intruvert.com

     

    Use your grant number as the username and password.

  • gfergus1 McAfee SME 125 posts since
    Nov 4, 2009
    Currently Being Moderated
    4. Jul 8, 2013 10:53 AM (in response to saumyapillai)
    Re: McAfee M-2950 IPS

    It sounds as though the server is not getting an IP address.  The manager installation is only setting up a static IP bind in the case of the manager server having multiple addresses.

     

    You will need to use the windows control panel to set the IP of the server.

  • hschupp Newcomer 20 posts since
    Dec 11, 2008
    Currently Being Moderated
    8. Aug 16, 2013 12:24 PM (in response to saumyapillai)
    Re: McAfee M-2950 IPS

    Since you are able now to login to the NSM I see that you have resolved your IP issue.

    The next step as you have started is to add the sensor(s) to the NSM.

    There are prequisites that are needed for that process to complete properly:

     

    Open the ports between the NSM and the sensor(s).

              UDP - NSM Source port 4167 to Sensor listening on UDP 8500

              UDP - Sensor Source port 8500 to NSM listening on 4167

              TCP - Sensor listening on TCP port 8501 through 8504

              TCP - Sensor listening on port 22 for SSH connectivity

     

    Usually if the sensor is on the same segment as the NSM this is not an issue but there is any firewall between the sensor and NSM you will need to have the FW Admin add those ACLs.

     

    You would also want to ensure that any Local Firewall on the NSM Server allows all that as well (whether speaking Windows FW or an application FW installed on the NSm server).

     

    Once those prerequisites are in place you then start the sensor setup/install:

     

    1. Add the sensor by name into the NSM's Device list - creating the secretkey as you do.

     

         This will prep the manager for having the sensor 'call-in' later in the steps.

         The sensor will show up in the NSM Home page as "unknown"

         It will not be listed in the Configure Page/Resource Tree yet.

     

    2. On the sensor type 'setup' and configure the name to match, the IP, Mask, and Gateway info.  Also define the IP address of the NSM server.   Reboot the sensor to embed that information on the sensor.

     

    3.  On the sensor CLI type "show mgmtport' to show what the speed/duplex has negotiated to.  If the link has negotiated to a half-duplex conenction that can impact on the sensor being able to recieve the data package during the next steps of connecting the sensor to the NSM.  

         Example: The management port on the sensor defaults to AUTO negotiate.  If the switch that it is conencted to is hard-coded to Full-duplex then the link will usually negotiate to 10 or 100 Half-duplex.  You can change the switch to be AUTO to match that of the sensor or you can hard-code the sensor management port to also be Full duplex.

         Example:  set mgmtport speed 100 duplex full

     

    Now that you have all the ACLs in place and a solid management port speed/duplex link established you can perform the next step in the process which is to establish the connection between the NSM and the Sensor.

     

    4. On the sensor CLI type: 

                   set sensor sharedsecretkey

         This will first set up a secure trust between the sensor and the NSM. (You'll see that as "Trust = Yes" when running the "status" command from the sensor cli while the sharedsecret key process is going through its paces.

     

    You then should see (keep entering 'Status" command every 10-15 seconds) the Alert, Packetlog, and Command channel change from DOWN to UP.

     

    Once that completes the sensor will now show up in the Resource Tree under the Configure page of the NSM.

    BUT..

     

    The process so far has just set up the communication channels.  The NSM will now query the sensor for a bunch of info .. name, ip, model, version, how long running, configuration state data -- basically getting an inventory of information ABOUT the sensor. 

     

    Using that information it compiles a configuration package for the sensor that includes the default policy, global settings, etc and pushes that out to the sensor.

     

    You can 'track' that process in several manners:

     

    From NSM go to the Configure Page -- Select the Domain (My Company level) and from the menu select LOGS then submenu - Long Running Processes.  You should see the Update package (says something like Signature set update in Progress) being pushed to the sensor.

     

    If this is successful THEN the sensor will populate into the Resource Tree of the NSM and the "Unknown" state will clear and it will show that the sensor is ACTIVE.  

     

    That data package is transferred over the TCP port 8504 that you made sure was opened.

     

    The other way to track the progress of the configuration push to the sensor is from the sensor CLI.

    After you see that the TRUST = Yes and all the channels show UP.. type:

     

              download status

     

    It will show you the progress of the data transfer.

    Note .. that the NSM compiles the package after the first part of the sharedsecret process and then pushes that to the sensor.  Point is that it can take up to 4 or 5 minutes before the actual data transfer starts so be patient when looking at the download status output .. I usually just trust the NSM's long-running process to tell me when the package has been transferred successfully.  If there is a problem and it fails I will then look at the error message for the sensor in the NSM Fault Status page and run the download status on the CLI to see if it tells me why it failed.

     

    If it DOES fail then the sensor will not be manageable from the NSM (because that 'package' included info for the sensor about how the two (NSM and Sensor) would communicate.).

     

    You can see that the "Unknown" state that you are asking about exists as the expeected state until the sensor is completely joined to the NSM... so the answer to your question is that it could be several causes as outlined in the processes above.  Any failure along the way can result in that status ...

     

    So - review the processes as described and see what did not happen.

    For instance .. that configuration push to the sensor can fail if port 8504 sees a lot of CRC errors .. which is a condition that a Half-Duplex link of the management port will see if you have that AUTO versus Fixed mismatch between the sensor and the switch.

     

    Hope this helps!

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points