Search for sender's originating IP address in headers

[pronto 6]

Servus Community,

we are looking for the setting "Search for sender's originating IP address in headers" in the policy for our Exchange Server as described in [1] for example. We have installed a Reverse Proxy Server in service in front of our Exchange servers and need the evaluation of the original IP address for the full support of the ESET security features (IPBlacklist for example). Is this setting outdated, does it not work anymore or is this always active now? How can we test if the setup works as expected? The Apache web server on the reverse proxy is set to send the original IP address (ProxyPreserveHost On). We are currently using ESET Mail Protection for Exchange Server version 9.

[1] https://help.eset.com/emsx/6.5/en-US/index.html?idh_config_av_agent2.htm

FYI: A support ticket has also been created for this issue under the ID 00442012

Thx & Bye Tom

Edited October 24, 2022 by pronto
Ticket ID added

[M.K. 17]

Hi, this setting is still available, but only via the configuration XML, for example:

<?xml version="1.0" encoding="utf-8"?>
<ESET>
 <PRODUCT NAME="emsx" VERSION="9.0">
  <ITEM NAME="plugins">
   <ITEM NAME="01004101">
    <ITEM NAME="settings">
     <ITEM NAME="XMON_AGENT_CONFIG">
      <NODE NAME="OriginalIPHeader" TYPE="string" VALUE="X-Originating-IP" />
      <NODE NAME="UseOriginalIPHeader" TYPE="number" VALUE="1" />
     </ITEM>
    </ITEM>
   </ITEM>
  </ITEM>
 </PRODUCT>
</ESET>
 

[pronto 6]

Hi M,

do you have a manual where we can find the handling about this way of setup undocumented settings. Why is this setting removed in the GUI?

Is there a possibility to test this setup?

Thx & Bye Tom

[M.K. 17]

The setting should work the same as before, i.e. when turned on (UseOriginalIPHeader=1) and with the header name defined (OriginalIPHeader), then whenever EMSX finds such header in the email, it's value - if it's valid IP address - is used instead of the connecting server IP address. That should relate to all protection layers that process the connecting IP (antispam, SPF ...).

It has been removed from GUI, as it was often used in a way that was not intended. For the legitimate cases it is still available for advanced users.

[pronto 6]

Servus M,

Okay, I exported the ESET Mail Protection (Network) settings (See screenshot), then just put your code in <eset><product>PUT IN HERE</product></eset> and import it again? Or should I select a different setting than network protection to export? How does that then behave in the case of an update?

Btw: As already mentioned at the beginning, we also have a ticket open in parallel and there came earlier the answer that this feature is now always on, where we asked back again whether this also affects HTTP, because the colleague referred specifically to SMTP:

Quote

Hello Mr. Wildgruber,

the originating IP Address is detected automatically in all new versions of Mail Security. you don't need to specify it manually, as that option is not available anymore and the version 6.5 is already in End of Life.

for an example, check the email headers and you'll see the originating IP Address "marked in red" similar to this:

X-ESET-AS: R=OK;S=0;OP=CALC;TIME=1666304162;VERSION=7938;MC=1344213395;TRN=0;CRV=-3;IPC=200.54.219.222;SP=0;SIPS=3;PI=3;F=0
X-ESET-Antispam: OK
X-EsetResult: clean, is OK

 

[M.K. 17]

You don't need to edit exported settings, you can just import that XML I've copied here in the chat. Just save those 15 lines to a file and import it - only those two settings will be affected by it.

As for the "the originating IP Address is detected automatically in all new versions of Mail Security" - that could be a bit misleading. It's true that our antispam engine tries to verify/detect the correct sender's IP address from the message headers automatically if the IP address provided from Exchange Server SMTP session is e.g. a local address (Edge server, other server in DAG etc...). But that has nothing to do with this setting (UseOriginalIPHeader) where you can explicitly specify which particular header contain the correct IP.

[pronto 6]

Servus M,

Well, we have imported this new configuration now and it is also in the config but we can't determine if this actually works. We have now created the following request with an original IP, which is definitely on the blacklist, but we cannot detect a blocked request in Eset Mail Security Logs.

GET / HTTP/1.1
Host: 192.168.11.20:8080
X-Forwarded-For: 223.171.91.191
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1

