ARD Port 3283 Scan?

Valued Contributor II

I have recently worked with a team to deploy a new NAC solution in our company. We are using ForeScout's CounterACT.

One thing that CounterACT has noticed is that many of my Macs will randomly scan other Macs for port 3283 (ARD). They do this across subnets/VLANs (i.e. this doesn't appear to be part of a Bonjour localized discovery process, etc). No other ports/services appear to be sniffed (SSH, AFP, etc)

I have asked the owners of these specific Macs if they are using Screen Sharing/ARD/VNC/ etc but they are not.

Most of my Macs have the OS X ALF firewall enabled. Most of the time incoming traffic is blocked except ICMP, ARD & SSH.

We use ARD here in IT for the usual tasks of running remote UNIX scripts, deploying packages, etc.

All of my Macs have ARD enabled for basically everything except Observe and Control. My IT Dept standardized on the cross-platform commercial tool TeamViewer when remote assistance is needed)

If I understand the behavior of ARD...

TCP & UDP port 5900 is used for screen Observe & control (VNC)
TCP & UDP port 3283 is for functions such as installing packages, scripts, getting reports, etc.
TCP port 22 is used for encrypted file transfers (SSH tunnel)

Im wondering why some of my Macs are sniffing around port 3283 for (seemingly) no apparent reason. Im going to do a deeper dive and start looking at each host in the CounterACT logs to determine a pattern, etc.

Any thoughts on this behavior?


Release Candidate Programs Tester

@dstranathan Are the macs scanning "random" IP's of those of the Admin macs running ARD?

(Which can be a pain to check with DHCP).

Valued Contributor II

The hosts and the targets appear to be random. Various VLANs and subnets. The Mac users claim to not be doing any type of peer-to-peer screen sharing, etc.

We have (3) IT macs with ARD admin apps. I have started making sure our ARD admin apps are off at night/weekends to see if we detect a pattern (and ARD is chatty anyway), but no - it doesn't appear to be our IT admin Macs.

Contributor III

We are having a similar issue with SEP RU5 blocking "Vulnerability" at port 3283 on seemingly random computers.

Release Candidate Programs Tester

One of the things ARD supports is Wake On Lan. It could be that this traffic is ARD checking to see if anyone needs woken up.

Valued Contributor II

I think I have a better idea of what might be happening...

I noticed that a bunch of my Mac client workstations had administrator computers listed that no longer exist.

For example, if you fire-up the ARD admin app and look at your Mac client workstations in your ARD computer lists, you will see the"Administrators" tab under (right-click and "Get Info"). This tab was populated by a lot of admin workstations that no longer existed (some admin computers were several years old). I suspect that my clients were trying to look for these systems. Stale DNS records didn't help either. I cleaned-up all my ARD clients settings and my 3283 problem appears to have decreased, but it did not resolve it 100%.

I also made an exclusion in my CounterACT NAC for my IT admin Macs, too.

@rtrouton I considered W-O-L too, but CounterACT reports Macs in ways that seem to be totally random and likely not a "Are you awake?" scenario. Just a hunch though, but the behavior doesn't seem like a W-O-L situation.

@llitz123 I'd like to hear more about your environment regarding this matter.

Dont ya love when one IT tool fights with another IT tool, and the resultant outcome is busy work for IT staff? Hey, its job security, right?

Contributor III

We too use ARD. We have about 55 Macs mostly 10.9 with some 10.10.5.
We use Symantec Endpoint Protection RU5.
We had a variety of Macs who weren't admin machines with Symantec Notification pop-ups for Vulnerability BLOCKED:

We have 6 Windows 2008 R2 servers for various roles and none of them blocked any intrusions. We have a few PC workstations and none of them blocked any intrusions (port scans) that I'm aware of, yet the initial user trouble report came from an intrusion warning seemingly coming FROM a Windows 7 Pro desktop. I submitted the SEP logs from the Windows 7 machine to Symantec support to see if they can offer any insight.
I did not have the Symantec warning pop-up and I'm on an admin machine running 10.9.5. One other admin running 10.10.5 did get the warning pop-up.