Guest 9999

Online Armor fares poorly in latest firewall test

Recommended Posts

Guest 9999

The March 2014 Firewall test from AV-Comparatives shows Online Armor in a very poor light.  I suspect/hope this is due to their purposful lack of configuration to simulate an "average" user's experience with default settings.  I've happliy used OA for years on XP, and just purchased a Win 8 laptop which I was planning to try OA free on.  But I'd need some reassurance & recommendations from Emsisoft as to why AVC scored them so poorly & how to avoid a similar real-world experience.  Report & screencap attached, along with a Google link to the report (I gave up trying to navigate their website):

https://encrypted.google.com/search?q=firewall+2014+site%3Ahttp%3A%2F%2Fwww.av-comparatives.org&btnG=Search&hl=en&as_nlo=&as_nhi=&lr=&cr=&safe=images&gbv=1

post-24912-0-69855900-1396302504_thumb.jpg
Download Image

Share this post


Link to post
Share on other sites

First of all: I have removed the PDF you attached. The PDF is copyrighted material and must not be uploaded anywhere without the written permission of AVC. The test report is available here:

http://www.av-comparatives.org/wp-content/uploads/2014/03/avc_fw_201403_en.pdf

We tried to replicate their results to figure out what went wrong, but unfortunately we can't replicate the behavior they documented on our test systems. We are currently in contact with AVC to figure out what exactly happened. I will post an update as soon as we heard back from them.

Share this post


Link to post
Share on other sites
Guest 9999

Thanks for the quick reply, I look forward to hearing more.  I'm sure you guys know what you're doing, but maybe one of the other firewalls they tested left some conflicting component behind, or maybe it had something to do with some sandbox or VM they were using?

Share this post


Link to post
Share on other sites

The test was done on real hardware. More likely is a conflict between Online Armor and the driver of the wireless LAN adapter they used. But we won't know until we get more details from them.

Share this post


Link to post
Share on other sites

It would be interesting to have a reply to the concern's about OA's default configuration here and not on Wilders. This is the place where people that use OA should expect a decent reply to the very disturbing results in AV comparative's test.

 

I also find Fabian Wosar's reply to the RDP issue (basically confirming RDP access will always be allowed by default, since the RDP port is not part of the restricted port's list) to be quite surprising. How is it acceptable that in its default configuration, OA behaves worse than the native W7 firewall?

  • Upvote 1

Share this post


Link to post
Share on other sites

I also find Fabian Wosar's reply to the RDP issue (basically confirming RDP access will always be allowed by default, since the RDP port is not part of the restricted port's list) to be quite surprising. How is it acceptable that in its default configuration, OA behaves worse than the native W7 firewall?

Technically RDP isn't a threat unless you turn it on (it is off by default in Windows). Also, incoming RDP traffic wouldn't make it past the Network Address Translation on most routers and modems, so this would only be an issue on connections that don't have NAT (such as 3G/4G "mobile broadband" connections).

On top of that, Windows user accounts are required by RDP by default. If you have a single user account and no password, then it shouldn't work at all (at least on Windows 7). If you have a password, then someone connecting via RDP would need to know it. Obviously the security settings can be changed for the Remote Desktop Service, and there are older and potentially more vulnerable versions of Remote Desktop, however for these things to be changed without your knowledge then an infection would need to bypass the protection of Online Armor's HIPS and your anti-virus software.

There's also the fact that RDP is one of the most widely used remote access protocols, and blocking it would be unacceptable to a great many people and businesses.

Share this post


Link to post
Share on other sites

I also find Fabian Wosar's reply to the RDP issue (basically confirming RDP access will always be allowed by default, since the RDP port is not part of the restricted port's list) to be quite surprising. How is it acceptable that in its default configuration, OA behaves worse than the native W7 firewall?

RDP is off by default. You must turn it on first, which is equivalent to your expressed consent to use RDP. How would bothering you to enable it twice be of any benefit to you?

Share this post


Link to post
Share on other sites

Technically RDP isn't a threat unless you turn it on (it is off by default in Windows). Also, incoming RDP traffic wouldn't make it past the Network Address Translation on most routers and modems, so this would only be an issue on connections that don't have NAT (such as 3G/4G "mobile broadband" connections).

On top of that, Windows user accounts are required by RDP by default. If you have a single user account and no password, then it shouldn't work at all (at least on Windows 7). If you have a password, then someone connecting via RDP would need to know it. Obviously the security settings can be changed for the Remote Desktop Service, and there are older and potentially more vulnerable versions of Remote Desktop, however for these things to be changed without your knowledge then an infection would need to bypass the protection of Online Armor's HIPS and your anti-virus software.

