A little history
http://www.linuxquestions.org/questi...threadid=19374

It turns out that for some reason that baffles me, I can no longer get any of my 'added' rules to have any effect.

I removed all the 1800 or so tags and just left the basics. Then started watching my logfiles for skiddies scanbstrds. (didn't take long.

I added a rule
iptables -A INPUT -s xxx.xxx.xxx.xxx -j DROP, and then to my suprise watched my log files continue grow with skid entries from the very ip I just blocked.

(now I'm pissed and concerned)

I flushed all my rules, restarted iptables (picked up my basic rules for/etc/sysconfig/iptables) and tried again with the same result. Even bounced the box a time or two for good measure, all with the same result.

I'm on a mandrake 8.1 distro which was using V1.2.2 of iptables.
So I went and grabbed 1.2.6a and put it in. I used the default locale of 1.2.6a (usr/local) so it didn't interfere with the installed version and renamed the exec's to *.122 then created sym links to the new version.

Same result. The odd thing is that I've remote scanned my box, and my basic rules appear to be only allowing the ports I want open (80 & 22), plus I'm still doing forwarding from my internal address just fine, as well as logging SYN on certian ports.

I've got a laptop that I run the same version on, still 1.2.2 and it works fine.

I've done an strace to verify i'm calling the new version. I compared it to an strace of my laptop and noticed that near the bottom, the working on calls a mod prob, were the defuct one does not. (haven't straced the orig 1.2.2, but could)

I've compared md5sums on the 1.2.2 versions of binaries and libs and compared them on the two boxen.

Can't think of what to do next.

I've got portsentry and prelude(snort) running on the box as well, as I have from the beginning. They appear to be working fine as portsentry will attempt to block for stupid people trying to connect to closed ports (which has no effect since tables is outta-whack) and prelude is continuing to inform me of 'iis' attacks as the skiddies hit my web server. (shutting down thse services make no diff)

ANY sugesstions are welcome - scratch and re-install is next, but then what would I learn from that. :=}

BTW, I've also checked for root kits.

from strace:

WORKING -

open("/lib/iptables/libipt_standard.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\3\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=2360, ...}) = 0
old_mmap(NULL, 5688, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40017000
mprotect(0x40018000, 1592, PROT_NONE) = 0
old_mmap(0x40018000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x40018000
close(3) = 0
socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 3
getsockopt(3, SOL_IP, 0x40 /* IP_??? */, 0xbffff410, 0xbffff40c) = -1 ENOPROTOOPT (Protocol not available)
open("/proc/sys/kernel/modprobe", O_RDONLY) = 4
read(4, "/sbin/modprobe\n", 1024) = 15
close(4) = 0
fork() = 2731
wait4(-1, NULL, 0, NULL) = 2731
--- SIGCHLD (Child exited) ---
socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 4

NOT WORKING -

open("/usr/local/lib/iptables/libipt_standard.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\3\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=3241, ...}) = 0
old_mmap(NULL, 5620, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40017000
mprotect(0x40018000, 1524, PROT_NONE) = 0
old_mmap(0x40018000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x40018000
close(3) = 0
socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 3

Whew. I guess this is stuff for the netfilter mailinglist at samba.org, but I'll give it a go...
Did you rebuild the kernel after "make pending patches kernel_dir"?
No (older) netfilter modules builtin?
Does modprobe know where to load the correct modules from? Do they exist in /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter?
Does manually loading 'em help?
Does lsmod show all correct modules loaded?

Whew is RIGHT -

No, I did not rebuild kernel (newbie fear & lack of knowledge)

I will post/join netfilter list a samba.org (majordomo@netfilter.samba.org ?)

The only steps I did for 1.2.6a was -
[read README/INSTALL saw that it would not overwrite my current bin's & lib's]
make KERNEL_DIR=/usr/src/linux-2.4.8/kernel
make install KERNEL_DIR=/usr/src/linux-2.4.8/kernel

(I ASS-U-ME'd my kernel was recent enough since I was readily using all functions of 1.2.2)

I've just removed my symb links and did a strace on iptables.122 and it looks similar to the one for 1.2.6a posted above, no modprobe.

(unfortunately I didn't discover strace until AFTER I installed 1.2.6a)

I looked through my system, and although I didn't see it in my .bash_history I realized that I installed libpcap 0.7 & tcpdump 3.7.1 on Apr 2. Could this be my problem? in /usr/lib/libpcap.so.0 & *.5 and /usr/local/lib/libpcap.a , but have /usr/sbin/tcpdump (- V =3.6, libpcap .06) and /usr/local/sbin/tcpdump (-V=3.7.1, libpcap .07)

The only other thing was apache update back in March.

Proper modules and in proper .../netfilter dir

Here's the output from lsmod:
Module Size Used by
ip6_tables 11936 0 (unused)
ipt_MASQUERADE 1600 1 (autoclean)
af_packet 12560 2 (autoclean)
ipt_REJECT 3312 0 (autoclean)
ipt_limit 1280 10 (autoclean)
ipt_state 944 12 (autoclean)
ipt_LOG 3776 10
ip_conntrack_ftp 3792 0 (unused)
iptable_mangle 2048 0 (autoclean) (unused)
iptable_nat 16560 0 (autoclean) [ipt_MASQUERADE]
ip_conntrack 15600 3 (autoclean) [ipt_MASQUERADE ipt_state ip_conntrack_ftp iptable_nat]
iptable_filter 2048 0 (autoclean) (unused)
ip_tables 11488 10 [ipt_MASQUERADE ipt_REJECT ipt_limit ipt_state ipt_LOG iptable_mangle iptable_nat iptable_filter]
usb-uhci 21232 0 (unused)
usbcore 50752 1 [usb-uhci]
3c59x 25952 1 (autoclean)
eepro100 17120 1 (autoclean)
rtc 5600 0 (autoclean)

I'm gonna try the new libpcap & tcpdump again placing the exe in the proper dir.

1.2.6a had some fixed for the kernel source as stated in the readme, but I can't see how much dependant iptables is on the kernel having that code fixed, I'd say it wouldn't hurt to compile a new kernel just to test.
IMHO libpcap (filtering) hasn't anything to do with iptables, as libpcap-using apps are earlier in the sniffing foodchain compared to the iptables stuff.

The advantage of rebuilding the kernel after patching it with the iptables stuff is you get a clean kernel, with the proper modules in the proper place.
*If you don't like to overwrite your current /lib/modules/<kernelversion> scheme, open up the Makefile in the kerneldir you're going to compile from, look for the var EXTRAVERSION at the top, and add something like "EXTRAVERSION = -01" (w/o quotes). After patching configuration, building the kernel & iptables the kernel modules would install in /lib/modules/<kernelversion>-01 which is great if you mess around with kernels.

HTH somehow.
Btw, I'm interested in learning the cause of this, so if you get word from the mailinglist at samba, plz post the solution/fix/advice/whatever else here if you can.

Sorry - maybe your rule for logging comes before the rule for dropping?

(This is not an April Fool's joke!) the FBI announced it had discovered malicious code wiping out the data on hard drives and dialing 911. This is a vicious virus and needs to be stopped quickly. That can only be done through wide-scale individual action. Please forward this note to everyone who you know who might be affected.

Please delete this post (was posted on the wrong place)

Can someone please delete this post?