[gentoo-user] OT - ipkungfu perhaps not doing its job
Can anyone tell me why I have about a hundred of these Nov 16 08:00:03 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 Nov 16 08:00:06 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 Nov 16 08:00:09 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 Nov 16 08:00:12 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 when that IP address is in /etc/ipkungfu/deny_hosts.conf? Here's my rules; I don't understand them: bullet ~ # ipkungfu -l Chain INPUT (policy DROP 2 packets, 144 bytes) pkts bytes target prot opt in out source destination 45662 6103K ACCEPT all -- anyany anywhere anywherestate RELATED,ESTABLISHED 0 0 LOGall -- lo any 0.0.0.1 anywhereLOG level warning prefix `IPKF IPKungFu (--init)' 0 0 DROP all -- eth0 any 210.188.206.107 anywhere 0 0 DROP all -- eth0 any 222.90.206.62 anywhere 0 0 DROP all -- eth0 any 61.178.185.124 anywhere 0 0 DROP all -- eth0 any 65.98.76.197 anywhere 0 0 DROP all -- eth0 any 211.234.99.230 anywhere 0 0 DROP all -- eth0 any 60.191.34.155 anywhere 0 0 DROP all -- eth0 any sd-2742.dedibox.fr anywhere 140 DROP all -- eth0 any nameservices.net anywhere 155 DROP all -- eth0 any 222.135.146.45 anywhere 28 1598 ACCEPT all -- anyany camille.espersunited.com anywhere 7 351 ACCEPT all -- anyany catherine.espersunited.com anywhere 0 0 DROP all -- anyany anywhere anywhererecent: CHECK seconds: 120 name: badguy side: source 0 0 LOGtcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG limit: avg 3/sec burst 5 LOG level warning prefix `IPKF flags ALL: ' 0 0 LOGtcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE limit: avg 3/sec burst 5 LOG level warning prefix `IPKF flags NONE: ' 0 0 LOGtcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG limit: avg 3/sec burst 5 LOG level warning prefix `IPKF PORTSCAN (nmap XMAS): ' 0 0 LOGtcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN limit: avg 3/sec burst 5 LOG level warning prefix `IPKF PORTSCAN (nmap FIN): ' 0 0 LOGtcp -- eth0 any anywhere anywheretcp flags:FIN,SYN/FIN,SYN limit: avg 3/sec burst 5 LOG level warning prefix `IPKF flags SYN,FIN: ' 0 0 LOGtcp -- eth0 any anywhere anywheretcp flags:SYN,RST/SYN,RST limit: avg 3/sec burst 5 LOG level warning prefix `IPKF flags SYN,RST: ' 0 0 LOGtcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG limit: avg 3/sec burst 5 LOG level warning prefix `IPKF SYN,RST,ACK,FIN,URG: ' 0 0 LOGtcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE limit: avg 3/sec burst 5 LOG level warning prefix `IPKF PORTSCAN (nmap NULL): ' 0 0 DROP tcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG 0 0 DROP tcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE 0 0 DROP tcp -- eth0 any anywhere anywheretcp flags:FIN,SYN/FIN,SYN 0 0 DROP tcp -- eth0 any anywhere anywheretcp flags:SYN,RST/SYN,RST 0 0 DROP tcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG 0 0 DROP tcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG 0 0 DROP tcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN 0 0 DROP tcp -- eth0 any anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE 3 276 ACCEPT icmp -- anyany anywhere anywhereicmp echo-request 85 3400 LOGall -- anyany anywhere anywherestate INVALID limit: avg 3/sec burst 5 LOG level warning prefix `IPKF Invalid TCP flag: ' 85 3400 DROP all -- anyany anywhere anywherestate INVALID 0 0 LOGall -f eth0 any anywhere anywherelimit: avg 3/sec burst 5 LOG level warning prefix `IPKF Fragmented Packet: ' 0 0 DROP all -f eth0 any anywhere anywhere 0
Re: [gentoo-user] OT - ipkungfu perhaps not doing its job
On Thursday 16 November 2006 20:29, Michael Sullivan wrote: Can anyone tell me why I have about a hundred of these Nov 16 08:00:03 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 Nov 16 08:00:06 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 Nov 16 08:00:09 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 Nov 16 08:00:12 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 when that IP address is in /etc/ipkungfu/deny_hosts.conf? Here's my rules; I don't understand them: [snip] 1 55 DROP all -- eth0 any 222.135.146.45 anywhere Some scipt kiddie is trying a brute force attack on your ftp port trying random combinations of user name and pasword every three seconds. 'dig 45.146.135.222.in-addr.arpa PTR' tells me that the address belongs to some maschine on network sdjnptt.net.cn and that turns out to be what looks like some chinese isp. So, a chinese person is trying to exploit your machine. Hey, it happens. And will happen for about the rest of your life. The solution is to drop them at the firewall, and the above rule is doing exactly that. This specific attack from this specific person at that specific address si no longer something you need to worry about :-) alan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu perhaps not doing its job
On Thu, 2006-11-16 at 21:09 +0200, Alan McKinnon wrote: On Thursday 16 November 2006 20:29, Michael Sullivan wrote: Can anyone tell me why I have about a hundred of these Nov 16 08:00:03 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 Nov 16 08:00:06 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 Nov 16 08:00:09 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 Nov 16 08:00:12 bullet ftp(pam_unix)[2045]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=222.135.146.45 when that IP address is in /etc/ipkungfu/deny_hosts.conf? Here's my rules; I don't understand them: [snip] 155 DROP all -- eth0 any 222.135.146.45 anywhere Some scipt kiddie is trying a brute force attack on your ftp port trying random combinations of user name and pasword every three seconds. 'dig 45.146.135.222.in-addr.arpa PTR' tells me that the address belongs to some maschine on network sdjnptt.net.cn and that turns out to be what looks like some chinese isp. So, a chinese person is trying to exploit your machine. Hey, it happens. And will happen for about the rest of your life. The solution is to drop them at the firewall, and the above rule is doing exactly that. This specific attack from this specific person at that specific address si no longer something you need to worry about :-) alan So why do I get the hourly log reports (from logcheck) saying that this IP is trying to access my FTP? How does vsftpd know about this if they're being dropped at the firewall? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu not
Hi, On Thu, 5 Oct 2006 18:53:55 -0500 Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote: On Thursday 05 October 2006 14:44, Hans-Werner Hilse [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] OT - ipkungfu not': [...] Note that the first 29 bits are all equal. In addition, the first 30 bits are all equal. Yeah, stupid me :-) Shouldn't count to much bits when I ought to be asleep. So it would be sufficient to specify a /29 netmask (255.255.255.248). However, we can't specify a /30 because two addresses in each block (the highest and the lowest) are reserved for network (anycast) and broadcast (multicast). While this is correct when going for the standard common implementation, linux will happily accept a broadcast address _outside_ of the specified network (beware of routing issues). And anycast is mainly a routing issue and AFAIK not even implemented in linux. Linux will therefore happily accept an IP with all non network bits unset. I don't recommend both in any way, cause different IP stacks may have different opinions on that. That's why I wrote it is likely to break routing and broadcasting. -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu not
On Friday 06 October 2006 03:13, Hans-Werner Hilse [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] OT - ipkungfu not': On Thu, 5 Oct 2006 18:53:55 -0500 Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote: So it would be sufficient to specify a /29 netmask (255.255.255.248). However, we can't specify a /30 because two addresses in each block (the highest and the lowest) are reserved for network (anycast) and broadcast (multicast). While this is correct when going for the standard common implementation, linux will happily accept a broadcast address _outside_ of the specified network Yeah. I'm not sure why. It makes my little brain hurt just thinking of it. But, broadcast is not used much. More than anycast, sure, but, not much. That said, a router that did only understood standard broadcast [1] will send those packets to every known machine with the correct netmask. Thus, that address is reserved and should not be used unless you really know your setup. And anycast is mainly a routing issue and AFAIK not even implemented in linux. Anycast is virtually unused anywhere. I'd imagine it could be used in some crazy layer 3 clustering solution, but I've never actually seen it used. That said, sending a packet out to the anycast address is dangerous. A router that did implement anycast [1] need not send out those packets to the machine you believe you've assigned that address to (it may route it to any known machine with the correct netmask). Thus, that address is reserved and should not be used unless you really know your setup. Linux is nice and does let you assign this address, for a number of reasons. That's why I wrote it is likely to break routing and broadcasting. Using the network or broadcast addresses as an assigned address is likely to break the routing, but using a netmask that is of an unusual length 30, 29, or 28 (as opposed usual lengths of 8, 16, or 24 *only*) will not, as long as the computers all agree on a netmask -- which is required even for usual length netmasks. -- If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. -- Gentoo Developer Ciaran McCreesh [1] ...and knew your netmask. It's not transmitted, and in these days where we use CIDR it can't be determined from the IP. (I believe classful networks were assigned ranges, but I'm not sure.) pgpb8bGenqQvI.pgp Description: PGP signature
Re: [gentoo-user] OT - ipkungfu not
On Friday 6 October 2006 14:32, Boyd Stephen Smith Jr. wrote: Anycast is virtually unused anywhere. I'd imagine it could be used in some crazy layer 3 clustering solution, but I've never actually seen it used. Actually, ipv6 uses anycasts extensively. -- gentoo-user@gentoo.org mailing list
Anycast (was: Re: [gentoo-user] OT - ipkungfu not)
On Friday 06 October 2006 08:05, Etaoin Shrdlu [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] OT - ipkungfu not': On Friday 6 October 2006 14:32, Boyd Stephen Smith Jr. wrote: Anycast is virtually unused anywhere. I'd imagine it could be used in some crazy layer 3 clustering solution, but I've never actually seen it used. Actually, ipv6 uses anycasts extensively. Well, I thought we were limiting discussion to IPv4, but thanks for the info. I didn't know that IPv6 made much use of anycast. (My big hope is that we get wide acceptance of IPv6 multicast.) -- If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. -- Gentoo Developer Ciaran McCreesh pgpzTkEhpo6b2.pgp Description: PGP signature
Re: [gentoo-user] OT - ipkungfu not
On Wed, 2006-10-04 at 18:57 -0700, Ryan Tandy wrote: Michael Sullivan wrote: I'm having a problem with ipkungfu on one of my boxes. According to the log files, it's running, but it doesn't seem to be firewall-ing. It's not working on 192.168.1.2. Here's nmap output from 192.168.1.3: camille ~ # nmap -sT -PT 192.168.1.2 Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-10-04 20:39 CDT Interesting ports on bullet.espersunited.com (192.168.1.2): (The 1657 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 143/tcp open imap 445/tcp open microsoft-ds 587/tcp open submission 631/tcp open ipp 746/tcp open unknown 993/tcp open imaps 2049/tcp open nfs 3632/tcp open distccd MAC Address: 00:10:4B:73:8E:81 (3com) Nmap finished: 1 IP address (1 host up) scanned in 0.597 seconds OK. What does iptables -L report? Is iptables in your default runlevel? (hint: it shouldn't be.) If iptables is being started after ipkungfu for some reason, it may be overwriting ipkungfu's iptables rules with its saved (blank) ruleset. Try 'rc-update del iptables reboot' if iptables is present in any runlevels. When you start ipkungfu, are there any error messages? bullet ipkungfu # iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywherestate RELATED,ESTABLISHED LOGall -- 0.0.0.1 anywhereLOG level warning prefix `IPKF IPKungFu (--init)' DROP all -- 125.250.19.90anywhere DROP all -- abo-140-170-68.bab.modulonet.fr anywhere DROP all -- 220.163.199.101 anywhere DROP all -- 217.10.189.30anywhere ACCEPT all -- bullet.espersunited.com anywhere ACCEPT all -- camille.espersunited.com anywhere ACCEPT all -- catherine.espersunited.com anywhere ACCEPT all -- bubbles.espersonline.com anywhere ACCEPT all -- 192.168.1.101anywhere ACCEPT all -- 192.168.1.102anywhere ACCEPT all -- 192.168.1.103anywhere DROP all -- anywhere anywhererecent: CHECK seconds: 120 name: badguy side: source LOGtcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG limit: avg 3/sec burst 5 LOG level warning prefix `IPKF flags ALL: ' LOGtcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE limit: avg 3/sec burst 5 LOG level warning prefix `IPKF flags NONE: ' LOGtcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG limit: avg 3/sec burst 5 LOG level warning prefix `IPKF PORTSCAN (nmap XMAS): ' LOGtcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN limit: avg 3/sec burst 5 LOG level warning prefix `IPKF PORTSCAN (nmap FIN): ' LOGtcp -- anywhere anywheretcp flags:FIN,SYN/FIN,SYN limit: avg 3/sec burst 5 LOG level warning prefix `IPKF flags SYN,FIN: ' LOGtcp -- anywhere anywheretcp flags:SYN,RST/SYN,RST limit: avg 3/sec burst 5 LOG level warning prefix `IPKF flags SYN,RST: ' LOGtcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG limit: avg 3/sec burst 5 LOG level warning prefix `IPKF SYN,RST,ACK,FIN,URG: ' LOGtcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE limit: avg 3/sec burst 5 LOG level warning prefix `IPKF PORTSCAN (nmap NULL): ' DROP tcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG DROP tcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE DROP tcp -- anywhere anywheretcp flags:FIN,SYN/FIN,SYN DROP tcp -- anywhere anywheretcp flags:SYN,RST/SYN,RST DROP tcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG DROP tcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG DROP tcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN DROP tcp -- anywhere anywheretcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE ACCEPT icmp -- anywhere anywhereicmp echo-request LOGall -- anywhere anywherestate INVALID limit: avg 3/sec burst 5 LOG level warning prefix `IPKF Invalid TCP flag: ' DROP all -- anywhere anywherestate INVALID LOGall -f
Re: [gentoo-user] OT - ipkungfu not
Hi, On Thu, 05 Oct 2006 08:07:49 -0500 Michael Sullivan [EMAIL PROTECTED] wrote: ACCEPT all -- 192.168.1.0/24 anywherestate NEW [...] And I can still detect all those ports open from nmap on another machine. Yep. That's how it should be according to your iptables dump. I never fighted with ipkungfu, but I think the LOCAL_NET configuration opens the door for the given network. At least that's how I interpret that comment there that says you should enter loopback network data if not sure. You probably should really do that. -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu not
On Thu, 2006-10-05 at 15:22 +0200, Hans-Werner Hilse wrote: Hi, On Thu, 05 Oct 2006 08:07:49 -0500 Michael Sullivan [EMAIL PROTECTED] wrote: ACCEPT all -- 192.168.1.0/24 anywherestate NEW [...] And I can still detect all those ports open from nmap on another machine. Yep. That's how it should be according to your iptables dump. I never fighted with ipkungfu, but I think the LOCAL_NET configuration opens the door for the given network. At least that's how I interpret that comment there that says you should enter loopback network data if not sure. You probably should really do that. -hwh I've configured it this way because the IP address of each of my computers will be changing once I get this firewall thing working. I'll try that though. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu not
Hi, On Thu, 05 Oct 2006 09:45:57 -0500 Michael Sullivan [EMAIL PROTECTED] wrote: On Thu, 2006-10-05 at 15:22 +0200, Hans-Werner Hilse wrote: Yep. That's how it should be according to your iptables dump. I never fighted with ipkungfu, but I think the LOCAL_NET configuration opens the door for the given network. At least that's how I interpret that comment there that says you should enter loopback network data if not sure. You probably should really do that. I've configured it this way because the IP address of each of my computers will be changing once I get this firewall thing working. I'll try that though. Well, I meant: Networks listed in LOCAL_NET are probably _meant_ to have full access. So what you describe is essentially a misconception about what LOCAL_NET does configure. And since there is a comment in the ipkungfu config file that says you should enter 127.0.0.1 there, I guess it is meant to generally allow traffic. And you'll probably want to allow 127.0.0.1 anyway (if not even 127.0.0.0/8). That configuration seems to end up in the iptables INPUT section right before a catch-all that drops all other traffic, and that really makes me think that everything is working fine, just as configured. Probably changing it to the suggested 127.0.0.1 will fix the issue. -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu not
On Thu, 2006-10-05 at 19:33 +0200, Hans-Werner Hilse wrote: Hi, On Thu, 05 Oct 2006 09:45:57 -0500 Michael Sullivan [EMAIL PROTECTED] wrote: On Thu, 2006-10-05 at 15:22 +0200, Hans-Werner Hilse wrote: Yep. That's how it should be according to your iptables dump. I never fighted with ipkungfu, but I think the LOCAL_NET configuration opens the door for the given network. At least that's how I interpret that comment there that says you should enter loopback network data if not sure. You probably should really do that. I've configured it this way because the IP address of each of my computers will be changing once I get this firewall thing working. I'll try that though. Well, I meant: Networks listed in LOCAL_NET are probably _meant_ to have full access. So what you describe is essentially a misconception about what LOCAL_NET does configure. And since there is a comment in the ipkungfu config file that says you should enter 127.0.0.1 there, I guess it is meant to generally allow traffic. And you'll probably want to allow 127.0.0.1 anyway (if not even 127.0.0.0/8). That configuration seems to end up in the iptables INPUT section right before a catch-all that drops all other traffic, and that really makes me think that everything is working fine, just as configured. Probably changing it to the suggested 127.0.0.1 will fix the issue. -hwh What if I wanted 70.234.122.249, 70.234.122.250, and 70.234.122.251 as the network. What would the syntax for those three be? I've never been able to figure out what the 127.0.0.1/8 syntax means... -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu not
Hi, On Thu, 05 Oct 2006 13:59:06 -0500 Michael Sullivan [EMAIL PROTECTED] wrote: What if I wanted 70.234.122.249, 70.234.122.250, and 70.234.122.251 as the network. What would the syntax for those three be? I've never been able to figure out what the 127.0.0.1/8 syntax means... That slash notation is a shortcut for the netmask. /8 is the same as netmask 255.0.0.0. The number that comes after the slash is the number of bits that is set in the netmask, counting from left. E.g.: 255.0.0.0 (decimal) = ... (binary). This is the first eight bits are set. A netmask gets masked onto the IP it belongs to to determine the net. That is the network mask is combined via an AND operation with the tested IP on the one hand and with the other tested IP (e.g. our own) on the other hand. Both results must match. I'll use the private subnet 192.168.x.y as an example: You can use it as it is specified: To build some Class-C networks. Such a network is specified as a /24 network. That's the first 24 bits set and results in a netmask of 255.255.255.0. That essentially means: all addresses that match the first 24 bits of the current IP do belong to our network. Such a network would be all IPs from 192.168.x.0 (x like in our current IP) up to 192.168.x.255. If you configure it instead with a /16 netmask (255.255.0.0), it would include everything from 192.168.0.0 up to 192.168.255.255. Concerning the IPs you've mentioned, that looks like 70.234.122.249 = 01000110.11101010.0010.1001 70.234.122.250 = 01000110.11101010.0010.1010 70.234.122.251 = 01000110.11101010.0010.1011 Note that the first 29 bits are all equal. So it would be sufficient to specify a /29 netmask (255.255.255.248). Note that this will also include the IP 70.234.122.248. It would probably not be wise to actually set this as an IP netmask when configuring the interfaces (will most certainly break routing and broadcasts), but it can be used in iptables configuration to match that given range of hosts. I don't know ipkungfu, but I would be surprised if there wasn't the possibility to specify more than one LOCAL_NET. And a better name for that config setting would actually be ALLOW_NET or similar. -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu not
On Thursday 05 October 2006 14:44, Hans-Werner Hilse [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] OT - ipkungfu not': Concerning the IPs you've mentioned, that looks like 70.234.122.249 = 01000110.11101010.0010.1001 70.234.122.250 = 01000110.11101010.0010.1010 70.234.122.251 = 01000110.11101010.0010.1011 Note that the first 29 bits are all equal. In addition, the first 30 bits are all equal. So it would be sufficient to specify a /29 netmask (255.255.255.248). However, we can't specify a /30 because two addresses in each block (the highest and the lowest) are reserved for network (anycast) and broadcast (multicast). You don't have to know what these are used for, just that you can't assign them. Since one of your addresses is all 1's after the common part (IPv4 addres is 32 bits, common part is 30 bits, so that means the 2 bits at the end are both 1), you have to move up to a larger netmask (in this case the next largest, /29, will do). Note that this will also include the IP 70.234.122.248. As would a /30, but in both cases it will be reserved (for network) and can't be assigned to a single machine. In a /30 your 70.234.122.251 would be reserved (for broadcast) which is why you need to use /29. It would probably not be wise to actually set this as an IP netmask when configuring the interfaces (will most certainly break routing and broadcasts), ??? SBC assigns our household a /29 block. It is *required* that we configure that as our 255.255.255.248 as our netmask if we want routing to work. I've also used /30 and /28 networks for routing. Classful addressing is dead, long live CIDR addressing. -- If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. -- Gentoo Developer Ciaran McCreesh pgpzAkI0EfNwv.pgp Description: PGP signature
[gentoo-user] OT - ipkungfu not
I'm having a problem with ipkungfu on one of my boxes. According to the log files, it's running, but it doesn't seem to be firewall-ing. It's not working on 192.168.1.2. Here's nmap output from 192.168.1.3: camille ~ # nmap -sT -PT 192.168.1.2 Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-10-04 20:39 CDT Interesting ports on bullet.espersunited.com (192.168.1.2): (The 1657 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 143/tcp open imap 445/tcp open microsoft-ds 587/tcp open submission 631/tcp open ipp 746/tcp open unknown 993/tcp open imaps 2049/tcp open nfs 3632/tcp open distccd MAC Address: 00:10:4B:73:8E:81 (3com) Nmap finished: 1 IP address (1 host up) scanned in 0.597 seconds Here's /etc/ipkungfu/ipkungfu.conf. It's the only file I've altered for ipkungfu: # Please read the README and FAQ for more information # Some distros (most notably Redhat) don't have # everything we need in $PATH so we specify it here. # Make sure modprobe, iptables, and route are here, # as well as ordinary items such as echo and grep. # Default is as shown in the example below. #PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:/usr/local/sbin # Your external interface # This is the one that connects to the internet. # Ipkungfu will detect this if you don't specify. EXT_NET=eth0 #EXT_NET=eth1 #EXT_NET=ppp0 # Your internal interfaces, if any. If you have more # than 1 internal interface, separate them with # spaces. If you only have one interface, put lo # here. Default is auto-detected. #INT_NET=eth0 #INT_NET=eth1 #INT_NET=lo # IP Range of your internal network. Use 127.0.0.1 # for a standalone machine. Default is a reasonable # guess. LOCAL_NET=192.168.1.0/255.255.255.0 # Set this to 0 for a standalone machine, or 1 for # a gateway device to share an Internet connection. # Default is 1. #GATEWAY=1 # TCP ports you want to allow for incoming traffic # Don't add ports here that you intend to forward. # This should be a list of tcp ports that have # servers listening on them on THIS machine, # separated by spaces. Default is none. ALLOWED_TCP_IN=21 22 25 80 # UDP ports to allow for incoming traffic # See the comments above for ALLOWED_TCP_IN #ALLOWED_UDP_IN= # Temporarily block future connection attempts from an # IP that hits these ports (If module is present) #FORBIDDEN_PORTS=135 137 139 # Drop all ping packets? # Set to 1 for yes, 0 for no. Default is no. #BLOCK_PINGS=0 # Possible values here are DROP, REJECT, or MIRROR # # DROP means your computer will not respond at all. Stealth mode # # REJECT means your computer will respond with a # message that the packet was rejected. # # MIRROR, if your kernel supports it, will swap the source and # destination IP addresses, and send the offending packet back # where it came from. USE WITH EXTREME CAUTION! Only use this if you fully # understand the consequences. # # The safest option, and the default in each case,, is DROP. Don't change # unless you fully understand this. # What to do with 'probably malicious' packets #SUSPECT=REJECT SUSPECT=DROP # What to do with obviously invalid traffic # This is also the action for FORBIDDEN_PORTS #KNOWN_BAD=REJECT KNOWN_BAD=DROP # What to do with port scans #PORT_SCAN=REJECT PORT_SCAN=DROP # How should ipkungfu determine your IP address? The default # answer, NONE, will cause ipkungfu to not use the few # features that require it to know your external IP address. # This option is good for dialup users who run ipkungfu on # bootup, since dialup users rarely use the features that # require this, and the IP address for a dialup connection # generally isn't known at bootup. AUTO will cause # ipkungfu to automatically determine the IP address of # $EXT_NET when it is started. If you have a static IP # address you can simply enter your IP address here. # If you do port forwarding and your ISP changes your IP # address, choose NONE here, or your port forwarding # will break when your IP address changes. Default is # NONE. #GET_IP=NONE GET_IP=AUTO #GET_IP=192.268.1.2 # If the target for identd (113/tcp) is DROP, it can take # a long time to connect to some IRC servers. Set this to # 1 to speed up these connections with a negligible cost # to security. Identd probes will be rejected with the # 'reject-with-tcp-reset' option to close the connection # gracefully. If you want to actually allow ident probes, # and you're running an identd, and you've allowed port # 113 in ALLOWED_TCP_IN, set this to 0. Default is 0. DONT_DROP_IDENTD=1 # Set this to 0 if you're running ipkungfu on a machine # inside your LAN. This will cause private IP addresses # coming in on $EXT_NET to be identified as a spoof, # which would be inaccurate on intra-LAN traffic # This will cause private IP addresses coming in on # $EXT_NET
Re: [gentoo-user] OT - ipkungfu not
Michael Sullivan wrote: I'm having a problem with ipkungfu on one of my boxes. According to the log files, it's running, but it doesn't seem to be firewall-ing. It's not working on 192.168.1.2. Here's nmap output from 192.168.1.3: camille ~ # nmap -sT -PT 192.168.1.2 Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-10-04 20:39 CDT Interesting ports on bullet.espersunited.com (192.168.1.2): (The 1657 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 143/tcp open imap 445/tcp open microsoft-ds 587/tcp open submission 631/tcp open ipp 746/tcp open unknown 993/tcp open imaps 2049/tcp open nfs 3632/tcp open distccd MAC Address: 00:10:4B:73:8E:81 (3com) Nmap finished: 1 IP address (1 host up) scanned in 0.597 seconds OK. What does iptables -L report? Is iptables in your default runlevel? (hint: it shouldn't be.) If iptables is being started after ipkungfu for some reason, it may be overwriting ipkungfu's iptables rules with its saved (blank) ruleset. Try 'rc-update del iptables reboot' if iptables is present in any runlevels. When you start ipkungfu, are there any error messages? -- gentoo-user@gentoo.org mailing list
[gentoo-user] OT - ipkungfu
I'm trying to install ipkungfoo on my server box. I followed the instructions in the README file. When I went to start it, it gave me a string of errors, that I'm not sure how to fix: bullet ipkungfu # ipkungfu Checking configuration... FATAL: Module ip_tables not found. iptables v1.3.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. ipkungfu can't create new chains or the script was interrupted previously! Flushing iptables rulesets... FATAL: Module ip_tables not found. iptables v1.3.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. Clearing old chains and tables... cat: /proc/net/ip_tables_names: No such file or directory Your kernel lacks LOG support required by this script. Aborting. Any clues? It sounds to me like it's a kernel module thing, but what would a kernel module have to do with a firewall? It said that iptables might be out of date, but iptables was emerged right before ipkungfu. If it matters, the kernel info is: bullet ipkungfu # uname -a Linux bullet 2.6.14-gentoo-r5 #1 SMP Mon Dec 26 14:54:40 CST 2005 i586 AMD-K6(tm) 3D processor AuthenticAMD GNU/Linux -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu
On 1/11/06, Michael Sullivan [EMAIL PROTECTED] wrote: I'm trying to install ipkungfoo on my server box.I followed theinstructions in the README file.When I went to start it, it gave me astring of errors, that I'm not sure how to fix:bullet ipkungfu # ipkungfu Checking configuration...FATAL: Module ip_tables not found.iptables v1.3.4: can't initialize iptables table `filter': iptables who?(do you need to insmod?)Perhaps iptables or your kernel needs to be upgraded. ipkungfu can't create new chains or the script was interruptedpreviously!Flushing iptables rulesets...FATAL: Module ip_tables not found.iptables v1.3.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?)Perhaps iptables or your kernel needs to be upgraded.Clearing old chains and tables...cat: /proc/net/ip_tables_names: No such file or directoryYour kernel lacks LOG support required by this script. Aborting. Any clues?It sounds to me like it's a kernel module thing, but whatwould a kernel module have to do with a firewall?It said that iptablesmight be out of date, but iptables was emerged right before ipkungfu. If it matters, the kernel info is:bullet ipkungfu # uname -aLinux bullet 2.6.14-gentoo-r5 #1 SMP Mon Dec 26 14:54:40 CST 2005 i586AMD-K6(tm) 3D processor AuthenticAMD GNU/Linux-- gentoo-user@gentoo.org mailing listMichael,there is a whole section in menuconfig netfilter the firewall is a kernel thing. you need to have support in your kernel, although i would thing the iptables ebuild would look for it. -- if you are tired of virii look at http://fedora.redhat.com/ and for those of you still using AOL's messangertry out http://gaim.sf.net/... and for photoshop see http://www.gimp.orguse http://www.gimp.org/
Re: [gentoo-user] OT - ipkungfu
Michael Sullivan schreef: I'm trying to install ipkungfoo on my server box. I followed the instructions in the README file. When I went to start it, it gave me a string of errors, that I'm not sure how to fix: bullet ipkungfu # ipkungfu Checking configuration... FATAL: Module ip_tables not found. iptables v1.3.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. ipkungfu can't create new chains or the script was interrupted previously! Flushing iptables rulesets... FATAL: Module ip_tables not found. iptables v1.3.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. Clearing old chains and tables... cat: /proc/net/ip_tables_names: No such file or directory Your kernel lacks LOG support required by this script. Aborting. Any clues? It sounds to me like it's a kernel module thing, but what would a kernel module have to do with a firewall? The Linux firewall (iptables) *is* a kernel module. Meaning that it has to be enabled in the kernel, and it doesn't sound like it is. In my (extremely limited) experience (I use Firestarter to control iptables and its rules), it is best to compile iptables and the various filters (basically all of them) as modules into the kernel rather than statically. Certainly for Firestarter, and it sounds like for ipkungfu as well, this is preferable, so that the utility can grab and load the modules it needs on the fly. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu
On Wed, 2006-01-11 at 16:30 -0500, Andrew Frink wrote: On 1/11/06, Michael Sullivan [EMAIL PROTECTED] wrote: I'm trying to install ipkungfoo on my server box. I followed the instructions in the README file. When I went to start it, it gave me a string of errors, that I'm not sure how to fix: bullet ipkungfu # ipkungfu Checking configuration... FATAL: Module ip_tables not found. iptables v1.3.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. ipkungfu can't create new chains or the script was interrupted previously! Flushing iptables rulesets... FATAL: Module ip_tables not found. iptables v1.3.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. Clearing old chains and tables... cat: /proc/net/ip_tables_names: No such file or directory Your kernel lacks LOG support required by this script. Aborting. Any clues? It sounds to me like it's a kernel module thing, but what would a kernel module have to do with a firewall? It said that iptables might be out of date, but iptables was emerged right before ipkungfu. If it matters, the kernel info is: bullet ipkungfu # uname -a Linux bullet 2.6.14-gentoo-r5 #1 SMP Mon Dec 26 14:54:40 CST 2005 i586 AMD-K6(tm) 3D processor AuthenticAMD GNU/Linux -- gentoo-user@gentoo.org mailing list Michael, there is a whole section in menuconfig netfilter the firewall is a kernel thing. you need to have support in your kernel, although i would thing the iptables ebuild would look for it. -- if you are tired of virii look at http://fedora.redhat.com/ and for those of you still using AOL's messanger try out http://gaim.sf.net/... and for photoshop see http://www.gimp.org use http://www.gimp.org/ Would that be Networking--Networking Options--Network Packet Filtering (replaces ipchains) off of genkernel --menuconfig all? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] OT - ipkungfu
On 1/11/06, Michael Sullivan [EMAIL PROTECTED] wrote: On Wed, 2006-01-11 at 16:30 -0500, Andrew Frink wrote: On 1/11/06, Michael Sullivan [EMAIL PROTECTED] wrote: I'm trying to install ipkungfoo on my server box.I followed the instructions in the README file.When I went to start it, it gave me a string of errors, that I'm not sure how to fix: bullet ipkungfu # ipkungfu Checking configuration... FATAL: Module ip_tables not found. iptables v1.3.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. ipkungfu can't create new chains or the script was interrupted previously! Flushing iptables rulesets... FATAL: Module ip_tables not found. iptables v1.3.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. Clearing old chains and tables... cat: /proc/net/ip_tables_names: No such file or directory Your kernel lacks LOG support required by this script. Aborting. Any clues?It sounds to me like it's a kernel module thing, but what would a kernel module have to do with a firewall?It said that iptables might be out of date, but iptables was emerged right before ipkungfu. If it matters, the kernel info is: bullet ipkungfu # uname -a Linux bullet 2.6.14-gentoo-r5 #1 SMP Mon Dec 26 14:54:40 CST 2005 i586 AMD-K6(tm) 3D processor AuthenticAMD GNU/Linux -- gentoo-user@gentoo.org mailing list Michael, there is a whole section in menuconfig netfilter the firewall is a kernel thing. you need to have support in your kernel, although i would thing the iptables ebuild would look for it. -- if you are tired of virii look at http://fedora.redhat.com/ and for those of you still using AOL's messanger try out http://gaim.sf.net/... and for photoshop see http://www.gimp.org use http://www.gimp.org/Would that be Networking--Networking Options--Network Packet Filtering (replaces ipchains) off of genkernel --menuconfig all?--gentoo-user@gentoo.org mailing listYes that would be it.-Cynyr -- if you are tired of virii look at http://fedora.redhat.com/ and for those of you still using AOL's messangertry out http://gaim.sf.net/. .. and for photoshop see http://www.gimp.orguse http://www.gimp.org/
