[gentoo-user] OT - ipkungfu not

[gentoo-user] OT - ipkungfu not

[Michael Sullivan]

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 to be identified as a spoof. Default is 1.
#DISALLOW_PRIVATE=1

# For reasons unknown to me, ipkungfu sometimes causes
# kernel panics when run at init time. This is my
# attempt to work around that.  Ipkungfu will wait
# the specified number of seconds before starting, to
# let userspace/kernel traffic catch up before executing.
# Default is 0.
WAIT_SECONDS=5

# This option, if enabled, will cause ipkungfu to set
# the default policy on all builtin chains in the filter
# table to ACCEPT in the event of a failure.  This is 
# intended for remote administrators who may be locked 
# out of the firewall if ipkungfu fails.  A warning to 
# this effect will be echoed so that the situation can be
# rectified quickly.  This is the same as running
# ipkungfu with --failsafe.  Default is 0.
#FAILSAFE=0

This config is the exact same as on my other two boxes, except that the
other two work.  What gives?

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] OT - ipkungfu not

[Ryan Tandy]

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

Re: [gentoo-user] OT - ipkungfu not

[Michael Sullivan]

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             anywhere            state
RELATED,ESTABLISHED
LOG        all  --  0.0.0.1              anywhere            LOG level
warning prefix `IPKF IPKungFu (--init)'
DROP       all  --  125.250.19.90        anywhere
DROP       all  --  abo-140-170-68.bab.modulonet.fr  anywhere
DROP       all  --  220.163.199.101      anywhere
DROP       all  --  217.10.189.30        anywhere
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.101        anywhere
ACCEPT     all  --  192.168.1.102        anywhere
ACCEPT     all  --  192.168.1.103        anywhere
DROP       all  --  anywhere             anywhere            recent:
CHECK seconds: 120 name: badguy side: source
LOG        tcp  --  anywhere             anywhere            tcp
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: '
LOG        tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE limit: avg 3/sec burst 5 LOG level
warning prefix `IPKF flags NONE: '
LOG        tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG limit: avg 3/sec burst 5 LOG
level warning prefix `IPKF PORTSCAN (nmap XMAS): '
LOG        tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN limit: avg 3/sec burst 5 LOG level
warning prefix `IPKF PORTSCAN (nmap FIN): '
LOG        tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN/FIN,SYN limit: avg 3/sec burst 5 LOG level warning prefix
`IPKF flags SYN,FIN: '
LOG        tcp  --  anywhere             anywhere            tcp
flags:SYN,RST/SYN,RST limit: avg 3/sec burst 5 LOG level warning prefix
`IPKF flags SYN,RST: '
LOG        tcp  --  anywhere             anywhere            tcp
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: '
LOG        tcp  --  anywhere             anywhere            tcp
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             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN/FIN,SYN
DROP       tcp  --  anywhere             anywhere            tcp
flags:SYN,RST/SYN,RST
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE
ACCEPT     icmp --  anywhere             anywhere            icmp
echo-request
LOG        all  --  anywhere             anywhere            state
INVALID limit: avg 3/sec burst 5 LOG level warning prefix `IPKF Invalid
TCP flag: '
DROP       all  --  anywhere             anywhere            state
INVALID
LOG        all  -f  anywhere             anywhere            limit: avg
3/sec burst 5 LOG level warning prefix `IPKF Fragmented Packet: '
DROP       all  -f  anywhere             anywhere
LOG        icmp --  anywhere             anywhere            icmp
timestamp-request limit: avg 3/sec burst 5 LOG level warning prefix
`IPKF ICMP Timestamp: '
DROP       icmp --  anywhere             anywhere            icmp
timestamp-request
syn-flood  tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,ACK/SYN
LOG        tcp  --  anywhere             anywhere            tcp flags:!
SYN,RST,ACK/SYN state NEW limit: avg 3/sec burst 5 LOG level warning
prefix `IPKF New Not SYN: '
DROP       tcp  --  anywhere             anywhere            tcp flags:!
SYN,RST,ACK/SYN state NEW
DROP       tcp  --  anywhere             anywhere            multiport
dports netbios-ns,6666
DROP       udp  --  anywhere             anywhere            multiport
dports ms-sql-m
ACCEPT     tcp  --  anywhere             anywhere            state NEW
multiport dports ftp,ssh,smtp,http
ACCEPT     all  --  anywhere             anywhere            state NEW
ACCEPT     all  --  192.168.1.0/24       anywhere            state NEW
REJECT     tcp  --  anywhere             anywhere            tcp
dpt:auth reject-with tcp-reset
LOG       !icmp --  anywhere             anywhere            limit: avg
3/sec burst 5 LOG level warning prefix `IPKF INPUT Catch-all: '
DROP       all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state
RELATED,ESTABLISHED
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.101        anywhere
ACCEPT     all  --  192.168.1.102        anywhere
ACCEPT     all  --  192.168.1.103        anywhere
DROP       all  --  anywhere             anywhere            recent:
CHECK seconds: 120 name: badguy side: source
LOG        tcp  --  anywhere             anywhere            tcp
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: '
LOG        tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE limit: avg 3/sec burst 5 LOG level
warning prefix `IPKF flags NONE: '
LOG        tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG limit: avg 3/sec burst 5 LOG
level warning prefix `IPKF flags FIN,URG,PSH: '
LOG        tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN limit: avg 3/sec burst 5 LOG level
warning prefix `IPKF PORTSCAN (nmap XMAS): '
LOG        tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN/FIN,SYN limit: avg 3/sec burst 5 LOG level warning prefix
`IPKF flags SYN,FIN: '
LOG        tcp  --  anywhere             anywhere            tcp
flags:SYN,RST/SYN,RST limit: avg 3/sec burst 5 LOG level warning prefix
`IPKF flags SYN,RST: '
LOG        tcp  --  anywhere             anywhere            tcp
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: '
LOG        tcp  --  anywhere             anywhere            tcp
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             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN/FIN,SYN
DROP       tcp  --  anywhere             anywhere            tcp
flags:SYN,RST/SYN,RST
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
DROP       tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN
LOG        all  --  anywhere             anywhere            state
INVALID limit: avg 3/sec burst 5 LOG level warning prefix `IPKF Invalid
TCP flag: '
DROP       all  --  anywhere             anywhere            state
INVALID
LOG        all  -f  anywhere             anywhere            limit: avg
3/sec burst 5 LOG level warning prefix `IPKF Fragmented Packet: '
DROP       all  -f  anywhere             anywhere
LOG        icmp --  anywhere             anywhere            icmp
timestamp-request limit: avg 3/sec burst 5 LOG level warning prefix
`IPKF ICMP Timestamp: '
DROP       icmp --  anywhere             anywhere            icmp
timestamp-request
syn-flood  tcp  --  anywhere             anywhere            tcp
flags:FIN,SYN,RST,ACK/SYN
LOG        tcp  --  anywhere             anywhere            tcp flags:!
SYN,RST,ACK/SYN state NEW limit: avg 3/sec burst 5 LOG level warning
prefix `IPKF New Not SYN: '
DROP       tcp  --  anywhere             anywhere            tcp flags:!
SYN,RST,ACK/SYN state NEW
DROP       tcp  --  anywhere             anywhere            multiport
dports netbios-ns,6666
DROP       udp  --  anywhere             anywhere            multiport
dports ms-sql-m
REJECT     tcp  --  anywhere             anywhere            tcp
dpt:auth reject-with tcp-reset

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state
RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            state NEW

