Re: TODO question
On Tue, Mar 26, 2002 at 11:02:49PM +0100, -=Quequero=- wrote: > I'm sorry for these stupid questions but i need some help :PPP > > TODO file > NICE to have section > x REJECT optionally generates port unreachable with faked SOURCE > erm..._faked SOURCE_ means an icmp packet with a faked source ip? > And why it could be useful? Please read the netfilter-devel archive. There has been discussion about this before. > Ah...another stupid question :PP what does 'x' and '-' means in TODO list? > Thanx a lot to all :)) x == alrady implemented TODO item (finished) - == outstanding TODO item (needs to be implemented) > -=Quequero=- -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
Re: TPROXY and original dest address question
On Tue, Mar 26, 2002 at 04:21:04PM +0100, Balazs Scheidler wrote: > Hi, > > I found some time to get back to my transparent proxy support for Netfilter. cool. We'd really like to see this getting forward. > - TPROXY target redirects a session > > - the original destination address/port number is stored in the IPCB() part > of the skb > > - as soon as the socket is created this address/port number is copied into > sk->tp_pinfo.af_tcp (struct tcp_opt) This would happen in tcp_v4_hnd_req() > > - this information is queried by the application using a getsockopt call to > fetch the original destination address, the getsockopt can be implemented > by registering an nf_sockopt_ops > > I'd like to have the core-members advice, is this a good way? Harald? This looks fine to me, but I'm not as much into the sockets code as others are. If you want to make it really correct, I'd send that Mail to the [EMAIL PROTECTED] Mailinglist. David Miller, Andi Kleen and Alexey Kuznetsov (the networking gods) are hanging out on that list, so you might get some comments related the 'abuse' of tp_pinfo.af_tcp and IPCB() from them. Based on their reaction you will see if there is a need to change something or if they would like something like this in the kernel. > Bazsi -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
Re: Fw: Re: Profiles to patch-o-matic ?
On Tue, Mar 26, 2002 at 05:18:37PM -0300, Rodrigo Senra wrote: Oi Rodrigo, tudo bem? > Is there a way to define profiles to patch-o-matic. > I mean to define a subset of desired patches with Y as the default answer > and N to the rest and them submit it to p-o-m? you can just give the 'runme' script a list of patches. Like cd patch-o-matic ./runme pending/foo.patch extra/bar.patch base/buz.patch runme in latest CVS also has a '--batch' option which removes the necessity of piping 'y' to stdin. > I'll need this for testing purposes. Is there anybody working on this ? It's already there. > I guess it is just a matter of changing 'runme' script in order to read > a default-answers-file and used it instead of stdin. Or I could pipe > p-o-m to a Python script that would act as the user answering Y or N. yes, you can just pipe something to stdin. Shell-script is enough, no need for python. > Suggestions ? -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
Re: conntrack NAT manips
On Tue, Mar 26, 2002 at 11:23:40PM +0100, Patrick Schaaf wrote: > Hi all, > > reading the conntrack code, and thinking about optimizations (there are > plenty...), I come to this question: as implemented, the ip_nat_info field > of each conntrack contains an array of 'manips', max. 6 of them. Each manip > applies to a certain mask of hooks, and changes either the source or > destination IP address of the current skb. The changes happen as the > various hook functions in the NAT code are executed. exactly. > An alternative implementation would apply address mangling to each > individual skb exactly once. For both directions, the conntracking > structure would contain the set of changes to apply to IP and protocol > addresses, and possibly there would be a _precomputed_ checksum adjust > stored within the conntrack. That breaks a lot of things, mainly that your ruleset is nolonger able to match on the best combination of source and destination address. > Now, the "step-by-step" application in the current framework, > if I understand things correctly, is visible in the iptables > rule chains in the various tables. What I wonder about is, > how many rulesets _rely_ on such "partial modifications" of > the individual skb, and what is the purpose of that usage? It's absolutely necessarry. Where would this 'single' point in the stack be? at post_routing is too late, because the routing decision is already made. So you would need to do all nat at pre_routing. this means that you do SNAT at prerouting. So your firewall ruleset will never see the real (e.g. 192.168.x.x) address of SNATed / MASQUERADEd connections. So how do you distinguish between individual clients in your internal network? This is just the most common example, of course. Another issue: how big is the optimization? How many connections do really have SNAT and DNAT at the same time? In most cases you only have one manipulation. Precomputed checksum mangling? mmh... could be interesting - but this could be implemented with the current code as well. > best regards > Patrick -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
Re: TPROXY
On Tuesdayen den 26 March 2002 16.33, Balazs Scheidler wrote: > Providing a client certificate to the server is not very common, if it is > required a tunnel can be opened to that _specific_ server, and nothing > else. > > So using a real decrypting HTTPS proxy for general https traffic, and > opening holes to specific destinations is definitely more secure than a > simple 'pass-through' hole in the firewall. You missed the point here. Using a decryption HTTPS proxy invalidates both the use of client certificates AND the use of server certificates, which makes the use of SSL somewhat pointless. Further, unless the proxy runs it's own CA trusted by the browsers then the users will always be warned that the server certificate is invalid when using such proxy. Regards Henrik Nordström
Re: TPROXY and original dest address question
Hi, I have the intent to develop real transparent proxy support into the kernel 2.4 series (not a backport of the original 2.2 code) Since at a few places it affects network core I asked the question below on netfilter-devel and they directed me to here. Could you please comment on it? For a reference, the implementation tries to touch the networking code the least possible, so it rewrites destination addresses prior they enter the networking core. Its a simple, stateless DNAT. On Wed, Mar 27, 2002 at 08:59:01AM +0100, Harald Welte wrote: > On Tue, Mar 26, 2002 at 04:21:04PM +0100, Balazs Scheidler wrote: > > Hi, > > > > I found some time to get back to my transparent proxy support for Netfilter. > > cool. We'd really like to see this getting forward. > > > - TPROXY target redirects a session > > > > - the original destination address/port number is stored in the IPCB() part > > of the skb > > > > - as soon as the socket is created this address/port number is copied into > > sk->tp_pinfo.af_tcp (struct tcp_opt) This would happen in tcp_v4_hnd_req() > > > > - this information is queried by the application using a getsockopt call to > > fetch the original destination address, the getsockopt can be implemented > > by registering an nf_sockopt_ops > > > > I'd like to have the core-members advice, is this a good way? Harald? > > This looks fine to me, but I'm not as much into the sockets code as others > are. > > If you want to make it really correct, I'd send that Mail to > the [EMAIL PROTECTED] Mailinglist. > > David Miller, Andi Kleen and Alexey Kuznetsov (the networking gods) are hanging > out on that list, so you might get some comments related the 'abuse' of > tp_pinfo.af_tcp and IPCB() from them. > > Based on their reaction you will see if there is a need to change something > or if they would like something like this in the kernel. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: conntrack NAT manips
> > An alternative implementation would apply address mangling to each > > individual skb exactly once. For both directions, the conntracking > > structure would contain the set of changes to apply to IP and protocol > > addresses, and possibly there would be a _precomputed_ checksum adjust > > stored within the conntrack. > > That breaks a lot of things, mainly that your ruleset is nolonger able > to match on the best combination of source and destination address. I am aware that this would break things. As I'm not using NAT myself in the real world (except for REDIRECT), I want to hear real world uses of that distinction, so I can think about what's really needed. > > Now, the "step-by-step" application in the current framework, > > if I understand things correctly, is visible in the iptables > > rule chains in the various tables. What I wonder about is, > > how many rulesets _rely_ on such "partial modifications" of > > the individual skb, and what is the purpose of that usage? > > It's absolutely necessarry. Where would this 'single' point in the stack > be? at post_routing is too late, because the routing decision is already > made. So you would need to do all nat at pre_routing. Yes, that's the basic idea. > this means that you do SNAT at prerouting. So your firewall ruleset will never > see the real (e.g. 192.168.x.x) address of SNATed / MASQUERADEd connections. The prerouting operation _could_ be split into a PRE-MANGLE and POST-MANGLE part, with the NAT operation seen as yet another mangling. > Another issue: how big is the optimization? How many connections do > really have SNAT and DNAT at the same time? In most cases you only > have one manipulation. That's the main reason for me thinking about the thing. We currently have 6 manip[] structures in each conntrack, and use 0 of them most of the time (for non-NATted connections), and 1 of them almost all of the rest of the time. For combined SNAT/DNAT we would need 2. We have 6, one for each of 3 different hooks. It's the latter I call into question here. > Precomputed checksum mangling? mmh... could be interesting - but this > could be implemented with the current code as well. Sure, store the checksum delta along with the manips. Makes the 6 of them still a bit larger, but if would help... However, I doubt that it would help that much. The current per-packet incremental checksum computation does not dominate the conntrack operation. best regards Patrick
Re: Fw: Re: Profiles to patch-o-matic ?
The runme patch I sent a few days ago sort of allows you to do this. Regards Henrik Nordström MARA Systems AB, Sweden On Tuesdayen den 26 March 2002 21.18, Rodrigo Senra wrote: > Is there a way to define profiles to patch-o-matic. > I mean to define a subset of desired patches with Y as the default > answer and N to the rest and them submit it to p-o-m? > > I'll need this for testing purposes. Is there anybody working on this ? > > I guess it is just a matter of changing 'runme' script in order to read > a default-answers-file and used it instead of stdin. Or I could pipe > p-o-m to a Python script that would act as the user answering Y or N. > > Suggestions ?
Re: TPROXY
On Wed, Mar 27, 2002 at 10:15:56AM +0100, Henrik Nordstrom wrote: > On Tuesdayen den 26 March 2002 16.33, Balazs Scheidler wrote: > > > Providing a client certificate to the server is not very common, if it is > > required a tunnel can be opened to that _specific_ server, and nothing > > else. > > > > So using a real decrypting HTTPS proxy for general https traffic, and > > opening holes to specific destinations is definitely more secure than a > > simple 'pass-through' hole in the firewall. > > You missed the point here. Using a decryption HTTPS proxy invalidates both > the use of client certificates AND the use of server certificates, which > makes the use of SSL somewhat pointless. Further, unless the proxy runs it's > own CA trusted by the browsers then the users will always be warned that the > server certificate is invalid when using such proxy. I think you missed the point here. Of course the firewall verifies the server's certificate using its own trusted list of CAs. The user is not capable of deciding whether a certificate presented to him really belongs to the given server. They simply press 'continue' without thinking that the server they are communicating with is fake. Of course if you AND your users know what the hell a certificate is, they can decide but I think you are a minority. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: BUG: max number of expected connections
On 27 Mar 2002, Frank wrote: > kernel: ip_conntrack: max number of expected connections 1 of ftp > reached for 195.211.47.154->80.129.111.208, reusing > > appeared in my Syslog Today. Using CVS Version from March 23 and Kernel > 2.4.18-pre3-ac5 after 3 Days uptime. Reloaded my Iptables Script and > everything works fine. >From this info, I can't say it is a bug in newnat. It might easily be a bug in the FTP client. Do you know what kind of FTP session was it? What kind of client was used? Regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
Re: TPROXY and original dest address question
Please don't forget UDP. For UDP you need to save the original destination, and then implement a control message extension for sending this to userspace together with the packet in response to a recvmsg() call, or hack the kernel to return the original destination in IP_PKTINFO (would be the most natural I think). See earlier post from me for a lengthy discussion on how one can do this in the current NAT scheme. If you same the address in the actual skb then this becomes even easier. In case of IP_PKTINFO only only two lines.. Reviewing the existing sockopt options the following seems like the correct calls: * For TCP, return the original destination in getsockopt(SOL_IP, IP_PKTOPTIONS...) * For UCP, return the original destination in the IP_PKTINFO recvmsg control message, and if possible, use the same to allow the application to control the source address when sending packets using sendmsg(). What I do not quite get is how TPROXY is supposed to handle return traffic, fragmented packets or ICMP, if you are doing stateless NAT. Also, who is responsible for making sure the application protocol is NAT:ed properly in TPROXY. For example FTP PASV. Is it the kernel, or is it the userspace proxy responsibility to get the correct (foreign) IP address in such case? And what about "related" connections such as an FTP data channel? Sorry if I am making things overly complex here.. In my view (as an application developer, not netfilter hacker) the problems with the standard netfilter approach are: 1. Cannot easily support non-local bind, to allow the userspace proxy application to masquerade as the client 2. Cannot get the original destination of a redirected UDP packet in an easy manner (might be possible by parsing /proc/net/ip_conntrack and quess which is the correct "connection"...) 3. conntrack adds yet another state table, with a bunch of new DOS conditions one must worry about.. Regards Henrik
Re: TPROXY and original dest address question
On Wed, Mar 27, 2002 at 02:56:56PM +0100, Henrik Nordstrom wrote: > Please don't forget UDP. I won't. I definitely want UDP as well. > > For UDP you need to save the original destination, and then implement a > control message extension for sending this to userspace together with the > packet in response to a recvmsg() call, or hack the kernel to return the > original destination in IP_PKTINFO (would be the most natural I think). > > See earlier post from me for a lengthy discussion on how one can do this in > the current NAT scheme. If you same the address in the actual skb then this > becomes even easier. In case of IP_PKTINFO only only two lines.. > > Reviewing the existing sockopt options the following seems like the correct > calls: > > * For TCP, return the original destination in getsockopt(SOL_IP, > IP_PKTOPTIONS...) > > * For UCP, return the original destination in the IP_PKTINFO recvmsg control > message, and if possible, use the same to allow the application to control > the source address when sending packets using sendmsg(). ok. I originally wanted to have separate getsockopt calls, but it's better to use already established ones. The only possible problem that I need to tocuh the networking core which I want to avoid touching. > What I do not quite get is how TPROXY is supposed to handle return traffic, > fragmented packets or ICMP, if you are doing stateless NAT. It doesn't handle currently any of them. Fragmentation can be solved by defragmenting incoming packets. (they are destined to the local ip stack anyway) ICMP can be handled in the prerouting hook looking up possible transparent proxy entries. > Also, who is responsible for making sure the application protocol is NAT:ed > properly in TPROXY. For example FTP PASV. Is it the kernel, or is it the > userspace proxy responsibility to get the correct (foreign) IP address in > such case? And what about "related" connections such as an FTP data channel? Of course the proxy itself. How it currently works in Zorp (with kernel 2.2): * the FTP command channel is redirected to the proxy * when a PASV command is sent, a non-local bind is performed to bind to the server's IP & random port * the PASV reply is rewritten to contain information about the allocated port * the data channel is established when the client connects to the socket the firewall allocated * the connection to the server is then established by the proxy > > Sorry if I am making things overly complex here.. > > In my view (as an application developer, not netfilter hacker) the problems > with the standard netfilter approach are: > > 1. Cannot easily support non-local bind, to allow the userspace proxy > application to masquerade as the client > > 2. Cannot get the original destination of a redirected UDP packet in an easy > manner (might be possible by parsing /proc/net/ip_conntrack and quess which > is the correct "connection"...) > > 3. conntrack adds yet another state table, with a bunch of new DOS > conditions one must worry about.. conntrack will not be involved in TPROXY, though I want them to interoperate. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: TPROXY
On Wed, Mar 27, 2002 at 04:17:53PM +0100, Jean-Michel Hemstedt wrote: > > > On Tuesdayen den 26 March 2002 16.33, Balazs Scheidler wrote: > > The user is not capable of deciding whether a certificate presented to him > > really belongs to the given server. They simply press 'continue' without > > thinking that the server they are communicating with is fake. > > > > Of course if you AND your users know what the hell a certificate is, they > > can decide but I think you are a minority. > > > > We are far from TPROXY, but here is my point of view: > > - HTTPS decrypting proxy is an (mitma) alternative if you want > to block all "CONNECT" operations in your proxy. But it sounds > like an absuse protection against inside users. And unfortunately, > for the user itself, as mentionned above, it will block services > such as home banking as well. * If you allow HTTPS transparently, CONNECT is not invoked. * If you use a non-transparent HTTP proxy, the client requests a CONNECT from the proxy which in turn connects to the web server opening a hole in your firewall. You have three options: 1) enable SSL traffic without being able to verify its contents (Nimda through SSL anyone?) 2) disable SSL completely 3) use a decrypting SSL proxy with content verification > > - If your proxy allows "CONNECT" requests, then virtually anything > can pass through it, and HTTPS decrypting proxy does not make sense. why? I attach a decrypting HTTPS proxy when a CONNECT request is encountered, as follows: * Nontransparent HTTP proxy receives a CONNECT www.homebank.hu:443 HTTP/1.0 request * Http proxy stacks in an SSL proxy which receives the datastream after CONNECT * The SSL proxy decrypts traffic and stacks in a HTTP proxy again: [nontransparent HTTP proxy] | [decrypting SSL proxy invoked after CONNECT] | [stacked transparent HTTP proxy] The above scenario is completely doable with Zorp. > Then, if you are really concerned by insider attacks, what about a > session/tunnel timer which could be a possible (ugly) protection > against wormhole kinds of attacks, without invalidating ssl? IMHO it's not about insider attacks, its about incompetent clients who start trojan horses, get viruses and accept certificates without even knowing what it means. Decrypting on the firewall is not invalidating SSL. SSL is authentication+integrity protection+crypted traffic. Authentication is performed by the firewall, integrity protection is performed and the whole traffic is crypted. Authentication is moved from the client computer to the firewall, which checks it more strictly than most clients do. And the firewall accepts a certificate based on its policy. No user should override this. Of course when moving the certificate authentication is not an option (because client certificates are used, which are stored on a hardware token), you can still use a 'hole', but this can be limited to a few addresses only. btw: I think this discussion is off-topic on netfilter-devel, so we might continue our discussion in private. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: TPROXY
> On Wed, Mar 27, 2002 at 10:15:56AM +0100, Henrik Nordstrom wrote: > > On Tuesdayen den 26 March 2002 16.33, Balazs Scheidler wrote: > > > > > Providing a client certificate to the server is not very common, if it is > > > required a tunnel can be opened to that _specific_ server, and nothing > > > else. > > > > > > So using a real decrypting HTTPS proxy for general https traffic, and > > > opening holes to specific destinations is definitely more secure than a > > > simple 'pass-through' hole in the firewall. > > > > You missed the point here. Using a decryption HTTPS proxy invalidates both > > the use of client certificates AND the use of server certificates, which > > makes the use of SSL somewhat pointless. Further, unless the proxy runs it's > > own CA trusted by the browsers then the users will always be warned that the > > server certificate is invalid when using such proxy. > > I think you missed the point here. Of course the firewall verifies the > server's certificate using its own trusted list of CAs. > > The user is not capable of deciding whether a certificate presented to him > really belongs to the given server. They simply press 'continue' without > thinking that the server they are communicating with is fake. > > Of course if you AND your users know what the hell a certificate is, they > can decide but I think you are a minority. > We are far from TPROXY, but here is my point of view: - HTTPS decrypting proxy is an (mitma) alternative if you want to block all "CONNECT" operations in your proxy. But it sounds like an absuse protection against inside users. And unfortunately, for the user itself, as mentionned above, it will block services such as home banking as well. - If your proxy allows "CONNECT" requests, then virtually anything can pass through it, and HTTPS decrypting proxy does not make sense. Then, if you are really concerned by insider attacks, what about a session/tunnel timer which could be a possible (ugly) protection against wormhole kinds of attacks, without invalidating ssl? -jmhe-
Re: TPROXY
On Wednesdayen den 27 March 2002 16.17, Jean-Michel Hemstedt wrote: > - If your proxy allows "CONNECT" requests, then virtually anything > can pass through it, and HTTPS decrypting proxy does not make sense. A proxy can in theory verify that the supposedly SSL stream looks like a SSL stream and not something else.. The SSL and TLS data streams are quite structured. But a proxy cannot and must not decrypt or alter the SSL traffic. A "decrypting proxy" would of course intercept the CONNECT requests as SSL. > Then, if you are really concerned by insider attacks, what about a > session/tunnel timer which could be a possible (ugly) protection > against wormhole kinds of attacks, without invalidating ssl? Fact 1: If there is as much as a 1 bit communication channel (or even less if quantifiable), then this can be abused to build tunnels if you can place equipment on both sides. Fact 2: Valid use of SSL can be quite lengthy. For example a web application refreshing the display once each 5 minutes or so can easily keep a persistent connection open all the time. In my view the only acceptable use of a decrypting "SSL proxy" is if an organisation have a policy whereby all transmitted data must be logged or inspected upon leaving the organisation. In such policy the user would not (by the policy) be allowed at all to use encrypted SSL services without surrending the encryption to the organisation. In such case the "decrypting SSL proxy" is providing the service to reach https:// sites from within the organisation, not the use of SSL. Technically the term "SSL proxy" for this kind of service is quite misleading. "SSL or https gateway" is a better description. Not that this really has anything to do netfilter development or the TPROXY feature as such.. this is my las post on this thread. Regards Henrik Nordström
Re: TPROXY and original dest address question
On Wednesday 27 March 2002 16.17, Jean-Michel Hemstedt wrote: > - If your proxy allows "CONNECT" requests, then virtually anything > can pass through it, and HTTPS decrypting proxy does not make sense. A proxy can in theory verify that the supposedly SSL stream looks like a SSL stream and not something else.. The SSL and TLS data streams are quite structured. > It doesn't handle currently any of them. Fragmentation can be solved by > defragmenting incoming packets. (they are destined to the local ip stack > anyway) Defragmentation is defenitely needed for this thing to be used in production. For experimentation conntrack can be used to defragment.. > ICMP can be handled in the prerouting hook looking up possible transparent > proxy entries. Where is the "possible transparent proxy entries" defined? Internally in TPROXY, or in the host IP stack socket table? I guess this would be the rule table telling what should be diverted by TPROXY, which from my understanding would be your iptables ruleset... > > Also, who is responsible for making sure the application protocol is > > NAT:ed properly in TPROXY. > > Of course the proxy itself. Good. > conntrack will not be involved in TPROXY, though I want them to > interoperate. Of course. Just mentioned it as a reference on why I see that one cannot really use netfilter NAT for truly transparent proxying as it is today. Regards Henrik
Re: Request for a Beginning in libiptc and libipq
Well Sumit and Developers Let me explain well my questions: In the tutorials of iptables The packet goes through the different steps in the following fashion: see the comments Step Table Chain Comment 1 On the wire(internet) 2 Comes in on the interface(eth1) 3 mangle PREROUTING Here i cant use the QUEUE for analysis 4 nat PREROUTING 5 6 filter FORWARD Here go to the QUEUE for analysis if ACCEPT or DROP 7 nat POSTROUTING 8 Goes out on the outgoing interface ( eth2 ). 9 Out on the wire again (LAN or anothe computer ). The program i have it catch the packets that come from eth1 and go to the QUEUE , compare the IP of packet with a file with IPs direction and DROP or ACCEPT the packet , for it go to the eth2 my question are: 1.- Can i use libiptc or another lib or *.h for enable the ip_queue without the common script [root]#modprobe iptable_filter [root]#modprobe ip_queue i found int internet this but i can't do working for problems in compilation 2.- Can I use libiptc or another lib or *.h for manipulate the packet and compare with a file with IP's and enable go to the QUEUE without scripts below, for example: iptables -I FORWARD -j QUEUE or iptables -t mangle -I PREROUTING -j QUEUE 3.- Why using table "mangle" for sent the packet to the QUEUE in PREROUTING the catch of the packet is more fast than using the QUEUE in the table "filter" in FORWARD 4.- In the HOW-TO hacking-netfilter i read some functionality using KERNEL function for add rules i read this but How can I do ? The objective of this, is for using only one program to enable ip_queue and add or remove new rules in the tables mangle or filter without scripts so, Please help me, answer me this question or explain me another good idea for build it in only one program all this. Thank you for help a this begining in netfilter with iptables 1.2.5 Paul Villacreses - Original Message - From: "Sumit Pandya" <[EMAIL PROTECTED]> To: "PAUL FABRICIO VILLACRESES LEON" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, March 26, 2002 9:29 PM Subject: RE: Request for a Beginning in libiptc and libipq > -Original Message- > From: PAUL FABRICIO VILLACRESES LEON > [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 10:58 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Request for a Beginning in libiptc and libipq > > > >> I have a program using libipq gived for Sumit and work good(Thank you) > but a > So Cheers... ;-) > >> want to catch the packets before it going to QUEUE for analisys and > enable > >> the ip_queue in a c program, i know that using the shared library of > >> iptables.c and libiptc.h but again i didn't find an example c program > using > >> this libiptc. and enable the ip_queue. > I'm confused with what you wana say and achieved by this. QUEUE is > basically to take action on packet in user-space. Are you boather of > unnecessary traversal of your packets to user-space(QUEUE)? If it's so then, > there are so many "match extensions" you can take help of them to > selectively traverse your packets into user-space. Finally GOD of all these > "match-extensions" is "string". > Hope This helps, > -- Sumit > >
