DNS server "attacks" (ie timeouts back in) / a rule to avoid blocks?

Discussion in 'other firewalls' started by pbw3, Oct 21, 2009.

Thread Status:
Not open for further replies.
  1. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    Stem,

    I am not sure I follow your process.. Are you saying that raw unsolicited UDP packets sent to a client machine (with Outpost) get reported by the Packet log, and the originating IP blocked (if it exceeds the criteria, for number of attacks in a certain time, to generate an intruder timeout block ), and obviously the same for some DNS replies to the client machine as I have seen above; but that if these are specifically unsolicited DNS requests (to the client machine), then these are reported by the Packet log as before (because no allow in firewall rule in place), but somehow the intruder timeout criteria is ignored just for these DNS requests.. I do not follow that at all, or have I misunderstood you..??
     
  2. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Yes
    Correct

    You have not misunderstood.

    It is a bug or a mix up in filtering (IMHO)


    - Stem
     
  3. Manny Carvalho

    Manny Carvalho Registered Member

    Joined:
    Jun 3, 2004
    Posts:
    270
    The Attack Detection plugin does look at traffic first. However, unless you tell me otherwise, it doesn't look like it considered this an attack since the host wasn't blocked. It looks like these may be late packets, exceeding the 600 msec time window, blocked by AD but there weren't enough of them to be considered an "attack" which would then block the host as well.

    It is surprising this happens with OpenDNS as I never see such things in my logs and I use them. It may be there's more latency in your system than mine. I'll presume this wasn't an attack as defined by Outpost since it looks like the host wasn't blocked and you posted nothing from the Attack Detection log. If the host was blocked then none of your DNS requests would have been resolved for the blocked time period which would make your browser appear to freeze up.

    Try enabling the flags column on the packet log. This might offer a clue of what these packets were doing.

    I can't offer any other explanation Stem but I'll ask the other Outpost forum moderators and Agnitum to take a look at this thread and see what they say.
     
    Last edited: Oct 23, 2009
  4. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    Manny,

    Correct, in this case it wasn't a DNS server block because at that time I must have had it set for more than "4 blocks for a timeout" - and you are right, that would show in the Attack Detection summary log rather than the detailed Packet log here.

    Although all of the items (that we can see here) are recorded in the Packet log as "Blocked by the Attack Detecton component" (OP actually mis-spells it!).. The question raised earlier was: Should these late replies be reported in the Packet log, alongside potentially more genuine entries, with that same description.

    Bear in mind also that in this particular example there were 4 attacks simply for one DNS request. If there are several requests together (quite possible when surfing), then, depending on how many attacks I have it set for a block etc, will depend on whether I get an alert / server block.

    My interpretation of the 600ms would be that it relates to the intruder block criteria, ie if 6 attacks occur in less than 600ms (using your default, for example), Attack Detection will implement an intruder block.

    Yes, I was surprised too and I think you may be right about this being latency on this internet connection.

    Yes, and that got frustrating (!), which I why I implemented the rule back at post 1 and have now changed to trusting the DNS servers, and in any case changing the stringency of the Attack Criteria. I am now using 7 attacks over a period of 1000ms, from 2 / 3 and 600ms at an earlier stage.. ie stricter on the greater time period to collect them, but more lenient with the number.. yes, could be 6 over 600ms as per one of the options, but whatever...:)

    The flags are enabled, and I see these for the TCP attacks / timeouts, but these are simply UDP packets. I removed the blank tab on the post above so that there was not a space between bytes and "allow / block reason"..

    OK, that would be really great if someone can explain some of these issues.. I can easily "manage this" (as mentioned above, and as I am sure many others have done before), but as much as anything, I am simply really interested to understand better what is happening in this context..

    Many thanks..
    Peter


    PS... This made me laugh..!! Wilders got timed out just as I was about to post this..:)

    I won't show you the 50 or more "fin ack", "rst ack" etc "attacks" currently sitting in the Packet log, but here is the AD log:
    18:01:39 65.175.38.194 Host blocked for 1 min SCAN (48331, 47819, 48075, 49099, 48587, 48843, 47307, 46283)
    18:02:39 65.175.38.194 Intruder unblocked
     
  5. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Well, I already know some explanations that could be put forward, but will await.

    I will put forward that Outpost "Attack plugin" is outdated and requires some "love" from the Vendor. One simple example is the Attack protection of "RFPARALYZE Attack". Now as that was a vulnerability in win 95/98, which I believe was patched, also how many users are still using win 95/98, but more to the point, Outpost no longer installs on those OS. There are other just as outdated.
    Another point can be the "RST Attack", if this is filtering RST/ACK, then is there a pre-check to see if the packet is part of a current connection, or is it simply dropped by the Attack plugin.?


    - Stem
     
  6. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    Stem / Manny,

    Just a quick follow up from earlier, I tried putting the logging into Level 2 debug mode, which clarified a few things for me.

    1) The style of reporting in the Packet Log is now very different. Instead of just "attacks", it is now a more complete packet log, and does seem clearer as to what is taking place.

    2) My question above re multiple requests for DNS:
    would seem right.. ie this is a very typical profile for DNS requests, taken directly from my packet log, with varying numbers of requests outs / replies ins.

    Out - Allow
    Out - Allow (ie re-sent due to lack of response)
    Out - Allow
    In - Allow
    In - Allow or Block
    In - Block

    These constitute about 5% to 10% of my DNS requests, the other ~90% are mainly simple 1 for 1 replies.

    Hence, it seems to me, and clearly my knowledge is non existent compared to you guys, that the extra packets coming back need to be stopped (ie not allowed through to the port), but not presented in the same way as unsolicited attacks as regards Attack Detection scan counters etc.

    This should not be difficult as the firewall knows exactly how many requests it has just allowed out from that port. All it has to do is allow reasonable time to mop up any very late matched replies (up to and including the number of requests that it allowed out).
     
  7. Escalader

    Escalader Registered Member

    Joined:
    Dec 12, 2005
    Posts:
    3,710
    Location:
    Land of the Mooses
    Well you could be right! The vendor should answer your questions.

    What bothers me as a semi trained FW guy is WHY do you/ me and other users have to work on vendor issues whatever they may be? If it's a design issue of how to determine what an attack is "real" or just a packet timing issue, we should not have to work on this period!

    There must/should be an independent testing lab that sets design standards for two way FW's. I know there is a list of them in the stickies here in this forum.

    Once the design standards for attack and SPI, rule adherence etc etc then the lab ( no advertiser support thanks) should conduct tests to see IF the design standards have been met in the coding vendors write to meet standards.

    What 3rd party products can we list that have been properly tested in the labs?

    To me it's the same idea as cars being safety/crash tested by the government agencies.

    I'm dreaming. :'( End of personal rant.

    PS for now I've removed ALL third party FW's from my setup and will rely on my other layers to protect me from g..d knows what! Yes the windows FW is on.

    AlphaShield in front of my router for ALL pc's sharing protection
    Firefox no script
    Nod33 V4 all 4 protectors maxed out, particularly the real time file with heuristics maxed out
    KeyScambler Premium
    RoboForm for psw management
    Host File filled with blocklists

    Occasional scan by SuperAntiSpyware Pro

    This is a sea change for me , will return to FW's when Windows 7 gets to SP1:D
     
  8. Manny Carvalho

    Manny Carvalho Registered Member

    Joined:
    Jun 3, 2004
    Posts:
    270
    My interpretation of this thread all along had been that what we are observing is the nature of the UDP protocol. UDP is a simple stateless means of data transmission that offers no error checking. The protocol would rather drop packets and avoid the overhead that goes along with error checking.

    Unfortunately the lack of documentation for OP's event viewer can lead to some interesting interpretations. It's true that the logging is different when its changed to level 2 [or other levels] debug mode. Exactly how I'm not sure as I never bothered wasting my time to discover. I expect Agnitum to document that and thus far I haven't seen it. I'm sorry I didn't mention this earlier since it might have cleared up matters a little quicker. I got diverted.

    I do think that you figured out your issues with the packet log in that its just how the UDP protocol works and that log is confusing. Let's see what Stem's take is on this.
     
  9. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Yes I understand the various problems with UDP. But we are looking at how Outpost is handling this. not the protocol itself.

    First of all, outpost as been around for quite some time, I myself was using it a few years ago (version 3/4 I think) on one of my PCs, but I would of thought by now it would of improved on its packet filtering.

    For UDP DNS lookups, of course, packet are lost etc, replies may never be returned or even 3 replies to 3 previous request(as example) may be returned.
    It should not be difficult for a Vendor who can spend so much time on leak test prevention to set in place a stateful table (or as some call it for UDP, a "pseudo-stateful mechanism") where info for the DNS packet sent (IP/Port/Ident) is stored for a timeout period (as mentioned, for 60 seconds), then if a late reply is made to a closed port within the timeout period, the packet can be checked, and if it matches the kept info, then it can simply be dropped as a late reply and logged as such.
    For a firewall to block the DNS server because it sends late replies is defeating the main purpose of the firewall, which is supposed to help prevent such Internet loss.


    - Stem
     
  10. Manny Carvalho

    Manny Carvalho Registered Member

    Joined:
    Jun 3, 2004
    Posts:
    270
    Fair enough Stem but none of this results in internet loss. None was reported here. There is a pseudo connection mechanism going on but anything beyond that gets dropped. We can certainly disagree/complain on the timeout period and how its logged but the packet handling seems right to me.
     
  11. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Did I misinterpret the first post?;-
    I will disagree, as if there is a timeout, then I believe it is only set on the port not the packet. I will find some time to verify.


    - Stem
     
  12. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    657
    Location:
    HKEY/SECURITY/ (value not set)
    I am not experiencing the problem projected in this Thread regarding DNS Timeouts due to Dropped or Blocked DNS Packets.

    All DNS requests from svchost.exe point to the Routers IP Address 192.168.0.1 and the Router performs the DNS Lookup, the Primary and Secondary IP Addresses of the Internet Service Provider are
    stored in the Router as the Router is configured to Automatically Obtain an IP Address. Nowhere in Outpost Firewall Pro are there entries of DNS pointing directly to the Internet Service Providers DNS Servers.

    svchost.exe exists the following DNS Rules with Stateful Inspection Activated:

    (001) to (004) other allow rules

    (005)
    Allow Outbound UDP to Local DNS for SVCHOST.EXE
    Where the Protocol is: UDP
    and Where the direction is: Outbound
    and Where the remote address is: GATEWAYS, DNS_SERVERS (192.168.0.1, 192.168.0.1)
    and the remote port is: DNS (53)
    Allow
    and Report this activity
    and Activate stateful inspection

    (006)
    Block Other Outbound UDP to DNS for SVCHOST.EXE
    Where the protocol is: UDP
    and Where the direction is: Outbound
    and Where the remote port is: DNS (53)
    Block
    and Report this activity

    (007)
    Allow Outbound TCP to Local DOMAIN for SVCHOST.EXE
    Where the protocol is: TCP
    and Where the direction is: Outbound
    and Where the remote address is: GATEWAYS, DNS_SERVERS (192.168.0.1, 192.168.0.1)
    and Where the remote port is: DOMAIN (53)
    Allow
    and Report this activity
    and Activate stateful inspection

    (008 )
    Block Other Outbound TCP to DOMAIN for SVCHOST.EXE
    Where the protocol is: TCP
    and Where the direction is: Outbound
    and Where the remote port is: DOMAIN (53)
    Block
    and Report this activity

    (009) to (016) other allow/block rules

    (017)
    Block Other Inbound TCP for SVCHOST.EXE
    Where the protocol is: TCP
    and Where the direction is: Inbound
    Block
    and Report this activity

    (018 )
    Block Other Outbound TCP for SVCHOST.EXE
    Where the protocol is: TCP
    and Where the direction is: Outbound
    Block
    and Report this activity

    (019)
    Block Other UDP for SVCHOST.EXE
    Where the protocol is: UDP
    Block
    and Report this activity


    I also respectfully disagree with the practice of not explicitly defining direction for UDP in Firewall Rules, UDP is an 'connectionless' Protocol but does exist 'Direction'.
    Agnitum Firewall Pro by default defines direction for UDP when creating Firewall Rules Automatically and Logs and/or Alerts accordingly without any "confusion" or "issues".

    OPF_DNS02.JPG


    HKEY1952
     
  13. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    I personally have not seen DNS replies blocked, but that does not actually help those with the problem,
    You appear to contradict yourself.
    You say you use Stateful inspection, but then state to use only Direction/outbound in the rule. By the implementation made by Agnitum, when the outbound is successful, then all communications are allowed to/from that IP.

    From Paranoid2000 (in 2003) description.

    Quotes from Paranoid2000 at Outpost forum

    I think from the fact that description, which is over 6 years old (and stated as current by Manny), indicates lack of development in the stateful process of packets within Outpost.



    - Stem
     
  14. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    @ Escalader

    I understand..:)

    I know this is slightly OT, but actually, despite having to go through this process to quieten it down, I really do like the product .. Yes, I can think of functional improvements (separate from the "bugs" / issues raised above) like with any product, but the logging is great and the rule setting is quite intuitive for me personally.

    The other thing is that as a result I am learning lots (it's all relative of course!), and which I regard as a big plus, and ditto from reading here, including your optimisation thread..

    I was happily using the Windows firewall, and which worked absolutely fine and was effortless, but there is the element that wants to monitor / understand better, at then at some stage I'll leave it alone.. and learning and exercising control with a product like this is much easier than say trying to do that with the Windows firewall (starting from my more limited knowledge base)..
     
  15. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    No misunderstanding.. yes, it used to result in temporary internet loss. Thanks to your input here, I have now tried relaxing the intruder block timeout rules (rather than keep my earlier 49K to 65K rule), and will continue to keep an eye on the packet log to get that balance right.

    Slightly different, and seems consistent, but I had a very unusual burst of between 15 and 20 blocked "inbounds" from each server (all within 1 second) and this time there was no "time block" on either server (despite my setting being just 7 per 1000ms)..:) They were all attempted DNS replies, not "requests" as per your post above Stem, and I didn't have the DNS IP as trusted or any other general allow rule in place. Maybe it's learning.. :)

    What's interesting re your pseudo-connection comment is the time delay. A lot of those replies came after more than 30 seconds (after the DNS request - not sure why so long), and none of the replies got accepted (not even the first one for each request). With the others before (0-3 second delay), at least the first was always getting accepted even if the second and third etc got blocked. Is the port closing, or maybe the firewall is using some pseudo-state for just the first reply up to say 30 seconds..

    If Agnitum come back to you at all Manny with some good info later, obviously I would be very interested to learn more?
     
    Last edited: Oct 26, 2009
  16. Escalader

    Escalader Registered Member

    Joined:
    Dec 12, 2005
    Posts:
    3,710
    Location:
    Land of the Mooses
    Well if I can be allowed to reply as you say a bit OT but IMHO I owe the forum some sort of explanation as to WHY I have removed ( for now) all 3rd party FW's. If this is the wrong place to post this then maybe the moderator will move this post elsewhere.

    I am very glad you are and have learned technical things about how to use these products. I went down that same path on more FW's than I care to list and do not regret the learning. BUT my removal action is not due to difficulty in learning how to drive the products any more. I know you didn't say that I'm saying that for me!

    Taking the car analogy a bit further, say I have an easy to drive comfy ride etc etc. But if the car is prone to crashing and killing me due to flawed brakes or air bags you pick it I don't want to be in that car period.

    For now and again this is me only, I've lost confidence in all these vendors to fix the fundamentals like SPI, accurate logs, full respect of user rules even my stupid ones! I don't know if it is due to the pursuit of ratings or not it could be, they are of course in business to make money, if they don't pursue that they are gone!

    I meant what I said about real independent laboratory testing. Which of all these products has been subjected to that level of testing?

    All I hear on that is a deafening silence.
     
  17. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    Thinking of the thread above, I guess one needs to be clear as to what extent some issues might be the equivalent of dodgy brakes (or worse), compared say to just some rust on the rear bumper that is overdue some attention..

    I agree, and I suspect quite a few people would find that interesting - and as firewalls, not as HIPS or leak test contestants.. and I also suspect there are some around here who could probably already correctly predict the outcomes..

    But even with that info if it existed, the best advice I have seen on here from a quite a few of you, is along the lines of "choose a firewall that you feel comfortable with and can understand, and is consistent with your ability to configure it", on the basis is that, however competent it is, a firewall is only as good as it is managed and used, and it obviously helps if you like and feel confident and comfortable with what you are using.

    Quite right..!! :)
     
  18. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    657
    Location:
    HKEY/SECURITY/ (value not set)
    EXACTLY.....when Stateful Inspection is enabled, all communications FROM the remote IP are allowed, however, the RESPONSES FROM the remote IP, ARE NOT INBOUND CONNECTIONS, they are only RESPONSES to the
    already established CONTROLLED OUTBOUND CONNECTION. That is what Stateful Inspection is for. Stateful Inspection serves two purposes
    :

    01) - Stateful Inspection is an process that tracks CURRENTLY ALLOWED CONNECTIONS.
    When an newly received packet MATCHES an existing allowed connection, the packet DOES NOT go through the rule inspection process. The packet is allowed automatically.
    This way, the firewall can handle most network traffic safely without an complex configuration of firewall rules.

    02) - Stateful Inspection enables the simplification of the rule base. For traffic that is INITIATED IN ONE DIRECTION ONLY, you DO NOT have to create rules that permit traffic in both directions.
    With Stateful Inspection, every time an packet is SENT OUT of the computer, the firewall keeps track of it. When an packet COMES BACK to the firewall, the firewall can tell whether or not the "in-bound packet"
    is a REPLY or RESPONSE to the packet that was SENT OUT. Stateful Inspection SHOULD NOT be enabled however, if the Firewall Rule exists an CONTROLLED INBOUND RULE.


    Highlight in Quote by HKEY1952


    Before one can understand all of this however, first one must understand the difference between OUTBOUND CONNECTIONS and INBOUND CONNECTIONS:

    01) - OUTBOUND CONNECTIONS = An Outbound Connection is what your computer MAKES to connect to an remote computer or remote server or ANYTHING OUTSIDE.
    Any packets SENT BACK to your computer FROM the remote computer or remote server or anything outside ARE ONLY RESPONSES to your computers requests and ARE NOT INBOUND CONNECTIONS.
    The responses from the remote computer or remote server or anything outside are only "in-bound responses" to an already established OUTBOUND CONNECTION.

    So.....when an Firewall Rule with Stateful Inspection enabled, that allows ONLY OUTBOUND CONNECTIONS, receives the "in-bound response packet" from the remote computer or remote server or anything outside,
    Stateful Inspection REMEMBERS the OUTBOUND CONNECTION and the OUTBOUND CONNECTIONS DESTINATION and upon receiving the "in-bound response packet" from that SAME DESTINATION through the SAME OUTBOUND CONNECTION,
    Stateful Inspection:
    ALLOWS the "in-bound response packet" because the newly received packet MATCHES THE EXISTING ALLOWED OUTBOUND CONNECTION.

    02) - INBOUND CONNECTIONS = An Inbound Connection is what your computer GETS when an remote computer or remote server or anything outside REQUESTS ACCESS to your computer from the OUTSIDE.
    Any packets SENT BACK to the remote computer or remote server or anything outside ARE ONLY RESPONSES to the requests of the remote computer or remote server or anything outside and ARE NOT OUTBOUND CONNECTIONS.
    The responses from your computer are only "out-bound responses" to an already established INBOUND CONNECTION.

    So.....when an Firewall Rule with or without Stateful Inspection enabled, that allows ONLY OUTBOUND CONNECTIONS, receives an packet from an remote computer or remote server or anything outside, requesting access to your computer,
    the Firewall Rule will drop the packet and reject the connection and WILL NOT respond with an "out-bound response packet" to the already SEVERED INBOUND CONNECTION ATTEMPT.


    There is no contradiction here on my part and I will not defend or argue my point any further because I know that I am right.


    Resources:
    What is Stateful Packet Inspection?:
    http://support.kerio.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=51

    Symantec Endpoint Protection 11.0 Network Threat Protection (Firewall) Overview and Best Practices White Paper (Stateful Inspection further down the page):
    http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007121714495348

    What is inbound and outbound connection mean?:
    http://answers.yahoo.com/question/index?qid=20080918164940AAbl2Qc

    What is an inbound connection (detected by firewall)?:
    http://answers.yahoo.com/question/index?qid=20081002054847AAsKvgN

    Stateful Inspection by Paraniod2000:
    http://www.outpostfirewall.com/forum/showthread.php?t=7443


    HKEY1952


    EDIT: For clarity
     
    Last edited: Oct 26, 2009
  19. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK

    Unfortunately you are stating/showing links to other SPI implementations.

    Outpost SPI works as does stateful FTP. It allow connections in BOTH directions, it allows ALL traffic between the host and the remote IP once the initial connection is established (or in UDP, from the first packet)

    One of the main problems/ confusions is that each Vendor can have its own version of what is now a very broad term.


    - Stem
     
  20. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    @HKEY 1952..

    Is SPI as described in the post by Paranoid, or as recommended to be applied, different (and possibly additional) to that described by other vendors, such as Kerio..?? For example, Outpost does not seem to recommend that rules need to use its documented SPI. Most of its presets do not have SPI on by default. I don't use SPI for any of my outbound rules, and I have no inbound allow rules.

    And yet, clearly there is still an application state process taking place in Outpost, as when outbound requests are made, the inbound responses are allowed, including for UDP that otherwise has no connection state of its own: my own DNS rules are outbound only (actually they work fine whether the rule is outbound or directionless), and they allow the responses back in (subject to the discussion above!)..

    Out of curiosity, have you tried switching SPI off at all and seeing if it changed anything? And if so, would that test determine whether some other form of state process might be taking place?

    Apols if more questions than answers..:)
     
  21. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Your Welcome.

    You should not worry too much about scans. The scans I see these days are mainly looking for various server ports and they are not made (well from what I see in my logs) quick enough to set off a scan alert as set in various firewalls.

    As you say, just keep an eye on the log and see what is happening with your DNS server.


    - Stem
     
  22. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Well, I have been trying for a few years trying to get vendors to implement better packet filtering (and try to get users of firewalls aware). The problem is that packet filtering is not what a lot of users fully understand, and most probably dont want or need to (why should they).

    I think its getting time to call it a day.


    - Stem
     
  23. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    657
    Location:
    HKEY/SECURITY/ (value not set)
    Disabling Stateful Packet Inspection DOES NOT change anything as far as the OUTBOUND CONNECTION is concerned, the "in-bound response packet" from the remote source will ALWAYS pass through unless there exists an
    Controlled Firewall Rule to Block such transfer of packets from that particular remote source.....but then why would one block it, they are requesting it through the Firewall Rule.

    Whenever an Outbound Connection is established, that Outbound Connection is going to receive an "in-bound response packet" from the remote source.
    Remember, that "in-bound response packet" from the remote source IS NOT AN INBOUND CONNECTION.....and is going to happen with or without Stateful Packet Inspection Enabled.....so.....

    Think of Stateful Packet Inspection, when enabled for that particular OUTBOUND Firewall Rule, as sort of an 'Gateway' for that Firewall Rules OUTBOUND CONNECTION, Stateful Packet Inspection will:
    INSURE THAT THE "IN-BOUND RESPONSE PACKET" FROM THE REMOTE SOURCE IS DESTINED TO THE INTENDED OUTBOUND CONNECTION THAT MADE THE REQUEST, IF NOT, THE "IN-BOUND RESPONCE PACKET" WILL BE DROPPED.....and.....

    If Stateful Packet Inspection WAS NOT Enabled for that particular Firewall Rules OUTBOUND CONNECTION, then, yes, other state processes would hopefully catch the intruder, such as System-Wide Rules, ICMP Settings,
    Attack Detection, IP Blocklist, Antivirus/Antispyware, Host Protection, and Web Control.


    HKEY1952


    EDIT: For clarity
     
    Last edited: Oct 26, 2009
  24. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    The SPI setting in Outpost firewall rules is an addition to a basic static rule system.

    Let me try to explain,

    When you set rules in Outpost(for example) to allow outbound to remote port 80(HTTP) for your browser then that is a static rule, when you then connect out (for example) to this forum the rule is checked and the connection allowed, from then on the comms between the host(you) and the forum for that connection are allowed for that IP/Port (going to a website or this forum may have 3 4 or more connections to actually open the page and exchange all the data you see on the screen). Static rules are basic in that they usually only check IP/Port.

    Now, when you enable the SPI option in an Outpost firewall rule, that then enables what is referred to as "Dynamic rules", the current implementation in Outpost for this Dynamic rule system is similar (if not the same) as stateful FTP. What it does is to allow all outbound and all inbound connections once the rule is matched. This is useful for FTP data transfers as the extra rules for port use are only temporary and in use only while the initial connection is active.

    Now in some other stateful packet filters, such as WIPFW, that uses (SPI) dynamic rules but they are used (on such as an HTTP connection) to determine the next packet within a current connection, it will determine what the next packet should be, and only allow the packet based on the dynamic rule (not the static rule) for that specific connection.(this checks more than just the IP/Port).

    The statement made by Paraniod200 concerning inbound connections:
    This info is only for the current SPI implementation within Outpost firewall (the SPI option within the rule you can enable)l. This is because of the way it works, as when the inbound connection is established then outpost would allow other connection attempts and respond.(Outpost would consider the initial connection as some form of FTP initial connection and create dynamic rules) which could result in replies to scans etc.


    - Stem
    (retired)
     
  25. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    657
    Location:
    HKEY/SECURITY/ (value not set)
    As an final note.....

    There is big misunderstanding here about Agnitums Stateful Packet Inspection.

    A) - This statement is wrong:

    quote=Stem/
    Now, when you enable the SPI option in an Outpost firewall rule, that then enables what is referred to as "Dynamic rules", the current implementation in Outpost for this Dynamic rule system is similar (if not the same) as stateful FTP. What it does is to allow all outbound and all inbound connections once the rule is matched. This is useful for FTP data transfers as the extra rules for port use are only temporary and in use only while the initial connection is active.
    \end quote=Stem


    Agnitum Stateful Packet Inspection, when enabled on an outbound connection, DOES NOT "allow all outbound and all inbound connections once the rule is matched."

    There are no "Dynamic rules" involving Agnitum Stateful Packet Filtering, however there exists 'dynamic packet filtering'.
    Filtering decisions are based not only on user-defined rules (as in static packet filtering) but also on the context established by prior packets that were passed through the firewall
    .

    What Agnitum Stateful Packet Inspection actually does is this:

    01) - Agnitum Stateful Packet Inspection, when enabled on an outbound TCP connection:
    When the outbound rule is triggered, and the connection is established in accordance to the controlled outbound rule, then ALL CONSEQUENT, NOT SUBSEQUENT, ALL CONSEQUENT TCP TRAFFIC, NOT ALL TCP CONNECTIONS,
    ALL CONSEQUENT TCP TRAFFIC between the given hosts, irrespective of ports and direction, will either be ALLOWED or BLOCKED ACCORDING TO THE SPECIFIED CONTROLLED RULE SET.

    02) - Agnitum Stateful Packet Inspection, when enabled on an outbound UDP connection:
    When the outbound rule is triggered, and the packet has been sent in accordance to the controlled outbound rule, an 'pseudo connection' is established, in other words, an virtual or temporary simulated connection is established.
    Then ALL CONSEQUENT, NOT SUBSEQUENT, ALL CONSEQUENT UDP TRAFFIC between the GIVEN OPENED PORTS ON THE HOSTS will either be ALLOWED or BLOCKED IN BOTH DIRECTIONS ACCORDING TO THE SPECIFIED CONTROLLED RULE SET.

    03) - Agnitum Stateful Packet Inspection, when enabled on an outbound FTP connection:
    FTP always requires an return connection, which can be automatically allowed by specifying stateful inspection in its rule.


    B) - This statements terminology is wrong:

    quote=Paranoid2000 at Outpost Forum/
    When a rule including the "Activate Stateful Inspection" option is matched, Outpost will allow all subsequent incoming and outgoing connections for that application which:

    * Go to or come from the same remote host involved in the rule-matching connection;
    * Occur while this connection is open (if it used TCP);
    * Occur within 100 seconds of the last packet sent for this connection (if it used UDP).
    \end quote=Paranoid2000 at Outpost Forum


    There is wrong terminology being used here that is causing confusion, the statement is correct otherwise:

    01) - The definition of subsequent = Occurring or coming later or after, following in order or succession.
    (in other words, just one after the other, no restrictions)

    02) - The definition of consequent (used by Agnitum in describing Stateful Packet Inspection) = Following as an logical conclusion, following or progressing logically.
    (in other words, one after the other in logical order, such as allow or block)

    Highlights in quotes by HKEY1952



    References:
    What is 'stateful inspection'? by Agnitum:
    http://www.agnitum.com/support/kb/article.php?id=1000176&lang=en

    Stateful Inspection, invented by Check Point Software Technologies:
    http://www.checkpoint.com/products/downloads/Stateful_Inspection.pdf


    HKEY1952


    EDIT: For clarity
     
    Last edited: Oct 27, 2009
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.