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

Hello Thread:

This is a wording/definition debate. Interesting as a college debate but not in the real world of day to day security matters. I mean no disrepect to the posters here. Clearly, they are dedicated to their understandings and you have to respect that.

What matters to me and I suspect many users of these products is what does proper professional independent testing show is TRUE?.

We have experienced smart posters not agreeing on what other peoples words mean. I for one can't deal with these kinds of posts one claim then another. How do I decide which to "accept"?

Only testing of firewalls in a lab under the same identical conditions can determine the facts. These I don't know where to get. Sponsored "testing" sites don't cut it. These just feed the ratings game and that is called marketing.

I see no immediate solution to this unless someone else has a source/ link.

 

Stem, That's really clear, especially the re-iteration between static and dynamic, thanks - some googling I was doing makes more sense...

Noted..!!

 

One accepts this, directly from Agnitum, that is what One accepts!:

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



HKEY1952


EDIT: URL

 

Well, no. Nothing personal of course but I respectfully can't do that.

They are a vendor so naturally they will "say" that their definition is correct. If I were a vendor I'd do the same.

We need more than if vendor x says this it must be right! The proof of the effectiveness of 3rd party FW's must come from non vendor sources.

Vendor y says something else, vendor z something similar but not exactly the same. We need something like a definition from IEEE or some such organizations as that, THEN the independent tests to KNOW what the truth is.

That's how I see it. For now I have 2 unused licences I'm in wait state!

 

The main problems are with every firewall stating SPI. Most simply filter IP/Port. I have always thought of SPI (or statful packet filtering) as packets being fully filtered within a connection, whereas the filtering on IP/Port is only for that limited info, which does of course filter out SYN(connection) packets depending on direction.
The link given by HKEY1952 to Agnitum concerning its SPI states how their SPI rule is used for FTP connections, so that once the outbound connection is made then inbound is also allowed

- Stem

 

Well, I thought I should setup and confirm this behaviour with the SPI, as it as been a while since I tested outpost. I did actually think (for some reason) that the dynamic rules where logged, as being for the SPI, but they are not.

I created a rule to allow (only) outbound HTTP for the application (it is just one of the applications I use for packet filter test). I then connected out, the application was listening on port for inbound (as it would for FTP), which was allowed without a specific rule to do so (see pic, note that the outbound connection is made (which is the control connection within the rule), then an incoming connection was allowed/established)



This is a simple test that anyone can try, just a need to have an home Lan with at least 2 PCs.

So the SPI within the rule is as I have put forward, it as not changed since the last time I tested.

 

If you have license, then why not use it.?

Dont be put off with this SPI. Just leave the SPI option disabled, you still have the same filtering as with most other 3rd party firewalls.


- Stem

 

Packet filters vs Intrusion Detection (Stateful Inspection)

An PACKET FILTER examines every network packet that passes through it, and either forwards or drops the packet, according to an set of rules established by the Firewall Administrator.
An packet filter can be configured to block TRAFFIC by creating rules to block: IP Addresses, Protocols, Port Numbers, and Direction.

STATEFUL INSPECTION operates in an manner similar to an packet filtering firewall in that it also examines the source and destination addresses of every packet that passes its way, however,
an PACKET FILTER is NEVER AWARE of the context of ANY COMMUNICATION. Each packet that passes through it is treated on an INDIVIDUAL BASIS.

An firewall that employs STATEFUL INSPECTION techniques attempts to keep track of REQUESTS and RESPONSES to be sure that they MATCH.
Firewalls that employ STATEFUL INSPECTION maintain tables or an 'pseudo connection' that store temporary information about CURRENT CONNECTIONS so that it can determine whether INCOMING packets are
unsolicited or whether they are in RESPONSE to an REQUEST. When an CONNECTION TERMINATES the firewall removes references from its internal tables or severs the 'pseudo connection' so that an external
source cannot use it to gain entry again. Another name sometimes used for this type of firewall is "DYNAMIC PACKET FILTER".

FTP always requires an INBOUND CONNECTION because FTP is based on an Client/Server architecture. Unlike an DNS Request or just opening up an Browser to an Web Page that only requires an OUTBOUND CONNECTION.
In the FTP Protocol, every command SENT by the CLIENT must be followed by an REPLY FROM the SERVER. In some cases, more than one reply will be SENT to the client.
An FTP Server is called an 'DAEMON' on Unix or Linux Systems, and an 'SERVER' on Microsoft Windows Systems.

