Jump to content

Mike

Members
  • Content Count

    44
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Mike

  1. In the last couple of weeks, I've seen multiple posts from Eset saying it'll be ready in a fews days. As a result I've been checking-in multiple times a day in the last 10days, but no sign of it yet. Most recently they are now saying "soon", which I'm hoping means imminent (and therefore shorter than a few days?).... rather than it signalling a delay has arisen and so it will be longer than a few days.

     

    As others have said the real answer is "when it is ready". Here's hoping it is imminent...

     

    Mike

  2. I can understand this info being kept in a log of historic problems... but the system should definitely detect resolved problems (especially connection ones!), and not show them once cleared.

     

    This should apply to virus definitions and OS updates too, as these are only really useful whilst current! Once system is updated, ERA should show as green for these machines instantly.

     

    Is this coming in ERA v6.2?

     

    Mike

  3. I have found that when creating a live installer, that putting the routable URL in the optional "address of server as seen from client" box does work. I had tried that on a early test and not got it to work, so hadn't pursued that further. There must have been something else broken on that first attempt that threw me off the scent!

     

    So I've managed to connect some new clients externally using that method with the live installer. I've also successfully used the policy method to fix some already deployed agents. So I am least working now...

     

    Ok. I'm still interested in whether there is merit in changing that SQL table entry, so that it uses the routable URL to the same server. Feels like that wluld be neat, with no downsides (if it will work)

     

    My next move though is probably to wait for ERA v6.2 as there was something about moving servers coming, which may or may not be what I'm looking for. If that doesn't fix it, I might then try the SQL route (with suitable backups first) to see if that works.

     

    Mike

  4. I tried option 1 tonight, and mine is still reporting OS out of date warnings from 2 weeks ago... despite the update task completing successfully tonight, and the agent concerned reporting in many times in the last few hours since the update completed.

     

    Really feels like a crucial piece of the software reporting logic needs fixing urgently for this feature to be any use. Here's hoping it comes in v6.2 in the coming days....

     

    Mike

  5. Nosing around the SQL tables, I found:

    tbl_servers

     

    which only has one row in my table, which has an entry for:   server_name.local-domain.lan

     

    Can I edit that row to have the externally routable version of that URL instead?

     

    I would be tempted to just try it to see, but I wasn't sure what the "server_mask" column was there for, and therefore if it would break something if I changed the URL in that table.

     

    Anyone any thoughts about that?

     

    Keen to change the default somewhere, so that everything that references the default URL for Eset Rempte Admin gets the correct one, without me having to manually change it a variety of places as suggested above (like manually updating policies, manually updating the bat files for installers etc).

     

    Mike

  6. Thanks for that. Not sure how I didn't find that before.

     

    What I discovered was that the server URL set in those policies was actually set as "127.0.0.1" which surprised me! (Wasn't even the machinename.localdomain.lan)! I'm presuming it wasn't actually using this setting, as that wouldn't find the correct server even locally on the office network, so presumably there is another setting somewhere, which was being used to route the agents to the correct server internally... just not from out on the internet.

     

    Anyway.... forcing out a policy with the correct externally routable URL has worked for those external laptops that I could VPN back in to the main office from, so they could pick up the policy change and then they were able to successfully report back correctly even without the VPN. So that solution is going to be all good for those which I can visit and temporarily connect via a VPN to the office.

     

    However, I get the impression that the Agent installer by itself is looking for the non-routable URL (presumably in the form: machinename.localdomain.lan  rather than 127.0.0.1) and therefore even if I remotely install the agent onto these machines, I will still need to get them to connect somehow to pick up the correct policy to start calling home.

     

    This is an issue for us, as most of our laptops permanently live in the field and never connect to the office network (neither locally or via VPN).

     

    What I need is a way to change the default setting, so that when I give them the Agent (by whatever means) it is already configured correctly, so I don't need to do anything else extra to get them to pick up the new correct policy, and therefore is ready to go.

     

    Is this something I can change somewhere as the default? Or even re-build the agent installers with the correct setting baked in. I feel like I must be missing something obvious somewhere... and have been surprised I can't find it..... unless it is something that can only be set at the time of install and not changed later??

     

    Mike

  7. Hi,

     

    Foolishly I set the URL for my test install of ERAv6 as one that is only internally routable (i.e.  era_server_name.local-domain.lan) and I am now rolling it out wider, I realised my mistake.

     

    I now want to enable agents to connect via an externally routable URL (i.e.  era.external-domain.com) instead, but unsure where to change this? Is it in a profile setting somewhere, or in the agent itself? (I want to both change already connected agents/machines so they phone home when outside our lan, and also change the default so that new machines I rollout the agent to out in the field can now connect too).

     

    I've already configured the DNS for the desired routable URL both internally and externally, and configured the router to do the required port forwarding.... I just need to set the agents and the ESET products to connect there.

     

    Thanks

     

    Mike

  8. @michalp

     

    Thanks for the info. They are the conclusions I was coming to, but couldn't find in the documentation to prove either one.

     

    If there was a way to re-run the startup wizard routine, that might be useful to reimport the settings from a changed OVF file.

     

    It would also be great if these permitted locales were listed in the config help document for that OVF file.

     

    Thanks

     

    Mike

  9. Yeah, we only have about 30 clients here, so running a dedicated CentOS VM is possibly overkill anyway.

     

    Ironically, the reason I jumped to the pre-made CentOS VM in the first place was because of problems getting it working on SBS2008 (which eventually ESET support have resolved anyway - but after I'd already removed it from that machine!).

     

    The reason I persisted with the CentOS VM despite my initial problems, was that I decided that SBS2008 was probably the wrong place for it, even though ERAv5 had been happily running on that machine for several years. I think that dropping it onto a different Windows Server instance would make sense though.

     

    I'm OK with Linux, although Nano was a bit of a pain (compared to other simple command line text editors).

     

    We have a separate apps server which gets pretty low usage too, so I might use that machine for the task. I was planning to upgrade that machine to Server 2012 R2 and virtualise it in the near future, so utting it on that box would work. Save having extra cpu & memory overheads for another virtual machine & OS. It is also one less OS to manage and keep up to date!

  10. Hi,

     

    I was trying to install ERA v6 on an SBS2008 server and had a few issues, so I abandoned that route completely, and decided to use the supplied VM file to install the CentOS based system VM into Hyper-V (running on Server 2012R2).

     

    I kept failing to get the system to deploy and I incorrectly thought it must be incorrect values in the OVF config files, so in the end I ran the OVF config using the barest minimum to get it working (just the new password and en-NZ as locale - everything else as default). Turns out the problem was actually caused by an external network problem in Hyper-V (which I fixed elsewhere), so my fancy config file probably would have worked if I'd realised in time.

     

    I have now tried to re-edit my OVF config file to gain domain membership and AD groups. That doesn't appear to be working, and the name of the era server doesn't appear to be updating either. This leads me to believe that the OVF file is only being used on the first boot-up / configuration only, and is then ignored after that? Is that correct?

     

    Is there a way to get the OVF file to be re-read to update the settings on the installation, or do I pretty much have to start again with the conversion of the VM file into the right format? The docs aren't very clear if the OVF file is a one-hit thing, or a means of re-configuring the system in the future.

     

    I am also seeing errors about locale of server and setup being different, so I wonder if en-NZ is actually a supported location for the OVF anyway! If I need to re-deploy, I would want to get the correct value in that box next time.

     

    I also have a few questions around updating of CentOS and ERA, but I'll leave those until I get the configuration correct!

     

    The whole experience has made me concerned about the viability of using the supplied VM anyway, and wondering if I shouldn't just install ERA myself on-top of a copy of Windows Server 2012 / R2 (i.e a different box than my SBS install). It has been a VERY steep learning curve compared to ERAv5 which just worked. (I note other are equally frustrated with ERAv6, so glad it isn't just me finding problems - I'm normally good with new technology!)

     

    Thanks in advance for your help,

     

    Mike

  11. Hi,

     

    I have questions about this feature too.

     

    So I want to capture false positives for my own domain:  exampledomain.org

    This domain is allowed to send mail from our ISP's mail server, but also a few other places, so there will be maybe 5-10 separate IPs to allocate.

     

    Do I put the exampledomain.org in the From box?

     

    Then how do I handle adding all the different legitimate servers to accept mail from? Do I make multiple line entries each with exampledomain.org in the from box?

     

    What do I put in the score box? Is this a number that gets added on to the rest of the score calculated elsewhere? (so if I put 40 in this box, and the email already had a score of 55 from other spam detection criteria, then this would bump the score up to 95 if the mail came from that domain, but from an IP not listed... is that how it works?)

     

    The description of how this feature works could do with a bit of clarification.

     

    Thanks for your help.

     

    Mike

  12. I just heard (in this thread) that ESET have supposedly fixed this issue in the latest release version of EMSX (4.5.10015).

     

    I haven't tried installing this update yet, but maybe the first person who gets it installed, and confirms it has indeed solved the problem, can report back here for everyone. I will certainly be glad to be able to strip out my transport rules as I never managed to tweak them to get exactly what I wanted without some unintended implications!

     

    Thank you ESET. I was starting to think that with the Microsoft aspect to the problem, it might never get fixed!

     

    Mike

  13. Awesome! It always struck me as a little bit odd that ESET went to the trouble of defining all the categories of spam, probably spam, probably clean, and clean, BUT then to only allow treatment and tagging of the SPAM category. If there is a way to allow treatment at all those the different levels, that would be great.

     

    If you want to talk it through some more, then feel free to get in touch.

     

    I'll look into the 4.5.10015 update as have a proper solution to the BLANK SENDER issue will be great!

     

    Thanks

     

    Mike

  14. Hi,

    I have been frustrated by the limited options for dealing with Spam in Eset Mail Security for Exchange for a long time.

    (I outlined my frustrations a couple of years ago in this thread).

     

    The summary of my frustration is that ESET Mail Security allows us to define really accurately levels for Spam, Probably Spam, Probably Clean, and Clean with a granularity of 1 to 99 scoring. However the Quarantine/Deleting/Tagging module is very crude in only allowing us to deal with only the "Spam" category defined above - the others being ignored! This seems daft to me....

     

    The suggested work-around is to use ESET to write to the SCL, and then filter and quarantine in Exchange Transport. This is not very useful, because the high granularity that ESET provides in 1 to 99 scoring, is reduced to a crude 1 to 9. In our case, most spams arrive in the 9 category (including some false positives), so no chance to divide between them intelligently and therefore I might as well use ESET Quarantine for finer adjustment.

     

    This is where I have got to in the past on this subject, and I had accordingly left ESET doing the Quarantining for me, and suffered the one hit nature of the Quarantining action as being better than the crude SCL alternative because of the ability to trigger at 92 (for example) rather than a simple SCL=9.

     

    However, ideally I'd be able to trigger a range of different actions to happen at different levels (like available in Exchange), but to use the ESET 1 to 99 range instead of the crude SCL that the Exchange route demands. (ie Delete at one score, Quarantine at a different score, Tag at yet another score etc).

     

    I think I might have stumbled across a potential fix for this, but it is still at the ideas stage.... so I wanted to bounce it off a few more knowledgeable heads before I do a test run (and risk upsetting my users!)

     

    The idea came from my solution to solve the blank sender spam problems as discussed here. Because these Exchange Transport Rules can use the headers, they can be triggered by any text match, I was wondering if I could set up some rules to trigger some more granular processing. They can potentially respond to the "X-ESET-AS: SCORE=99" type line in the header.

     

    However, whilst I feel like it is probably possible to achieve what I want, I don't want to create a separate rule for each spam score number to be actioned, i.e. one rule for 99, one rule for 98, one rule for 97 etc etc.

     

    Ideally I want to split out my own higher category of "Blatant Spam" as I define it (probably just 99 for now), and quarantine these in a separate quarantine location that needs less thorough checking - but maybe ultimately delete/reject these outright if the rules works well with no false positives.

     

    Then I would Quarantine say 93 - 98 and keep for easy checking by an admin.

     

    I would then deliver but tagged as [spam], maybe scores of 88 - 92 (so the user sees and deals with these)

     

    Below that I might deliver untagged, or possibly have a [spam?] tag for another range.

     

     

    Any ideas if what I am hoping for might be achievable using transport rules?

     

    Mike

     

     

  15. I've checked with ESET, and their solution is basically a rehash of mine:

    hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3346

    They suggest text filters for keeping hold of Out of Office, and delivery failure notices. I might still keep my SCL=1 in there, as at least this will allow any SCL=-1 entries to pass through unblocked (which seemingly many Out of Office messages are).

    So it looks like no further progress has been made on this, however I am guessing the problem lies with Exchange, so ESET might not be able to do much about this other than offer workarounds.

    I'll try some text rules with "SCL=1 and above" and see how it works...

    Mike

  16. I'm getting some of them with a SCL of 1 now. That seems ridiculous! Looks like my rule is now picking up some genuine delivery failure messages too, which is a pain as the user doesn't know their email failed to get through.

    Will need to tweak the rules if I can to allow them through, or I'll have to manually pass delivery failure messages back to the intended recipients.

    Ideally ESET would have their own solution in place by now, any news on this? This was meant to just be a temporary bandaid solution...

    Mike

  17. Glad this has helped others too.

    Just to report back, that I've had mails slipping through with a SCL of 3 which seems pretty low to me. Of course the ESET scoring isn't available since it can't write to the headers, so we'll have to live with that.

    Fortunately most "Out Of Office" messages appear to have a confidence level of "-1" so it would appear we can set this rule down that low without causing any OoO messages to be lost.

    I'll be testing that new low value from today. Other than this most recent spam that slipped through, the rule has been owrking perfectly for me.

    Mike

  18. We have been having the most annoying spam problem for the last week with "Eset Mail Security for Exchange" (EMSX from here onwards) and Exchange 2007 (on an SBS2008 server).

    The spams started last Friday, and are typified by having a "Return-Path" in the header as: "<>".

    EMSX correctly identifies all these emails as spam, and says it has shifted them to the Quarantine as we have configured it to do. However the offending emails with a blank return path sender are actually being delivered to the end user's mailboxes instead of the quarantine!

    I spent several days faffing with various of my own fix attempts, before finally reporting it to Eset NZ (Chilisoft). Eset were aware of the problem, and had been attempting various fixes themselves for another site.

    In the end ESET's devs have discovered it was an Exchange problem, where Exchange was stopping ESET or itself from writing anything to the headers of the emails. Their offered work-around today was:

    You can use the following workarounds for the time being (use one or the other):

    1) Configure EMSX to delete spam instead of quarantining it. This works correctly but there is a risk of deleting a valid message.

    2) Enable Sender Filtering and "Block messages that don't have sender information". This is an Exchange option (see here: hxxp://technet.microsoft.com/en-us/library/bb125179(v=exchg.141).aspx)

    Since we get too many false positives to make me happy to use the first suggestion, that only left the second.

    I tried creating the Sender Filtering for an email address called "<>" and set it to "Stamp Message as Blocked Sender" (since I also wasn't keen to reject these messages without knowing what effect it would have). However, it soon became apparent that this wasn't working, presumably because Exchange isn't writing to the headers, so of course it doesn't write the Blocked Sender message on the message. DOH! Should have realised that would be the case!

    Since ESET narrowed down the problem and issued their work-around earlier today, I've tried various other fixes in an attempt to find one that is acceptable for my environment until a long term fix can be put in place. I finally cracked it tonight with the following "Transport Rule" in Exchange.

    This method is flexible and powerful enough to allow you to process these spams in pretty much any way that suits you and is totally safe too!

    • Open “Exchange Management Console”

      .

    • Go to: Organization Configuration > Hub Transport > Transport Rules

      .

    • Choose create a new Rule.

      .

    • Give it a name: I chose “Blank Sender Spam Filter Rule”

      .

    • Give it a helpfully descriptive comment to remind you what the rule is for in future. I chose:

      “Spam Processing rule for Blank Sender in the "Return Path" (displays as "<>") with SCL above 7 (to let OutOfOffice messages through untouched). This rule is created to overcome a problem where spam with no return path gets corrected detected and marked as being sent to Quarantine, however the mail actually passes through to the mailbox untouched, and not marked as spam or removed. This is an Exchange Problem, but it also affects "Eset Mail Security for Exchange", since Exchange2007 blocks writing to the headers of these emails.”

      .

    • The most important bit is on the “Conditions” page, you tick:
      • “When a message Header contains specific words”. Then click the underlined “message header” at the bottom and type “Return-Path” and click the underlined “Specific Words” and type “<>” (both without the speech marks).
      • “When a Spam Confidence Level (SCL) rating is greater or equal to a limit”. At the bottom choose something like 7 or 8 for this limit. This will hopefully allow Out Of Office replies from external sources (which also often have an empty Return Path) to pass through to the intended recipient untouched by this rule. Before I added this extra condition, OoO replies were being quarantined too.
      post-339-0-64485200-1368786969_thumb.png

      figure 1 : screen grab summary of the “conditions” page

      .

    • For the Actions page you can choose your own actions as suits your needs. I have chosen for now to tick:
      • “log an event with message” so I can track how often the rule is being triggered, it also helps with testing.
      • “prepend the subject with string“ to add a distinctive spam label so I know where the message is coming from. I chose: [spam-TransportRule]
      • “redirect the message to addresses” and send it to your quarantine mailbox address for monitoring.
      post-339-0-63922600-1368786967_thumb.png

      figure 2 : screen grab summary of the “actions” page.

      .

    • When you know the rule is working safely to your liking and not capturing any false positives, you could choose to delete or reject the message on this action page instead of redirecting and labelling as spam.

      .

    Hopefully this simple Transport Rule creation wizard will help others to be rid of this Blank Sender spam until a more permanent fix can be found by ESET or Microsoft, and will save a few of you some hair-pulling frustration!

    Hope this helps a few other people...

    Mike

×
×
  • Create New...