hrmm, iptables -A vs. iptables-restore
hrmm, interesting question this would it be faster to reload say about 100 rule tables one by one when needed, or push all the firewall tables/rules (say bout 20,000 rules) with iptables-restore at one time? i have a firewall script which can say reload SNAT or DNAT tables without clearing the entire firewall, and reload certain rules aswell. i would just like to know if it would be better to push the entire 20k rule firewall in at the same time with 1 iptables-restore command? Regards Nigel Kukard (General Manager)
Re: [PATCH] ipv6header fix
On Mon, Mar 25, 2002 at 12:18:00AM +0100, Andras Kis-Szabo wrote:
Hi,
there's a patch to the ipv6header match module.
(I handled the skb structure in a wrong way)
[in debug mode with the tcpreplay6 is a very usefull thing :)]
++if 0
++ for (temp=0;tempskb-len;temp++){
++ if (!(temp % 16 )) DEBUGP(\nipv6_header data );
++ DEBUGP(%02X ,skb-data[temp]);
++ }
++endif
Those preprocessor macros do actually need '#' in front of them.
Already fixed in CVS.
Regards,
kisza
--
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
Hallo 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. 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 Mar 28 11:42:00 Frankux kernel: ip_conntrack: max number of expected connections 1 of ftp reached for 195.211.47.154-80.129.122.220, reusing Am Mit, 2002-03-27 um 14.20 schrieb Frank: On 27 Mar 2002, Jozsef 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? Im using Proftp 1.25rc1 and the Client was any Windows FTP Client. Look at the Time. 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:02 +0100] STOR 1. Planet Earth (The mavis´s).mp3 226 4200362 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:02 +0100] LIST -a 226 294 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:02 +0100] PWD 257 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:12 +0100] CWD /upload/UnDone (Australien 1999) 250 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:13 +0100] DELE 10. Careless memories (Area 7).mp3 550 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:13 +0100] LIST -a 226 294 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:13 +0100] PWD 257 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:23 +0100] CWD /upload/UnDone (Australien 1999) 250 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:23 +0100] DELE 10. Careless memories (Area 7).mp3 550 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:23 +0100] LIST -a 226 294 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:52:23 +0100] PWD 257 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:08 +0100] CWD /upload/UnDone (Australien 1999) 250 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:08 +0100] STOR 10. Careless memories (Area 7).mp3 550 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:08 +0100] LIST -a 226 294 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:08 +0100] PWD 257 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:45 +0100] CWD /upload/UnDone (Australien 1999) 250 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:45 +0100] CWD /upload/UnDone (Australien 1999)/.. 250 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:45 +0100] LIST -a 226 495 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:45 +0100] PWD 257 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:51 +0100] CWD /upload 250 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:51 +0100] CWD /upload/UnDone (Australien 1999) 250 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:51 +0100] LIST -a 226 294 195.211.47.154 UNKNOWN duran [26/Mar/2002:21:54:51 +0100] PWD 257 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:22:00:32 +0100] CWD /upload/UnDone (Australien 1999) 250 - 195.211.47.154 UNKNOWN duran [26/Mar/2002:22:01:26 +0100] STOR 11. Save a prayer (Pollyanna).mp3 226 4962302 and here the appeareance in the Syslog Mar 26 21:54:08 Frankux kernel: ip_conntrack: max number of expected connections 1 of ftp reached for 195.211.47.154-80.129.111.208, reusing -- Frank
Re: TPROXY and original dest address question
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.. In my previous attempts to forward port the transparent proxy features of 2.2, I simply used ip_defrag(skb), which returned non-NULL when a full fragment was reassembled. 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? in TPROXY. I guess this would be the rule table telling what should be diverted by TPROXY, which from my understanding would be your iptables ruleset... No. I have -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
RE: Request for a Beginning in libiptc and libipq
Hi Paul, I'm still not sure why you wanted to automate such process at kernel level. But Its really an interesting thought. Ya It took a little long time to move on your problem, but I've a hope to achieve this. You know me too usually take interest in such adventures, so I took you personally ;-) Anyway from your description I'd define your goal as Making System Calls from Kernel Space. I got this idea by khttpd module of kernel, and I got same deal on Internet from website of very popular Linux Identity Alessandro Rubini. Just go through his guide on link http://www.linux.it/kerneldocs/ksys/ksys.html. 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 To achieve this you require to write your own Target for netfilter, like ACECPT,REJECT,... Easiest to look into target TOS. 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. It depends on which traffic you wanted to intercept. If you Implement QUEUE in FORWARD then you will miss all those packets ehich intended to host. Just a Silly question here: Do you have clear idea of how packet travel into netfilter code? Which chains are travel and in which order? Don't get annoyed, from yours see the comments...Step Table Chain Comment... I can say that you have little idea atleast ;-). 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 ? It would be nice if you snapped that part of documentation in this mail. -- Sumit
[PATCH] transparent proxying, #2 release
Hi,
I have prepared a work-in-progress patch showing which directions I'm
heading with my transparent proxy patches. Here is a summary of changes:
1) It is now possible to query where a connection was destined. It is using
the method Henrik Nordstrom suggested:
I defined the IP_ORIGADDRS control message (can be enabled using a
setsockopt call, and queried using IP_PKTOPTIONS)
2) I also added support for fragmented packets. I didn't test it though,
comments on this are welcome. I'm doing this in my PREROUTING hook:
+ if (ip-frag_off htons(IP_MF|IP_OFFSET)) {
+ *pskb = ip_defrag(*pskb);
+ if (*pskb == NULL)
+ return NF_STOLEN;
+ }
3) I wrote a small program which shows how to use the currently implemented
features. It can be started from inetd (because that was the easiest way)
Comments, as always, are welcome.
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
diff -urN --exclude-from kernel-exclude linux-2.4.17-vanilla/include/linux/in.h
linux-2.4.17-TPROXY-ng/include/linux/in.h
--- linux-2.4.17-vanilla/include/linux/in.h Mon Nov 5 21:42:13 2001
+++ linux-2.4.17-TPROXY-ng/include/linux/in.h Wed Mar 27 08:54:22 2002
@@ -67,6 +67,7 @@
#defineIP_RECVTOS 13
#define IP_MTU 14
#define IP_FREEBIND15
+#define IP_ORIGADDRS 16
/* BSD compatibility */
#define IP_RECVRETOPTS IP_RETOPTS
@@ -107,6 +108,14 @@
struct in_addr ipi_spec_dst;
struct in_addr ipi_addr;
};
+
+struct in_origaddrs {
+ struct in_addr ioa_srcaddr;
+ struct in_addr ioa_dstaddr;
+ unsigned short int ioa_srcport;
+ unsigned short int ioa_dstport;
+};
+
/* Structure describing an Internet (IP) socket address. */
#define __SOCK_SIZE__ 16 /* sizeof(struct sockaddr) */
diff -urN --exclude-from kernel-exclude
linux-2.4.17-vanilla/include/linux/netfilter_ipv4/ipt_TPROXY.h
linux-2.4.17-TPROXY-ng/include/linux/netfilter_ipv4/ipt_TPROXY.h
--- linux-2.4.17-vanilla/include/linux/netfilter_ipv4/ipt_TPROXY.h Thu Jan 1
01:00:00 1970
+++ linux-2.4.17-TPROXY-ng/include/linux/netfilter_ipv4/ipt_TPROXY.hWed Feb 13
+09:29:34 2002
@@ -0,0 +1,15 @@
+#ifndef _IPT_TPROXY_H_target
+#define _IPT_TPROXY_H_target
+
+struct ipt_tproxy_target_info {
+ u_int16_t redir_port;
+ /* unsigned long fwmark; */
+};
+
+struct ipt_tproxy_user_info {
+ int changed;
+ u_int16_t redir_port;
+ unsigned long fwmark;
+};
+
+#endif /*_IPT_TPROXY_H_target*/
diff -urN --exclude-from kernel-exclude linux-2.4.17-vanilla/include/net/ip.h
linux-2.4.17-TPROXY-ng/include/net/ip.h
--- linux-2.4.17-vanilla/include/net/ip.h Mon Nov 5 21:43:09 2001
+++ linux-2.4.17-TPROXY-ng/include/net/ip.h Wed Mar 27 08:55:07 2002
@@ -46,6 +46,12 @@
#define IPSKB_MASQUERADED 1
#define IPSKB_TRANSLATED 2
#define IPSKB_FORWARDED4
+
+#if defined(CONFIG_IP_NF_TPROXY) || defined(CONFIG_IP_NF_TPROXY_MODULE)
+ u32 origdstaddr;
+ u16 origdstport;
+#endif
+
};
struct ipcm_cookie
diff -urN --exclude-from kernel-exclude linux-2.4.17-vanilla/include/net/sock.h
linux-2.4.17-TPROXY-ng/include/net/sock.h
--- linux-2.4.17-vanilla/include/net/sock.h Thu Mar 28 02:18:47 2002
+++ linux-2.4.17-TPROXY-ng/include/net/sock.h Thu Mar 28 05:19:41 2002
@@ -418,6 +418,11 @@
int linger2;
unsigned long last_synq_overflow;
+
+#if defined(CONFIG_IP_NF_TPROXY) || defined(CONFIG_IP_NF_TPROXY_MODULE)
+ u32 origdstaddr;
+ u16 origdstport;
+#endif
};
diff -urN --exclude-from kernel-exclude linux-2.4.17-vanilla/net/ipv4/ip_sockglue.c
linux-2.4.17-TPROXY-ng/net/ipv4/ip_sockglue.c
--- linux-2.4.17-vanilla/net/ipv4/ip_sockglue.c Wed Oct 31 00:08:12 2001
+++ linux-2.4.17-TPROXY-ng/net/ipv4/ip_sockglue.c Thu Mar 28 03:14:58 2002
@@ -48,6 +48,7 @@
#define IP_CMSG_TOS4
#define IP_CMSG_RECVOPTS 8
#define IP_CMSG_RETOPTS16
+#define IP_CMSG_ORIGADDRS 32
/*
* SOL_IP control messages.
@@ -107,6 +108,20 @@
put_cmsg(msg, SOL_IP, IP_RETOPTS, opt-optlen, opt-__data);
}
+#if defined(CONFIG_IP_NF_TPROXY) || defined(CONFIG_IP_NF_TPROXY_MODULE)
+
+void ip_cmsg_recv_origaddrs(struct msghdr *msg, struct sk_buff *skb)
+{
+ struct in_origaddrs ioa;
+
+ ioa.ioa_srcaddr.s_addr = 0;
+ ioa.ioa_srcport = 0;
+ ioa.ioa_dstaddr.s_addr = IPCB(skb)-origdstaddr;
+ ioa.ioa_dstport = IPCB(skb)-origdstport;
+ put_cmsg(msg, SOL_IP, IP_ORIGADDRS, sizeof(ioa), ioa);
+}
+
+#endif
void ip_cmsg_recv(struct msghdr *msg, struct sk_buff *skb)
{
@@ -135,6 +150,13 @@
if (flags 1)
ip_cmsg_recv_retopts(msg, skb);
+
+#if defined(CONFIG_IP_NF_TPROXY) || defined(CONFIG_IP_NF_TPROXY_MODULE)
+ if ((flags=1) == 0)
+ return;
+ if (flags 1)
+
Re: TPROXY and original dest address question
Balazs Scheidler wrote: Where is the possible transparent proxy entries defined? Internally in TPROXY, or in the host IP stack socket table? in TPROXY. Is TPROXY is a stand-alone netfilter module, not a iptables target? I thought it was a iptables target, but from your answer it seems like it should be a netfilter module on it's own.. Regards Henrik
Re: TPROXY and original dest address question
On Thu, Mar 28, 2002 at 04:02:46PM +0100, Henrik Nordstrom wrote: Balazs Scheidler wrote: Where is the possible transparent proxy entries defined? Internally in TPROXY, or in the host IP stack socket table? in TPROXY. I guess this would be the rule table telling what should be diverted by TPROXY, which from my understanding would be your iptables ruleset... No. I have You have what? Seems to be part of the message missing here..?? Yes, sorry. There's a translation table in TPROXY independent from the tproxy iptables table. The rules are in the iptables table called 'tproxy', and contains one transparent proxy rule for each service needed. As a connection is established, a new entry is added to the translation table with: remote addr/remote port, original dest/original port, local dest/local port. Then both the prerouting and the local output hooks perform translation of the packet flow according to the translation table. In a sence this table is similar to the conntrack tables, with the exception that the primary focus is to assign packet endpoints with local sockets, identified by their own IP/port pair. Thus the connection between a redirected session and a local socket is not the socket layer, but this translation table, therefore no packet with foreign IP address enter the networking core. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Strange Contracker problem in conjuction with Cisco Content Switch
Hi! We are experiencing problems with connection tracking with a Cisco Content Switch behind a firewall and think that it might partly be a problem with netfilter in stock Linux 2.4.17. We just started using CSS in a productive environment and now the number of connections in /proc/net/ip_conntrack have reached 20. Which may be OK, but the problem is that 75% of these connections are in UNREPLIED state and the timeout given as 3rd value in /proc/net/ip_conntrack goes up to values like: 431998 - alsmost 5 days. So 75% of all connections in the tracking list are garbage and only discarded after 5 days! Ok, the problem does arise with non CSS as well, but with CSS the rise was most pronounced, still connections are left open. Any ideas, explaination, Cheers, Martin Sperl
Re: TPROXY and original dest address question
On Thu, Mar 28, 2002 at 04:39:51PM +0100, Henrik Nordstrom wrote: Thanks. Explains it quite well. So there is yet another state table involved here. Now I am a little confused. What exacly is it that makes this new state table better suited for the job than conntrack? because we don't do full TCP tracking, and our NAT is quite limited. (only DNAT, and only to local IP stack). And in addition entries are not timeouted from the table. a new entry is added to this table when 1) a TPROXY destination is encountered 2) when a socket is 'bound' to a foreign address (either for listening and connecting) 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) 2) when a TCP rst is returned by the stack (happens only when a socket is not yet associated) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: TPROXY and original dest address question
Balazs Scheidler wrote: because we don't do full TCP tracking, and our NAT is quite limited. (only DNAT, and only to local IP stack). And in addition entries are not timeouted from the table. a new entry is added to this table when 1) a TPROXY destination is encountered 2) when a socket is 'bound' to a foreign address (either for listening and connecting) Ok. 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.. 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. 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. 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). Regards Henrik
[PATCH] add --reject-with tcp-synack to REJECT
Here's a minimalist patch-in-patch against 1.2.6a to add a
--reject-with tcp-synack option to the REJECT extension.
TCP SYN packets are replied to with a valid SYN-ACK, all others are
dropped.
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, but requiring no local per-connection resources.
This offers the same functionality as LaBrea - The Tarpit
http://www.hackbusters.net/LaBrea/ but doesn't require dedicated
hardware or IPs. Any TCP port that you would normally DROP or
REJECT can instead become a tarpit:
Example:
iptables -A INPUT -p tcp -m tcp --dport 80 -j REJECT --reject-with tcp-synack
No attempt is made to disguise ourselves as a real TCP stack, so things
like the sequence number are left at 0.
-- Aaron
---
diff -urP iptables-1.2.6a/patch-o-matic/extra/ipt_REJECT-tcp-synack.patch
iptables-1.2.6a.syn-ack/patch-o-matic/extra/ipt_REJECT-tcp-synack.patch
--- iptables-1.2.6a/patch-o-matic/extra/ipt_REJECT-tcp-synack.patch Wed Dec 31
16:00:00 1969
+++ iptables-1.2.6a.syn-ack/patch-o-matic/extra/ipt_REJECT-tcp-synack.patch Thu
+Mar 28 22:34:46 2002
@@ -0,0 +1,67 @@
+diff -r -u linux-2.4.18/include/linux/netfilter_ipv4/ipt_REJECT.h
+linux-2.4.18-synack/include/linux/netfilter_ipv4/ipt_REJECT.h
+--- linux-2.4.18/include/linux/netfilter_ipv4/ipt_REJECT.h Fri Jul 14 12:20:23
+2000
linux-2.4.18-synack/include/linux/netfilter_ipv4/ipt_REJECT.h Thu Mar 28
+21:06:58 2002
+@@ -9,7 +9,8 @@
+ IPT_ICMP_ECHOREPLY,
+ IPT_ICMP_NET_PROHIBITED,
+ IPT_ICMP_HOST_PROHIBITED,
+- IPT_TCP_RESET
++ IPT_TCP_RESET,
++ IPT_TCP_SYNACK
+ };
+
+ struct ipt_reject_info {
+diff -r -u linux-2.4.18/net/ipv4/netfilter/ipt_REJECT.c
+linux-2.4.18-synack/net/ipv4/netfilter/ipt_REJECT.c
+--- linux-2.4.18/net/ipv4/netfilter/ipt_REJECT.c Sat Oct 6 08:50:28 2001
linux-2.4.18-synack/net/ipv4/netfilter/ipt_REJECT.cThu Mar 28 21:01:38
+2002
+@@ -32,8 +32,8 @@
+ attach(new_skb, nfct);
+ }
+
+-/* Send RST reply */
+-static void send_reset(struct sk_buff *oldskb, int local)
++/* Send RST or SYN-ACK reply */
++static void send_tcp_reject(struct sk_buff *oldskb, int local, int synack)
+ {
+ struct sk_buff *nskb;
+ struct tcphdr *otcph, *tcph;
+@@ -50,10 +50,14 @@
+ otcph = (struct tcphdr *)((u_int32_t*)oldskb-nh.iph + oldskb-nh.iph-ihl);
+ otcplen = oldskb-len - oldskb-nh.iph-ihl*4;
+
+- /* No RST for RST. */
++ /* No RST or ACK for RST. */
+ if (otcph-rst)
+ return;
+
++ /* No ACK for anything but a SYN. */
++ if (synack (!otcph-syn || otcph-ack))
++ return;
++
+ /* Check checksum. */
+ if (tcp_v4_check(otcph, otcplen, oldskb-nh.iph-saddr,
+oldskb-nh.iph-daddr,
+@@ -101,7 +105,10 @@
+
+ /* Reset flags */
+ ((u_int8_t *)tcph)[13] = 0;
+- tcph-rst = 1;
++ if (synack)
++ tcph-syn = 1;
++ else
++ tcph-rst = 1;
+ tcph-ack = needs_ack;
+
+ tcph-window = 0;
+@@ -308,7 +315,10 @@
+ send_unreach(*pskb, ICMP_HOST_ANO);
+ break;
+ case IPT_TCP_RESET:
+- send_reset(*pskb, hooknum == NF_IP_LOCAL_IN);
++ send_tcp_reject(*pskb, hooknum == NF_IP_LOCAL_IN, 0);
++ break;
++ case IPT_TCP_SYNACK:
++ send_tcp_reject(*pskb, hooknum == NF_IP_LOCAL_IN, 1);
+ case IPT_ICMP_ECHOREPLY:
+ /* Doesn't happen. */
+ break;
diff -urP iptables-1.2.6a/patch-o-matic/extra/ipt_REJECT-tcp-synack.patch.help
iptables-1.2.6a.syn-ack/patch-o-matic/extra/ipt_REJECT-tcp-synack.patch.help
--- iptables-1.2.6a/patch-o-matic/extra/ipt_REJECT-tcp-synack.patch.helpWed
Dec 31 16:00:00 1969
+++ iptables-1.2.6a.syn-ack/patch-o-matic/extra/ipt_REJECT-tcp-synack.patch.help
+ Thu Mar 28 22:34:46 2002
@@ -0,0 +1,17 @@
+Author: Aaron Hopkins [EMAIL PROTECTED]
+
+Adds a --reject-with tcp-synack option to the REJECT extension. TCP SYN
+packets are replied to with a valid SYN-ACK, all others are dropped.
+
+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, but requiring no local per-connection resources.
+
+This offers the same functionality as LaBrea - The Tarpit
+http://www.hackbusters.net/LaBrea/ but doesn't require dedicated
+hardware or IPs. Any TCP port that you would normally DROP or
+REJECT can instead become a tarpit:
+
+Example:
+
+ iptables -A INPUT -p tcp -m tcp --dport 80 -j REJECT --reject-with tcp-synack
diff -urP iptables-1.2.6a/patch-o-matic/extra/ipt_REJECT-tcp-synack.patch.userspace
iptables-1.2.6a.syn-ack/patch-o-matic/extra/ipt_REJECT-tcp-synack.patch.userspace
---
