Mirth Connect and Vulnerability Scanning

We run weekly vulnerability scans on our Production servers to help ensure HIPAA compliance. Even though access to our interface engine server instances are restricted by VPN access, a hospital or vendor partner might be compromised and begin to attempt to execute malicious activities against our Mirth servers. As such, we need to create our own “gorilla” to make sure potential attacks on our Mirth boxes don’t create undesired side effects.

The good news: Mirth out of the box is resilient to the attacks from Nessus, our vulnerability scanner. No dangers accrue, but there are considerations when using a vulnerability scanner to keep everything cool and kosher.

Password auditing and logging

Nessus on your box can log into Mirth. It doesn’t get far, but it does flood your logs with garbage login attempts. Mirth only allows you to restrict login retries for a specific user, so the garbage isn’t necessarily prevented. While this is harmless, if you want to lookup real user login audits you must tailor your search with Advanced search criteria like this.

(image: password-auditing.png)

Limit TCP attacks on your system

When Nessus finds an open port with open TCP connections, it attempts to grab maximum possible connections, then hit it with a litany of attacks. While the attacks themselves fail, it’s not good if Nessus opens up all the TCP connections that you’ve allowed for a specific channel and then keeps them. When we realized what Nessus was doing, we took two proactive steps to solve the problem.

Limit the number of simultaneous connections Nessus can use. You shouldn’t stop Nessus from accessing Mirth channels, but you don’t want it to block out your customer connections either. Don’t allow Nessus to open infinite connections on any given port/channel. You can do this by setting Max Simultaneous TCP Sessions / Host to a reasonable number. We went with 4. Ensure you have enough connections available on a channel to accommodate for your customer’s channels and Nessus at any given time.

(image: limit-tcp.png)

Kill connections after a specified period of time. Nessus will keep used TCP connections for vulnerability scanning open after it’s done testing. Finding enough connections is rather ugly. To fix this, change the default channel settings to kill connections after a set period of time, like 15 seconds.

(image: timeout.png)

Optimize error handling. A blank message or garbage message will error out on your channel, which should trigger your error handling. You may want to toss this towards a channel for processing in which you ignore errors or don’t page the team when you get hit with something from your Vulnerability scanner.