URL Rewrite. Need to configure request blocking

Try to remove the forward slash in the "URL path".
It's better to post the rule XML from web.config than a screenshot. Would be more informative.
Please do next time.

I have tried a different approach since I posted the question.

Instead of using request blocking, I have tried using 'IP and Domain restrictions' and Accepting the IP address of my localhost (192.168.0.7) and then setting access for unspecified addresses to Deny

Unfortunately this configuration did not work either.

After inspecting the IIS logs I found the following entry

2019-02-27 23:12:34 192.168.0.7 POST /ews/exchange.asmx - 443 - 60.228.124.140

The 192.168.0.7 is the IP address of my server (i.e. local host). This is the IP address that I'm allowing. In this case the connection that I want to block is from 60.228.124.140

But it seems that my rule is evaluating the requests based on 192.168.0.7, rather than 60.228.124.140

192.168.0.7 is s-ip

I need the rule to be based on info in: cs-uri-stem

So the rule that I want is where

cs-uri-stem contains /ews/ the IP address must be 192.168.0.*

Any thoughts on how I can implement this?

I've only used URL_Rewrite via the GUI / Wizard

Can you explain how to enter this rule as shown (it looks like I can paste the code in somewhere if I know how)

Here is a screenshot of the rule editor:
To modify the rule in the config file:
Go to the EWS folder, Find a file called web.config
Open i a text editor. Find your rules (the element tag name is <rule> )
Replace old rules with the new.

The rule is in place. Now we wait and see. If it works I won't get any alerts, if it doesn't I will and we can troubleshoot. If I don't receive any alerts in 24 hours I'll mark as the solution.

Thanks

Not working

Kinda fuzzy method of testing... Can't you just connect with remote desktop to some remote computer and try access the web folder to be sure the rule works as it should?

Well I know its not working because the bruteforce attacks are running and they're not being blocked

So to test we just wait and observe

How many rules you have? Please make sure you don't have a preceding rewrite rule which has a checkbox "Stop processing of subsequent rules" checked?

Just your rule is active when testing

I have one other rule (below) which I disable when testing. But which kills all access. that rule is active at the moment to stop the rubbish while we figure out what to do next

could you post the content of the <rules> node from you web.config ?

Path to web.config?

No. Please go to the EWS folder. Open the file Web.config in a text editor. Select all lines from <rules> to </rules>
Copy and Paste them here.

Sorry as by now would be apparent I know very little about IIS.

When I did the test I disabled Rule #1, so only your rule was active.

            <rules>
                <clear />
                <rule name="RequestBlockingRule3" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                        <add input="{REMOTE_ADDR}" pattern="127.0.0.1" negate="true" />
                        <add input="{REMOTE_ADDR}" pattern="192.168.0.*" negate="true" />
                    </conditions>
                    <action type="AbortRequest" />
                </rule>
                <rule name="RequestBlockingRule2" enabled="true" stopProcessing="true">
                    <match url="*" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                        <add input="{URL}" pattern="*/EWS" />
                    </conditions>
                    <action type="AbortRequest" />
                </rule>
            </rules>

Select allOpen in new window

Disabled Rule #2

Disabled Rule #2

Did that help?
How is it now, you can access from the local networks, as well as hackers from the internet? Both have access?
I don't see what could be wrong with the rule "RequestBlockingRule3". I tested that on my IIS and it works fine.
You should test the rules. You probably have more than one computer in the network?
Then temporary replace "192.168.0.*" with the IP address of the server "192.168.0.7" and then try to access from some another computer from your LAN. It should allow from the server by its address https://192.168.0.7/EWS but not from any other computer.

The scenario is this.

I have installed an application on the server that requires EWS to operate

Ever since then I've had issues with the bruteforce activity

So with all the attempts with the RequestBlocking rules to date, if the app is working, the hackers have access as well. If the app is broken the hackers are stuffed as well

Your suggestion is a good one. I will try it shortly and advise.

What I would really like to understand is that when I installed the app, what changes did it make to EWS - because all the issues started after the app was installed. (i.e. is EWS disabled by default or is it enabled and somehow the access permissions were changed in some way, so far I haven't got clarity on that from the vendor)

So I've disabled my rule #2

Access is denied from local computer

The app is working, so I see if I get more alerts

And the bad guys are getting through

The IIS log is the key I think

It shows the external requests, but they're not being blocked

Access is denied from local computer

So, the rule actually does work?
Try to temporary replace "Action" from "Abort request" to "Redirect" ("Redirect type" - "Temporary 307").
This way you would see your test requests in the log.
Then try to access from other machine in the network. Would you see your request attempt among the hackers requests?

How many virtual web servers server on this server computer? May be you trying to block one , but the have access trough another?

If you have a log at the extract from the IIS log earlier, it is coming via EWS

Or at least that is my assessment. Do you agree?

Is it possible to set a filer rule based on Domain\User (i.e. xyz\User) ?

And if so, can that be done at the site level or would it need to be added for each virtual directory?

You asked earlier whether some of the activity could be from other virtual servers. The answer is No. Because when my block-all rule is enabled on EWS there is no hacker activity in the Security logs (well that is not entirely true - there is still activity - but it is activity that is logged correctly and therefore I have controls in place to deal with it. With the EWS activity, I don't get the source IP address in the Event Logs and as a result the activity is not controlled.

I don't get the source IP address

But you said earlier that you did see the source IP address in the log:

After inspecting the IIS logs I found the following entry
2019-02-27 23:12:34 192.168.0.7 POST /ews/exchange.asmx - 443 - 60.228.124.140

So, what are the client's IP addresses you see in the log for the attacker's requests?

Is it possible to set a filer rule based on Domain\User

I don't think so. There is a variable called {REMOTE_USER}, but I tested it by replacing anonymous authentication with basic and the variable is still empty. I believe at the point the rules are applying, the user has not been yet authenticated, so you can't get his name.

Client IP address in the example is 60.228.124.140

Is it possible to change the binding on the EWS virtual directory?  (in other words to a port other than 443 ?).  I don't need EWS available externally, only for the local app.

You can set binding only to a virtual site, not to a directory. You could try to create one, but I don't know what could possible issues be.

Something doesn't make sense with the timestamp of the IIS logging. The logging was originally set to rollover daily, but I was having trouble matching up some of the activity in the IIS logs with the activity in the Security Event logs. So I changed the IIS logging to hourly.
So at the moment it is 9:42am here. And I am doing some testing. The timestamps in the latest IIS log file are being reported as 22:00 (i.e. it's like it is in a different timezone) ?

I think my analysis of the logs previously may have been compromised. I'm going to do some more testing and analysis. I appreciate your assistance. I'll assign all the points on this item to you at the end - but I may have further questions yet.