Re: Netfilter and Dynamic DNS
On Fri, Mar 29, 2002 at 11:37:55PM -0600, Mark Rinaudo (rr) wrote:
> I was wondering if anyone has seen an extension to netfilter to allow
> the use of dynamic dns names as sources in the filter table.
There is none right now.
> This would allow people with dynamic dns to be ACCEPT ed or DENY ed in
> with a rule that would periodically
> update its self as the client changed ip addresses.
Yes. That would be possible. It would also be probably vetoed on the basis
of putting a DNS resolver into the kernel. It does not belong there.
Some time ago, I suggested a solution where a user level process
does the DNS lookups periodically, and tells the kernel if things
change. I can provide the kernel part for that to work. To date,
nobody has stepped up and said he'd do the userlevel part. I won't,
and I won't start on the kernel part before I see the userlevel thing.
> I'm not sure if there is any security risk with this
There is. Your ruleset now relies on information dynamically modified
from an external source. That external source is now a "configuration knob"
for your firewall, lessening its security.
> or not but I sure could use something like this and would be interested
> in attempting an extension to do it IF someone else isn't already working
> on this idea.
Good to hear. Here's roughly what I want you to do:
- write a user level daemon
- have it read a config file which lists one DNS name per line,
or something like that
- have it query DNS for those names, and re-query according to
the TTL of the replies
- the DNS reply will, in general, consist of a list of A records.
Let's imagine you put the addresses into an array of 32 bit
addresses, array called dns_addr[], with the number of entries
in nr_dns_addr.
- call a function like this when you have made a lookup and got
some results:
set_dns_pool("www.something.com", nr_dns_addr, dns_addr);
- in iptables rules, use
iptables -A FORWARD -m pool --srcpool www.something.com -j BLA
I can provide you with a working set_dns_pool() function and kernel part,
if you give me the user level stuff.
Deal?
best regards
Patrick
[Q]I'd like to know how to nat...in nat module...
Hi...
How about your weekend^^ I wish you're in good time..
I'm now making xdmcp module for netfilter...
In ip_nat_xdmcp,
I'd like to masquerade like this...
I know the source ip and destination(masq server) ip and port..
If the source ip and masq ip & port are matched, I'd like to relay to real destination
& port
It's a tcp connection...
I've tried to do thisbut it failed..
In helper of ip_nat_xdmcp module...
After I know the source ip and masq port and real destination & port...,
I registered expect_realted packet using
--
newip = ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.ip;
/* Expect something from server->client */
tuple.src.ip = ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.ip;
tuple.dst.ip = ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.ip;
port = ct_xdmcp_info->port;
tuple.dst.protonum = IPPROTO_TCP;
tuple.dst.u.tcp.port = htons(port);
DEBUGP("%u.%u.%u.%u -> %u.%u.%u.%u :port %u related\n",
NIPQUAD(tuple.src.ip), NIPQUAD(tuple.dst.ip), port);
ip_conntrack_expect_related(ct, &tuple, &mask, NULL);
---
Is it right? it's for "from tuple src ip to tuple dst ip and dst port ,TCP connection"
After that...
In xdmcp_nat_expected function...
mr.rangesize = 1;
/* We don't want to manip the per-protocol, just the IPs... */
mr.range[0].flags = IP_NAT_RANGE_MAP_IPS;
mr.range[0].min_ip = mr.range[0].max_ip = newip;
/* ... unless we're doing a MANIP_DST, in which case, make
sure we map to the correct port */
if (HOOK2MANIP(hooknum) == IP_NAT_MANIP_DST) {
mr.range[0].flags |= IP_NAT_RANGE_PROTO_SPECIFIED;
mr.range[0].min = mr.range[0].max
= ((union ip_conntrack_manip_proto)
// { htons(xdmcpinfo->port) });
{ htons(6002) });
}
*verdict = ip_nat_setup_info(ct, &mr, hooknum);
-
But it's not working...
Please help me...if you know something..
In short, I'd like to make this working..
If some source ip, any port tried to connect masq ip and special port(I knew it
already)
forwarding to real dst ip and one port (I knew also)...
--
---
source ip masq ip
real dst ip
any port >6099(one port)
-> 6002(one port)
--
---
Thanks
Netfilter and Dynamic DNS
I was wondering if anyone has seen an extension to netfilter to allow the use of dynamic dns names as sources in the filter table. This would allow people with dynamic dns to be ACCEPT ed or DENY ed in with a rule that would periodically update its self as the client changed ip addresses. I'm not sure if there is any security risk with this or not but I sure could use something like this and would be interested in attempting an extension to do it IF someone else isn't already working on this idea. Thanks Mark Rinaudo
Re: Spare time - log-level
On Fri, Mar 29, 2002 at 02:05:18PM +0100, Bart Theunissen wrote: > Hi, > > I have some spare time and I want to contribute to the netfilter > project. I saw on the TODO list that the 'log-level save/restore' needs > some investigation. That seems like a good opportunity to get familiar > with the netfilter code. Can someone give me a bit more info about what > is going wrong with the 'log-level save/restore' ? First of all, thanks for the willingness to support the netfilter/iptables project. I'm not sure if this TDOO item is still valid. To investigate: Try to insert -j LOG rules with different numerically and string --log-level parameter. Then use iptables-save > file iptables-restore < file and see if the rules are restored correctly. > Greets, > Bart -- 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: [PATCH] add --reject-with tcp-synack to REJECT
On Fri, Mar 29, 2002 at 09:32:29AM +0100, Patrick Schaaf wrote: > > This will leave incoming connections in the ESTABLISHED state on the > > remote side, significantly slowing down Code Red or Nimda-style scans > > of the entire IP space, > > Yeah. And significantly slowing down Code Red requests through unsuspecting > proxies, bringing down the proxies, potentially. IOW: antisocial if used > on the Internet. > > Having over 150 proxies serving several million narrowband internet users, > I can tell you that I really hate that proposal. We handle it, heuristically, > but it's awful. And don't tell me I should disinfect the clients. That sucks. > > I feel this to be a dangerous option, and would protest inclusion into > the base kernel (protest shortly, that is, and with no authority at all :-) I totally agree with you. I refuse to include this extension into the iptables package - not even into the patch-o-matic 'broken' repository. This is a plain 'quality of implementation issue'. I don't want any code officially distributed as part of the linux firewalling subsystem behave in this antisocial way. > 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 and original dest address question
Balazs Scheidler wrote: > Hmm... this is a real problem, but I only see this occuring in our case > when we redirect a session, and responses must be de-NATed. In this case > however skb->sk is unique (except for maybe SYN-ACK, because socket is not > created until the three-way handshake is fully completed) There will in no doubt be a couple of corner cases where one has to guess a little based on the TPROXY table. * Concurrent SYN-ACK from two different destinations to the same client IP,PORT. * As above, but locally generated TCP RST on initial SYN or ACK (port closed, rejected, or syn backlog overflow and set to reset on overflow) * RST from the client in response to SYN-ACK. for example in case spoofed SYN. Maybe this can be ignored but you must then expire not fully connected TPROXY sessions (not having a local socket). * ICMP "port unreachable" on closed UDP sockets. And I am not sure about skb->sk in case of TCP RST when the application kills a socket (socket closed with data in the receive queue, and no linger). Regards Henrik
TPROXY, picking up the source address for UDP
Hi, Another problem I popped into while figuring out how to set the outgoing source address for UDP frames. In Linux 2.2 UDP sending with specified source address worked on a frame by frame basis, and I would like to keep this behaviour. An aux message would be used in sendmsg() to specify the outgoing source address of a packet. My problem is that it is quite difficult to change the source ip of the skb based on an aux message. In the kernel it works as follows: 1) udp_sendmsg is called 2) which in turn calls ip_cmsg_send, which sets up an ipcm_cookie struct 3) this struct is then passed to ip_build_xmit(), which sets up the skb based on ipcm My problem is that to attach create a new cmsg, I'd need to modify the cmsg_cookie struct as it is the only connection between the skb and sendmsg(), and in addition ip_build_xmit() must also be changed as this is the one which processes messages. An alternative way would be add a translation entry about the required change to the TPROXY translation table. The problem with this that adding the entry, sending a single frame, and removing the entry doesn't seem to be very atomic to me. (the only possibility here would be to create a flag assigned to the translation entry, saying that this entry is applied only once => but this might cause problems on SMP, as two processes might be issuing sendmsg() calls at the same time) Opinions? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Spare time - log-level
Hi, I have some spare time and I want to contribute to the netfilter project. I saw on the TODO list that the 'log-level save/restore' needs some investigation. That seems like a good opportunity to get familiar with the netfilter code. Can someone give me a bit more info about what is going wrong with the 'log-level save/restore' ? Greets, Bart
Re: TPROXY and original dest address question
On Thu, Mar 28, 2002 at 05:55:25PM +0100, Henrik Nordstrom wrote: > > an entry is removed from this table when > > > > 1) the socket associated with the entry is destroyed (iff a socket is > >associated with an entry) > > Ok. So there is integration between the tproxy table and the host IP stack > somehow, to keep the TPROXY table in sync with the host IP stack. Nice. Kind > of missing in conntrack.. Until now the only binding between the socket and the entry was the address of the local socket. This might have to be changed due to the problem you described below. > > 2) when a TCP rst is returned by the stack (happens only when a socket is > >not yet associated) > > Why this? And doesn't it allow for an easy DOS on TPROXY sessions? > > You should not be processing RST unless you are also processing TCP widows. > Not all RST packets resets "the" session. > > Ah, I think I understand now. You only do this when there isn't yet a socket > in the host IP stack. In such case it is needed. yes, an alternative would be a hook in the kernel which is called when a socket was not found to an incoming SYN. this is an ugly hack though. > Sounds like it could be made to work for TCP. > > UDP is a bit different thou.. but there isn't that big need of a any > connection table there, except for ICMP processing. For UDP I only want to do half-NAT, which means that it would be possible to send a UDP frame with a custom IP address, and receive one destined to somebody else. ICMP processing is needed when we send an UDP frame (with foreign source address), and the destination host returns an ICMP error to the sender. In Linux 2.2 we do the following as a transparent proxy with UDP traffic: * we have a sender socket, which we use to send packets with specified source AND destination address * prior to sending a packet we create, bind and connect a socket to a destination we are sending packets to (this socket receives ICMP errors) A similar approach is doable: * the source address is specified in a control message of sendmsg() * this doesn't create a translation entry in TPROXY * a separate socket is created, and a setsockopt is issued, which places socket related information into the translation table * when an ICMP error is received, the second socket is found, and ICMP error is rewritten accordingly * if no specific socket is found, it is forwarded (and dropped on the forward chain) > > Hmm.. regarding ICMP. How do you plan on handle ICMP from the host stack > without TCP window tracking? > > Problem: There may be multiple sessions from the same client IP,PORT to the > same PORT on multiple servers, and after NAT there isn't sufficient > information to distinguish these by the addressing alone. > > 10.0.1.4:52346 -> 192.168.96.32:80 > 10.0.1.4:52346 -> 192.168.84.253:80 > 10.0.1.4:52346 -> 176.16.48.52:80 > > The problem is much more evident if you look at UDP traffic, but exists for > TCP as well. For TCP you can easily see this if there is multiple clients > behind a NAT gateway (for example netfilter SNAT). > > Hmm.. this problem probably also applies to the de-NAT:ing of traffic, but > there you can probably get by by querying the socket for the real source > address (original destination address). Hmm... this is a real problem, but I only see this occuring in our case when we redirect a session, and responses must be de-NATed. In this case however skb->sk is unique (except for maybe SYN-ACK, because socket is not created until the three-way handshake is fully completed) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: Strange Contracker problem in conjuction with Cisco Content Switch
On Fri, Mar 29, 2002 at 09:59:58AM +0100, Harald Welte wrote: > > > b) Why does it occure primarily with the Cisco Content Switch. The > > numbers were much lower > >before utilising the content switch! So the CSS is ACK flooding! Is > > there a strange > >interaction between the CSS and netfilter? > > I have no Idea. I don't even know the Cisco product you are talking about. Harald, if your suspicion about ACK storms (externally triggered by some random attacker) are correct, then the CSS may have nothing to do with it, except having been in operation only when a stronger / longer ACK storm was active. In other words: a mere coincidence. The Cisco Content Switch is a glorified LocalDirector, as fas as I know. The usual per-TCP-connection loadbalancing, similar to linuxvirtualserver.org. We have the "sister product", IOS SLB on Catalyst 6xxx switches (also Cisco), in operation against a large number of conntracking servers, and no specific problems due to SLB or conntracking on the servers. best regards Patrick
Re: Strange Contracker problem in conjuction with Cisco Content Switch
On Fri, Mar 29, 2002 at 09:07:54AM +0100, Martin Sperl wrote: > Hi! > > Two questions regardin this strange effect: > a) Is there a performance penalty for this huge number of connections in > contracker? not if you widen the hash table (see list archive on discussions about that). > b) Why does it occure primarily with the Cisco Content Switch. The > numbers were much lower >before utilising the content switch! So the CSS is ACK flooding! Is > there a strange >interaction between the CSS and netfilter? I have no Idea. I don't even know the Cisco product you are talking about. > Cheers, > Martin -- 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: BUG: max number of expected connections
On 28 Mar 2002, Frank wrote: > and this BUG appeared again today but with Kernel 2.4.19-pre4-ac2 and > Iptables CVS from 27.03.02. Applied all pending-patches cleanly but > newnat would so i forced it and compiled fine. Still, there is no proof that this is a bug. > Mar 28 01:26:32 Frankux kernel: ip_conntrack: max number of expected > connections 1 of ftp reached for 192.168.0.1->192.168.0.12, reusing Such message may appear when the FTP client requests a new data channel without opening the previously requested one. There is one case, when it happens quite naturally: client sends an active FTP request, but the server refuses it. Then the client reverts to passive FTP and repeats the data channel request. A tcpdump of the FTP command session could help to find out where's the problem. 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: [PATCH] add --reject-with tcp-synack to REJECT
> This will leave incoming connections in the ESTABLISHED state on the > remote side, significantly slowing down Code Red or Nimda-style scans > of the entire IP space, Yeah. And significantly slowing down Code Red requests through unsuspecting proxies, bringing down the proxies, potentially. IOW: antisocial if used on the Internet. Having over 150 proxies serving several million narrowband internet users, I can tell you that I really hate that proposal. We handle it, heuristically, but it's awful. And don't tell me I should disinfect the clients. That sucks. I feel this to be a dangerous option, and would protest inclusion into the base kernel (protest shortly, that is, and with no authority at all :-) best regards Patrick
Re: Strange Contracker problem in conjuction with Cisco Content Switch
> Two questions regardin this strange effect: > a) Is there a performance penalty for this huge number of connections in > contracker? Yes. This has been discussed, with possible remedies (hashsize parameter to ip_conntrack) mentioned, about a week ago. See the thread at http://marc.theaimsgroup.com/?l=netfilter-devel&m=101652012506915&w=2 > b) Why does it occure primarily with the Cisco Content Switch. We cannot tell. Only a trace analyzed will be able to tell. best regards Patrick
