On Thu, 2013-05-02 at 00:17 +0200, Pascal Hambourg wrote:
> Hello,
>
> Matthew Babcock a écrit :
> > Please excuse the delayed response.
>
> No problem.
>
> > To answer your question, no I cannot, yet.
> >
> > However, I can demonstrate iptables following what the "state" be on UDP
> > packets using DNS.
> [...]
> > You should see as I do, that the UDP DNS request are logged under the
> > state NEW, and that the response was logged under the state ESTABLISHED.
>
> Nothing new here. UDP possible states are :
> - NEW for a datagram creating a new connection or belonging to a
> "connection" which has seen traffic only in one direction ;
> - ESTABLISHED for a datagram belonging to a "connection" which has seen
> traffic in both directions ;
> - RELATED when a conntrack helper expects a UDP datagram related to an
> existing connection (e.g. TFTP or SIP).
Much of that is my point. I am not sure why you make the statement
specific to UDP while omitting the "INVALID" state.
> Note that this is not specific to UDP, conntrack does the same with all
> connectionless protocols.
>
Yes! I was aware, but thank you for point that out.
> > I consider this, iptables differentiating between "New" and
> > "Established" UDP "connections", reason to extrapolate that iptables can
> > follow state in UDP packets such as flagging on "Invalid" or out of
> > state UDP packets.
>
> UDP is connectionless by nature, so how would you define the INVALID
> state of a UDP datagram ?
>
Yes, I am sure we all know UDP is a "connectionless" protocol, but as I
said in the email you are responding to, and as you cited yourself, NEW,
ESTABLISHED and RELATED states can be applied to UDP and ICMP and likely
other connectionless protocols. What you are saying is a large part of
my point.
iptables can determine, based on some criteria, what "state" a
connectionless protocol is in.
So, this is happening one of two? possible ways. One is very
rudimentary, the other is super plausible and I expect it is not beyond
the developers of iptables. The former being, just matching based on
source ip and port, destination ip and port, only information from the
packet headers, and timeframe. The other option I consider super
plausible, is as I eluded to previously, is looking past the packets
header into the application layer.
> > I aim to try and create an "Invalid" UDP state packet. I will follow up
> > if I try regardless of the outcome.
>
> Good luck. I meant it.
>
>
Thank you. I have not read the source code, it may well not work.
However, I feel my point is still valid that iptables could be(come) an
application aware firewall, even if just with rudimentary connectionless
protocols such as DNS or ICMP, much like you just pointed out.
As I conceptualized previously and am now elaborating on, there are
several application layer protocols that have their own "state", yet are
transported over unreliable transport protocols.
Example #1, DNS requests.
DNS packets have Transaction IDs. See the RFC rfc1035
"This identifier is copied the corresponding reply and can be used by
the requester to match up replies to outstanding queries."
So, an "established" DNS connection over UDP is *determined most
accurately through the layer 7 protocol*, matching the transaction IDs
in the absence of TCP Flags.
As I write this, I realize that the specific example above, iptables
determining state based on transaction IDs as well as direction of the
communication would go very far in flushing out DNS Cache Poising
attempts. Not preventing successful ones perhaps, but making them
clearly obvious as you would see a bunch of "INVALID" DNS responses.
Example #2, ICMP Pings.
I believe the standard for ICMP ping messages states that a ICMP ECHO
Response, is only created in response to an incoming ICMP Echo Request.
It seems to me that if iptables looked a bit beyond the headers (my
suggested premise) it could easily flag a unsolicited ICMP Echo response
as an INVALID state packet. Much as it would an unsolicited SYN ACK
packet.
--
To UNSUBSCRIBE, email to debian-firewall-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1367561336.2612.1633.camel@Lappy.ARSec.local