There's also the fact that RDP is one of the most widely used remote access protocols, and blocking it would be unacceptable to a great many people and businesses.

RDP works fine when part of the restricted ports list and the connecting computer is trusted or the network is trusted. 

 

The issue is precisely of relevance when you are not behind a hardware firewall, which happens often enough, as it doesn't seem that you want OA to be bought only by those that use it behind a hardware fireall. In such a situation, it would be expected that OA provides complete stealth. Hey, the Windows firewall does it, how is it understandable that OA does not?

 

 

RDP is off by default. You must turn it on first, which is equivalent to your expressed consent to use RDP. How would bothering you to enable it twice be of any benefit to you?

It would provide a better degree of control. Your reply applies to multiple situations where you are going to use a firewall. If I want to enable MySQL or SQL Server I need to install such apps and open my firewall to allow connections. I don't see how this is different.

 

I understand there is a trade off between ease of use and security and the balance is rather delicate. However, having a firewall that does not provide full stealth by default, is not, IMHO, a very good option. You can even argue that OA is configured to deal with most frequent or most likely threats, but that still is not enough. Microsoft's own arguing about MSE, for example, is that it fares well enough in real life situations, as it protects against most likely threats. Should we use MSE over EAM because of that? I doubt that your answer will be yes, and rightly so.

 

To be honest, this situation is not Emsisoft's fault alone, as much of this situation persists from the time of Tall Emu. I find it rather surprising that you don't see this as a liability, one that can affect OA's credibility. 

Share this post


Link to post
Share on other sites

It would provide a better degree of control. Your reply applies to multiple situations where you are going to use a firewall. If I want to enable MySQL or SQL Server I need to install such apps and open my firewall to allow connections. I don't see how this is different.

Actually, both will create default firewall rules to enable remote access to the ports involved. So in fact you don't have to create those firewall rules to allow connections. You need to create them to limit connections, which is the same approach Online Armor takes. That being said, Online Armor is not built for an enterprise environment. We don't even support server versions of Windows officially. So any enterprise scenarios can be dismissed simply based on the fact that the product isn't tailored towards that clientele.

 

I understand there is a trade off between ease of use and security and the balance is rather delicate. However, having a firewall that does not provide full stealth by default, is not, IMHO, a very good option.

It does provide full stealth by default. Enabling RDP is not the default. That's the point.

You can even argue that OA is configured to deal with most frequent or most likely threats, but that still is not enough. Microsoft's own arguing about MSE, for example, is that it fares well enough in real life situations, as it protects against most likely threats. Should we use MSE over EAM because of that? I doubt that your answer will be yes, and rightly so.

Microsoft's stance is the opposite. They actually encourage people to use something other than MSE and see MSE as the bare minimum base line of protection. Just look at Microsoft's reactions to some of the tests.

 

To be honest, this situation is not Emsisoft's fault alone, as much of this situation persists from the time of Tall Emu. I find it rather surprising that you don't see this as a liability, one that can affect OA's credibility.

Online Armor's credibility is not that it is an excellent firewall. Quite frankly the firewall part is by far the weakest part of it due to lacking IPv6 support and the fact that it doesn't allow for more complex rules. If you ever tried to create more advanced rules that are possible in almost every firewall product out there, you know what I am talking about. It is also the reason, why we decided to rebuild the firewall core of the upcoming Emsisoft Internet Security suite from scratch instead of just using the Online Armor firewall parts. Online Armor's strength is outbound control as well as the HIPS. Both aspects are far more relevant to home users, which is the target audience for Online Armor, and were completely ignored by the test you are referring to.

That being said, we do have plans to implement the new firewall core we developed for our Emsisoft Internet Security product in Online Armor as well.

Share this post


Link to post
Share on other sites

Actually, both will create default firewall rules to enable remote access to the ports involved. So in fact you don't have to create those firewall rules to allow connections. You need to create them to limit connections, which is the same approach Online Armor takes. That being said, Online Armor is not built for an enterprise environment. We don't even support server versions of Windows officially. So any enterprise scenarios can be dismissed simply based on the fact that the product isn't tailored towards that clientele.

 

It does provide full stealth by default. Enabling RDP is not the default. That's the point.

