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
    I was regularly receiving blocked packets on port 53 from my DNS servers. Looking at the detailed text log events, these looked like timeouts from packets (DNS requests) already sent out. ie I am assuming that the UDP connection lost its "pseudo state" (within Outpost) due to the DNS server taking too long to return a particular packet to the internal port that sent it? It's a very small percentage of all outbound DNS requests, but enough to occasionally have the servers blocked under my (fairly tight) Attack Detection block rules..

    My rule for DNS requests is the usual "UDP outbound to DNS servers on port 53"; the "state" process means no inbound rule is needed. This rule is in SVCHOST only: with Vista SP1 and Outpost, I do not need a global DNS rule, nor do I need DNS rules for each app - SVCHOST seems to insist on handling all DNS requests, whatever other DNS rules are, or are not, in place..

    I then found that if I tried adding a rule to also allow UDP inbound, specifically from DNS servers / port 53, to local ports 49152 to 65535, the DNS inbound blocks stopped (this is a "low level" rule - in Outpost meaning at system level, eg includes traffic not controlled by applications, and is tested after the svchost app rule above).

    Instead I now get "outbound" blocks on ICMP, of type 3/3 in the blocked Packet log (I have "destination unreachable" outbound set up as blocked on ICMP rules). Reading a little, this might suggest that my 49K to 65K rule above is effectively letting the UDP packets back in, but because they are no longer "live" (or in "state") as far as Outpost is concerned, and the port they were sent from by SVCHOST is no longer expecting anything, the packets are dropped, which then triggers the ICMP error alert that I am seeing in the Packet log.

    The advantage to me - is that now the DNS servers do not get temporarily blocked by too many false inbound alerts. A possible issue is that my new rule is potentially allowing unsolicited inbound traffic, albeit from a very specific protocol / IP / port combination?

    Am I well off the mark here, or does this make sense..??

    Peter

    PS.. One or two other minor points..
    If I add the 49K to 65K rule to SVCHOST, it has no effect, as one would expect, as "state relating to the app etc" within Outpost has been lost. If I add the rule to "global rules" (which in Outpost means applied to any applications), again it has no effect because there is no application expecting the packet.

    A different option I tried was "trusting" the DNS servers (which obviously works and instead generates "packets dropped due to closed port" in the log), but fully trusting the IP address is less restrictive than the specific rule above. I'm not sure why one causes a dropped packet alert, whereas the other triggers an attempted ICMP response?..
     
  2. wat0114

    wat0114 Guest

    I'm not sure I understand fully what you have, but try removing the direction from your DNS rule so that you only have:

    UDP, Port 53, possibly your DNS server(s) ip addresses. Specifying direction(s) for DNS rules seems to cause issues.
     
  3. Stem

    Stem Firewall Expert

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

    More than likely, yes.
    It is the DNS service (svchost) that will make all DNS lookups while it is active. If you did want to make all applications perform their own DNS lookups, you would need to disable the DNS client is the windows services.
    Yes. The packets are being processed differently due to the rule to first allow them. Because they are allowed, but then found to be going to a closed port, ICMP is being sent back by the system but then being blocked by the firewall.

    IMHO, it is better to have the packets dropped at the perimeter (not being allowed in). If OP is blocking the DNS servers due too many late replies (that are being seen as an attack), then disable the "Block attacker for 5 min"(I think that is the wording). Any late replies will still then be dropped (as will any attack), but the IP of the attacker (in this case your DNS servers) will not then be blocked.

    - Stem
     
  4. s23

    s23 Registered Member

    Joined:
    Feb 22, 2009
    Posts:
    263
    Hi

    I have the same problem with outpost. Even with my ISP DNS or with Open DNS. My doubt is: You recommend disable the "Block Intruder IP for 5 minutes" or add the DNS (through DNS IPs or the Macro presented by Outpost) to the attack detection exclusions?
     

    Attached Files:

  5. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    That's an interesting one.. I have actually found in practice that it does it with either option, ie removing the direction of UDP or simply using outbound, but will experiment some more with this to see if there is any significant difference day to day..

    Stem,
    Thanks for confirming my basic understanding...

    OK, I understand, I hadn't picked up on that..

    Yes that is the wording, and I have toyed a little with this, and with the number of attacks that triggers a block, and yes I can reduce the effect substantially this way.. I have typically had it set quite tightly, and my instinct is to leave it on - rather than switch it off - if nothing else so that it can provide an alert occasionally for anything real; but I guess I can achieve that simply by reducing the time period (of the block) down to 1 minute say, and increasing the number of "attacks" before which it is triggered, which will then have less impact wrt DNS.

    I am guessing that what you are saying is that the Attack Detection module blocks all such attacks anyway, whether it is one by one or due to an IP time out, and hence reducing the effect of "block intruder" does not materially impact on that; and hence this approach is less risk than letting the packets in (even from a very specific IP / port source to a likely closed port), and even if we are probably talking about relatively minor levels of comparable risk..

    If choosing the allowed packets in route, would the restricted rule above be slightly less risk than trusting the DNS servers completely, or is there another factor in play there?
     
  6. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    IMHO, there should actually be no need to do either. We are looking at simple late replies from an outbound request that should be handled statefully.
    For such as UDP DNS lookups, an entry should be made for the outbound, rather than the filter process relying on if an application is still waiting on port or not, it should be a timeout from when the packet was sent. So for example, a DNS packet is sent, a state entry for that is then made with a timeout,of lets say 60 seconds, which should be plenty of time for a late reply. The application awaiting the reply, if the reply is late, will move on, and that port seen as closed, but if a late reply arrives within the timeout, then checking should be made to see if there is an entry for the outbound still active (based on IP/port/identity), if there is such an entry, then the packet dropped due to late reply(and logged as such), if there is no entry, then the packet should be dropped and added to a counter for that IP for possible scanning/flood, an alert/blocking would then take place when the packet count was to the packet count settings for scanning/flood.


    The packet filtering in OP (IMHO) really needs a serious update.


    - Stem
     
  7. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    I have been meaning for quite a while to perform packet filtering tests on OP pro to verify how the packets are being filtered, however. I suspect that all packets are being pushed through the "Attack plugin", so if an IP is actually attacking, then rather than filter all the packets through the plugin, the attacker is blocked at an higher level (blocked IP) and the packets are then not further processed (which can then result in better performance if any scanning is taking place).


    - Stem
     
  8. Manny Carvalho

    Manny Carvalho Registered Member

    Joined:
    Jun 3, 2004
    Posts:
    270
    I haven't read this whole thread but you're right Stem, Attack Detection is high on the list of filtering traffic. Below is the priority Agnitum lists but they don't have the new IP Blocklist listed which I believe should be first.

    Outpost Traffic Filtering Sequence:

    • 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

    http://www.agnitum.com/support/kb/article.php?id=1000120&lang=en
     
  9. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Thanks for the info. That combined with the info concerning the "Attack plugin" would lead me to believe there is very little (if anything) in the way of stateful filtering.


    - Stem
     
  10. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    This may be a bit detailed (and not detailed enough to be actually useful), but I did a quick exercise looking at my Firewall log and Packet log, and and I think I understand what you are saying here..

    I had thought that the DNS timeouts were significantly delayed from the original request, ie I assumed they were occurring because they were going beyond the normal 30 or 60 second UDP timeout limit.

    However, now I look more closely at the detail, most of these timeouts are occurring within a few seconds of the original DNS request. This is a typical example:

    netstat4.log [Firewall log]
    2009/10/21 19:53:00 new packet connection: UDP/10.214.36.144:64033 -> xxx.xxx.192.126:53 <SVCHOST.EXE:1672> [00004CC5/00004CCD] 00000450
    2009/10/21 19:53:00 stat: [00004CC5/00004CCD] -> 73, 0
    2009/10/21 19:53:01 new packet connection: UDP/10.214.36.144:64033 -> xxx.xxx.201.126:53 <SVCHOST.EXE:1672> [00004CC5/00004CCE] 00000450
    2009/10/21 19:53:01 stat: [00004CC5/00004CCD] -> 73, 0
    2009/10/21 19:53:01 stat: [00004CC5/00004CCE] -> 73, 0
    2009/10/21 19:53:03 stat: [00004CC5/00004CCE] -> 146, 0
    2009/10/21 19:53:05 stat: [00004CC5/00004CCD] -> 146, 300
    2009/10/21 19:53:05 stat: [00004CC5/00004CCE] -> 219, 450

    mac.log [Packet log]
    2009/10/21 19:53:04 recv UDP xxx.xxx.201.126:53 -> 10.214.36.144:64033 (150) block by FFFFFFD0 IDS:allow single portscan
    2009/10/21 19:53:04 recv UDP xxx.xxx.201.126:53 -> 10.214.36.144:64033 (150) block by FFFFFFD0 IDS:allow single portscan
    2009/10/21 19:53:05 recv UDP xxx.xxx.192.126:53 -> 10.214.36.144:64033 (150) block by FFFFFFD0 IDS:allow single portscan
    2009/10/21 19:53:05 recv UDP xxx.xxx.201.126:53 -> 10.214.36.144:64033 (150) block by FFFFFFD0 IDS:allow single portscan

    and another:

    netstat4.log
    2009/10/21 19:53:02 new packet connection: UDP/10.214.36.144:64552 -> xxx.xxx.201.126:53 <SVCHOST.EXE:1672> [00004CCF/00004CD6] 00000450
    2009/10/21 19:53:03 stat: [00004CCF/00004CD6] -> 74, 0
    2009/10/21 19:53:04 stat: [00004CCF/00004CD6] -> 148, 0
    2009/10/21 19:53:04 new packet connection: UDP/10.214.36.144:64552 <- xxx.xxx.192.126:53 <SVCHOST.EXE:1672> [00004CCF/00004CD8] 00000450
    2009/10/21 19:53:05 stat: [00004CCF/00004CD6] -> 148, 274
    2009/10/21 19:53:05 stat: [00004CCF/00004CD8] -> 0, 137
    2009/10/21 19:53:06 stat: [00004CCF/00004CD8] -> 0, 137

    mac.log
    2009/10/21 19:53:04 recv UDP xxx.xxx.201.126:53 -> 10.214.36.144:64552 (137) block by FFFFFFD0 IDS:allow single portscan
    2009/10/21 19:53:05 recv UDP xxx.xxx.201.126:53 -> 10.214.36.144:64552 (137) block by FFFFFFD0 IDS:allow single portscan

    It is the Packet log (or mac.log) which contains the "attack" information.
    ?.?.201.126 and ?.?.192.126 are the two ISP DNS servers.. btw - I have exactly the same kind of examples if I use OpenDNS rather than the ISP..

    This does not change the issue of resolving the original DNS time block issue (ie "a rule allowing packets in" versus "lessen the attack detection criteria for a time block"), but does suggest that somehow there is a struggle here to deal with the admin of "matching off DNS packets, when they might get slightly delayed" versus "deciding that something should be reported"? This might be exasperated by the fact that I often use a mobile broadband connection, which (I don't know but I am guessing) may sometimes cause marginal additional delays.
     
  11. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    I think I may be getting my head around this separation of the Attack Plugin..

    If I exclude the DNS servers in Attack Detection (ie trust the DNS servers), and allow SVCHOST out to DNS (application rules), no problems accessing the internet.
    If I exclude the DNS servers in Attack Detection, but now untick SVCHOST from being able to access DNS, I am blocked (even though the DNS servers are trusted by Attack Detection).

    ie Excluding the DNS servers from being monitored in Attack Detection appears only to affect the Attack Detection module, and seems to have no effect on the other later firewall rules (application / global rules etc), which I had not appreciated. I had assumed that trusting an IP in Attack Detection (especially as it is first in the processing order) left that IP address free from being monitored by all subsequent firewall block rules.

    Hence, S23, if my understanding is correct, your solution would appear to be best, ie exclude the DNS servers from Attack Detection, on the basis that trusting an IP there seems to have no impact on the filtering that the firewall later performs.

    If anyone thinks my understanding is wrong, please tell me, and I will anyway experiment some more with this.

    [Edit: My thinking here is flawed: Excluding DNS servers or not in Attack Detection should clearly not impact on whether SVCHOST can access the DNS servers. SVCHOST needs an application rule (either a specific rule or a global application rule) to allow it internet access, irrespective of whether an IP is trusted or not.]
     
    Last edited: Oct 25, 2009
  12. Manny Carvalho

    Manny Carvalho Registered Member

    Joined:
    Jun 3, 2004
    Posts:
    270
    Stateful inspection can be turned on in the rules in order for connection state filtering to occur for "non-directional" protocols like UDP. SPI will then control traffic using this pseudo connection. It is safer than making a host trusted which would allow all inbound traffic for that host. However, SPI will hold the ports open for that host and allow all traffic in response to outgoing traffic. You solve one problem but create another.
    http://www.agnitum.com/support/kb/article.php?id=1000176&lang=en and the forum SPI FAQ although written awhile back when SPI came out in V2, it still holds.

    "Attacks" from DNS servers are generally due to slow responses to DNS queries. After a certain time, Outpost no longer considers an incoming DNS response to be a reply and calls it an attack because it just falls out of the time window. You can modify this time window in Attack Detection advanced settings but this makes AD less sensitive to real attacks. A better approach is to move to faster responding DNS servers such as OpenDNS and leave direction out of the rules for UDP protocol. The fundamental issue is the non-directional nature of the UDP protocol. If a timely response is recieved from the DNS server then it will be considered a proper response rather than an attack. Problem resolved.
     
    Last edited: Oct 22, 2009
  13. pbw3

    pbw3 Registered Member

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

    Just for info, I have now tried using SPI for the SVCHOST DNS rule but it does not work.. It doesn't cause problems at all, but Attack Detection still reports attacks, and in the same short time periods as before, ie these are not happening outside of the 100 seconds designated by Outpost's SPI..

    Using OpenDNS or removing the direction criteria makes no difference to me in respect of this..
     
  14. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    well that proves a serious need for an update to Outpost firewall packet filtering.
    I do actually remember that now, and all it is good for is FTP, as once the first connection is made that satisfy the rule, then every connection any direction is allowed (to that connection IP)

    A late DNS reply simply should not be seen as an attack, period.

    It is a pity Agnitum have not spent more time on improving packet filtering, yet another vendor more interested in climbing the "Leak test prevention" ladder.

    - Stem
     
    Last edited: Oct 22, 2009
  15. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    It wont work for that, as the application will still need to be listening on port for the packet.
    It looks like if there is any sort of state table for UDP, then the entry is lost when the application closes the port.
    I can check to see if a table/filtering is in place, I just need to find some spare time.


    - Stem
     
  16. Manny Carvalho

    Manny Carvalho Registered Member

    Joined:
    Jun 3, 2004
    Posts:
    270
    I'm surprised this is happening. Would you please post how you changed to OpenDNS and the Outpost logs for both the firewall and Attack Detection around the time when an attack is reported? Just a screenshot from the event viewer with the header showing.
     
    Last edited: Oct 22, 2009
  17. Manny Carvalho

    Manny Carvalho Registered Member

    Joined:
    Jun 3, 2004
    Posts:
    270
    We will have to disagree on this one then. It may be that Attack Detection is a bit sensitive but the difference between an attack and normal traffic can at times be different to figure out. Since a DNS reply has no handshake like TCP traffic there's just no way of knowing whether a late reply is legitimate or not. I'd rather it default to calling it an attack. I never actually see a problem on my systems like this at all with OpenDNS. Maybe something else is going on.

    I won't disagree about the Leak test prevention though.
     
  18. Escalader

    Escalader Registered Member

    Joined:
    Dec 12, 2005
    Posts:
    3,710
    Location:
    Land of the Mooses

    Hi Manny: I hope this question is not OT in this thead if it is I will repeat in in the OP testing and optimization thread.

    It's about how OP expects me the user to exploit the SPI on/off box in the construction of rules? I have never seen it as an option by application before ( at least I don't think I have). Should I just go through each rule I've got and if the box is there just tick it? My guess, ( always dangerous) is that OP would want them only on www facing applications? :doubt:

    What criteria(s) should the OP user have to make this decision?
     
  19. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    I have already put forward on thread how the firewall could check if the packet is a late DNS reply in a time period (+check IP/Port/Identity). A single late DNS reply is not an attack unless the packet is spoofed, but that is not checked, it is just a fact that a DNS reply going to a closed ports triggers Outpost to state= "Attack". It just looks a case of to me of the firewall trying to make it look like it is blocking attacks and worth the cost of the product.
    At most, a single DNS reply going to a closed port should be placed under the "Attack" definition as a single scan, then at least it can be disabled without having to disable all the Attack detection. (for those who do not know. The firewall does not have an actual named attack detection for this, it is just a case that these packets are detected going to a closed port)

    Tell Agnitum

    - Stem
     
  20. Manny Carvalho

    Manny Carvalho Registered Member

    Joined:
    Jun 3, 2004
    Posts:
    270
    Stateful Inspection is turned on for any application rule by ticking that option in box 2 of the edit rules option as shown in my attachment. It shouldn't be an option that is often used but may be handy for a few uses as explained in the FAQ I quoted above.
     

    Attached Files:

    • SI.gif
      SI.gif
      File size:
      18.1 KB
      Views:
      1,805
  21. Manny Carvalho

    Manny Carvalho Registered Member

    Joined:
    Jun 3, 2004
    Posts:
    270
    A single DNS reply won't be considered an attack. It takes at least 6 [the default value and changeable] connection requests before OP defines it as a port scanning attack. The single port scan is off normally.

    Actually OP has grown less chatty with the newer versions rather than plastering people with dialog. I don't think I've seen one for weeks now.
     

    Attached Files:

    • AD.gif
      AD.gif
      File size:
      34.7 KB
      Views:
      14
  22. pbw3

    pbw3 Registered Member

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

    Hope this helps.. Columns should be self evident - in the firewall log, the address / port is external, following by bytes out / in. In the Packet log, first address / port is source, second is target, with just one bytes column.

    Firewall log
    12/10 16:37.22 SVCHOST.EXE OUT UDP 208.67.222.222 53 138 170 Generic Host Process DNS UDP connection
    12/10 16:37.23 SVCHOST.EXE OUT UDP 208.67.220.220 53 138 255 Generic Host Process DNS UDP connection

    Packet log
    12/10 16:37.29 Block IN UDP 208.67.222.222 53 10.212.76.16 59861 85 Blocked by the Attack Detecton component
    12/10 16:37.29 Block IN UDP 208.67.220.220 53 10.212.76.16 59861 85 Blocked by the Attack Detecton component
    12/10 16:37.29 Block IN UDP 208.67.222.222 53 10.212.76.16 59861 85 Blocked by the Attack Detecton component
    12/10 16:37.29 Block IN UDP 208.67.220.220 53 10.212.76.16 59861 85 Blocked by the Attack Detecton component

    I don't have lots as I tried this just to see if the problem went away, which it didn't (I retrieved these from an Excel dump, log since cleared) - but I am sure I can always generate some "new" if that's useful..
     
  23. s23

    s23 Registered Member

    Joined:
    Feb 22, 2009
    Posts:
    263
    It's a shame that the "Firewall" vendors is more interested in improve leaktests results and satisfy tests like matousec than offer better products that do what a firewall need do...
     
  24. pbw3

    pbw3 Registered Member

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

    I am presuming that there must be some alternative form of state working here (other than simply SPI as you mention above), otherwise setting a rule up for DNS for outbound only would not work (?), which obviously it does..


    Is the issue here that the Attack Detection plug in module may be operating somewhat independently of the firewall?

    In the examples above in post 10, it looks as if the firewall (firewall log) seems to be accepting the packets back in late specifically against the original request (final two rows of netstat4 in the first example in post 10), suggesting a) some form of matching back in, and b) with a delay; but that the Attack Detection plug in (shown in the Packet log) may already be partially flagging them as single scan attacks..?? It's difficult to tell from the info and the precise times shown, but I can see other examples with similar time profiles..

    Alternatively, is the problem not to do with late responses but multiple responses? Ie packet sent, no response, packet re-sent from same port, and re-sent again.. Packet later received, port gets closed, another packet received (and another), both treated as scans by AD (because the port is closed?) etc.. Despite the obvious logic that if 3 packets got sent, anything up to 3 back in (with the right kind of info / password etc, and within a reasonable time period - 30 seconds or whatever, similar to a normal concept for SPI?) might be acceptable behaviour to AD.. Again, am I way off the mark here..!?


    I think my own solution here maybe to trust the DNS servers (in Attack Detection), and then also reduce the Attack Detection blocking criteria. For what it's worth and not sure it helps here, but I get the same thing sometimes from web sites that I regularly visit (with TCP), very occasionally on port 80 but more often wrt 443, ie the sites I am visiting sometimes give false alerts in the Packet Log. There does seem something slightly too chatty at times (with FP's) with the way that the AD plug in seems to work in practice, at least on my set up that is.

    Don't misunderstand me, despite raising this issue, much else about the look and feel of the functionality of this (firewall) I like - the rules settings etc are very intuitive, and the logging is excellent - I started this process looking for more network actvity info and control, rather than for HIPS / leaks etc. But obviously the AD impacts on the firewall "feel", so if not at all detrimental to the essential firewall filtering and control capabilities (and obviously please tell me if I am wrong??), the optimal solution may simply be to turn the AD noise down a little, but accept of course that the packet log will have lots of false scans / blocks..
     
  25. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Then Outpost is in error with its logging. A single DNS reply packet is logged as blocked by "Attack plugin"(well, words to that effect).

    My main point again: Late DNS replies from the DNS server, does not matter how many, should not then cause Outpost to block that DNS server. Now I know you have already stated, that
    but as I know, a check can be made, it is just Agnitum have not introduced it.

    I have found something:-
    sending a small flood(10 with no delay) of DNS replies to the host(with outpost) installed causes a block of the originating IP, the same as if I make a small flood of raw UDP. Now if I send a small flood of DNS request to the host, the packet are dropped and logged as before, but the originating IP is not blocked. So (IMHO) It looks like the Attack filtering in outpost is buggy, OR, it looks like they have mixed up the detection. IE:- If the host was an actual DNS server, then rules would be in place to allow that inbound and/or the host would be serving an home network, so it would be in a trusted zone which would bypass the attack plugin.

    So, if a flood (and here I mean 1000 with no delay) of DNS request can be made against outpost and the originating IP is not blocked, then why would a small flood of DNS replies then cause the DNS server to be blocked.

    Do you think this may be a mix up or a bug?


    - Stem
     
Loading...
Thread Status:
Not open for further replies.