Firewall with these features??

If you say so.

Emphasis mine:

Point A: First of all SPI is almost irrelevant in regard to trojan detection or execution permissions. Protecting from malware, IDS stuff etc is more the domain of a DPI. As for malformed packets - the vast majority of firewalls will be able to reject suspect TCP packets. eg. 'Bad packets with the wrong checksum, packets with no TCP flag set, etc. If your firewall detects specific named attacks (but does not include a 'traditional IDS') than this too is more in the domain of DPI.

Point B: I don't know how your system is setup or what netblock you're in but it's obvious you are overstating the affect of the 'attacks' you are detecting. (Care to tell us exactly what your alerts say?) Unless you're simultaneously running a web server on the same machine with SSH and SQL also running then it's evident that you are believing all the FUD that your firewall alerts you to without knowing what they mean.

I don't know what you're trying to say here. But if you personally believe that you can make your setup more secure by installing multiple software firewalls each of which share a certain amount of feature capability than you are seriously misguided.

Well http is quite popular as a covert channel - that is: inside out attacks because most firewall rulesets allow it without filtering. The other popular covert channel is ICMP (eg. pings). Yet as P2K already stated:

So in terms of inside-out attacks eg. trojans and the like Stateful Packet Inspection would be quite useless unless they went outside the 'expected' sequence of events for the protocol. For example a stream of HTTP POST commands in one direction only. A firewall with Application-specific filtering emphasis on the other hand would allow such a stream but only if the application (i.e. trojan) was in its list of allowed applications.

See point A. And as P2K already stated:

So it is doubtful that your so called full-SPI firewall supports all the P2P applications you are using. For unsupported apps all that is being done is Packet-level (or network-level) SPI, which most application-specific firewalls already do anyway.

 

OK, is DPi something I can get somewhere?

 

Though you aren’t wrong, you are misinterpreting what I had said and why I had said it. Anyways, again you aren’t wrong but you seem to be putting across the idea SPI don’t serve no purpose and so why should it be implemented and used in software firewall products. Though SPI does not prevent Trojan infections, but it can benefit when up against some types of Trojan infections. And you probably understand when I mention about ACK tunnelling Trojans, by blocking unsolicited packets that lets in nutz see/retrieve and damage to the point easily rendering windows unbootable…

As for benefiting me while I surf, SPI does numerous things like block different types of scans, and while I surf the internet and especially the places I visit I do see many types of scan packets, and assuming I’m not the only one surfs these places it would be fair for me to say the next user may not be all knowing like you or myself and behind stateful packet-filtering system or activated for reasons I could easily mention in regards to Look ‘n’ Stop’s SPI implementation. And this being the case, it is possible user contains service that could be easily exploitable or form of Trojan infection with no or weak password handling that could lead to them setting user up with backdoor or in the addition of Trojan infection already, a more favourable backdoor.

I don’t think you are stupid, and so I know you won’t deny the fact SPI (and I’m not in reference to IDS or DPS…) are beneficial against many forms of malformed and unsolicited packets and regardless if some or many packets are merely harmless “uninvited” packets. For instance denying these could speed up internet performance in addition aswell as system performance, or will you try to deny this also?

If you thinking I’m not capable of understanding between different forms of scan packets, flood packets (which I refer as attacks), threats like exploiting packets you would be wrong. Though I have to admire you for saying this and asking the question, many times people lacking knowledge in this area are paranoid and quick to make assumptions about packets they see logging. And so I know where you coming from…

And again bit more admired here, no what I were saying is if you running two or more software firewalls, they be more acceptable / injuring of software conflicts that can leave them wide open in many cases. But some cases where one is knowledgeable enough and with proper attendance can make the two layers shared between two products work in harmony, an fine example would be 8Signs or CHX-I with Look ‘n’ Stop Application filtering layer. Misguided? No? Not unless you don’t agree Look ‘n’ Stop Application filtering layer doesn’t compliment strong and true stateful packet-filtering system?

True stateful packet-filtering systems works at network layer while application filter based software firewalls (excluding Look ‘n’ Stop) I have ever saw does not, when they advertise SPI what really it is, is stateful-like which there is a difference that they the software developers don’t want you or I aware of.

As for true stateful packet-filtering systems not compatible with p2p software, that is just bull ****, sorry for my choice of words, but I have first hand experiences with different packet-filtering systems and I know what works and don’t.

 

Ok so you're talking about scans, types of port scans I guess. You do realise that you cannot stop people scanning your machine? I would also like to point out that the vast majority of firewalls deny unsolicited packets and so would not let any packets from portscans through.

I still do not think this is a good idea. Here's why:
With any two software firewalls what you have is two black boxes. The help file and GUI may give some indications of what to expect, but there will always be something you cannot know about it. What is always difficult to determine is how modularised the application is. eg. How much separation is given to individual components and how they relate as a whole.
That is to say how much each component depends on another even if it is 'disabled' through a user interface. You do not know.
Second, does the firewall really operate as is indicated by the documentation. Even with regression testing, you just do not know.
Now have two firewalls operating simultaneously. Which one has priority over the other, even if one should not affect the other since you're using 'separate' capabilities of each?
Is it the one installed last?
Is it the one with the lower level driver?
Does one 'filter' traffic so the other is less effective?

