Warn people that ipchains and ipfwadm are going away.

Name: Warn that ipchains and ipfwadm are going away
Status: Trivial

At the recent netfilter workshop in Erlangen, we was decided to remove the backwards compatibility code for ipchains and ipfwadm. This will allow significant cleanup of interfaces, since we had to have a mid-level interface for the backwards compatibility layer to use.

Start off with a warning for 2.6.9, so any remaining users have a chance to migrate. Their firewall scripts might not check return values, and they might get a nasty surprise when this goes away.

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .5978-linux-2.6.9-rc2-bk6/net/ipv4/netfilter/ipchains_core.c .5978-linux-2.6.9-rc2-bk6.updated/net/ipv4/netfilter/ipchains_core.c
@@ -1,3 +1,5 @@
+#warning ipchains is obsolete, and will be removed soon.
+
 /* Minor modifications to fit on compatibility framework:
    [email protected]
 */

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .5978-linux-2.6.9-rc2-bk6/net/ipv4/netfilter/ipfwadm_core.c .5978-linux-2.6.9-rc2-bk6.updated/net/ipv4/netfilter/ipfwadm_core.c
@@ -1,3 +1,5 @@
+#warning ipfwadm is obsolete, and will be removed soon.
+
 /* Minor modifications to fit on compatibility framework:
    [email protected]
 */

Isn't a compile-time warning a bit "soft"? Especially when compilation of a kernel easily produces > 100 warnings, as it does right now.

Regards

Sure, but you have to start somewhere. Next step will be #error. Then finally remove the whole thing (I don't want to remove the whole thing to start with, since that would create a silent failure).

Cheers,
Rusty.

http://linux.conf.au - Call for papers.  Join us!

I was rather thinking of some prominent printks at module init time. People using distro kernels will never see compile time warnings.

I just added some warnings, but modprobe ipchains always fails on 2.6.9-rc2:

FATAL: Error inserting ipchains (/lib/modules/2.6.9-rc2-rcf/kernel/net/ipv4/netfilter/ipchains.ko): Device or resource busy

in log buffer:
ip_conntrack version 2.1 (8191 buckets, 65528 max) - 332 bytes per conntrack
Unable to register netfilter socket option

Am I missing something?

Regards

You can't have ipchains and iptables loaded at the same time. You must first manually unload iptables, then you can successfully load the ipchains module.

Yes, I know, something seems strange here.

Just to be sure, I disabled iptables completely and rebooted:
(Complete config.gz is attached.)

# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
CONFIG_IP_NF_QUEUE=m
# CONFIG_IP_NF_IPTABLES is not set
CONFIG_IP_NF_NAT_NEEDED=y
# CONFIG_IP_NF_ARPTABLES is not set
CONFIG_IP_NF_COMPAT_IPCHAINS=m
CONFIG_IP_NF_COMPAT_IPFWADM=m
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set

This gives me the same error upon modprobe ipchains.

If I disable CONFIG_IP_NF_CONNTRACK, I get unresolved symbols:
ipchains: Unknown symbol ip_ct_log_invalid

(Is that combination supposed to work?)

lsmod (ALSA snipped):

vfat                   10432  0
stir4200               10052  0
irda                  110972  1 stir4200
crc_ccitt               1664  1 irda
fat                    36320  1 vfat
parport_pc             29440  1
lp                      7976  0
parport                32072  2 parport_pc,lp
floppy                 50576  0
radeon                120676  2
nvidia_agp              5404  1
agpgart                26024  2 nvidia_agp
8139too                19200  0
mii                     3712  1 8139too
crc32                   3840  2 stir4200,8139too
evdev                   6848  0

Regards

Fixed by this patch. The conntrack protocols need ip_ct_log_invalid which is defined in ip_conntrack_standalone, so ip_conntrack is loaded automatically before ipchains. This patch moves it over to ip_conntrack_core.

Dave, please apply on top of the other netfilter patches.

Regards
Patrick

# This is a BitKeeper generated diff -Nru style patch. #
# ChangeSet
# 2004/09/22 02:04:02+02:00 [email protected]
# {NETFILTER]: Move ip_ct_log_invalid to ip_conntrack_core.c
#
# Signed-off-by: Patrick McHardy <[email protected]>
#

# net/ipv4/netfilter/ip_conntrack_standalone.c
#   2004/09/22 02:03:37+02:00 [email protected] +0 -2
#   {NETFILTER]: Move ip_ct_log_invalid to ip_conntrack_core.c
#   
#   Signed-off-by: Patrick McHardy <[email protected]>
# 
# net/ipv4/netfilter/ip_conntrack_core.c
#   2004/09/22 02:03:37+02:00 [email protected] +1 -0
#   {NETFILTER]: Move ip_ct_log_invalid to ip_conntrack_core.c
#   
#   Signed-off-by: Patrick McHardy <[email protected]>
# 
diff -Nru a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c
--- a/net/ipv4/netfilter/ip_conntrack_core.c	2004-09-22 02:10:28 +02:00
+++ b/net/ipv4/netfilter/ip_conntrack_core.c	2004-09-22 02:10:28 +02:00
@@ -74,6 +74,7 @@
 static kmem_cache_t *ip_conntrack_cachep;
 static kmem_cache_t *ip_conntrack_expect_cachep;
 struct ip_conntrack ip_conntrack_untracked;
