Support for checks against open ports and check for Azure RCE

[shpendk]

This PR was supposed to just be a check for Azure's RCE CVE-2021-38647. However, because we don't have a fingerprint (and we won't be able to create one from what I could gather) and the issue is on a custom port, i created support for running checks against open ports. The basic idea is this:

1. Just like you can define affected_software on an Issue, you can define affected_ports
2. affected_ports is an array of protocol/port combinations
3. During enrichment of NetworkService entities, issues are queried and affected_ports is matched with the open port on the NetworkService entity.
4. The check is ran

I reckon this enables us to have more checks where an open port is enough for us to fire the check. Of course it would be ideal to fingerprint the service on said open port, but as in this case that's not always possible.

Ps: Typhoeus was failing to connect via https to the target, which is why i swapped libcurl4-gnutls-dev with libcurl4-openssl-dev. This works and from what I could tell doesn't affect other TSL connections.

[m-q-t]

Did a quick run-through on testing the newly implemented run_vuln_checks_from_open_ports() functionality and how its inference would work.

Here is a quick summary of the tests I performed:

• Enriched a URI which pointed to a host that had Port 1270 open but no Azure fingerprint => Task was not ran
• Enriched a URI which pointed to a host that resulted in being fingerprinted as Azure but none of the affected ports open => Task was ran
• Enriched a URI which was not fingerprinted as Azure nor had any of the affected ports open => Task was not ran

Fantastic work 🔥 as run_vuln_checks_from_open_ports() now opens up the possibilities of implementing new types of checks an example being checking whether a server running RMI is vulnerable to deserialization (pre-JEP 290).