What you have is not two layers of differing thickness covering the same surface area. Nor can you be sure that one covers one part and the other firewall covers the other (a single layer as total). What you have in the onion analogy is more like tectonic plates which are curved under each other at certain point, overlapping completely in some areas, other areas completely exposed or others covered by one layer only.

Then there is the problem of failure and redundancy. One firewall may fail-hard in a failure but how will this affect the other?

I never said they weren't compatable. Rather the level of security for 'unknown' protocols will be less than for those clearly stated as being 'fully supported and detected'' in the Full Stateful Packet Inspection sense as listed on the box.

 

Unlikely found in any software firewalls. Most likely in the latest and greatest hardware firewalls.

 

- Not entirely in reference to only mere scan packets that were just an example.
- Of course you or I can’t stop someone from “attempting” but I surely prevent them from succeeding what they set out to-do with a good packet-filtering acting as middle-man regardless what you may think.
- Lately everything is indeed improving a bit, but without the use of stateful packet-filtering system “many” TCP scan types can bypass the standard/outdated packet-filtering systems. Except one I know of, rest can be handled by improving non-stateful packet-filtering systems by implementing/allowing controls for TCP flags, but the TCP ping packet however cannot be dealt by anything else except a stateful packet filtering system. Now if the software firewall don’t offer controls for TCP flags, as long as you using stateful or stateful-like packet-filtering system the SPI can shield you from all types of TCP scan packets. Or do you disagree with this also?

The key words are “not think”, and the difference between you and I is I know, and I’m insulted that you would think very little of me, the fact remains I did that, done that and I definitely would know if they aren’t in harmony with each other. And I did make it perfectly clear about using 8-Signs or CHX-I packet-filtering system (containing zer0 App-handling) with Look ‘n’ Stop Application-filtering layer ONLY.

Look ‘n’ Stop emulates the network interface drivers, and if u de-check “Internet filtering enabled” you stop its packet filtering process so a strong and true stateful packet-filtering system can begin regardless the driver loading order. And if you still want to be difficult after saying that ghost16825, let me tell you this, Removing/Disabling Look 'n' Stop packet-filtering Driver can be done, for instance Look 'n' Stop user's connections properties you can Disable or Remove "Look 'n' Stop Driver" that emulates the network interface for the adapter. Do I have to say more ghost16825? Or do you see the picture?

 

Ok now we're getting somewhere (I think)

Alright which of the scans in the nmap man page are you referring to?
( http://www.insecure.org/nmap/data/nmap_manpage.html )
My guess, although I don't like to make assumptions, is that it is one or all of these: FIN, Xmas Tree, or Null scan modes. I believe the majority of consumer firewall products will not give up any identifying info to Null Scans.
What other non-full-stateful-packet-inspection firewalls do with other TCP flags is another story. I know for a fact that Kerodo found some quirky behaviour with Kerio 2x with regard to FIN amongst other TCP flags.
Is this cause for great alarm? Does this mean that useful connections could be made to pass through the firewall?
No, I do not think so.
Do I think that this behaviour could be used for firewall (OS) fingerprinting? Yes, possibly.
With differing behaviour in response to TCP flags does this mean a single FIN, Xmas or Null scan could give away any meaningful information?
No, I do not think so.
What if these 3 scans were used together, along with other scans like TCP connect?
Possibly you might get some useful information about what ports are open, but this too is unlikely due to conflicting results from each scan. Firewall OS fingerprinting is more likely.

Stateful or "stateful-like aka Packet-level (or network-level) SPI"? If you meant only full SPI then you are wrong. You stated previously that you believed most firewall products to have stateful-like packet inspection, not full-stateful-packet-inspection. Hence, according to you most consumer firewalls should not be able to deal with TCP ping.

As stated verbatim from the nmap page:

Hence the term TCP ping is essentially an ACK packet or a SYN or a simple TCP connect. All if not nearly all software firewalls handle TCP connect scans, ACK scans and SYN scans. And these would have only 'stateful-like' inspection as you put it.

No, I do agree. Firewall manufacturers just have to be careful how they handle such things as I alluded to above.

No, I see the picture. Lock 'n' Stop is an exceptionally rare case of an application which is highly modularised and provides for full separation of components.

 

I apologize if I don’t include every little detail, I’m up all hours and I’m always busy doing something, I don’t have time to overlook all what I post, so I appreciate you ask questions rather then put words in my mouth “* You stated previously that you believed most firewall products to have stateful-like packet inspection, not full-stateful-packet-inspection. Hence, according to you most consumer firewalls should not be able to deal with TCP ping. “


Now I know you read the following

Looking again more closely to this here, does that give any indication I were specifically in reference to only a true stateful packet inspection systems being able to handle TCP ping scans?