Posts by ncolter

    As long as at least one of the brokers in your client's broker list in the dxlclient.config file is available, and an administrator has not removed the client's certificate information from ePO (for ePO-managed fabrics) or the broker (for open fabrics), the client would be expected to connect successfully.


    The only scenarios where re-provisioning should be required:

    • You are trying to connect to a new broker that was not included in the previous provisioning's broker list in dxlclient.config and broker CAs in ca-bundle.crt.
    • The broker no longer has the client certificate information.
      • On an ePO-managed fabric, this can be checked in the DXL Certificates (Third-Party) server settings.
      • On an Open Broker fabric, this can be checked by checking that the client CA is present in the /dxlbroker-volume/keystore/ca-client.crt on the Open Broker.

    It is not recommended to include the provisioning logic inside of the actual connection logic if you are doing both as a part of the runtime operation of your integration.


    A client's connection to the DXL fabric is subject to outside influences such as network connectivity (among other issues), and if the provisioning is a part of connecting it would be possible to end up sending several provisioning requests. Provisioning is not only a relatively expensive operation in terms of computation compared to simply connecting, each new successful provisioning will store the certificate and related information in your ePO database (for ePO-managed fabrics) and/or in your brokers' client certificate store.


    Long story short... If you are using a script or some other programmatic way of provisioning your client, this should be entirely separate to your connection logic. This way, it will only run one time.

    The only problem I see is the inclusion of the "http://" prefix at the beginning of the proxy URL in your config file. The OpenDXL client(s) do not parse out this information when passing the URL information to the proxy library


    For example, your [Proxy] section should look more like this:


    [Proxy]

    Address=test.proxy.proxylab
    Port=9999
    User=prUser
    Password=prPass


    An OpenDXL "code camp" is being held at the MPOWER 2019 Cybersecurity Summit.


    Arrive a day early and broaden your McAfee solution expertise by adding OpenDXL code camp training to your MPOWER experience. In this hands-on workshop led by technical experts and community members, you will gain the knowledge and understanding to leverage existing integrations and to create OpenDXL orchestration flows, service wrappers, and clients to support your OpenDXL initiatives. This workshop will be a hands-on walkthrough of creating an OpenDXL Fabric, orchestrating existing tools using OpenDXL Node Red connectors, and developing code/scripts to integrate with OpenDXL, such as those featured at www.opendxl.com.


    Date: Monday, September 30

    Location: ARIA Resort & Casino, Las Vegas – Level 3: Starvine 3 & 4

    Hours: 8:30am - 5:00pm


    The camp is available to anyone interested in getting hands-on experience with the latest OpenDXL-related technologies. Information can be found on the MPOWER 2019 event website.

    Course Details

    This workshop will be very hands-on, and will involve implementing code/scripts to integrate with OpenDXL, such as those featured at www.opendxl.com. By attending this course, you will leave with:

    • An understanding of the concepts and possibilities of what can be done with OpenDXL with knowledge of how to implement and modify services & flows created by others
    • Experience integrating with McAfee Threat Intelligence Exchange (TIE), McAfee Active Response (MAR), and 3rd party security tools
    • A strong OpenDXL foundation to build on as you interact with the community and best practices for building your own enhancements

    Who Should Take This Class

    Session participants should come with a desire to learn the fundamentals of working with OpenDXL and how leveraging OpenDXL can simplify the process of automating interactions between several products. Basic scripting skills are required for configuring and modifying flows. Please note that students are responsible for bringing their own laptop to class to access the lab materials.

    In the meantime, here is a sample showing the correct way to use the Python version of the OpenDXL ePO Client Library:



    This sample should display output similar to the following in the console:

    Code
    1. [
    2. {
    3. "id": "1108",
    4. "message": "System transferred successfully",
    5. "name": "SAMPLE-SYSTEM-TO-TRANSFER",
    6. "status": 0
    7. }
    8. ]

    The files listed are used to authenticate certificates for broker-to-broker and client-to-broker communication.


    ca-broker.crt 
    ca-broker.key

    Certificate Authority used by clients and brokers to authenticate a broker's certificate. On clients, this file is typically named ca-bundle.crt
    broker.crt
    broker.key
    The certificate/key pair for this broker. (Clients and other brokers authenticate this certificate using their copy of the broker CA).
    ca-client.crt
    ca-client.key
    Certificate Authority used by brokers to authenticate a client's certificate.

    clara_kt is correct, service registration should be handled in by creating a prototype version of Application.prototype.onRegisterServices in your application.


    There are several callbacks you can expect the Application to execute:


    Application.prototype.onLoadConfiguration Executed after the Application has parsed the configuration file but before creating/populating the DxlClientConfig object that will be used to connect to the fabric.
    Application.prototype.onRegisterEventHandlers Executed after the DXL Client has connected to the fabric. Used for registering event handler callbacks for the service.
    Application.prototype.onRegisterServices Executed after the DXL Client has connected to the fabric, after onRegisterEventHandlers. Used for creating and registering services.
    Application.prototype.onDxlConnect
    Executed after the DXL Client has connected to the fabric, after onRegisterServices. Used for any behavior you wish to execute immediately after the client has connected but before running the Application.
    Application.prototype.onRun Executed after the Application has started running (after loading configuration, and connecting to the fabric).


    Here is an example a prototype function implementation for Application.prototype.onRegisterServices:

    The broker port 8883 does not need to be opened in both directions - the port only needs to be opened to allow the child broker to reach out to the parent broker.


    The child broker will always be initiating the connection to the parent broker.

    It's recommended that users who want to get started with the DXL nodes/flows available for Node-RED visit the OpenDXL Node-RED Nodes solution. The GitHub repository for that project contains a wiki and documentation that not only help with setting up the required environment, but provide samples and API information.


    Additionally, there is also the OpenDXL Node-RED Docker solution. There you will find a Docker image that is ready out-of-the-box to support the official OpenDXL Node-RED solutions available. Note that some additional environmental requirements may need to be met for the various community-built solutions that use Node-RED.

    Hi Vhardy,

    Unfortunately the OpenDXL team doesn't have the information on hand regarding TIE product features (at least the ones unrelated to DXL) .


    We'll see if we can locate documentation regarding TIE's reporting node functionality and let you know as soon as possible. One thing that may help you get started would be the following TIE 2.3.0 Installation Guide: Configure the TIE server extension. Note that the information regarding a "Reporting Secondary" server requires a second deployment of a TIE server.


    There may be additional helpful information in the TIE 2.3.0 Product Guide.


    ---


    - Update -


    This is outside of our wheelhouse, it seems.


    We recommend that you speak with your point of contact in McAfee Support to directly request information on this issue. They should be able to help you more detailed information regarding TIE reporting nodes.

    Glad to hear you're enjoying the start of this new feature for OpenDXL. Having this kind of information available has been a popular request, and it's great to finally be able to provide it.


    We are planning to increase the available number of API specifications for solutions to include all McAfee-created solutions (including commercial solutions such as TIE and MAR. Partner solutions may eventually get API specifications as well, provided by the partner themselves.


    Each McAfee-created solution with an API specification will also have the specification available in YAML or JSON format - in fact these formatted documents are used to generate the more reader-friendly version you see in the API Specification tab.


    We should have many more specifications available soon!

    As you mentioned, the online documentation for the various OpenDXL solutions are hosted using Github Pages. To set them up, we used the following guide:

    (For whatever reason, GitHub typically tries to direct users to a more general "What is GitHub Pages?" article, which is much less helpful.)

    We can see how the current functionality of the certificate export/import for multi-ePO fabrics could lead to confusing circumstances when combined with OpenDXL's built-in provisioning. Our team will have to take some time to evaluate if a change (or customization) to this feature would reduce the potential for misunderstandings.

    It sounds like you are using the CLI option outlined here: Command Line Provisioning (CLI). To use client certificates generated using this method across brokers managed by different ePO Servers in a Multi-ePO DXL fabric, you would need to access the keystore on the brokers themselves, which we don't recommend unless absolutely required. Please let us know if you need more information about this particular method.


    An easier and safer option for enabling clients to connect to brokers managed by different ePO Servers on a Multi-ePO DXL fabric is to generate your own CA and import it in the DXL Certificates (Third Party) section of the ePO Server Settings. If that option works for your environment, please see the following instructions:


    (Found under External Certificate Authority (CA) Provisioning in the Data Exchange Layer (DXL) Python SDK Documentation)

    1. Certificate Files Creation (PKI)
    2. ePO Certificate Authority (CA) Import
    3. ePO Broker Certificates Export
    4. ePO Broker List Export
    5. Repeat Step 2 on the other ePO Servers on your Multi-ePO DXL fabric (using your new third party CA)
    6. Use Agent Wake-Up prompt the brokers to check for updates
    7. Connect your client to any broker managed by an ePO that has your third-party CA

    Hi Exie ,

    There still isn't a concrete date on the OpenDXL Java Client, our team's recent push has been focused on the new OpenDXL JavaScript Client, as well as bug fixes and updates to existing Python solutions.


    Rest assured that our team wants to provide a Java-based client to the community as soon as possible!