Forum Discussion
Local User Account Brute Attack with EOP
Hello Again Jeff!
It is always rough when you have the problem/attack coming from you on-prem, as you do need to keep that open and communicating with O365 to ensure a smooth coexistence. I will say I think your solution is going to have to live outside of that, as you will struggle when you try to mess with the federation/coexistence. As such I would look at this as a security issue on prem not through the hybrid connection.
1. The most obvious is to put in place measures to watch/monitor the on-prem exchange better. Putting in place IP blocklists, or using your local firewall to try to keep specific ips/locations out may be best. Everything else is going to be somewhat half measures as they will block stuff through o365 but not through a direct login/access to your on-prem.
from there:
2. I would probably approach this from an identity/access stand point.
Standing up claims rules in ADFS would probably work best, you can just block login access from unknown places. Azure AD can do this somewhat, as well. I am unsure if you would need your onprem server in there (but blocking AzureAD probably doesn't block the direct access to the exchange on prem).
Hope this atleast helps gets ideas flowing.
Adam
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.