Why do you think only enterprise scenarios would need this? I am a developer, I have MySQL and SQL Server installed both on my desktop and laptop, as I need them for development work. I run my own network at home and I use my laptop in multiple networks. I have my network cards as untrusted in OA and I individually trust machines I want to allow access to my computers. It works fine at home but, in the case of the laptop, I want to use it in whatever networks I intend without need for reconfiguration and I would like it to be stealth and for sure wouldn't want RDP attempts to occur from machines I have not authorized. The purpose of the firewall in OA should include not allowing machines not marked as trusted in networks not marked as trusted to connect to a machine running OA in anyway.

 

 

 

 

Microsoft's stance is the opposite. They actually encourage people to use something other than MSE and see MSE as the bare minimum base line of protection. Just look at Microsoft's reactions to some of the tests.

 

I have seen different replies in different contexts. One of such replies is based on the telemetry data collected by Microsoft, that purportedly shows MSE would be effective in a huge percentage of  such "real world scenarios" - the telemetry data is collected from "real" computers spread out through the world. If I was to be reassured by such a reply, I would be using MSE, not EAM.

 

 

Online Armor's credibility is not that it is an excellent firewall. Quite frankly the firewall part is by far the weakest part of it due to lacking IPv6 support and the fact that it doesn't allow for more complex rules. If you ever tried to create more advanced rules that are possible in almost every firewall product out there, you know what I am talking about. It is also the reason, why we decided to rebuild the firewall core of the upcoming Emsisoft Internet Security suite from scratch instead of just using the Online Armor firewall parts. Online Armor's strength is outbound control as well as the HIPS. Both aspects are far more relevant to home users, which is the target audience for Online Armor, and were completely ignored by the test you are referring to.

 

Well, I don't see how things can be put that simply. I don't want threats coming in, even if OA is great at stopping them getting out, once they get in. That doesn't make sense to me, I am sorry to say it. I have always seen (and recommended) OA as a great part of a decent security strategy, and I am quite surprised that you are so clearly stating OA's firewall is not that good. I guess I will have to think more carefully whether I can recommend OA, at least for people who will be running it in scenarios where there is no hardware firewall.

 

I also think your previous statement is a bit contradictory. I don't think home users have very complex needs regarding the creation of firewall rules and OA's firewall should be a good option for such users. It does lack in terms of default config, it seems, but even that could be easily overcome, if you so desired.

 

As to the credibility, you should be careful about what you say, really. I came here today alerted by a user on the Windows Secrets Lounge that was simply asking if he should switch from OA to something else. Also, the replies on the Wilders Security forum do not seem to follow your reasoning, at not least not a relevant part. To me, personally, it does affect OA's credibility to the point that I may have to stop recommending it, which is something I have been doing for many years, at least until a decent reply to the questions raised by the test in question is given.

 

I thank you for your openness, even if I am not that happy about OA's firewall apparent weaknesses. 

Share this post


Link to post
Share on other sites

Why do you think only enterprise scenarios would need this? I am a developer, I have MySQL and SQL Server installed both on my desktop and laptop, as I need them for development work.

Which is already an enterprise scenario.

I run my own network at home and I use my laptop in multiple networks. I have my network cards as untrusted in OA and I individually trust machines I want to allow access to my computers. It works fine at home but, in the case of the laptop, I want to use it in whatever networks I intend without need for reconfiguration and I would like it to be stealth and for sure wouldn't want RDP attempts to occur from machines I have not authorized. The purpose of the firewall in OA should include not allowing machines not marked as trusted in networks not marked as trusted to connect to a machine running OA in anyway.

In that case Online Armor isn't the product for you. The only aspect trusted and untrusted computers interact with are protected ports. Meaning if you have any server running and allowed it to open a port, this port will be accessible from both trusted and untrusted computers unless the port was specifically set to be restricted. You can't even create rules manually to do what you want to do in Online Armor at the moment, which brings me back to my previous statement that rule creation in Online Armor's firewall is very limited. So you can't create rules manually to get the result you want in Online Armor by specifically dropping all incoming packets from a given network except if they were sent from specific IPs in your network. Emsisoft Internet Security will allow you to do exactly that by the way:

qrQhNZ4.png

Using that dialog, you can just create rules to drop all packets from a specific network, before application rules are taken under consideration, except for packets that have been sent from specific computers you trust. That's the first time anyone has seen that dialog by the way, so consider yourself special ;).

 

