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

Hello,

No one as mentioned adding better filtering for all UDP, we are looking at adding better filtering for DNS (but I (IMHO) would also like better filtering for DHCP). That should not add any noticeable overheads, if implemented correctly.

What could be seen as a current threat or not, Agnitum certainly have no problem having "Attack" protection against threats stated as being against such as win 3.1/ win95/98
Unfortunately quite a number of 3rd party firewalls that intend to replace even the inbuilt XP firewall (which filters out invalid flagged packets) actually do not filter to that level and allow invalid/illegal flagged packets (IMHO) they should be adding to the filtering not taking it away.

The IP spoofing protection is enabled by default (although Agnitum infer this protection is actually within the SPI feature that is enabled within the rule.). Spoofed/crafted packets are from current captured traffic, that current traffic capture contains not only the IP to spoof, but also other info which include the MAC address currently being used and allowed, so a check on an IP even with ref to its current MAC is of no use in this type of attack.
Realize, I am not looking at possible redirect, there is no intention for a reply from the host being attacked to the node attacking, it is simply a possible disruption of traffic via spoofed packets that I am currently looking at.

So that would put forward again that the current implementation by Agnitum does not block IP spoofing.
From the point of a security product vendor they need to be specific and be fully correct in what they state is being protected against. A statement of "IP spoofing" protection is not putting forward that the protection is only in certain specific circumstances, it is putting forward IP spoofing protection as an overall protection which is incorrect.


Regards,

- Stem

 

Software vendors need to consider the complete range of systems (and users), not just the high-end. That includes netbooks with sluggish Atom processors and those with older systems who don't wish to upgrade (this is being typed on a 1GHz PIII notebook running Win2K for example).

The issues described with DNS are, at root, issues with UDP packet processing.

Agreed.

Agnitum's SPI page shouldn't mention IP spoofing when discussing their Stateful Inspection option but it does otherwise provide a good explanation on what it does, as does Outpost's Help.

If you are spoofing the MAC address along with the IP address, then there is no way for a software firewall to detect it. However spoofing IP alone is easier and more common and being able to detect it is a useful option for the minority of users who could be affected.

I'd agree, but if this means going into a level of detail about network protocols that would deter new users, then some simplification is justifiable. Saying "this protects against the most likely encountered forms of IP spoofing" would be accurate in my view (with source routing being so widely filtered) while not requiring a networking degree to understand.

 

As there are options for the level of logging, there can be levels of filtering. Putting forward a need to take into account the slowest PC the firewall could be installed on is not an excuse for lack of filtering options.
Actually, it does give me a smile that the logging is in fact better than the packet filtering.

UDP packets for DNS can be easily distinguished with the use of remote port 53. Other vendors have implemented checks (including a check on Ident) for DNS without a need to add extra filtering to all UDP.

Well, that article as certainly been linked to more than once in this thread. One point I have not brought up concerning that article (in relation to its static/base filtering):-

Now I have always considered a SYN packet as the start of a new connection. So in a base rule that specifically only allows outbound connections, then that rule should not allow inbound SYN packets on that outbound connection, but outpost does.

