Here is a really embarassing question

Never concerned about exposing my knowledge gaps I want to ask this.

Is there such a thing as a false positive when my OP FW scan log lists a blocked attacker ip and the ports it scanned?

In other words,OP is telling me ip x scanned 4 ports etc and in fact the scan never occurred at all?

What am I missing here?

 

How do you know it was a false positive? I mean the log said that someone had done a port sniff. How do you know that it didn't actually happen? Just trying to clarify.

 

No . No such false positive exists . It is POSSIBLE OP misread something but , something did happen . And it was PROBABLE they were all 4 port scans . To clarify : No . Not a false positive

 

With OP yes.

Could be late replies, (as we have seen with the "DNS late reply" thread), and yes, late replies can get through a router and then be blocked by the software firewall.

- Stem

 

Hi: Well, the OP technical support told me it was BUT I don't KNOW it.

You are right, I don't know that either, it's very confusing to my feeble brain the scan either happened or it didn't.

I'll read Stem's post now and see if I can learn about this mess.

 

Hello Stem:

In this case, OP FW Pro 7 windows 7 64 bit, the "false positive" is always from the exact same ip and follows the exact same user (me) activity.

1) I turn off OP's self protection
2) I update OP (on manual update) and "new" downloads arrive, presets (rules)and scripts etc
3) Then up comes the blocked ip and ports scanned message/log


FWIW, I have DNS service disabled as I use DHCP.

The recommended OP solution is to place this ip/site in the excempt from filering list ( cover it up as I see it). That site is the OP update site itself.
Is this a wise remedy?

All my other update sites produce NO such warnings.

I will now read the DNS late reply thread.

Thanks for replying.

 

Blast, I can't find

DNS late reply thread

Wilder's search doesn't like the DNS word...

 

This one?

https://www.wilderssecurity.com/showthread.php?t=256231

 

Thanks Fax!

 

No problem!

 

Hi Escalader,

IMHO, no. Agnitum need to find/resolve the problem, certainly as it is from their own servers.

Do you have the log entries for the blocked packets?

- Stem

 

Right, I didn't follow their advice.

I'll give you some text log now and some "new" more detailed jpg logs if I can be scanned again

PS: I reduced the block time to 5 minutes now

1:33:30 PM 74.53.2.24 Subnet blocked for 60 min SCAN (52161, 52673, 53185)

Order 1
IP Address 74.53.2.24
Status Succeed
Country USA - Texas
Network Name NETBLK-THEPLANET-BLK-14
Owner Name ThePlanet.com Internet Services, Inc.
From IP 74.52.0.0
To IP 74.55.255.255
Allocated Yes
Contact Name ThePlanet.com Internet Services, Inc.
Address 315 Capitol
Suite 205
Houston
Email admins@theplanet.com
Abuse Email abuse@theplanet.com
Phone +1-281-714-3560
Whois Source ARIN
Host Name
Resolved Name updates.agnitum.com

resolved names are:

4e.2.354a.static.theplanet.com
1a.2.354a.static.theplanet.com
52.2.354a.static.theplanet.com


or variations.

 

It is actually the packets I am interested in, to see what OP is classifying as need to block the IP.

Is there anything in your logs to show their IP being blocked and what the packets are? (if I remember correctly, OP would log to flag level for TCP).


- Stem

 

Attached are 2 logs please ask for more as you see fit.

 

The first just appears to show what is allowed, the second does not tell us anything to show the reason for the block.

I am wondering if it is RST packets (which used to be blocked by the attack plugin) that is setting off this block (which would be amusing).

I would get back to OP support. They need to confirm that either:- Their server is attacking you, or the firewall is incorrect with its filtering/blocking.

This, to me, just shows bad packet filtering.

- Stem

 

Will submit ticket # 2 on this one. I'll reference this thread for the details. They will enjoy that

Mean while I got it again and provide now a 3rd log from their FW to see it that gives any clue on this one.

NOT DNS protocol if the log can be believed.

The only other clue (maybe) was just prior to this chain of events the system went out to OpenDNS using DNS.

 

Yes, its showing what I thought in that the firewall is blocking all packets with "RST" flag, which puts forward Agnitum believes all packets containing "RST" flags are illegal

What I believe is happening, is that after you make your update, the Agnitum servers are closing the connection with RST(more than likely RST ACK) and the firewall with is blocking of such packets as an attack is then blocking the server (the firewall is even blocking the outbound RST ACK and calling it an attack,... are you attacking anyone?)

Once again I will say:- Bad packet filtering.


- Stem

 

Thanks Stem, I'm not surprised.

To answer your question YES, maybe the vendor advocates may think I'm attacking them by complaining

I'm considering un-installing OP at this point since I can't trust it's protection filtering being weak.

I hate the idea of the work to setup Windows FW for outbound control

 

This in itself does not show a weak filtering firewall, just that it is incorrectly blocking IPs.
Just disable the "block attacking IP" option. As you are behind a router it is not a case that you are going to be directly scanned from external (to LAN) IPs.

Dont then, just leave OP installed.


- Stem

 

Right, I'll hang in there for a bit.

 

I must have misunderstood . The scans were scans . I am guessing you were asking if OP blocking something because it thought it was a threat . In that case , most certainly falses can happen . I thought you wanted to know if OP would tell you there was a scan when there was not . I apologize . Glad someone else understood

 

No need to apologize! I had no clue only observations.

If it wasn't for Stem and posters like him who call it straight I still wouldn't know. The block was/is real just misnamed/id'd by the software.

OP needs to fix this as IMHO it is a chronic condition for them.

 

Hi Stem:

To disable the "blocking attack IP option" as you called it, I made the following settings in OP FW Pro 7.

Comment please, does this seem okay to you?

 

Surprise! Agnitum support has asked for all my logs, config file and machine ini files. They indicated that Agnitum does NOT scan client computers and that their developers believe this is a BUG!

I have sent them this data and the hints from this thread to assist them in their work.

We wait, now I will implement Stem's workaround to avoid false blocks/logs etc.

I wonder where I send the user testing bill

 

Hi Escalader,

Yes, that should stop that IP being blocked, but will still stop any scans.

Can you do a quick test (I know you like testing), in that attack plugin, disable the "Port Scanning" option, then run the update for OP. Then check your logs for blocked packets (you can of course also enable the port scanning option again in the attack detection after the update).


- Stem