***We do NOT have an XSAN in our environment, that might be helpful to know. Just a collection of MACs floating around in a Windows domain.
And in march the mobile devices...
A few months ago, I logged onto one of our two Win 2008 R2 DCs and found hundreds of thousands of Audit Failures (5152 & 5157). After sifting through the event logs, I had a pretty good idea that the DropBox app was a core culprit. After researching and receiving suggestions from E-E users (thank you), I have now disabled the LANSync service and in some cases "Unlinked" phones from the service where applicable. That seems to have cleared a couple thousand Audit Failures.
Now - onto the endless other services and apps that people drag in when they bring their various devices into our network.
One area of note is that in our business we actually use many of these services and apps to do our daily work. Most notably, iPads, iPhones and OS X devices are the front runners where the mobile app explosion can be witnessed. Not unlike most other businesses or even households today. So you sort of can't "block all" and be done with it.
At present, XSAN is on my radar, as my Security Event Logs (on the aforementioned DC) are now filled to the brim again with Audit Failures - this time largely from XSAN activity.
I have learned that there are 16,383 ports used by Apple to usher traffic to & fro for iOS and OSX Xsan Filesystem Access activity.
49152-65535 TCP Xsan - - Xsan Filesystem Access
49152-65535 UDP - - - Back to My Mac
So, after a long while thinking we were under attack, I have a better picture of what is truly occurring, but I wonder how can I limit this unwanted traffic? As with disabling the LANSync for DropBox chatter, I should be able to curb the MAC broadcast activity from the OSX or iOS device itself. Some service, some sync that could be turned off, while not crippling the device functionality. With DropBox, LANSync is off and DropBox still works. So I am looking for the variable that would make this statement true:
XXXX is off and Apple Device still works.
Has anyone experienced this same or similar scenario - and if so, what has worked for you?
And for the record, disabling the auditing of 16,383 ports doesn't seem like a really great avenue. I know that suggestion will come up, so respectfully no thank you in advance.