Hi,
I’m writing a firewall under win2000 and to do that i wrote a
driver at Ndis level using DDK. Now, my problem is to know the state
of each active connection, source_IP, destination_IP, source port and
destination port. In a few word Netstat informations.
My question is: is it possible access this informations using some TDI
call
or something similar?
Thanks,
Luca
IOCTL_TCP_QUERY_INFORMATION_EX (which is used for
getsockopt()/IPPROTO_TCP) can maybe help, but I do not know the
details.
BTW - the firewall can learn this stuff from the traffic it filters,
just read RFC793 about when SYNs and FINs are sent and retransmitted.
Max
----- Original Message -----
From: “luca”
To: “NT Developers Interest List”
Sent: Monday, March 31, 2003 6:51 PM
Subject: [ntdev] firewall & connection tracking
> Hi,
> I’m writing a firewall under win2000 and to do that i wrote a
> driver at Ndis level using DDK. Now, my problem is to know the state
> of each active connection, source_IP, destination_IP, source port
and
> destination port. In a few word Netstat informations.
> My question is: is it possible access this informations using some
TDI
> call
> or something similar?
> Thanks,
> Luca
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>
> ----------
From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, March 31, 2003 8:19 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: firewall & connection trackingIOCTL_TCP_QUERY_INFORMATION_EX (which is used for
getsockopt()/IPPROTO_TCP) can maybe help, but I do not know the
details.BTW - the firewall can learn this stuff from the traffic it filters,
just read RFC793 about when SYNs and FINs are sent and retransmitted.
It should. It would be rather funny firewall if it have to ask above layered
driver for connection details. Moreover, one of firewall purposes on NT is
to protect TCPIP stack against attacks against known and uknown bugs (as
ping of the death before). So it should be more stable and reliable and
can’t rely on tcpip driver.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
>…It would be rather funny firewall if it have to ask above layered
driver for connection details…
You are right, but if a receive a packet belong to a establish connection
i can give it to above layer without pass it through firewall rules.
…one of firewall purposes on NT is to protect TCPIP stack against
attacks against known and uknown bugs (as ping of the death before).
In addition to firewall rules, that block only indesiderate connections, i
use an IntrusionDetectionSystem(IDS) that drop corrupts and malicious
packets.
In reguard of ping-of-death problem my goal is to use a bandwith limiter.
Thank for your attention,
Luca
> ----------
From: xxxxx@yahoo.com[SMTP:xxxxx@yahoo.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, April 01, 2003 11:34 AM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: firewall & connection tracking>…It would be rather funny firewall if it have to ask above layered
>driver for connection details…
You are right, but if a receive a packet belong to a establish connection
i can give it to above layer without pass it through firewall rules.
Sure but firewall had to approve this connection in the past so it can store
info about it.
>…one of firewall purposes on NT is to protect TCPIP stack against
>attacks against known and uknown bugs (as ping of the death before).
In addition to firewall rules, that block only indesiderate connections, i
use an IntrusionDetectionSystem(IDS) that drop corrupts and malicious
packets.
In reguard of ping-of-death problem my goal is to use a bandwith limiter.
I thought ping-of-death problem wasn’t bandwidth but big pings fragmented
incorrect way and TCPIP crashed during defragmentation. It can be my memory
which leaks quickly…
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
>Sure but firewall had to approve this connection in the past so it can
store info about it.
Suppose i try to make a connection with a server. When i send the syn or
an output packet in general, the SO store informations about this
connession in a table. I presume these informations are source IP,
destination IP, source port, destination port and connection’s state.
When i receive the ack packet, or another type of packet, if i’m able to
access to the connection table i can verify if it belong to some
connection only compare IPs and ports.
So my question is: is possible manage “connection-tracking-table” directly
without use any TDI call?
Reguards
Luca
> ----------
From: xxxxx@yahoo.com[SMTP:xxxxx@yahoo.com]
Reply To: xxxxx@lists.osr.com
Sent: Wednesday, April 02, 2003 2:50 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: firewall & connection tracking>Sure but firewall had to approve this connection in the past so it can
>store info about it.Suppose i try to make a connection with a server. When i send the syn or
an output packet in general, the SO store informations about this
connession in a table. I presume these informations are source IP,
destination IP, source port, destination port and connection’s state.
When i receive the ack packet, or another type of packet, if i’m able to
access to the connection table i can verify if it belong to some
connection only compare IPs and ports.
So my question is: is possible manage “connection-tracking-table” directly
without use any TDI call?
Why not? Every packet is passed through your firewall so you have the same
info as TCPIP driver. Just study the RFC which Max recommended; there should
be TCP state diagram which should be enough to determine currect connection
state.
In addition, packets are usually received at DISPATCH_LEVEL which can
prohibit some TDI calls. You’d have to queue packets and use worker threads
with negative impact to communication speed.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
>Why not? Every packet is passed through your firewall so you have the
same
info as TCPIP driver. Just study the RFC which Max recommended; there
should be TCP state diagram which should be enough to determine currect
connection state.
In addition, packets are usually received at DISPATCH_LEVEL which can
prohibit some TDI calls. You’d have to queue packets and use worker
threads with negative impact to communication speed.
I know TCP state diagram and I have already written the code for UDP and
ICMP protocol too but I think is more interesting use kernel instruments.
Thanks for yuors councils
Luca
Build it yourself and forget the one created by TCP.
Max
----- Original Message -----
From: “luca”
To: “NT Developers Interest List”
Sent: Wednesday, April 02, 2003 4:50 PM
Subject: [ntdev] Re: firewall & connection tracking
> >Sure but firewall had to approve this connection in the past so it
can
> >store info about it.
>
> Suppose i try to make a connection with a server. When i send the
syn or
> an output packet in general, the SO store informations about this
> connession in a table. I presume these informations are source IP,
> destination IP, source port, destination port and connection’s
state.
> When i receive the ack packet, or another type of packet, if i’m
able to
> access to the connection table i can verify if it belong to some
> connection only compare IPs and ports.
> So my question is: is possible manage “connection-tracking-table”
directly
> without use any TDI call?
>
> Reguards
> Luca
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>
> I know TCP state diagram and I have already written the code for UDP
and
ICMP protocol too but I think is more interesting use kernel
instruments.
No.
As Michal said, the firewall must not depend on upper layer - i.e.
TCP.
Max
It will want to say that I will close myself in laboratory to write
connection tracking for my firewall…SIGH! 
Thanks to all for the precious aid!!!
Luca