Chain syn-flood (2 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere            limit: avg
10/sec burst 24
LOG        all  --  anywhere             anywhere            limit: avg
3/sec burst 5 LOG level warning prefix `IPKF SYN flood: '
DROP       all  --  anywhere             anywhere
bullet ipkungfu # rc-update show | grep 'iptables'
bullet ipkungfu # /etc/init.d/ipkungfu restart
 * Stopping ipkungfu ...
Stopping ipkungfu:                                              [  OK  ]
[ ok ] * Starting ipkungfu ...
[ ok ]bullet ipkungfu #

And I can still detect all those ports open from nmap on another
machine.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] OT - ipkungfu not

[Hans-Werner Hilse]

Hi,

On Thu, 05 Oct 2006 08:07:49 -0500 Michael Sullivan
<michael@espersunited.com> wrote:

> ACCEPT     all  --  192.168.1.0/24       anywhere            state 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

[Michael Sullivan]

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
> <michael@espersunited.com> wrote:
> 
> > ACCEPT     all  --  192.168.1.0/24       anywhere            state 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

[Hans-Werner Hilse]

Hi,

On Thu, 05 Oct 2006 09:45:57 -0500
Michael Sullivan <michael@espersunited.com> 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

[Michael Sullivan]

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 <michael@espersunited.com> 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

[Hans-Werner Hilse]

Hi,

On Thu, 05 Oct 2006 13:59:06 -0500
Michael Sullivan <michael@espersunited.com> 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) = 11111111.00000000.00000000.00000000 (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.01111010.11111001
70.234.122.250 = 01000110.11101010.01111010.11111010
70.234.122.251 = 01000110.11101010.01111010.11111011

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

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

On Thursday 05 October 2006 14:44, Hans-Werner Hilse <hilse@web.de> wrote 
about 'Re: [gentoo-user] OT - ipkungfu not':
> Concerning the IPs you've mentioned, that looks like
> 70.234.122.249 = 01000110.11101010.01111010.11111001
> 70.234.122.250 = 01000110.11101010.01111010.11111010
> 70.234.122.251 = 01000110.11101010.01111010.11111011
>
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] OT - ipkungfu not

[Hans-Werner Hilse]

Hi,

On Thu, 5 Oct 2006 18:53:55 -0500 "Boyd Stephen Smith Jr."
<bss03@volumehost.net> wrote:

> On Thursday 05 October 2006 14:44, Hans-Werner Hilse <hilse@web.de>
> 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

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

On Friday 06 October 2006 03:13, Hans-Werner Hilse <hilse@web.de> wrote 
about 'Re: [gentoo-user] OT - ipkungfu not':
> On Thu, 5 Oct 2006 18:53:55 -0500 "Boyd Stephen Smith Jr."
> <bss03@volumehost.net> 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.)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Anycast (was: Re: [gentoo-user] OT - ipkungfu not)

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

On Friday 06 October 2006 08:05, Etaoin Shrdlu <shrdlu@unlimitedmail.org> 
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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] OT - ipkungfu not

[Etaoin Shrdlu]

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