The entire request is sent that way:

$ openssl s_client -connect 192.168.1.6:https

We would have expected a matching entry in ESET Mail Protection, but it did not come. Does ESET have to be restarted after the config change?

Thx & Bye Tom

[M.K. 17]

You can verify it in the Mail server protection log - e.g. turn on logging of all messages

<?xml version="1.0" encoding="utf-8"?>
<ESET>
 <PRODUCT NAME="emsx">
  <ITEM NAME="plugins">
   <ITEM NAME="01004100">
    <ITEM NAME="settings">
     <ITEM NAME="MAILSERVER_CONFIG">
      <NODE NAME="LogAllMessages" TYPE="number" VALUE="1" />
     </ITEM>
    </ITEM>
   </ITEM>
  </ITEM>
 </PRODUCT>
</ESET>
 

send an email containing the header (i.e. X-Originating-IP: X.Y.Z.W) and you should see the X.Y.Z.W address in the "IP Address" column instead of the address of the sending server. The column has zero width by default, you need to resize it first - it is the second column right after "Time".

If that address is on the Blocked IP list, the whole email should be marked as spam.

[pronto 6]

Hi M,

thanks for your explanation but I'm guessing we still have a missunderstanding. What we want to test is not if an email is blocked (SMTP/25) but client connections over HTTPS/443 (EWS, OWA, Autodiscover etc).

We have placed a reverse proxy (Apache; HTTPS) in front of our mail servers and now the client arrives e.g. via OWA with the internal IP address of the proxy server instead of its own public IP address. However, it is possible to send the original IP address in the header in the proxy configuration (X-Forwarded-For), which we have set and also verified that this is indeed the case. But this is an HTTP request, not an SMTP based communication.

Since we put the proxy server into service, no more blocked requests are logged on port 443 on the Exchange server, which were matched with an IP blacklist. This is unusual and can now have two causes. Either the proxy server discards all malicious requests, which we have not set (mod_secure and other dynamic security features are not yet enabled on the proxy) or ESET analyzes the wrong field in the HTTP header when checking the request.

Finally, there is the possibility that the firewall between the proxy server and the mail server removes the X-Forwarded-For tag, but the support of the firewall manufacturer has denied this. We could now install a packet sniffer on the Exchange and analyze whether this tag really arrives the Exchange server, but before I do that I would like to clear up our misunderstandings.

If ESET is analyzing the wrong IP address at this point, our proxy server setup in front of the Exchange is rather insecure, at least as long as we don't outsource this analysis to the proxy server itself. This is a critical point.

Thx & Bye Tom

[pronto 6]

Hi Marko,

I'm pretty sure the feature doesn't work anymore. The last entry in the logfile is pretty much the time when we put the reverse proxy into service.

Thx & Bye Tom

[M.K. 17]

The "UseOriginalIPHeader" setting is relevant only for the Mail security, not for Network protection component. So yes, that was a misunderstanding from our part.

[pronto 6]

2 hours ago, M.K. said:

The "UseOriginalIPHeader" setting is relevant only for the Mail security, not for Network protection component. So yes, that was a misunderstanding from our part.

And what do we do now?

[Marcos 5,070]

On 10/27/2022 at 12:08 PM, pronto said:

I'm pretty sure the feature doesn't work anymore. The last entry in the logfile is pretty much the time when we put the reverse proxy into service.

You have posted a screenshot of the Network protection log. Do you suspect some of the detections to be false positives or how is the screenshot related to the originally reported issue? The highlighted record seems to be a correct block since 192.241.217.39 is a known source of attacks: https://www.abuseipdb.com/check/192.241.217.39

[pronto 6]

5 minutes ago, Marcos said:

The highlighted record seems to be a correct block since 192.241.217.39 is a known source of attacks: https://www.abuseipdb.com/check/192.241.217.39

Hi Marcos,

the highlighted record in the log file is the last record we've seen since we put a reverse proxy server into service. We have configured the reverse proxy server to send the original IP address in an X-Forwarded-For header tag, but it seems that ESET does not analyze this record in the header. Instead, ESET now seems to analyze the internal IP address of the reverse proxy server. With this we fear to have put a bypass around the IP address list database.

Our question was, how do we have to configure ESET to evaluate the correct IP address?

Thx & Bye Tom