+unsigned int ip_ct_log_invalid;

DEFINE_PER_CPU(struct ip_conntrack_stat, ip_conntrack_stat);

diff -Nru a/net/ipv4/netfilter/ip_conntrack_standalone.c b/net/ipv4/netfilter/ip_conntrack_standalone.c
@@ -48,8 +48,6 @@
 extern atomic_t ip_conntrack_count;
 DECLARE_PER_CPU(struct ip_conntrack_stat, ip_conntrack_stat);
 
-unsigned int ip_ct_log_invalid = 0;
-
 static int kill_proto(const struct ip_conntrack *i, void *data)
 {
 	return (i->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.protonum == 

Yes, works fine. Does this mean that ipchains was broken for a while, but no one complained?

Anyway, here is another trivial patch against -bk7 that adds runtime warnings. IMO most users are going to miss compile time warnings, or won't even compile kernels themselves.

Regards

diff -Nurp tmp/linux-2.6.9/net/ipv4/netfilter/ipchains_core.c linux-2.6.9/net/ipv4/netfilter/ipchains_core.c

@@ -1800,6 +1800,9 @@ int ipfw_init_or_cleanup(int init)
 
 	if (!init) goto cleanup;
 
+	printk(KERN_WARNING
+		"Warning: ipchains is obsolete, and will be removed soon!\n");
+			
 #ifdef DEBUG_IP_FIREWALL_LOCKING
 	fwc_wlocks = fwc_rlocks = 0;
 #endif

diff -Nurp tmp/linux-2.6.9/net/ipv4/netfilter/ipfwadm_core.c linux-2.6.9/net/ipv4/netfilter/ipfwadm_core.c

@@ -1420,6 +1420,9 @@ int ipfw_init_or_cleanup(int init)
 	if (!init)
 		goto cleanup;
 
+	printk(KERN_WARNING
+		"Warning: ipfwadm is obsolete, and will be removed soon!\n");
+			
 	ret = register_firewall(PF_INET, &ipfw_ops);
 	if (ret < 0)
 		goto cleanup_nothing;

I like having runtime info as well as a compile time warning, but maybe the message should mention that iptables is staying and people should migrate??

FYI. I just migrated to iptables. The code downloaded from the Debian site did not compile cleanly, but enough worked to make most of the shared libraries and the iptables executable.

The total time to do everything was slightly under 2 hours.

The errors from the distribution are:

cc -O2 -Wall -Wunused -I/usr/src/linux-2.4.26/include -Iinclude/ -DNETFILTER_VERSION=\"1.2.6a\" -fPIC -o extensions/libipt_ECN_sh.o -c extensions/libipt_ECN.c extensions/libipt_ECN.c: In function `parse':
extensions/libipt_ECN.c:51: `IPT_ECN_OP_REMOVE' undeclared (first use in this function)
extensions/libipt_ECN.c:51: (Each undeclared identifier is reported only once
extensions/libipt_ECN.c:51: for each function it appears in.)
extensions/libipt_ECN.c: In function `print':
extensions/libipt_ECN.c:82: `IPT_ECN_OP_REMOVE' undeclared (first use in this function)
extensions/libipt_ECN.c:83: warning: unreachable code at beginning of switch statement
extensions/libipt_ECN.c: In function `save':
extensions/libipt_ECN.c:99: `IPT_ECN_OP_REMOVE' undeclared (first use in this function)
extensions/libipt_ECN.c:100: warning: unreachable code at beginning of switch statement

make: [extensions/libipt_ECN_sh.o] Error 1 (ignored)
ld -shared -o extensions/libipt_ECN.so extensions/libipt_ECN_sh.o
ld: cannot open extensions/libipt_ECN_sh.o: No such file or directory
make: [extensions/libipt_ECN.so] Error 1 (ignored)

ip6tables.o: In function `addr_to_host':
ip6tables.o(.text+0x4d8): undefined reference to getnameinfo' ip6tables.o: In function parse_hostnetworkmask':
ip6tables.o(.text+0x731): undefined reference to in6addr_any' ip6tables.o: In function print_firewall':
ip6tables.o(.text+0x19e7): undefined reference to `in6addr_any'
collect2: ld returned 1 exit status
make: [ip6tables] Error 1 (ignored)

The build command was:

#
#!/bin/sh
#
#make pending-patches KERNEL_DIR=/usr/src/linux-uname -r make -i KERNEL_DIR=/usr/src/linux-uname -r

The pending patches resulted in many rejects but the kernel was virgin 2.4.26.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.

What replaces the firewall stuff? It can't just "go away"!

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.

Ever heard of iptables?

/Martin

I guess I'll have to convert 1340 lines of ipchains commands to iptables -yech!

I had convert something to ipchains a couple of years ago. That's when I only had to kill-off only about 100 spam-hosts.

Now I gotta convert again. Soon they'll be replacing ls with echo * and nothing will work.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.

Ouch! If it takes 1340 lines of ipchains commands, a direct translation to iptables syntax is both counter-productive and extremely wastefull of system resources, cpu in particular. I admittedly have a dsl router in front of my machine, so it does 99% of that job, but if I wanted to put up with the idiosyncracies of the Roaring Penguin PPPoE, I could skip the router and be just as secure with the less than 30 active lines of my present iptables script. With the router, I'm invisible to the outside world. Of course that does restrict me some as I've not figured out how to drill a hole thru all that to allow a torrent server to function. The peace of mind is worth that loss IMO. Its been over a year now since portsentry-1.1 saw a trigger and logged it.

Humm, thats a lie, from the firewalls /var/log/messages.1 file:

[root@gene root]# grep attackalert /var/log/messages* /var/log/messages.1:Sep 16 18:09:16 gene portsentry[1159]:
attackalert: UDP scan from host: home1.bellatlantic.net/199.45.32.43 to UDP port: 32771
/var/log/messages.1:Sep 16 18:09:16 gene portsentry[1159]:
attackalert: Host 199.45.32.43 has been blocked via wrappers with
string: "ALL: 199.45.32.43"
/var/log/messages.1:Sep 16 18:09:17 gene portsentry[1159]:
attackalert: Host 199.45.32.43 has been blocked via dropped route using command: "/sbin/iptables -I INPUT -s 199.45.32.43 -j DROP" /var/log/messages.1:Sep 16 18:09:17 gene portsentry[1159]:
attackalert: UDP scan from host: home1.bellatlantic.net/199.45.32.43 to UDP port: 32771
/var/log/messages.1:Sep 16 18:09:17 gene portsentry[1159]:
attackalert: Host: home1.bellatlantic.net/199.45.32.43 is already blocked Ignoring

Time to send another nastygram to verizon since thats one of their nameservers, and clear out that address from the hosts.deny file.

FWIW, the last time that happened, in April 2003, the hack attempt trashed a siemans router and I had to replace it with that linksys. Must be time to change the user and password in it again too...

FWIW, verizon has apparently a problem keeping their nameservers from being hacked.

Surely you jest?

Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Isn't this just the replies to legitimate dns queries? Wouldn't be the first time legitimate traffic is recognised as a portscan.

HTH,
M4

iptables is a much better firewall than ipchains and, in my opinion, anybody using ipchains should upgrade to iptables. I, for one, am quite pleased to see that ipchains will be removed.

Sean

Good day, all,

I have a script that does a first pass of converting an ipchains
firewall script to an iptables firewall script at

http://www.stearns.org/i2i/ipchains2iptables
http://www.stearns.org/i2i/ipchains2iptables.README

Because of architectural differences between the two firewall
technologies it can't produce a perfect translation, but it does handle most of the grunt work.
Cheers,
- Bill

---------------------------------------------------------------------------
"The sign on the window next to the entrance of OptInRealBig's
offices in Westminster leaves no room for misunderstanding. Or irony. NO SOLICITING."
http://www.westword.com/issues/2004-01-29/feature.html/3/index.html
--------------------------------------------------------------------------
William Stearns ([email protected]). Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org
--------------------------------------------------------------------------

Thanks. I just wrote a 10-line 'C' program to do it. Just changes "ipchains" to "iptables" and removes "-y". I had to add the create command on the first line, simple. Thanks -all.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.

Good day, all,
[CC list snipped]

If that works for you, great, but depending on your firewall
structure there are more differences between the two than simply replacing ipchains with iptables.
Cheers,
- Bill

---------------------------------------------------------------------------
"Decisive action in the hour of need
denotes the hero but does not succeed."
-- Marion D. Hutchins
(Courtesy of Kate Bates)
--------------------------------------------------------------------------
William Stearns ([email protected]). Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org
--------------------------------------------------------------------------

In the upcoming kernel 2.4, which will be released January 2001, iptables will replace ipchains.

Regards

ipchains and ipfwadm are very old firewall implementations.
The current linux firewall code is called "iptables" and that has been present for a long time time, and that is staying.

So, the linux kernel still has firewall features, even with ipchains and ipfwadm removed.

James

I thought I understood the "new development model" but I guess I don't. Are working features now going to be removed from the "stable" chain instead of during a development cycle?

Not a complaint, I thought the new method was regarding new features...

   -bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me