Forum Discussion
Local User Account Brute Attack with EOP
Thanks for the response. I am waiting for it to happen again and see if I can tie the instance in with active IP addresses. We do not have a lot in place for monitoring as we are a small business. I was hoping MS would provide a reasonable solution like to enable direct IPs for their services only to connect to our Exchange server, but that was not the case. We will not get our local AD out of this equation fast enough... We do not have ADFS in place. The goal is to get all of our services/servers in Azure and remove the local premise servers.
Makes sense, you will also have problems doing any just whitelisting of O365, they have sooooooooooooooooooooooooooo many servers (https://support.office.com/en-us/article/office-365-urls-and-ip-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2 - its a huge list) that update constantly, anytime I have tried to deploy a solution that whitelisted them but was more secure on others it seemed like a headache.
I think you are correct that moving forward to be cloud based is probably the best way to **bleep** this in the butt, and get on top of the problem.
Goodluck!
Adam
- As you are hybrid, you cannot remove your Exchange Server on-premises as you need that to manage your AD recipients you have in the cloud. But if all your mailboxes are in Exchange Online and AutoDiscover points to Exchange Online directly then you do not need to publish the on-premises server to the Internet for user access. Therefore stop https inbound to the server. This will stop bad login attempts to the on-premises server and so stop account lockout. Also ensure your account lockout is not to low as well so that users are locking themselves out a well
All of our mailboxes are cloud only, yes. We still use the on-premise to handle on-boarding users (that whole GGUID, or something like that) and we use on-premise for routing mail between servers, which is slowly changing. But otherwise, yeah, all MX records, Cnames, etc point to EOP. So it is safe to block https on the firewall at this point ? Seems risky and odd that MS did not offer this but if it works, I am all for it.
Great - so where does autodiscover.yourdomain.com point to - it should now point the autodiscover.outlook.com as per the DNS settings in the tenant.
Where do users to to for OWA - if they go to mail.yourdomain.com (or whatever it was) they get told to use outlook.com/owa/yourdomain - as long as they go there first and not to your on-premises server then good. You could configure an automatic redirect on a website or load balancer to keep doing this, you dont need it to point to Exchange Server anymore.
So now you can stop HTTPS access to your Exchange Server(s) from the internet.
