0

I got two VMs on Azure that are in the same subnet. One VM (10.1.0.6) has clamav daemon running, the other runs a Java Wildfly Application (10.1.0.5).

I would like to send files from Java Application to the clam av daemon.

I checked that Clamav is running and listening on port 3310:

 netstat -ant|grep 3310
 tcp        0      0 127.0.0.1:3310          0.0.0.0:*               LISTEN
 
 netstat -lnp | grep clam
 (Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
 unix  2      [ ACC ]     STREAM     LISTENING     800631   -             
 /var/run/clamav/clamd.ctl

For the Clam Av server there are all inbound ports open within the virtual private network. However, if I check on the java server if the port is available via telnet or nc I get:

telnet 10.1.0.6 3310
Trying 10.1.0.6...
telnet: Unable to connect to remote host: Connection refused

nc -vz 10.1.0.6 3310
nc: connect to 10.1.0.6 port 3310 (tcp) failed: Connection refused

If I send files via Java Application I get the same error.

Is my clamav setup correctly and is this issue related to my Subnet configuration?

Thanks for your help!

Felix Hagspiel
  • 101
  • 2
  • Have you checked the firewall on the VMs themselves, and any NSG's applied? – Sam Cogan Jul 28 '20 at 15:49
  • On the VM are no firewalls installed so far, as they are not reachable from outside. I did not create a specific NSG, because I thought that in the subnet everything is allowed (AllowVnetInBound / Any port, any protocol, destination: VirtualNetwork, source: VirtualNetwork). Is a NSG mandatory to allow VMs to communicate between each other, even when they are in the same subnet? – Felix Hagspiel Jul 28 '20 at 20:00
  • If you used the wizard in the portal to create the VM it has more than likely created an NSG for you. If you changed no rules then it should allow all traffic in teh vnet – Sam Cogan Jul 29 '20 at 21:10
  • @SamCogan Thank you, I thought so as well. I created a support ticket to azure and will keep you updated. – Felix Hagspiel Aug 02 '20 at 12:01
  • @SamCogan the listening address was the problem. Thank you for your help anyway! – Felix Hagspiel Aug 04 '20 at 09:49

1 Answers1

0

The problem was that the daemon was listening on the loopback IP address (127.0.0.1). I had to switch this is to listen on 10.1.0.6 (0.0.0.0 should also work).

added in /etc/clamav/clamd.conf:

TCPSocket 3310
TCPAddr 10.1.0.6

added in /etc/systemd/system/clamav-daemon.service.d/extend.conf

ListenStream=10.1.0.6:3310

Restarted the daemon and now it is working!

Felix Hagspiel
  • 101
  • 2