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

I dont really want to get into a discussion of possible consequence of this, as it would only then start some argumentative debate of what is, or what is not a possible threat. (I dont have the time and certainly not the patience)
The point I am making here is that there is a large difference in the description put forward by Agnitum of it firewalls filtering capabilities and the actual filtering capabilities implemented.


- Stem

 

Hi Stem,

thank you for providing test results. Would you or have you conducted similar/same tests on other software firewalls or even Windows fw, and would you be willing to share your results?

 

Stem:

Good work.

I hope Agnitum Technical people read this thread and use these available public tools to test and improve/correct their own products.

After all it is in their interest to do that. My fear is they will simply mount a defence or marketing effort to cloud the matter.

I hope I'm wrong.

PS: As a user who just reinstalled the product this is NOT a confidence builder

 

Hi,
I have tested many firewalls, but the results for 3rd party firewalls are not current. (for the windows XP built in firewall, which results are current can be seen in this post which shows illegal packets such as SYN/FIN being dropped/filtered out of the connection- which I highly suspect is also current for the inbuilt Vista firewall).

As time permits, I will test again the various firewalls, starting with confirming the current filtering in windows Vista inbuilt firewall.


- Stem

 

Just to add, before one of the users of this firewall start posting with such as "This means nothing", "there is no threat" etc etc, then I will point you to the description put forward from Agnitum for the need for SPI

which Outpost firewall does not.

 

Sure, understood..

 

Excellent, and thanks again

 

Now i m starting to wonder whats the SPI implementation of PC Tools Firewall.

It would be excelent if Stem would do some tests in some special thread for more firewalls.We really dont know what vendors are marketing as SPI in their software personal firewalls on the market and what exactly does this feature.
The older ARP spoofing thread and this one have 5 stars of 5 from me.
Somehow i was beliving that using SPI with a firewall is less permisive and controls a little more the packets (thus offering more security) before they flow.Now i m not sure .

 

Well, we should all wonder about all these FW's so as NOT to have false confidence in them.

This is false advertising and one wonders how good the developers are to have such a mismatch between claimed security and actual implementation? I'm really ticked at them all! Not you guys posting at all but the situation we face.

The thing what bothers me about all this is is like many, I read the ratings and study the forums including the venodrs own forums and read the user documentation then trial the products and then buy. I don't have the tools or skills or time to do what Stem does for us all here. I don't know if he has time to do the top FW's or not BUT why should one guy carry the weight!

Where are the independent labs on this? This IMHO is a mess....

 

I have a few observations on this test but I'm not totally sure I understand the setup so Stem can correct me if I'm wrong.

I think the test shows that:

1. You start with a spoofed address then there's no getting around it.
2. That SPI is working as described.

This thread has been about the UDP protocol but TCP was used here. That makes a difference because TCP is robust and uses a handshake whereas UDP is "connectionless." But that's not my main point, although part of it.

The test started, I think, by sending out a packet from PC1 [88.10.25.101] with OP installed to PC2 [88.10.25.100]. This set up a "trusted" communication using spoofed addresses. The firewall can't tell if an address is spoofed on the outbound packet if there's a rule set to allow such traffic which I think there was. Once setup and allowed then future communications will also be allowed. I'm not surprised by this since the rules allow it.

With SPI turned on then things become less secure as mentioned in the referenced KB article:

Once a connection with SPI is turned on then all consequent connections between the hosts are allowed making the connection less secure not more. That's just how SPI works. SPI just won't help in this situation and is not recommend to be used as stated in the KB article.

The one kicker in all this is the spoofed packet from the third machine [88.10.25.201]. It makes no sense to me that this was allowed in with no SPI and a untrusted LAN. It makes no sense because this is basically unsolicited inbound traffic which should be blocked. Either that or the firewall just isn't working. But we know that's not true because this thread started out about UDP traffic being blocked by Attack Detection. I can't explain why this happened, aside from some configuration error, but if this is truly a bug then nobody should use Outpost because it would mean that it fails at such a fundamental as to make it untrustworthy. I just don't think that is the case. Something else is at work here.

 