The FTP server daemon listens for FTP REQUESTS on TCP Port 21.

The server is composed of two components:

01) - The first component of the server is the Server-PI "server protocol interpreter"
This is the component that listens to TCP Port 21 and interacts with the client counterpart, the User-PI "user protocol interpreter"
The user protocol interpreter initiates an FTP session by sending an OUTBOUND CONNECTION REQUEST to the server.
The clients request can also include an specified Port that the client wants the server to use when it opens an data channel.

02) - The second component of the server is the Server-DTP "server data transfer process"
This is the code that interacts with its client counterpart, the User-DTP "user data transfer process" to perform the actual file data transfers through an INBOUND CONNECTION to the client.
The important thing to remember is that two channels of communication are used for FTP, one for commands and one for the actual exchange of data, and that both of these channels work in both directions.
Again, by enabling STATEFUL PACKET INSPECTION for FTP, FTP is free to open OUTBOUND and INBOUND connections SAFELY without excessive overhead with firewall rules.


HKEY1952

 

First, there are NO DYNAMIC RULES, there exists however, DYNAMIC PACKET FILTERING

Second, the two computers are on the same Local Network, Enabling NetBIOS or Trusted for the Local Network in Outpost overrides Stateful Packet Inspection (SPI)
NetBIOS and/or Trusted are obviously enabled or there would be no connection.

EDIT:

HKEY1952

 

Incorrect again. You are really digging a deep hole for yourself.

The LAN was not trusted and netbos was disabled. When the SPI in the rule was disabled, the inbound connection was blocked.

Rather than you keep making colorful posts and quoting unrelated info on how stateful Inspection should be implemented, you should actually set up and test

- Stem

 

I thought I had better reply to that statement.

It could be that Outpost does not create Dynamic rules, but that would cause it some difficulty in maintaining dynamic filtering. Unless of course it simply does not filter and allows everything to/from the connected IP after control connection with remote IP.

I am more used to IPFW and WIPFW(IPFW windows version) that use Dynamic filtering with the ability to actually lists its current dynamic rules.

 

Exactly Stem.....which proves that Stateful Packet Inspection is working as designed.....meaning.....

Being that NetBIOS and Trusted are disabled for the Local Area Network, Outpost in turn rules the Local Area Network with: "Limited Access to LAN"

"Limited Access to LAN" = NetBIOS communications are blocked, all other communications are handled by APPLICATION AND GLOBAL RULES.....so.....

Being that the ENT.exe Application Rule allows: (*Allow Outbound TCP to HTTP for ENT.exe) with no explicit Rule allowing Inbound Connections, Outpost's "Limited Access to LAN" Blocks the Inbound Connection, however,

Enabling Stateful Packet Inspection, Dynamically Allows the Inbound Connection for that session, because the ENT.exe Application Rule Allows Outbound Connection to the Local Area Network through ENT.exe.

Disabling Stateful Packet Inspection, results in no Dynamic Packet Filtering, and Outpost's "Limited Access to LAN" Blocks the Inbound Connection.

HKEY1952

 

Stem,
I'm being slow again (!) - is that test above as follows:

With SPI enabled on PC1:

1) PC1 > PC2 : PC1 sends packet / establishes connection to PC2 (to port 80 on PC2)
....20 seconds later..
2) PC1 < PC2 : PC2 sends new packet back to PC1, and from port 1032, not from port 80
3) PC1 accepts new packet from PC2

Without SPI, the packet back from PC2 would only have been accepted by PC1 had it been deemed to be a normal "reply". Ie the port (at least) would have needed to match: so it would have needed to come from port 80, rather than 1032.

With 2) above, was it a completely fresh connection made by PC2 to PC1, rather than just "a reply but from a different port". Hence, re flags etc, did PC2 initiate a connection that, without SPI, would otherwise have been regarded by PC1 as an unsolicited scan of some type?

If either understanding is correct (re port, or new connection/flags?), then presumanbly one should only switch SPI on in Outpost for specific purposes (such as FTP) - and instead use its normal filtering to manage all other connections?

 

That is advisable pbw3.....or.....only apply Stateful Packet Inspection to Certain Application Rules where the destination is TRUSTED to reduce the chore and overhead of creating INBOUND RULES.
Stateful Packet Inspection will insure that the INBOUND RESPONSES and INBOUND CONNECTIONS are from the SAME REMOTE SOURCE that was requested by the Application Rule.


HKEY1952


EDIT: Correction

 

As I have been putting forward all along. It was you who stated it does not work this way.



