Hi,
Outpost is not exactly getting any more logical in its blocking behaviour. Have a look at the following log entry:
Block UDP packet sent: [myip:port] -> [remoteip:port] Allow all activity for [program.exe]
Nice, eh? Observed with v2284.
Regs,
150d
PS: Can anyone tell me how to suppress those idiotic smiley icons when posting normal text?
Just now, I was noticing that a packet was allowed through using a rule that didn't apply to it - again. The rule was defined for an executable that didn't exist any more (residing on a removable drive) and did specify this program as "trusted". It was applied to a packet that clearly didn't have anything to do with the rule - nor was it the correct EXE nor the right port. (And again, sorry, I didn't capture any of the log before clearing it. But the issue is described in depth in an earlier post of mine where I first discovered the problem. Circumstances haven't changed.)
I have seen this (and complained about) with versions prior to 2284, too. The bug has not been fixed. Gentlemen, I dare say we have a problem here.
Regs,
150dYou may be right. It's hard to say exactly without seeing the details. I've never seen a rule for one program being used by another unrelated program. So if that happened then I'd say its a bug. I would report that to Agnitum: 1
Welcome to the forum.
An example please from the logs showing what you are describing.
even in 'trusted' an application may prompt a block where an incoming packet is unexpected. a UDP packet, being connectionless, can be sent out by a program, and if it does not get a reply within a reasonable window, may provoke a block as op can no longer assume it was legit. you may be able to add a rule allowing incoming udp to/from the subject ports and the myip/remoteip.
text with a full colon (":") (or a semicolon ';')followed by other punctuation or characters frequently provoke a smilie a : followed by a ( or ) will do this :( this is frowning) adding a space is enough to kill it as in : ( this is not frowning)
the std. smilies are:
:p = :p
;) = ;)
:D = :D
:o = :o
:( = :(
:) = :)
another more labour intensive method is to surround the offending text in a {noparse}{/noparse} (use square brackets though) to forbid the forum software from parsing, or converting, the text, which is what i used in the table above.
Now with it off.
:p
Dang - that works. You learn something new every day.
but it's for each post apparently that setting doesn't stick.
An example please from the logs showing what you are describing.
Assuming "bcom" is seeing the same problem as I do there is just nothing interesting to post from the log: It says that a.exe is being allowed by the rule "allow all for b.exe". That's it.
Regs,
150d
select either "Standard Editor" or "Enhanced Interface".
Now the option is visible. Thank you very much for the hint.
Regs,
150d
Check this screenshot, the option is disabled by default.
There is no such option in my interface:
That might work. Lets see with that option on.
:p
This comes down to the sequence in which OP applies its rules. Namely:
Block intruder's host (Attack Detection)
Trusted Zones
Global NetBIOS Block/Allow Rule
Low-Level System Rules with the "High Priority" flag set
Global Rules applied before application rules
Application Rules (Blocked/Trusted/Partially Allowed)
Low-Level System Rules
Global Rules applied after application rules
Allow NAT Packets
ICMP Rules
Outpost Policy
Block Transit Packets
So a trusted application is not exactly non-existent.
http://www.agnitum.com/support/kb/article.php?id=1000120&lang=en
As far as the smilies just remember to put a space after a colon or a semicolon.
even in 'trusted' an application may prompt a block where an incoming packet is unexpected.
I don't understand what you mean. If I define a program as "trusted" the firewall should be as non-existent where communication with or by the said program is concerned. If the program chooses to handle a packet, that's fine, if it chooses not to, that has to be fine with the firewall, too.
Besides, Outpost obviously detected that the packed was intended for the program in question, else it wouldn't have cited the specific rule. Why did it still interfere?
a UDP packet, being connectionless, can be sent out by a program, and if it does not get a reply within a reasonable window, may provoke a block as op can no longer assume it was legit. you may be able to add a rule allowing incoming udp to/from the subject ports and the myip/remoteip.
I _have_ defined a rule for this case. It says "whatever comes or goes from this program, leave it alone" - unless I'm wrong that exactly is the definition of "trusted". Why isn't this rule followed?
another more labour intensive method is to surround the offending text in a {noparse}{/noparse} (use square brackets though) to forbid the forum software from parsing
This &%§$ is really getting me down. Isn't there any place one can disable this crap once and for all, globally? Moderators?
Regs,
150d
As far as the block, I agree with your reasoning but can you post some of the other log entries around that blocked entry.
Ah - sorry, I didn't save any more of it. This message was repeated all over together with two other blocks (some RIP and IGMP router messages that are always blocked).
Contradications like this usually end up being a configuration issue but it may be that something is wrong with the 2008 Trusted list, since hardly anybody uses it we don't focus too much on it.
Just now, I was noticing that a packet was allowed through using a rule that didn't apply to it - again. The rule was defined for an executable that didn't exist any more (residing on a removable drive) and did specify this program as "trusted". It was applied to a packet that clearly didn't have anything to do with the rule - nor was it the correct EXE nor the right port. (And again, sorry, I didn't capture any of the log before clearing it. But the issue is described in depth in an earlier post of mine where I first discovered the problem. Circumstances haven't changed.)
I have seen this (and complained about) with versions prior to 2284, too. The bug has not been fixed. Gentlemen, I dare say we have a problem here.
Regs,
150d
I don't think so individually. But try going into your profile and in the Message Editor Interface select Basic Editor mode. That's the only possibility I see. It may not work since the code is built into the message entry box by the forum software.
As far as the block, I agree with your reasoning but can you post some of the other log entries around that blocked entry. I'd like to see what else was going on at the time. Just copy and paste them here. Your IP address is non-routable so its not a security issue. OP is usually pretty logical how rules are applied. Contradications like this usually end up being a configuration issue but it may be that something is wrong with the 2008 Trusted list, since hardly anybody uses it we don't focus too much on it.
This comes down to the sequence in which OP applies its rules.
I don't think that this is open for interpretation since Outpost explicitly stated the rule it based the "block" on. It was not some deep-hidden setting but a defined rule. Which happened to say "allow all".
But you're right, let's take this piece by piece:
Block intruder's host (Attack Detection)
AD is disabled completely.
Trusted Zones
This should only be a "Positive Rule", meaning that some communication would be allowed even though it wouldn't be otherwise. Not the case here.
Global NetBIOS Block/Allow Rule
UDP traffic, convention doesn't apply.
Low-Level System Rules with the "High Priority" flag set
None do exist.
Global Rules applied before application rules
None apply.
Application Rules (Blocked/Trusted/Partially Allowed)
Matching rule was cited in the log entry, it says "allow all" (trusted).
Low-Level System Rules
None apply.
Global Rules applied after application rules
None apply.
Allow NAT Packets
"Positive Rule", even though I don't exactly understand what it does...?
ICMP Rules
Set to "allow everything".
Outpost Policy
Set to "Rules wizard", in other words, "ask about what you don't know and treat the rest by the rules defined".
Block Transit Packets
Not the case here.
So the packet shouldn't have been blocked, don't you agree?
As far as the smilies just remember to put a space after a colon or a semicolon.
So it really is tue, the crap cannot positivly be disabled at all?
Regs,
150d
i have the exact same porlbem with rules being applied for different programs. It does onky occur when ypou specify rukes for a application different to allowing all or blocking all trafic. So I tried avoiding it by only allowing or blocking all traffic for my apss, but in some cases outpost doesnÄt accept this and does always promt on each connection attempt until you create a specific rule...
Here it is a little different:
- When I start the program (emule.exe) the first time I get asked the usual questions. I choose "allow all". The program then works quite well.
- When I start the same program a second time, every connection that is attempted prompts the rule wizard. Regardless of what I choose, the question always pops up again.
The alternative I found is to completely remove the program from Firewall/Network Rules after each run, before I start it a second time. If I do that, on the second run the questions (raw IP access, run as server etc.) appear anew, but only once each.
Additionally, if I do not remove the program from Outpost's settings after the program has been run, its rules are applied to other executables. Any connection, in or out, may be wrongly allowed by the "allow all" for emule.exe even it is maintained by a completely different executable.
I have reported this problem to Agnitum even before christmas last year, if I remember correctly. Nothing happened, the current version still has the same security hole.
Regs,
150d
i have the exact same porlbem with rules being applied for different programs. It does onky occur when ypou specify rukes for a application different to allowing all or blocking all trafic. So I tried avoiding it by only allowing or blocking all traffic for my apss, but in some cases outpost doesnÄt accept this and does always promt on each connection attempt until you create a specific rule...
This &%§$ is really getting me down. Isn't there any place one can disable this crap once and for all, globally? Moderators?
As far as I know not globally. You can disable smilies for individual post. When replying or posting in the Additional Options section under Miscellaneous Options you can check "Disable smilies in text". This option is not available using Quick Reply unless you Go Advanced.
Point taken. ;)
In order to view advanced options to enable things like this goto User CP -> Edit Options -> Miscellaneous Options -> Message Options Interface (scroll all the way down) and select either "Standard Editor" or "Enhanced Interface". Remember to "Save Changes" at the bottom of the page.
Screenshot attached. ;)
Dang - that works. You learn something new every day.
I can't find the option you're using. I see the list on the bottom left corner of my window telling me what I may do or not and what's enabled or not, but when I click on the (enabled) Smiley item I only get an explanation of what a smiley is, I can't disable the graphics.
Can you help me?
Regs,
VGER
Can you help me?
Regs,
VGER
Check this screenshot, the option is disabled by default.
 I could use some help again...
 Lost Licences |
blocked because allowed