Manny,

The spoofed packet from the third PC is from 88.10.25.100 not .101, ie same address as the second PC.. [Edit - Ignore this line, my mistake, I mis-read 201 for 101..]

I presume it is allowed in because PC1 has a link at that point with PC2, and PC1 recognises PC2's IP address.. ie PC1 does not consider it to be unsolicited because it has an established link with PC2's IP address.

As the firewall still seems to be working perfectly normally in terms of its port and IP address filtering, I am not sure that this contradicts the UDP example above. As soon as a deemed reply was received (from the DNS server above and on the correct port), the "pseudo" UDP connection was closed and hence we saw the "attacks" being raised for the later DNS replies. In this TCP case, the connection is still open as far as PC1 is concerned.

I too would very much like to see more testing afresh and on other firewalls as well...

 

Unfortunately you are making incorrect assumptions.

First. The connection is made, there is NO spoofing involved, it is a simple direct HTTP connection from the host(88.10.25.101) to a remote PC(88.10.25.100).

The actual attack (IP spoofing) is then made from the 3rd PC(88.10.25.201) against the host with outpost installed (the 3rd PC spoofs the IP address of 88.10.25.100)

Even with a static rule system that employs direction in the rule, then inbound SYN(connection) packets should not be allowed on a current/active outbound connection.
From the description made by Agnitum, enabling SPI does infer an increase in security, as it is stated as being able to block IP spoofing, which it does not.

The only mention concerning where SPI is not to be used is for inbound packets generally.

 

Hi Stem,

so for clarity:

1. Outpost is installed on .101 (source ports is ethereal 160)
2. The http (port 80) pc is .100
3. The spoofing pc is .201 but spoofing .100

Is this correct?

 

Can you untick SPI in the rules Stem and then see what happens. Let's just see if the the 3rd PC(88.10.25.201) spoofed packets are allowed in without SPI involved in the mix.

 

Yes, correct

 

I did, as mentioned in the post.

I first made the test without the SPI, then remade the tests with the SPI option enabled. The results where the same.

 

Setup on VM network, same result.

 

Just bad packet filtering.

 

Hello Thread:

IMHO, the proper response for the OP vendor to this is not to waste time "defending" but to take the test results Stem has produced for us and say thanks for the data, we will try to reproduce these tests in our lab and IF we verify them, we will fix the problem.

In the meantime, I have a question for Stem.

As my router has an Alphashield in front of it protecting the PC's sharing the router does that device provide the SPI function for me?

 

I did not want to intrude in this discussion, I am not 'Outpost' user, but 'stateful' is 'stateful'.

All that you demonstrated so far show that 'stateful engine' checks if a packet is consistent and belongs to an allowed connection, or some host tries to scan ports or just open an allowed connection.

In both cases response can be perfectly correct from a 'stateful' point.

In your log I do not see how responds rule that blocks these intentions, if exist ?

To understand how you have done the test would need to see 'Date/Time' interval, that you constantly hide?

--

 

You should not worry too much, as I mentioned earlier:-

@All

There as already been a lot of confusion of the side of its users as to what SPI is actually implemented. I have shown that the SPI option is in fact statefulFTP and would expect it to open any ports in any direction when needed after that control connection is made and during the time it is maintained.

So, I will stress again the point I put forward above. That is because Agnitum state the protection against IP spoofing and that cannot be done simply by filtering IP/Port (and this is not related to the spoofing protection for the ARP)

 

No vendors or developers have the time or desire to respond, nothing to defend! Is yust one trends FTT test.

--

 

You have shown nothing. Read my post above #95, but confusion yes with your partial trends log screenshot.

I tell you this and then stop!

Stateful engine rule must check a packet against stateful rule, but can't modify corresponding state data, only if ..(You may wish to start with reading a general overview of :stateful engine packet check, stateful rule).

