Hi Marty,
We were having a look at this example and found something that we don't completely understand. In the controller.py module, the class "SearchContext" is defined like this:
class SearchContext(object):
""" Class to hold context of searches, so that asynchronous searches can be co-ordinated """
def __init__(self, context):
self._context = copy.copy(context)
self._active_searches = []
self._id = uuid.uuid4().__str__()This differs to the equivalent ID creation present in the CustomThreatService class available in the rc_cts Python package:
request_id = str(uuid5(self.namespace, json.dumps(body)))
The body variable is what is received in the POST requests made by Resilient.
After studying the previous implementation, we understood that the purpose of this ID is:
- Have a way of tracking asynchronous requests to the actual Threat Source, so Resilient can poll for the results later making GET requests.
- Cache the results from the Threat Source during a given TTL, so the two consecutive requests for the same artifact value and type just returns the cached value.
However, in the Django implementation the ID seems to be generated without making use of the input data or any seed whatsoever and it looks like if Resilient makes the exact same request many times in a short period of time, none of these requests will have the same UUID.
As we came to this conclusion by inspecting the code and not running it yet, could you please check and let us know if this is an error? If so, how can be request a fix? This would potentially have a big performance impact for our Threat Sources.
------------------------------
Regards,
Carlos Ortigoza
------------------------------
Original Message:
Sent: Thu December 12, 2019 01:35 PM
From: Marty James
Subject: Custom Threat Sources security
I know we have a simpler sample application too, so this answer depends upon which sample you started with...
If based on the Django sample, the README.md points to uwsgi documentation and provides an example way to host using nginx: https://github.com/ibmresilient/resilient-python-examples/tree/master/django-custom-threat-service#sample-configuration-with-nginx
If you are using nginx simply uncomment the section in the nginx.conf file which is labelled as "# Enable these settings for SSL". Personally I'm a big fan of nginx, because it is very flexible.
There are some other production-ready web servers to host Django applications - https://gunicorn.org/ is one that I have seen used for a large application in the past.
More information / discussions can be found at the following links:
https://vsupalov.com/django-runserver-in-production/
https://www.quora.com/Which-web-server-suits-Django-best-Apache-Nginx-or-something-else
https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Deployment
------------------------------
Marty James
Original Message:
Sent: Wed December 11, 2019 10:27 AM
From: Yongjian Feng
Subject: Custom Threat Sources security
I see. Did you guys develop this CTS or downloaded it from the App Exchange please?
------------------------------
Yongjian Feng
Original Message:
Sent: Wed December 11, 2019 08:06 AM
From: Carlos Ortigoza
Subject: Custom Threat Sources security
Hello,
I mean how can we have the Custom Threat Source listening on an URL like:
- https://mydomain.com:8888
Instead of:
I didn't find any reference about how to configure this but I might be looking at the wrong documentation.
Regards,
------------------------------
Carlos Ortigoza
Original Message:
Sent: Wed December 11, 2019 07:27 AM
From: Yongjian Feng
Subject: Custom Threat Sources security
Hello Carlos,
Thanks for contacting us.
Could you please explain in more details what you meant by "deploy a Custom Threat Source over HTTPS"?
Thanks,
Yongjian
------------------------------
Yongjian Feng
Original Message:
Sent: Mon December 09, 2019 04:29 PM
From: Carlos Ortigoza
Subject: Custom Threat Sources security
Hello,
We were wondering how we can deploy a Custom Threat Source over HTTPS. We were going through the documentation and didn't find any reference about how to do it.
Besides this, we were also wondering how can we make it listen on all interfaces or something different to localhost. We considered already implementing a forwarding rule using iptables but something native is preferable.
Regards,
------------------------------
Carlos Ortigoza
------------------------------