I have seen different replies in different contexts. One of such replies is based on the telemetry data collected by Microsoft, that purportedly shows MSE would be effective in a huge percentage of  such "real world scenarios" - the telemetry data is collected from "real" computers spread out through the world. If I was to be reassured by such a reply, I would be using MSE, not EAM.

Microsoft is a huge company, so different replies are bound to happen. Just look at the "UAC is a security feature" and "UAC is not a security feature" mess. In general I prefer to go with the statements of the people who worked on it, so I tend to believe the MSE manager's reply, that they are bound to be the bottom of the test because they don't even try to be the best to allow for innovation by third party developers that users should actually use more than what any PR guy tries to sell as a reaction to another disastrous test result. But we are getting kind of off-topic here.

Well, I don't see how things can be put that simply. I don't want threats coming in, even if OA is great at stopping them getting out, once they get in. That doesn't make sense to me, I am sorry to say it.

Except that you won't even get to the PC from the outside in the first place due to the aforementioned prevalence of routers. Even if the system is connected directly to the internet, you need a vulnerable service first that you can access from the outside, which is exceptionally rare for most home users since all Windows default services are already protected. So this leaves you with stuff coming in from a connection initiated by your computer first (like your browser for example), which no firewall will protect your from because a firewall only cares about who and what is sending or receiving packets and not the content of these packets.

I have always seen (and recommended) OA as a great part of a decent security strategy, and I am quite surprised that you are so clearly stating OA's firewall is not that good. I guess I will have to think more carefully whether I can recommend OA, at least for people who will be running it in scenarios where there is no hardware firewall.

Or just tell them to add RDP to their protected port list. Which will fix the issue you are referring to. If they even use RDP, which they most likely won't because TeamViewer and Co. are just so much more hassle free since they just work and don't require ugly port forwarding rules :).

 

I also think your previous statement is a bit contradictory. I don't think home users have very complex needs regarding the creation of firewall rules and OA's firewall should be a good option for such users. It does lack in terms of default config, it seems, but even that could be easily overcome, if you so desired.

So if we add RDP to the list, you will find a different port that is not on it. And you can apply the same arguments to that new port as well. And another one, and another one. The default ruleset covers exactly that: The defaults. RDP is not a default. If you try to take into account all possible services the user may enable or install, you quickly end up with a convoluted port list containing thousands of entries.

But even if you somehow come up with a set of guidelines on how to choose which of all the possible ports is worth being added to the restricted port list or not, you still end up with a huge issue: Online Armor Free does not allow access to Advanced Mode which contains the restricted port list. So if there was an Online Armor Free user out there, that does want to use RDP over the Internet (which isn't so far fetched, given that this is the original purpose of RDP), he can't, because only computers and local networks can be marked as trusted. He can't delete the port restriction either, simply because he does not have access to the required menus.

Since you are a developer you are also quite aware about how difficult it is to change defaults. Should the defaults be applied to the existing installations as well? This will break any setups that rely on RDP not being restricted. You will understand how big of an issue losing remote access to a system you don't have physical access to can be just because we decided to publish an update that suddenly added RDP to the list of restricted ports. Should we not apply the new default? Than potentially thousands of existing installations will remain "unprotected".

Bottom line is: Changing the default config is not nearly as easy as you make it out to be.

Share this post


Link to post
Share on other sites

Which is already an enterprise scenario.

 

Well, it may be a matter of semantics, but I would call it more of a power user scenario. Any user with a bit more knowledge and a willingness to experiment may install software that communicates over any given port and it should be possible to use OA to protect such ports with minimum effort (or none at all, preferably).

 

 

In that case Online Armor isn't the product for you. The only aspect trusted and untrusted computers interact with are protected ports. Meaning if you have any server running and allowed it to open a port, this port will be accessible from both trusted and untrusted computers unless the port was specifically set to be restricted. You can't even create rules manually to do what you want to do in Online Armor at the moment, which brings me back to my previous statement that rule creation in Online Armor's firewall is very limited. So you can't create rules manually to get the result you want in Online Armor by specifically dropping all incoming packets from a given network except if they were sent from specific IPs in your network. 

 

Damn, wish you would have told me that about 5 years ago, been wasting license money all this time :).

 

Emsisoft Internet Security will allow you to do exactly that by the way:

qrQhNZ4.png

Using that dialog, you can just create rules to drop all packets from a specific network, before application rules are taken under consideration, except for packets that have been sent from specific computers you trust. That's the first time anyone has seen that dialog by the way, so consider yourself special ;).

 

Thanks, I appreciate you showing that. 

 

 

