Jump to content

dallas7

Member
  • Posts

    142
  • Joined

  • Last visited

Everything posted by dallas7

  1. ThreatDB and components OK. Virus sigs not... Created: 11/22/2011 9:30:05 PM Summary: Automatic Update successful Description: New threat database has been downloaded and installed Event type: Auto update(11) Event action: None(1) Created: 11/22/2011 9:30:08 PM Summary: Automatic Update successful Description: New version of Online Armor components has been downloaded and installed Event type: Auto update(11) Event action: None(1) Created: 11/22/2011 9:30:08 PM Summary: Virus signatures update failed Description: Failed to update the AV module. Event type: Auto update(11) Event action: None(1)
  2. I'm seeing the same OA++ error as JWC: Created: 11/22/2011 12:36:30 PM Summary: Virus signatures update failed Description: Failed to update the AV module. Event type: Auto update(11) Event action: None(1) Last attempt was 11/22/11 17:42:54 MST (UTC -7) No ThreatDB/Components updates observed, failed or otherwise since then. Last successful Virus/ThreatDB/Components updates was 11/21/11 22:21:22 for OA++ Last successful ThreatDB/Components updates was 11/21/11 21:12:22 for OAP FWIW, Ashampoo A-M Ikarus and Emsi virus file updates have been OK through this period.
  3. Thank you for your personal attention to my thread. While I appreciate there must be a timely delay before you push out an updated T3 engine, my original inquiry was about the version 1.1.103.0 1.1.107.0 engines beginning with my support ticket opened November 2. The .109 arrived coincidentally during that discussion which prompted the opening of this thread on November 11. My point was that the v5.1.0.1331 setups I downloaded almost two months ago installed OAP and OA++ with a T3 engine at least six months old. And it remained that way even after I activated my ++ license and while OA itself went through two updates. (Yes, as far as I know OAP makes no use of either engine, but your installer nonetheless builds an A2 directory wherein they reside.) In re-reading these posts I do notice your use of "the old engine" (singular) which may imply you planned to support only engine.dll and abandon t3.dll. This would be a logical conclusion considering the T3 versions from .103 to .107 were never published. Can you please assure us updates for both engines will be published up until the time you retire OA++? Cheers.
  4. Not quite sure why the silence on this posting or why it felt like I was pulling teeth over at [email protected] but today I got a resolution: "Hello, the current version of the t3.dll in Online Armor++ is 1.1.109.0. The update was released yesterday." But no comment or answer to my inquiry on commitment to future updates of engine.dll or t3.dll and I've run out of energy to persue that - anyone here care to elucidate? OA++ customers should check their A2 folder for the file version date in Properties under the Details or Version tab. Since I successfully updated T3 myself (via method beyond the scope of this posting), I can't report if the push is actually occurring though I have no cause to think otherwise. There are three legitimate reasons why I'm so concerned about the engine updates: 1) Ikarus and Ashampoo deemed it necessary to update the T3 engine, as did Emsisoft for Anti-Malware (v5 & v6) and Emergency Kit. It is therefore necessary for OA++. 2) A new installation of OA++ having a T3 engine from April is OK but not receiving an update is not OK. As a reminder, as per the CEO: I reiterate that it is not my expectation, nor will it ever be, that OA++ be developed out to the new a2engine.dll or a next iteration of Ikarus. I do expect that updated versions of the current engine.dll and t3.dll be pushed out until the time that Emsisoft deems it to be to their advantage in the marketplace to phase out OA++.3) In October I had a sample of a file identified at that time as trojan.win32.jorik.IK by Emergency Kit, Ashampoo, Virus Total (T3 v1.1.107.0 & Emsisoft) and Hitman Pro (Ikarus & A2). However, as of November 1 OA++ (T3 v1.1.103.0 or the A2 v? engine) did not detect it which prompted opening a ticket with [email protected] on November 2. Aside: I had not tracked the Emsisoft engine through this period but my OA++ and Emergency Kit versions are both at the current file version 5.10.11. Thank you for allowing me this venue to present my perspective (though not as "interesting" as the one from ruirib.) Cheers.
  5. Yes. Except for Ashampoo A-M, my XP and Win7 systems have near mirror setups. I have been expecting Set Filter for Win 7 would eventually look like XP but that's not happening (OA++SetFilt.jpg & OAPsetFilt.jpg respectively from screenshots above). Since I don't use the laptop (Win7, OA++) as much as I use my tower, it wasn't until just recently I have directly observed the "Show update notifications" and History functions are failing. This behavior is consistent and repeatable: I can pick up my laptop after a day and half or so and open the lid and within a minute watch connections open to emsisoft, online-armor and ikarus, monitor a bunch of stuff download and related system activity. No components, threat data base or signature notifications whatsoever. Nor are the usual three entries to be found in History - just those a day or more older (Program Guard, Firewall decision, etc.) from the last time I used the laptop. But I can browse the folders and see a bunch of new files where they would be expected to be. This behavior is hit or miss: I have "Check for updates" set for one hour. When I work with the laptop for a few hours, I'll usually see three or four virus updates and maybe a threat database and there will either be a notification or not and a History entry or not. I don't consider these to present any compromise to security or protection as I'm satisfied the updates are implemented correctly. I'm just "Look what I'm seeing" and possibly can we get those secondary features in line. Having log filters is nice. Especially since OAP on WinXP is working so well. Cheers!
  6. I've got a support ticket open for this at the Customer Center (since 11/2), but I thought I'd throw this up here, too. I was surprised to see the Ikarus T3 engine as version 1.1.103.0 in OA++ which I installed a few weeks ago, run as a trial for 28 days then registered. 1.1.107.0 had been current for some months and I was expecting an eventual update to 1.1.107.0 but failed to see that happen as of this posting. Today Ashampoo A-M updated from 107 to 109. If you run/update the free Emsisoft Emergency Kit today you'll get 109. Ikarus has available 109 for its free command line app. While I fully understand and support Emsisoft's OA++ roadmap with respect to its own current version 6 engine and an inevitable next-gen Ikarus (T4?) engine, I don't believe it's too much that 109 be pushed out to OA++ users. Especially in consideration that OA++ is still offered for sale at Emsisoft (http://www.emsisoft..../software/oapp/) and marketed at sites like Softpedia, FreebieST and Downloadcrew. I don't believe this would in any way detract by much from the work being done now toward a highly anticipated "new common code base" replacement for EISP. 1) Can we expect 109 to be pushed out to OA++ any time soon? As in maybe next week the latest? 2) If one manually replaces the 103 dll with 109, will that "break" anything? Thank you!
  7. This is an interesting thread and now my curiosity is tweaked... Just to be clear, we're discussing the "Date Modified" date stamp. Right? I notice these dat files exist in two places in each of my OA++ and OAP installs: in the Online Armor root folder and the a2 subfolder. As of this posting the stamps for a2trust are respectively 9/27 and 3/25 in OAP and 10/19 and 10/24 in OA++. FYI, run and update Emergency Kit (a2emergencykit.exe) and that file is 10/24. I have had In addition, automatically trust programs signed with valid digital signatures always enabled since installing OA on my two systems for the first time early in October. Does that needed to be disabled in order for a2trust.dat to get updated? And is it my understanding that the blacklist is handled by a file named a2trust.dat? Cheers.
  8. It seems like the Log Viewer in ++ on my Win7 system isn't building selections as nicely as in Premium on my XP system. As far as I've observed, these selections populate automatically unless there's something I've been doing that escapes my notice. The ++ one should have at least as many by now as the Premium. "Enable logging" is "All activity" and all Firewall Ports rules are set to "User Defaults" for Logging. Any ideas? Thanks!
  9. My humble opinions for all OA products: I notice the OA Premium Components and Threat Database gets updated at least once a day so I set for every 6 hours. To my knowledge, the "Check for updates:" selections in Free are the same as in Premium. As for OA++, Ikarus alone releases T3 signatures nearly every two hours (sometimes more) and Emsisoft is nearly as active with their A2 sigs. Which is just one of the many reasons why they're so good. So I set that to check updates every hour. FYI: the Ikarus product, Anti-Virus Utilities, default check interval is 20 minutes and can't be adjusted; overkill IMHO. Cheers.
  10. I went back to Options to return Updates to Every Hour and noticed that other thing and thought, "I wonder...?" I unchecked "Send anonymous information about programs...." and lo and behold the crazy oaui.exe bahvior ceased! Rechecking it returns the craziness. Re-unchecking it stops it. I'm going to leave it unchecked. Cheers!
  11. Thank you. Upon re-re-examining JWC's attachment, that now makes sense. Perhaps a screen shot from, well, I don't know, maybe... Device Manager might have been a better choice. Cheers.
  12. Yes and yes. On both systems, XP/OAP and W7/OA++. I have updates set to one hour on both. I've observed updates are handled by OArau.exe with connections to update.emsisoft.com. oaui.exe is wanting online-armor.com, www.tallemu.com, www.online-armor.com, crs.online-armor.com, crq.online-armor.com or lus.online-armor.com.
  13. Thanks. When I installed OA++ on my new Win7 laptop, I thought the dialogue for install/skip for TLEM was generated by the OA installer; it didn't look like a Windows dialogue. Be that as it may, when I installed .1331 earlier this month I now in hindsight recall I did skip TLEM which resulted in the kinds of issues shown in the "There are no active interfaces" screenshots posted by trujwin in the May 31 "Network computers not listed" thread here. I contacted [email protected] and was queried about the TLEM install, but couldn't remember. When .1383 was released I decided not to wait for the resident updater. I uninstalled .1331 and installed .1383, this time allowing TLEM - problems solved. That TLEM thing is one heck of a wrench in the cogs. In the meantime, I'm still wondering about... In the aforementioned JWC post #3 there is a screen shot of an occult third party utility showing a process named OAnet - Driver, OnlineArmor Service. Task Manager on my XP and W7 systems show an Image Name of oasrv.exe and oasrv.exe *32 and described as Online Armor Component in W7. Are we talking about the same thing here?
  14. Thanks. I'm going to disable that Notify function then. Not much use otherwise. So sad.
  15. The behavior persists even when "Lookup external..." is disabled. I've attached a screenshot from W7/OA++ (rather than a text copy) to show I'm not making this up. And I was mistaken about the behavior in OAP under XP. I noted a port 80 TCP rule for oaui.exe, probably built during post-install learning. I monitored connectivity similar to W7/OA++. I deleted the rule and was almost immediately prompted to build a new one... Created: 10/30/2011 9:31:36 PM Summary: Firewall: User decision Description: C:\Program Files\Online Armor\oaui.exe, Outgoing TCP access allowed to: (online-armor.com;www.tallemu.com;www.online-armor.com;crs.online-armor.com;crq.online-armor.com;lus.online-armor.com) MY.WAN.IP.ADR:80 Event type: Firewall: User decision(15) Event action: Allowed(2) Here is a copy of the connectivity... 30/10/11 21:55:50 TCP -> 192.168.0.7:1060, 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/0) Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 30/10/11 21:57:26 TCP -> 192.168.0.7:1061, 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/1840)Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 30/10/11 21:57:27 TCP -> 192.168.0.7:1061, 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/0) Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 30/10/11 21:58:06 TCP -> 192.168.0.7:1062, 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/880) Passed by rule: "TCP, --> oaui.exe, [80], +(*)" This activity is continuous and persistent. I decided to block the port 80 rule and the connectivity to 80.237.x.x went berserk: 31/10/11 10:02:04 [TDI] TCP, Connect, 0.0.0.0:1197 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/4016) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:04 [TDI] TCP, Connect, 0.0.0.0:1198 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/2112) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:04 [TDI] TCP, Connect, 0.0.0.0:1196 -> 80.237.191.14:80, C:\Program Files\Online Armor\oaui.exe(1456/1080) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:05 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:05 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:05 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:05 [TDI] TCP, Connect, 0.0.0.0:1201 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/2712) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:10 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:10 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:10 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:10 [TDI] TCP, Connect, 0.0.0.0:1202 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3032) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:14 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:14 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:14 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:14 [TDI] TCP, Connect, 0.0.0.0:1203 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3432) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:18 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:18 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:18 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:18 [TDI] TCP, Connect, 0.0.0.0:1204 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3072) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:22 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:22 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:23 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:23 [TDI] TCP, Connect, 0.0.0.0:1205 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3196) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:27 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:27 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:27 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:27 [TDI] TCP, Connect, 0.0.0.0:1206 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3212) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:31 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:31 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:31 ICMP <- Echo reply 192.168.0.7 80.237.152.26Passed by ICMP rule 31/10/11 10:02:31 [TDI] TCP, Connect, 0.0.0.0:1207 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3008) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:35 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:35 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:35 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:35 [TDI] TCP, Connect, 0.0.0.0:1208 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/2360) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:40 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:40 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:40 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:40 [TDI] TCP, Connect, 0.0.0.0:1209 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/1480) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:44 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:44 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:44 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:44 [TDI] TCP, Connect, 0.0.0.0:1210 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/2528) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:48 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:48 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:48 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:48 [TDI] TCP, Connect, 0.0.0.0:1211 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3284) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:52 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:52 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:52 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:52 [TDI] TCP, Connect, 0.0.0.0:1212 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3412) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:02:57 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:02:57 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:57 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:02:57 [TDI] TCP, Connect, 0.0.0.0:1213 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3292) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:03:01 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:03:01 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:03:01 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:03:01 [TDI] TCP, Connect, 0.0.0.0:1214 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3688) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:03:04 [TDI] TCP, Connect, 0.0.0.0:1215 -> 80.237.191.14:80, C:\Program Files\Online Armor\oaui.exe(1456/3024) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:03:04 [TDI] TCP, Connect, 0.0.0.0:1216 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3400) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:03:04 [TDI] TCP, Connect, 0.0.0.0:1217 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3516) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:03:05 [TDI] ICMP, Connect, 0.0.0.0 -> 80.237.152.26, C:\Program Files\Online Armor\oaui.exe(1456/1524) [TDI] Passed by rule. 31/10/11 10:03:05 ICMP -> Echo request 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:03:05 ICMP <- Echo reply 192.168.0.7 80.237.152.26 Passed by ICMP rule 31/10/11 10:03:05 [TDI] TCP, Connect, 0.0.0.0:1218 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/596) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:03:54 [TDI] TCP, Connect, 0.0.0.0:1219 -> 80.237.191.14:80, C:\Program Files\Online Armor\oaui.exe(1456/3564) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:03:54 [TDI] TCP, Connect, 0.0.0.0:1220 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3676) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" 31/10/11 10:03:54 [TDI] TCP, Connect, 0.0.0.0:1221 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/3956) [TDI] Blocked by rule: "TCP, --> oaui.exe, [80], -(*)" Needless to say, I returned the rule to allow and things returned to "normal": 31/10/11 12:12:04 [TDI] TCP, Connect, 0.0.0.0:3452 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/5788) [TDI] Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 31/10/11 12:12:04 TCP -> 192.168.0.7:3452, 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/5788) Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 31/10/11 12:12:04 [TDI] TCP, Connect, 0.0.0.0:3451 -> 80.237.191.14:80, C:\Program Files\Online Armor\oaui.exe(1456/5176) [TDI] Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 31/10/11 12:12:04 TCP -> 192.168.0.7:3451, 80.237.191.14:80, C:\Program Files\Online Armor\oaui.exe(1456/5176) Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 31/10/11 12:12:05 TCP -> 192.168.0.7:3452, 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/5788) Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 31/10/11 12:12:05 [TDI] TCP, Connect, 0.0.0.0:3453 -> 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/5188) [TDI] Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 31/10/11 12:12:05 TCP -> 192.168.0.7:3453, 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/5188) Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 31/10/11 12:12:05 TCP -> 192.168.0.7:3451, 80.237.191.14:80, C:\Program Files\Online Armor\oaui.exe(1456/5176) Passed by rule: "TCP, --> oaui.exe, [80], +(*)" 31/10/11 12:12:06 TCP -> 192.168.0.7:3453, 80.237.152.26:80, C:\Program Files\Online Armor\oaui.exe(1456/5188) Passed by rule: "TCP, --> oaui.exe, [80], +(*)" I could accept this if I understood why it is necessary. Otherwise, I'd like to turn it off. What say? Thank you.
  16. Is it normal for OA++ oaui.exe to open a port 80 TCP connection to various sub-domains (including www) at online-armor.com for a couple of seconds every 90 seconds or so? (I'm seeing that on my Win7 system, not my XP system running OA Premium.) Thanks!
  17. For those of us (and me) who arrived at this show during intermission, do I wrap up this correctly? 1) For Win7 the OA installer prompts for permission to allow or skip the installation of TLEM, but not for WinXP. 2) Win7 has the OnlineArmor Miniport hidden Network adapter. WinXP does not. And these, if you don't mind: In the aforementioned JWC post #3 there is a screen shot of an occult third party utility showing a process named OAnet - Driver, OnlineArmor Service. Task Manager on my XP and W7 systems show an Image Name of oasrv.exe and oasrv.exe *32 and described as Online Armor Component in W7. Are we talking about the same thing here? In that same post it's mentioned "The oanet.sys driver (which was the TLEM driver)..." If that was the driver, what is it now? Cheers.
  18. On both my systems; OAP & OA++ When "Notify when OA contacts OASIS in realtime" is enabled, there's a balloontip every time there is any activity and the balloon seems to be populated with relevant data. However it's impossible to read that data as in wink of an eye another balloon appears, "Online Armor updated database according to the latest OASIS information." Is there any way to suppress that second balloon tip? I've tried to do that and if there is a way, it's not jumping out at me. Thank you!
  19. Ah, I didn't know that; thanks for the clarification. Since I have the BITS service disabled I just passed over that when I read the online help for that. My bad... But I am confused by that as it would infer the entries in Domains are exclusive to the Banking Mode which I do not use. I recently added *.verisign.com and *.*.verisign.com and was somewhat deluged by "Potential DNS Problem detected" pop ups even during casual surfing. Since the first two IPv4 octets of the 20-bit block address range were always a match, I always selected Allow. After about a week of that, I concluded that there is a disagreement in the lookups used by you and DynDNS and removed the two entries from Domains. Especially since the frequency of the pop ups increased in annoyance while logged into banking and financial sites. However, I do have about two dozen carefully crafted Protected entries for several of the banking/financial sites I use almost daily while not in Banking Mode. I am assuming that judging by the behavior for VeriSign described above, entries in Domains are acted upon regardless of Mode. Correct? BTW, none of the above are complaints in any way - just reporting my observations seeking further understanding. And, yes, those wild-carded entries for VeriSign are overkill. But it was fun to watch. But now with respect to all that I am befuddled as to how (in Premium and ++) to draw a line between Banking and Advanced Modes and as to where Web Shield begins and ends in those environments. Cheers!
  20. Premium and ++ will add things there when Learn is used for the Banking Mode - which is not in Free. http://www.emsisoft.com/en/info/oa/KF-Banking.html It's up to you, the astute user, to add domains manually as you see fit in the Free version. That's my understanding as it is.
  21. Just curious: The Online Help indicates, "This option allows you to change whether Online Armor will pop-up when the loopback interface is used and is enabled by default." When one un-checks "Intercept loopback interface," it is assumed, then, that ALL popups for 127.0.0.1 are suppressed and ALL those connections are allowed by default from thereon. Correct? Thank you!
  22. Yes, the *.ikarus.at I plugged in yesterday is gone. Sneaky! The Banking Mode was never a bullet point in my research for what I needed to find for a new Win7 64-bit system as my much-loved Malware Defender is 32-bit only. I turned off Malware Defender on this XP system so I could run a trial OAP and ended up purchasing a license. So, I'll mess with Banking Mode some more for that bank and if it works out it works out. That said, it does well with PayPal and another bank I use. I'm pretty much squared away with OAP otherwise; it bends nicely to my will and my Complete Control Obsession. Thanks again for your patience and steadfast support. You're the best. Cheers!
  23. Again, thank you for the reply. You've given me enough information to make the informed decision I needed to make. I never meant to imply you wouldn't take care of your customers or that I hold any malice toward the acquisition of OA by Emsisoft. However, be that as it may, I was never wild about running a behavior blocker and a HIPS, two of the best and extremely powerful, running under separate applications each having having had distinct and separate origins, design philosophy and development paths. But that's just me and why I decided to go with OA++ for the new laptop. Even if the Internet Security Pack was the only option, you can understand my reluctance to go with that at this point in time when Anti-Malware 6 looms so near. I never meant, either, to nail you down as to all of what the future brings, but just the period of a newly purchased OA++ license. The way I see it, you'll be supporting A2 sigs for, if not all of, most of that time. As for T3, if Ikarus decides to completely revamp their engineering, they'll have to support the previous one for a while, too. So, by the time I might be forced to abandon OA++ or (better yet) the license expires, the IS Pack will have matured considerably or you'll have brought your common code base product to market. Either one being a win-win. Pondering of all that, I wonder what Ashampoo is thinking about for their Anti-Malware? Oops. Did I go off topic? Cheers!
  24. 1) Good point! I had added Ikarus as Ashampoo A-M pulls the T3 sigs from there (and the A2 sigs from its own domain). I wonder if OAP is smart enough to know that and purge such entries from the Domain List?? I'll add it again and see what happens. This is almost fun. However, I did observe that the Ashampoo updates failed until I added *.ashampoo.com (and *.ikarus.net). Which indicates *.ashampoo.com works but *.bitdefender.net does not. What's wrong here? 2) Yes. The banking site will stall screen refreshes as it hammers the Internet until it finds either svrintl-crl or svrsecure-g2-crl which were used when that banking domain was learned. I'd not mind adding new VeriSign FQDNs manually until performance becomes acceptable, but as you can see from my experience with OCSP.AMS1. - it's isn't working. 3) Sorry. I forgot to mention I tried the ? and still had the problem. I am satisfied with the eight entries as that is all that is needed. Just adding it to the discussion. Thank you.
×
×
  • Create New...