If you were really concerned about such things, you wouldn't waste time here as a FTT.

 

G'day everyone,

I've not been active here for a while and I can't describe myself as being expert with the latest version of Outpost (being a 4.0 holdout for various reasons, not important here) but there are a few issues I would like to contribute to.

DNS response blocking
This has been a long-standing issue with Outpost in my experience. On balance, it is better to have a firewall that blocks more than it should (as long as it isn't anything critical) than one that errs on the permissive side.

However having Attack Detection trigger on DNS servers is definitely not a good thing and I would recommend adding DNS server addresses to the Attack Detection plugin's Trusted Host list if this occurs. If that doesn't work, then create a system rule as follows:

DNS Fallback: Protocol UDP, Inbound, Remote Host: Macro-DNS Servers, Remote Port DNS, Allow

This will allow all responses from your chosen DNS servers, regardless of whether they match any requests. It does imply a certain degree of trust but no more than that involved in using the server for DNS lookups in the first place.

While Outpost's handling of UDP could be improved, it would almost certainly involve having to store more data on past traffic, increasing memory and CPU utilisation (especially with programs making large numbers of connections at once, file-sharing apps being one example). Given past feedback on Outpost releases, far more users seem concerned about memory/CPU usage than accurate UDP filtering so it would seem likely (and not entirely unreasonable) that Agnitum is giving greater weight to these concerns.

Agnitum's SPI implementation
SPI, as others have pointed out, has been defined in numerous ways by different vendors. Agnitum's variant does appear to be working as described so this does not seem a problem. In my view though, it is only suitable for a small minority of applications and the most common of those (the FTP protocol) will use it whether selected or not.

Outpost not handling TCP packets with inappropriate/invalid flags
This is a failure on Outpost's part - well done for spotting this Stem. The most serious effects (network subsystems crashing due to invalid flag combinations) are not an issue with recent versions of Windows, but they should still be blocked and alerted on by the likes of Attack Detection.

IP address spoofing and Outpost's ability to block it
There are two scenarios to consider here:

Attacker spoofing from within the same LAN
This will show as an ARP mismatch (i.e. the spoofer has a different ARP address from the real IP) which should be detectable by Outpost's Attack Detection plugin - this has an option "Detect IP address spoofing" which needs to be enabled. Stem, could you please check if you had this switched on and if not, try enabling it?

Attacker spoofing from outside the LAN
Unless you have an insecure LAN (e.g. you are on a school/university network), then this is the more likely scenario. In this case, the attacker will need to use a feature called Source Routing to ensure that any response is sent back to their real address rather than the spoofed address.

This means that such packets can be identified by their use of source routing in their IP options field, but Outpost does not provide any option to block these (I'm not aware of any other personal firewall that offers this either).

However many ISPs will block source routed packets at the boundaries of their networks, so this issue is far less widespread than it may appear. Anyone wishing to check for themselves can do so first by performing a traceroute (tracert in Windows) to a website, noting all the IP addresses traversed and then doing a ping with the strict source route option (-k) listing those addresses - it will only get through if no ISPs are filtering source routed packets.

 

Wouldnt actual PC-s ,with Dual Core ,Tri Core and Quad Core of 2,8 to 3,x Ghz ,plus 2,3,4,6 and 8 Gigs of RAM do the the job just well ?
Past feedback is no more actual ,new hardware is used at large scale so software developers should start using 64 bit architecture and the new CPU capabilities (which have some cores idleing usually ,wasting computing power).

Also SOHO router manufacturers are promoting their hardware by exposing the SPI feature.
In Outpost the term SPI seems to name a useless feature which doesnt seem to enhance security (as roiuter vendors usually say).At least Outpost should rename that thing to avoid confusions.In Outpost seems that using SPI feature lowers security which is the oposite of what i red about SPI by Checkpoint.
I think Agnitum should start recoding right now.