Except that you won't even get to the PC from the outside in the first place due to the aforementioned prevalence of routers. Even if the system is connected directly to the internet, you need a vulnerable service first that you can access from the outside, which is exceptionally rare for most home users since all Windows default services are already protected. So this leaves you with stuff coming in from a connection initiated by your computer first (like your browser for example), which no firewall will protect your from because a firewall only cares about who and what is sending or receiving packets and not the content of these packets.

Or just tell them to add RDP to their protected port list. Which will fix the issue you are referring to. If they even use RDP, which they most likely won't because TeamViewer and Co. are just so much more hassle free since they just work and don't require ugly port forwarding rules :).

 

So if we add RDP to the list, you will find a different port that is not on it. And you can apply the same arguments to that new port as well. And another one, and another one. The default ruleset covers exactly that: The defaults. RDP is not a default. If you try to take into account all possible services the user may enable or install, you quickly end up with a convoluted port list containing thousands of entries.

 

As I said before, many people use laptops out in the wild, with no firewall in between. These users surely want to know their laptops are protected, as well. 

The user who started this on the Windows Secrets Lounge was already advised to add the RDP port to the protected ports list.

 

Indeed, full protection would likely mean "protecting" all ports. If that turns out to be expensive, do it the other way around, unprotect used ports. It would be a more economical way of doing things. It would be easy to produce this from the allowed ports list that already exists for each allowed program. Anyway, this discussion may be a bit theoretical now, since you are doing it anew.

 

 