Have you ever heard of TCP sequence numbers (they are included in TCP for added security and to help prevent IP spoofing ((as an example). Although (as I mentioned earlier in the thread) it is not impossible to still IP spoof when a check on sequence numbers is made, but it sure makes it a lot more difficult and is more probable to intercept IP spoofing than some simplistic IP/Port/MAC check.

Well maybe the info being given by Agnitum on its IP spoofing protection should include that it only protects IP spoofing from those who do not know how to IP spoof attack.

So your reasoning to the description put forward by Agnitum of its protection is due to the probability of its users ignorance on TCP/IP. From what I have seen, such a statement in fact confuses its user base into thinking they are more protected then they actually are.

 

No offence Paranoid2000 but you should really upgrade ,we are in 2009 (almost 2010).
Agnitum should develop a new Firewall Pro intended for hardware systems that run Windows 7 and leave the older versions of their software for older systems.
Nothing forces Agnitum to not mantain support for older versions, untill XP/2K "die" , so no one gets left aside no matter the hardware configuration.

 

Hi Paranoid,

Surely we are only talking about a table with say the last 60 seconds of "UDP out" requests being maintained at any point in time, or am I missing something.. Very rarely have these UDP packets from the DNS server been "that" late, usually more one of seconds.. & given from what you say that this has been a recurring issue, this has to be a relatively minor CPU issue (and not even relevant to RAM)..?? ie I'm not entirely sure I buy the "either / or" argument..

Are Agnitum good at responding to issues such as this - do they take note of people like you guys raising various issues, and then follow up and remove the errors in subsequent releases?

I would have thought a sound strategy to this (for any vendor) would be to ensure that those who are knowledgeable (such as yourselves) are mainly singing praises, and particularly about the core areas.

Yes, I do like the packet logging in debug mode - it's also easy to dump quickly into a spreadsheet and pivot / analyse if and when needed..

 

Hello Stem and Thread:

Part of the issue here, is the difference between what the documentation and marketing detail says these products can filter and how they filter and what actually happens on our real world setups. Vendors should ensure there are no differences and not put the product out on the market and hope the differences will not surface or expect us user guys to debug for them. You know SP1, SP2, SP3.

It's not a question of age of CPU or power of Ram at all. All products needs a certain minimum hardware/software requirement this as well should be "correct" and not set low so as to increase sales if that is what happens.

These products (all of them) either work to specification or they don't.
The differences between specification and working code can only be found by testing and should be done in the vendor labs! The definition of all terms like SPI that the vendor is working with should be spelled out so they can't be misread.

In a perfect world, there would be no differences to find but for the usual reasons we all know this is not a perfect world.

If the external labs don't do it, the ratings sites are marketing games then I'm down to Stem and guys like him to test and report findings.

OP has an opportunity here to use these results and comments to their advantage. Only time will tell if they do.

End of my quota for daily rants

 

Hi Escalader,

Unfortunately not everyone (well, only a very few) actually look and take these results as they are intended, and that is to simply inform the members of this forum as to the actual filtering taking place in the vendors product. There will always be more posting to such a thread (mainly the users of the product) arguing that the tests are flawed or the results mean nothing etc, etc etc, etc, or there are even some who would post to such a thread simply trolling.

I have only made a very basic test on TCP which shows to me a lack of filtering in Outpost. I will leave the thread before more un-needed discussion/argument or possible trolling takes place.


- Stem

 

Sure, a change could be done that way but it would only address DNS, not UDP generally. I would favour seeing the source of the problem being dealt with rather than a protocol-specific fix.

The SYN flag can occur on existing connections when sequence IDs need to be resynchronised (though the recipient should only be returning SYN/ACKs).

In the context of IP/MAC spoofing, what TCP gets up to is of little significance. However, TCP sequence numbers make little difference in the scenario you were replicating (an attacker on the same network segment as the victim, able to observe every packet sent out) as that attacker sees the IDs used by both sides (see the "Security Considerations" section at the end of RFC 1948). Only public/private key encryption would help.

Faking an IP address is trivial and requires no third-party software. Faking a MAC address requires third party software or fairly hairy Registry editing.

Any technical detail has the potential to confuse some people. The only concrete issue here though is an inappropriate mention of IP spoofing in a rules option explanation.

No offense taken, but I consider my current setup adequate for the job in hand. As such, it would be pointless and wasteful to spend time and money in an "upgrade", especially when that upgrade has the big downside of product activation. I have no intention of doing the 55-digit dance with Microsoft simply for daring to change hardware too frequently.

Where is the business sense in releasing a product that only 15% of PC users (based on the current Steam survey) could use?

 

If you guys look here, it seems that the vendor thinks there is a business case which is the point being made.

http://www.agnitum.com/news/2009-10-29-internet-security-windows7.php

I see OP with support for:

1) Windows 7
2) 64 Bit processors

Without doing that they may have 85% of the existing base but all that % could do is shrink as time rolls along with or without us!

 

Predicting sequece numbers is not as easy as a wording of such (and that paper puts forward more than simply sniffing a network). Plus, you need to quote the full context and take note of what is put forward.

It is far more likely that there will be a user who sniffs a network, then from that info simply attacks a node where a another user is connecting out to (for example) a game server. It is certainly far more probable than the attacker having a setup with software to sniff/transpose/predict sequence numbers for a crafted packet and having this done with reply made in the time an actual reply is made, and therefore is certainly more likely to be intercepted via a check on sequence numbers.

Just yet another un-needed discussion, as it is a point not specific to the actual attack being made.

I am certainly finished now.

 

Good job Stem, I can understand what you have been trying to do (extends way beyond this topic), and I agree entirely with it.

Different firewall developers keeps twisting and extending what it really means for a particular feature, developed their own 'lack of' implementation of a feature and try to market it as a full-blown original thing or something much better.

And the lack of details for particular features, one simply wants to scream till one's death ... they don't want to confuse people with technical details? Often enough people confused over the simplest BASIC things.

Listed features and detailed descriptions of the different functionalities for especially security software, should be fairly quick accessible to those who interested. And those who aren't and are confused, and don't bother researching, ... shame on them!


Like Stem have been saying, packet filters needs to be improved and try to go the extra mile, especially with how far behind they are in application-filtering based software firewalls.

UDP is as everyone who have been following this topic should know, UDP is an stateless protocol, so to secure better over UDP is to apply "protocols-specific fixes" rather than simply ignore UDP protocol altogther, I like to think option A would be a more preferred option.


DNS and DHCP by different "protocols-specific fixes" could easily enough make things a lot securer. And to get a little more carried-away, anyone ever hear of DHCP-snooping? http://en.wikipedia.org/wiki/DHCP_snooping


And...
"It is far more likely that there will be a user who sniffs a network, then from that info simply attacks a node where a another user is connecting out to (for example) a game server. It is certainly far more probable than the attacker having a setup with software to sniff/transpose/predict sequence numbers for a crafted packet and having this done with reply made in the time an actual reply is made, and therefore is certainly more likely to be intercepted via a check on sequence numbers." ... very nicely put stem.



Regards,
Phant0m``