Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 3 subscribers
  • Views 41805 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RPC_IN_DATA 401

AreshAreshi

Hi,

we access our internal server behind the utm with Rdgateway and WAF, I can access the internal servers no problem there, but when check the logs see this:

 

2017:04:05-09:00:17 securitysrv1-2 reverseproxy: id="0299" srcip="167.XX.XX..26" localip="62.XX.XX.190" size="13" user="-" host="167.XX.XX..26" method="RPC_IN_DATA" statuscode="401" reason="-" extra="-" exceptions="SkipURLHardening" time="16941" url="/rpc/rpcproxy.dll" server="remote.mydomain.com" referer="-" cookie="-" set-cookie="-"


2017:04:05-09:00:18 securitysrv1-2 reverseproxy: id="0299" srcip="167.XX.XX..26" localip="62.XX.XX.190" size="13" user="-" host="167.XX.XX..26" method="RPC_OUT_DATA" statuscode="401" reason="-" extra="-" exceptions="SkipURLHardening" time="16103" url="/rpc/rpcproxy.dll" server="remote.mydomain.com" referer="-" cookie="-" set-cookie="-"

 

we did setup the exceptions, why do I see the 401?



This thread was automatically locked due to age.
Parents
  • 0

    https://httpstatuses.com/401

    I think, the first access is not authenticated.

    regards

    mod

  • 0 in reply to mod2402

    Hi,

     

    I thought maybe because I use the option "Use my Rdgateway credential for remote computer" at RDP then the UTM dont like it, so I did disable this option and try to access the internal server with Rdgateway again and this time I had to authenticate twice, but unfortunately still I see the same 401 in the logs.

     

    Thaks

  • 0 in reply to AreshAreshi

    Hi Aresh,

    this has nothing to do with the utm. The 401 is returned from the exchange server. I think you have basic/default authentication configured on exchange site. With integrated authentication you should not see the 401.

    regards

    mod

  • 0 in reply to AreshAreshi

    Hey Aresh.

    I think that's just how things work. My guess is that the client tries to access the RCP Proxy unauthenticated first and only after receiving a 401 it authenticates. Wee see this because the UTM is chatty, as it should be.

    I see the same on one of my setups:

    First contact:

    2017:04:06-11:27:37 utm reverseproxy: id="0299" srcip="X.X.X.X" localip="Y.Y.Y.Y" size="13" user="-" host="X.X.X.X" method="RPC_IN_DATA" statuscode="401" reason="-" extra="-" exceptions="SkipURLHardening" time="1104795" url="/rpc/rpcproxy.dll" server="rds.domain.com" referer="-" cookie="-" set-cookie="-"
    2017:04:06-11:27:42 utm reverseproxy: id="0299" srcip="X.X.X.X" localip="Y.Y.Y.Y" size="13" user="-" host="X.X.X.X" method="RPC_OUT_DATA" statuscode="401" reason="-" extra="-" exceptions="SkipURLHardening" time="1124507" url="/rpc/rpcproxy.dll" server="rds.domain.com" referer="-" cookie="-" set-cookie="-"

    Later on, sucess:

    2017:04:06-11:28:59 utm reverseproxy: id="0299" srcip="X.X.X.X" localip="Y.Y.Y.Y" size="0" user="-" host="X.X.X.X" method="RPC_IN_DATA" statuscode="200" reason="-" extra="-" exceptions="SkipURLHardening" time="80830352" url="/rpc/rpcproxy.dll" server="rds.domain.com" referer="-" cookie="-" set-cookie="-"
    2017:04:06-11:28:59 utm reverseproxy: id="0299" srcip="X.X.X.X" localip="1Y.Y.Y.Y" size="195082" user="-" host="X.X.X.X" method="RPC_OUT_DATA" statuscode="200" reason="-" extra="-" exceptions="SkipURLHardening" time="75012636" url="/rpc/rpcproxy.dll" server="rds.domain.com" referer="-" cookie="-" set-cookie="-"

    I personally never noticed this. Maybe you're being a bit overzealous about this.

    Regards - Giovani

  • 0 in reply to giomoda

    Hi,

    Thanks for the update,

    you are right maybe I should ignore this. Just one more question I did check the log and see this at the top of the bot 403 errors that I didnot see lat time and it says:

    Should I also add the remoteDesktopGateway/ aslo to the paths of exceptoins lik /rpc/* and /rdweb/* etc as well?


    2017:04:10-12:15:34 securitysrv1-2 reverseproxy: [Mon Apr 10 12:15:34.509920 2017] [url_hardening:error] [pid 29460:tid 4087978864] [client 217.XX.XX.30:46560] No signature found, URI: https://remote.mydomain.nl.nl/remoteDesktopGateway/


    2017:04:10-12:15:34 securitysrv1-2 reverseproxy: id="0299" srcip="217.XX.XX.30" localip="62.XX.XX.190" size="284" user="-" host="217.XX.XX.30" method="RDG_OUT_DATA" statuscode="403" reason="url hardening" extra="No signature found" exceptions="-" time="690" url="/remoteDesktopGateway/" server="remote.mydomain.nl.nl" referer="-" cookie="-" set-cookie="-"

     

  • 0 in reply to AreshAreshi

    Hi Aresh,

    yes, you should also create an url hardening excepttion for this path.

    regards

    mod

  • 0 in reply to mod2402

    Actually, mod, I disagree. Creating an exception for this path would cause the client to try to use the new RDG protocol, which is not supported by UTM. When denying this path the client falls back to RPC over HTTPS (hence the rpcproxy.dll), which is supported by WAF by its builtin OutlookAnywhere support.

    Regards - Giovani

  • 0 in reply to giomoda

    Then just ignore my last post ;)

    regards

    mod

  • 0 in reply to mod2402

    Thank you all for the help

     

    Thanks

  • 0 in reply to giomoda

    could it this be the reson we see the 403 in the WAF logs?

  • +1 in reply to AreshAreshi

    Yes, it's denied (403) because there's no URL hardening exception for this path. It's expected to be denied and it must be denied if you want to use WAF to protect RDGateway. As I stated before, allowing it would cause the client to use a newer protocol that WAF is yet no able to handle. 

Reply
  • +1 in reply to AreshAreshi

    Yes, it's denied (403) because there's no URL hardening exception for this path. It's expected to be denied and it must be denied if you want to use WAF to protect RDGateway. As I stated before, allowing it would cause the client to use a newer protocol that WAF is yet no able to handle. 

Children
No Data
Unfiltered HTML