But even if you somehow come up with a set of guidelines on how to choose which of all the possible ports is worth being added to the restricted port list or not, you still end up with a huge issue: Online Armor Free does not allow access to Advanced Mode which contains the restricted port list. So if there was an Online Armor Free user out there, that does want to use RDP over the Internet (which isn't so far fetched, given that this is the original purpose of RDP), he can't, because only computers and local networks can be marked as trusted. He can't delete the port restriction either, simply because he does not have access to the required menus.

 

That's a commercial decision, not a technical one. I understand introducing limitations in low cost (or free) versions, but somehow diminishing from the feature set of  paid versions because of free versions, doesn't look that easy to understand. Of course, different configurations could be used for free and paid versions, even with the added maintainability issues - but that is your concern, and it should not affect your customers.

 

 

Since you are a developer you are also quite aware about how difficult it is to change defaults. Should the defaults be applied to the existing installations as well? This will break any setups that rely on RDP not being restricted. You will understand how big of an issue losing remote access to a system you don't have physical access to can be just because we decided to publish an update that suddenly added RDP to the list of restricted ports. Should we not apply the new default? Than potentially thousands of existing installations will remain "unprotected".

Bottom line is: Changing the default config is not nearly as easy as you make it out to be.

 

Users expect continued operation with no (or minimal) disruption  so that should determine what to do. That doesn't mean that the possibility of giving users the option to choose, let's say,in Advanced Mode, the choice of loading a new set of defaults, with adequate warnings, would not be possible.

Even when you introduce a new product to replace OA (Emsisoft Internet Security may it be) and the product works differently in this respect, some existing users that migrate to the new solution (even if not all), will experience similar situations, so warnings and full clarification of the change in behavior will still be required.

 

Look, as I said in my opening post, I understand that this goes back the origin of OA, but this doesn't limit the damage that such a glaring failure from OA can cause.

 

Again, I thank you for your candor. I think you have provided me with enough info to understand the full scope of the situation. Is there any idea on when the new security product will be on the market?

Share this post


Link to post
Share on other sites

Well, it may be a matter of semantics, but I would call it more of a power user scenario. Any user with a bit more knowledge and a willingness to experiment may install software that communicates over any given port and it should be possible to use OA to protect such ports with minimum effort (or none at all, preferably).

I consider adding a port to a single location minimum effort. Especially for power users, that are more likely to find the option in their firewall to disallow access to ports from untrusted networks than home users trying to find a way to allow them.

 

As I said before, many people use laptops out in the wild, with no firewall in between. These users surely want to know their laptops are protected, as well.

Those laptops are protected. What you tend to forget here, is that we were unable to reproduce any of the AVC results so far and only AVC tends to get these results. I am not doubting that the behavior on those systems occur as described, but a lot of people tried to recreate them and failed, which usually points toward an incompatibility between Online Armor and something on their system. Even their logs show that Online Armor blocked all tests with the exception of RDP, which isn't supposed to be blocked by design if the user allowed the RDP service to open the port, but for some reasons packets still get through. We are still busy trying to find out what is going wrong in their setup, but since we are relatively close to an EIS release we decided to focus on that first and look into the AVC issue after the EIS release.

 

Indeed, full protection would likely mean "protecting" all ports. If that turns out to be expensive, do it the other way around, unprotect used ports. It would be a more economical way of doing things. It would be easy to produce this from the allowed ports list that already exists for each allowed program. Anyway, this discussion may be a bit theoretical now, since you are doing it anew.

Such a system would be really really messy though. I mean, Online Armor already asks for processes that want to open a port. So people who allow the port to be opened, will expect that the application is actually able to communicate over that port without a second secretive list that is hidden somewhere in an advanced GUI mode. The reason that the protected port list exists is because a lot of the ports that Windows opens by default like the file sharing is done in kernel mode, so it can't be assigned to an actual process. If it wasn't for that, the list would have likely never existed in the first place.

 

Look, as I said in my opening post, I understand that this goes back the origin of OA, but this doesn't limit the damage that such a glaring failure from OA can cause.

Except that it isn't a glaring failure to begin with. You need to turn it on, Online Armor will ask you if you want the process open a port to allow outside computers to connect to it via the internet, you say yes and the port is available. If you want to limit access to the port based on source addresses you will need manual intervention. But that is always the case with any firewall product out there.

 

Again, I thank you for your candor. I think you have provided me with enough info to understand the full scope of the situation. Is there any idea on when the new security product will be on the market?

It has been in testing since the end of last year. We are making good progress and we expect it to move into public testing soon. However, there is no ETA we feel comfortable to commit to. In the end our goal is to release a stable product. Not meet a deadline.

Share this post


Link to post
Share on other sites

Fabian,

 

Thank you for your replies. I think there is no point in debating every single point you made, since we would disagree. I think I have stated my concerns and you have provided your views in a clear manner.

 

I think I will agree with you on that initial statement about OA not being known for being an excellent firewall. That seems clear, now. I hope EIS is a better solution, in that respect.

 

Regards

Share this post


Link to post
Share on other sites

Current firewalls do not seem to filter out packets from ports 1024-65535 tcp / udp mostly.

What worries me in armor online, that is to allow a program to access the internet will automatically allow access to any door without any warning and pop-up alert does not show information such as IPs, ports, files not recognized application tries to access or modify (lay users can allow or block something amiss). Another problem I see is that even manually configuring some armor online applications will ignore this and recreate new rules.

For print posted a few posts above, I saw the suite Emsisoft bring something like competing products.

Sorry my English!

Share this post


Link to post
Share on other sites

I have the two following questions:

 

1. according to the last post: how to close ports, say 10000-65535, for both TCP and UDP;

I tried to do it in Firewall -> Restricted Ports -> Add, but I was not able to enter a ports interval

 

2. when will you introduce to OA the firewall solutions you want to apply in EIS

 

That being said, we do have plans to implement the new firewall core we developed for our Emsisoft Internet Security product in Online Armor as well.

Share this post


Link to post
Share on other sites

I1. according to the last post: how to close ports, say 10000-65535, for both TCP and UDP;

I tried to do it in Firewall -> Restricted Ports -> Add, but I was not able to enter a ports interval

You can't, but it isn't necessary. Those ports are not open by default and you will have to confirm applications trying to open any ports if they are unknown.

 

2. when will you introduce to OA the firewall solutions you want to apply in EIS

Sometime after EIS is released. Since the EIS ETA is not known yet, neither is a possible OA update.

Share this post


Link to post
Share on other sites

OK, thank you for your reply!

 

BTW, I found the indirect way to close the ports:  Firewall -> Rules -> Ports -> New -> (All programs, Deny, Protocol: Both, Direction: Both)

Share this post


Link to post
Share on other sites

Where there is nothing open, there is nothing to close. You will get issues with that rule however, as applications you specifically allowed and want to open ports, may fail to do so.

Share this post


Link to post
Share on other sites

That being said, we do have plans to implement the new firewall core we developed for our Emsisoft Internet Security product in Online Armor as well.

 

Sometime after EIS is released. Since the EIS ETA is not known yet, neither is a possible OA update.

 

So, EIS is released, congratulations!  :)

And now could you please tell us something about your plans regarding the possible future development of Online Armor?

Share this post


Link to post
Share on other sites

And now could you please tell us something about your plans regarding the possible future development of Online Armor?

We will share information as soon as we are closer to a possible release, as we usually do.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.