- Stem

 

Yes.

Correct.

Yes. Unless the application was listening on port, which in the settings I had for outpost would of caused a popup to ask if I wanted to allow the inbound connetion)

Yes.

As I mentioned, Outpost already contains a packet filter (similar to most other firewalls) that filters by the static rule, so filtering is still made on at least IP/Port


- Stem

 

I believe at this point you should change your Title back to: Firewall Moderator


HKEY1952

 

No, I have retired as Moderator. The Admins have given me the new title.


Regards,

- Stem

 

Congratulations.

Regards,
HKEY1952

 

That's great - and many thanks...

..and that was me just thinking that your patience was beginning to wear thin.. LOL...

 

Actually, it has.

- Stem

 

Well, as the "What is 'stateful inspection'?" link to Agnitum was put forward showing its description of SPI, I thought I would just make some quick tests on Outpost.

First for clarity, from the link/description of SPI at Agnitum:-

Now that indicates a lower level of packet filtering than just IP/port, but lets continue with their description:-

So yes, it must be a lower level packet check than just IP/Port, because it needs to be to intercept IP spoofing.
Now I know we went through how Outposts allows 2 way traffic (inbound and outbound connections) when the SPI is enabled, but what I am looking at (and for) is this filtering that will stop IP spoofing, as to block that, then the packet filtering needs to be checking not only (in TCP) the IP/port, but also the flag settings and the sequence number (but please note, even with a check on that, it is possible (although difficult) to still be bypassed with IP spoofing).
So first, I set up, with an outbound active connection, with a rule to allow only that outbound, whilst the connection was active, I sent back IP spoofed packets to see how the firewall would react. I ran the test a number of times, then repeated the tests with the "SPI" option enabled in the rule. The results where exactly the same.

(my setup was on an internal LAN with a random IP address range, the LAN was not trusted)

This is the packet filter result from a short test (the log from outpost firewall):-



The log is read from bottom to top.

First is the outbound connection made.
1; I sent a spoofed SYN(connection) packet to the port current with the outbound connection, it was allowed and even an ack (acknowledgment was sent back)
2; I sent another spoofed SYN packet and again a response (A firewall with a current outbound connection should not allow an inbound SYN packet to that port)
3; I sent an "All flags set"(that is a TCP packet with all its flags set), then sent a "Null packet" (A TCP packet with no flags set). Both those packets are classed as illegal, yet both where allowed, (although the null packet actually made a null log entry). There was then an ACK sent back in response.
4; I then sent 2 FIN/SYN packets (these are actually classed by some as " the most well known illegal flag combination", the first was acknowledge, the second was also acknowledge, but then a response to close the connection (FIN/ACK) was sent out.
5; That was just ARP that was allowed, but it states due to "No Rule"
The connection was then closed.


So, it does not matter if the SPI is enabled or not, outpost simply filters to IP/Port and in this short test, allowed both spoofed and illegal packets inbound on an outbound ruled connection.

From that test result (IMHO) I would say that the description put forward by Agnitum concerning their firewall filtering ability is not entirely correct.



- Stem

 

An interesting test Stem may I ask for more details?

Did you use the spoofed addresses [88.10.25.10*] for all your traffic? That is, is that the IP address you used to initialize the oubound active connection?

What software did you use on the second PC to send back the packets? and what to initiate it?

What was the log level settings in the Troubleshooting section?

 

Stem,

That's a great demo, and suggests that there is not a lot of difference between SPI on or off. SPI off at least checks the external port, whereas with SPI on, the external port is not checked (to benefit FTP, as per your earlier test).

- What is the implication of the spoofed inbound? When Outpost responds to the illegal SYN in, presumably it must be responding to the real external IP address and not the spoofed one.
- What is the risk here, ie of the returned illegal flags not being dropped or rejected?

ie Are there potential consequences for this, and just in normal static filtering mode and ignoring SPI?

 

An outbound connection was made from 88.10.25.101 -> 88.10.25.100

The connection was made by ENT.exe (http://www.tamos.com/products/nettools/ a small program I purchased some time ago, and is useful to maintain an outbound connection for tests.
A 3rd PC (88.10.25.201) was used to send the spoofed packets, I used Colasoft packet builder to craft/send the spoofed packets for this test (the base packets where from a wireshark capture log of activity, which where then edited)
(Note: I used that software for this test simply as that software is openly accessible to all, if wanted to make these tests themselves

Both log levels where set to maximum in order to catch all frames.