Notifications
Clear all
Topic starter
we've been getting tmp files in our data in folder. Not sure where they are coming from, what is generating them or how to troubleshoot it? thx
Posted : February 8, 2019 7:47 am
Does your company run any sort of Nessus or vulnerability scan? We get these when Nessus runs-- it tests connectivity to each port and creates garbage files. It really wrecks havoc on Qvera as well, like crashing the entire process.
Posted : February 8, 2019 7:53 am
Topic starter
no, we do not. These tmp files just recently started showing up. I assumed it was the new lab interface we have setup but they have no idea.
Posted : February 8, 2019 8:04 am
Are the files empty? Is LL/DTS listening for HL7 messages over TCP/IP (for any interface) rather than file-based (especially for your new lab interface)?
We actually do file-based only because when the LL/DTS process crashes or restarts, we've found it does not handle messages received over TCP/IP gracefully.
-dp
Posted : February 8, 2019 8:09 am
Topic starter
The tmp files are not empty. Most of them have garbage content. There are a couple of tmp files where it seems like connection strings like GET /ports/.txt http/1.0.
Posted : February 8, 2019 8:17 am
Ah. The get command is HTTP (or similar protocol).
You have a listener on a host that is writing data received via TCP/IP to a file. I'll bet it's the LL/DTS process.
I just duplicated the same thing with ours. telnet <dts server> <port>, then type characters. Close the telnet session to write the file.
If you want to chase down the source, on your DTS server, take these steps:
- Open a command prompt (cmd).
- Run "tasklist | find "ml3dts"
- run "netstat -aon | find "<PID>" where <PID> is the 2nd column of the tasklist output (15548 in the below screenshot).
This will show you what port(s) the LL/DTS service is listening on.
From here, run Wireshark on your DTS server with a capture filter of "tcp port <port>" where <port> is a port number from step 3 above. If there is more than one port listening, the capture filter needs to be "tcp port <port1> or tcp port <port2> or tcp port <port3>" and so on.
Then wait for a temp file to appear. Stop the Wireshark capture process. You don't want it to capture too much anyway (I generally try to stay <1M packets to avoid causing system issues).
You can search Wireshark for whatever text string appears in the temp file. Once you find the packet, the source IP address is the host that's sending the HTTP requests. I'll bet Luladin is correct that something (like Nessus) is scanning the network for rogue services.
-dp
Posted : February 8, 2019 8:51 am
Topic starter
i will try that. thank you.
Posted : February 8, 2019 10:15 am
Topic starter
you are right! it turns out to be our new vulnerability scan testing. thank you!
Posted : February 11, 2019 2:25 am
