• Allow new incoming connection?

    From buck@110:300/1.1 to All on Fri Jun 21 20:29:04 2013
    I recently acquired a B&N Nook, which has caused me to raise these
    questions.

    First, a definition: Ports greater than 1024 are "unreserved" or "high" ports.

    My firewall is configured to allow ESTABLISHED and RELATED tcp
    connections where both source and destination ports are high, but it
    rejects NEW unless these are specifically allowed. For example, I allow incoming VNC on --dport 5900 to one computer and 6502 (for a program
    similar to VNC called NetOp) on another.

    The Nook is going nuts because it is being prevented from establishing
    NEW connections from google (74.125.142.0/24) on high ports.

    Is my rejection of NEW on high ports wrong? Should I allow just google?
    What is best practice (and why?)?
    --
    buck

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Say What? (110:300/1.1@linuxnet)
  • From Aragorn@110:300/1.1 to All on Fri Jun 21 20:36:56 2013
    On Friday 21 June 2013 20:29, buck conveyed the following to comp.os.linux.security...

    I recently acquired a B&N Nook, which has caused me to raise these
    questions.

    First, a definition: Ports greater than 1024 are "unreserved" or
    "high" ports.

    My firewall is configured to allow ESTABLISHED and RELATED tcp
    connections where both source and destination ports are high, but it
    rejects NEW unless these are specifically allowed. For example, I
    allow incoming VNC on --dport 5900 to one computer and 6502 (for a
    program similar to VNC called NetOp) on another.

    The Nook is going nuts because it is being prevented from establishing
    NEW connections from google (74.125.142.0/24) on high ports.

    Is my rejection of NEW on high ports wrong?

    In my opinion: yes.

    Should I allow just google? What is best practice (and why?)?

    The thing most newcomers to GNU/Linux always tend to misunderstand is firewalls, and especially so when they come from the Microsoft Windows
    world.

    Windows listens to just about every port - high or low - by default, and
    thus it needs a userspace firewall to stop things from coming in and
    things from phoning home. GNU/Linux is not like that. If you don't
    have any daemons or applications listening on a particular port, then
    all traffic to that port will be ignored by default. By consequence,
    there is no need to add a rule to your firewall - which is the Linux
    kernel itself, by the way - for traffic you don't want.

    You're not in Redmond anymore, Toto. ;-)

    --
    = Aragorn =
    GNU/Linux user #223157 - http://www.linuxcounter.net

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Strider (110:300/1.1@linuxnet)
  • From Richard Kettlewell@110:300/1.1 to All on Fri Jun 21 21:01:54 2013
    buck <buck@private.mil> writes:
    I recently acquired a B&N Nook, which has caused me to raise these questions.

    First, a definition: Ports greater than 1024 are "unreserved" or "high" ports.

    My firewall is configured to allow ESTABLISHED and RELATED tcp
    connections where both source and destination ports are high, but it
    rejects NEW unless these are specifically allowed. For example, I allow incoming VNC on --dport 5900 to one computer and 6502 (for a program
    similar to VNC called NetOp) on another.

    The Nook is going nuts because it is being prevented from establishing
    NEW connections from google (74.125.142.0/24) on high ports.

    To or from google?

    Is my rejection of NEW on high ports wrong?

    It seems like an odd distinction to build into the policy.

    Should I allow just google? What is best practice (and why?)?

    For inbound connections, the obvious cautious approach is to decide what
    you want to allow, permit that, and reject everything else.

    For outbound connections, it depends how much you trust the devices
    attached to network, for some value of “trust”. If you’re happy they’ll
    behave well then allow all outbound connections. If you suspect they’ll
    do something stupid then take the same approach as for inbound
    connections.

    --
    http://www.greenend.org.uk/rjk/

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Anjou (110:300/1.1@linuxnet)
  • From buck@110:300/1.1 to All on Sat Jun 22 08:35:40 2013
    Richard Kettlewell <rjk@greenend.org.uk> wrote in news:87wqpnwan1.fsf@araminta.anjou.terraraq.org.uk:

    buck <buck@private.mil> writes:
    I recently acquired a B&N Nook, which has caused me to raise these
    questions.

    First, a definition: Ports greater than 1024 are "unreserved" or
    "high" ports.

    EDIT: I meant greater than 1023. 1024 is a "high port"

    My firewall is configured to allow ESTABLISHED and RELATED tcp
    connections where both source and destination ports are high, but it
    rejects NEW unless these are specifically allowed. For example, I
    allow incoming VNC on --dport 5900 to one computer and 6502 (for a
    program similar to VNC called NetOp) on another.

    The Nook is going nuts because it is being prevented from
    establishing NEW connections from google (74.125.142.0/24) on high
    ports.

    To or from google?


    I said what I meant. FROM google. NEW, not ESTABLISHED and not RELATED.


    Is my rejection of NEW on high ports wrong?

    It seems like an odd distinction to build into the policy.

    In what way? I think allowing incoming connections requires justification,

    Should I allow just google? What is best practice (and why?)?

    For inbound connections, the obvious cautious approach is to decide
    what you want to allow, permit that, and reject everything else.

    Which I do. I just don't know if it matters when the incoming connection
    is on a high port, because there's no daemon\service associated.

    For outbound connections, it depends how much you trust the devices
    attached to network,

    N/A
    --
    buck

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Say What? (110:300/1.1@linuxnet)
  • From buck@110:300/1.1 to All on Sat Jun 22 08:46:17 2013
    Aragorn <thorongil@telenet.be.invalid> wrote in news:kq266k$3au$1@dont- email.me:

    Is my rejection of NEW on high ports wrong?

    In my opinion: yes.

    Should I allow just google? What is best practice (and why?)?

    The thing most newcomers to GNU/Linux always tend to misunderstand is firewalls, and especially so when they come from the Microsoft Windows world.

    Windows listens to just about every port - high or low - by default,
    and
    thus it needs a userspace firewall to stop things from coming in and
    things from phoning home. GNU/Linux is not like that. If you don't
    have any daemons or applications listening on a particular port, then
    all traffic to that port will be ignored by default. By consequence,
    there is no need to add a rule to your firewall - which is the Linux
    kernel itself, by the way - for traffic you don't want.

    You're not in Redmond anymore, Toto. ;-)

    ???

    See http://andthatsjazz.org/customfw.html
    and then maybe you can make such comments.
    --
    buck

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Say What? (110:300/1.1@linuxnet)
  • From Aragorn@110:300/1.1 to All on Sat Jun 22 08:53:24 2013
    On Saturday 22 June 2013 08:46, buck conveyed the following to comp.os.linux.security...

    Aragorn <thorongil@telenet.be.invalid> wrote in
    news:kq266k$3au$1@dont- email.me:

    Is my rejection of NEW on high ports wrong?

    In my opinion: yes.

    Should I allow just google? What is best practice (and why?)?

    The thing most newcomers to GNU/Linux always tend to misunderstand is
    firewalls, and especially so when they come from the Microsoft
    Windows world.

    Windows listens to just about every port - high or low - by default,
    and thus it needs a userspace firewall to stop things from coming in
    and things from phoning home. GNU/Linux is not like that. If you
    don't have any daemons or applications listening on a particular
    port, then all traffic to that port will be ignored by default. By
    consequence, there is no need to add a rule to your firewall - which
    is the Linux kernel itself, by the way - for traffic you don't want.

    You're not in Redmond anymore, Toto. ;-)

    ???

    See http://andthatsjazz.org/customfw.html
    and then maybe you can make such comments.

    Yes, so what's your point?

    --
    = Aragorn =
    GNU/Linux user #223157 - http://www.linuxcounter.net

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Strider (110:300/1.1@linuxnet)
  • From Richard Kettlewell@110:300/1.1 to All on Sat Jun 22 10:39:46 2013
    buck <buck@private.mil> writes:
    Richard Kettlewell <rjk@greenend.org.uk> wrote in
    buck <buck@private.mil> writes:

    The Nook is going nuts because it is being prevented from
    establishing NEW connections from google (74.125.142.0/24) on high
    ports.

    To or from google?

    I said what I meant. FROM google. NEW, not ESTABLISHED and not
    RELATED.

    ‘NEW’ doesn’t imply that the connections are inbound, it just means the connection tracker hasn’t seen packets from that connection before.

    What do they look like in tcpdump?

    Is my rejection of NEW on high ports wrong?

    It seems like an odd distinction to build into the policy.

    In what way? I think allowing incoming connections requires
    justification,

    I mean distinguishing high ports from low ports for this purpose seems
    odd.

    Should I allow just google? What is best practice (and why?)?

    For inbound connections, the obvious cautious approach is to decide
    what you want to allow, permit that, and reject everything else.

    Which I do. I just don't know if it matters when the incoming
    connection is on a high port, because there's no daemon\service
    associated.

    If nothing has bound to a port then the host will reject incoming
    connections. Whether the port number is above or below 1024 makes no
    different whatsoever.

    --
    http://www.greenend.org.uk/rjk/

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Anjou (110:300/1.1@linuxnet)
  • From David Hough@110:300/1.1 to All on Sat Jun 22 13:18:51 2013
    buck wrote:

    I recently acquired a B&N Nook, which has caused me to raise these
    questions.

    First, a definition: Ports greater than 1024 are "unreserved" or "high" ports.

    My firewall is configured to allow ESTABLISHED and RELATED tcp
    connections where both source and destination ports are high, but it
    rejects NEW unless these are specifically allowed. For example, I allow incoming VNC on --dport 5900 to one computer and 6502 (for a program
    similar to VNC called NetOp) on another.

    The Nook is going nuts because it is being prevented from establishing
    NEW connections from google (74.125.142.0/24) on high ports.

    Is my rejection of NEW on high ports wrong? Should I allow just google?
    What is best practice (and why?)?

    A few things - if you're using a NAT router then that pretty much stops anything inbound unless you make specific provision to forward a port to an internal IP address. It sounds as though this may be what you're doing.

    If so, rejecting NEW is only really blocking outbound stuff from the Nook
    and I can understand why it might get upset. My Nook doesn't get upset and I don't allow in anything that isn't to one of a few specific ports on
    specific machines.

    As an aside, unencrypted VNC over the internet is probably not a good thing, safer to allow in ssh and port forward over that.

    Dave


    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: the bus stop (110:300/1.1@linuxnet)
  • From Trevor Hemsley@1:0/0 to All on Sat Jun 22 14:37:14 2013
    On Fri, 21 Jun 2013 18:29:04 UTC in comp.os.linux.security, buck <buck@private.mil> wrote:

    I recently acquired a B&N Nook, which has caused me to raise these questions.

    First, a definition: Ports greater than 1024 are "unreserved" or "high" ports.

    My firewall is configured to allow ESTABLISHED and RELATED tcp
    connections where both source and destination ports are high, but it
    rejects NEW unless these are specifically allowed. For example, I allow incoming VNC on --dport 5900 to one computer and 6502 (for a program
    similar to VNC called NetOp) on another.

    The Nook is going nuts because it is being prevented from establishing
    NEW connections from google (74.125.142.0/24) on high ports.

    Is my rejection of NEW on high ports wrong? Should I allow just google? What is best practice (and why?)?

    Rather than telling us what you think your firewall rules do, how about posting
    the output of `iptables-save` so we can see what the rules do?

    --
    Trevor Hemsley, Brighton, UK
    Trevor dot Hemsley at ntlworld dot com

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: The Kofo BBS MBSE - telnet://fido1.kofobbs.ne
  • From Pascal Hambourg@110:300/1.1 to All on Sat Jun 22 14:47:48 2013
    Reply-To: pascal.news@plouf.fr.eu.org

    Hello,

    Aragorn a crit :

    Windows listens to just about every port - high or low - by default, and thus it needs a userspace firewall to stop things from coming in and
    things from phoning home.

    This is plainly wrong. Or maybe we have a different interpretation of
    the word "listen".

    GNU/Linux is not like that. If you don't
    have any daemons or applications listening on a particular port, then
    all traffic to that port will be ignored by default.

    This is plainly wrong too. Linux replies to packets sent to a closed
    port. Just as Windows does.

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Plouf ! (110:300/1.1@linuxnet)
  • From Pascal Hambourg@110:300/1.1 to All on Sat Jun 22 14:56:02 2013
    Reply-To: pascal.news@plouf.fr.eu.org

    Hello,

    buck a crit :

    My firewall is configured to allow ESTABLISHED and RELATED tcp
    connections where both source and destination ports are high, but it
    rejects NEW unless these are specifically allowed.

    Please note that NEW, ESTABLISHED and RELATED are _packet_ states, not _connection_ states.

    Also, accepting ESTABLISHED and RELATED packets with high source and destination ports only seems way to strict : it prohibits any continuous communication using low ports such as HTTP.

    What's your ruleset (printed by iptables-save) ?
    What are your requirements ?

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Plouf ! (110:300/1.1@linuxnet)
  • From Aragorn@110:300/1.1 to All on Sat Jun 22 15:09:00 2013
    On Saturday 22 June 2013 14:47, Pascal Hambourg conveyed the following
    to comp.os.linux.security...

    Hello,

    Aragorn a crit :

    Windows listens to just about every port - high or low - by default,
    and thus it needs a userspace firewall to stop things from coming in
    and things from phoning home.

    This is plainly wrong. Or maybe we have a different interpretation of
    the word "listen".

    I agree that my choice of words was not exactly optimal. Let's say that Windows has stuff listening on almost all the ports - certainly the
    privileged ones - by default, while in GNU/Linux (and other UNIX
    systems) this is not the case.

    GNU/Linux is not like that. If you don't
    have any daemons or applications listening on a particular port, then
    all traffic to that port will be ignored by default.

    This is plainly wrong too. Linux replies to packets sent to a closed
    port. Just as Windows does.

    As far as I know, if there is nothing actively listening for any
    particular connection, the kernel will by default silently drop the
    packets unless otherwise specified by firewalling rules.

    --
    = Aragorn =
    GNU/Linux user #223157 - http://www.linuxcounter.net

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Strider (110:300/1.1@linuxnet)
  • From Richard Kettlewell@110:300/1.1 to All on Sat Jun 22 15:27:53 2013
    Aragorn <thorongil@telenet.be.invalid> writes:
    Pascal Hambourg conveyed the following to comp.os.linux.security...
    Aragorn a crit :

    Windows listens to just about every port - high or low - by default,
    and thus it needs a userspace firewall to stop things from coming in
    and things from phoning home.

    This is plainly wrong. Or maybe we have a different interpretation of
    the word "listen".

    I agree that my choice of words was not exactly optimal. Let's say that Windows has stuff listening on almost all the ports - certainly the privileged ones - by default,

    Having actually checked rather than just guessing: there’s less than a
    dozen services potentially exposed to inbound connections by default.
    And that’s before looking at the default firewall.

    There is no such concept as “privileged port” in Windows.

    while in GNU/Linux (and other UNIX systems) this is not the case.

    GNU/Linux is not like that. If you don't
    have any daemons or applications listening on a particular port, then
    all traffic to that port will be ignored by default.

    This is plainly wrong too. Linux replies to packets sent to a closed
    port. Just as Windows does.

    As far as I know, if there is nothing actively listening for any
    particular connection, the kernel will by default silently drop the
    packets unless otherwise specified by firewalling rules.

    Pascal is correct. It sends a RST.

    --
    http://www.greenend.org.uk/rjk/

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Anjou (110:300/1.1@linuxnet)
  • From Pascal Hambourg@110:300/1.1 to All on Sat Jun 22 16:37:59 2013
    Reply-To: pascal.news@plouf.fr.eu.org

    Richard Kettlewell a crit :
    Aragorn <thorongil@telenet.be.invalid> writes:

    As far as I know, if there is nothing actively listening for any
    particular connection, the kernel will by default silently drop the
    packets unless otherwise specified by firewalling rules.

    Pascal is correct. It sends a RST.

    In reply to TCP packets sent to a closed port, as part of the TCP
    protocol. It sends an ICMP "port unreachable" in reply to UDP packets
    sent to a closed port, as part of the IP protocol.

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Plouf ! (110:300/1.1@linuxnet)
  • From buck@110:300/1.1 to All on Sat Jun 22 19:35:23 2013
    Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote in news:kq46t1$jva$1 @saria.nerim.net:


    What's your ruleset (printed by iptables-save) ?
    What are your requirements ?

    I now allow OUTBOUND tcp connections from the Nook to -d 74.125.142.188
    where --dports are 5228 and 14258. This stops the Nook from going nuts
    and prevents google from attempting to establish a connection to the
    Nook. I have no idea what traffic is exchanged and (for now) I don't
    care. After all, there are tons of Nooks that are safely operated
    without any firewall protection.

    Next week I'll root the Nook and find out what that traffic is.

    Complete aside: I was shocked to have the Nook's battery lose half its
    charge in the 2 hours or so that I spent reading (Google Chrome) postings
    to a web forum. I expected 6 to 8 hours of battery.
    --
    buck

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Say What? (110:300/1.1@linuxnet)
  • From buck@110:300/1.1 to All on Sat Jun 22 20:01:19 2013
    Here's 'iptables -nvL' FORWARD chain rules for the Nook.
    'EDIT' and '#' should be obvious. LnRf is a Chain that logs and REJECTs.
    The 'f' in 'LnRf' stands for FORWARD and the 'n' stands for 'and'.

    # # ACCEPT tcp -- * * 192.168.EDIT.44 0.0.0.0/0 \
    tcp spts:1024:65535 mport dports 80,110,443
    # # ACCEPT tcp -- * * 192.168.EDIT.44 74.125.142.188 \
    tcp spts:1024:65535 mport dports 5228,14258
    # # LnRf tcp -- * * 192.168.EDIT.44 0.0.0.0/0 tcp \
    spts:1024:65535 dpts:1024:65535
    # # ACCEPT udp -- * * 192.168.EDIT.44 0.0.0.0/0 udp \
    spt:123 dpt:123
    # # ACCEPT udp -- * * 192.168.EDIT.44 0.0.0.0/0 udp \
    spts:1024:65535 dpt:123
    # # ACCEPT udp -- * * 192.168.EDIT.44 0.0.0.0/0 udp \
    spts:1024:65535 dpt:53
    # # ACCEPT tcp -- * * 192.168.EDIT.44 0.0.0.0/0 state \
    ESTABLISHED tcp spts:1024:65535 dpts:1024:65535
    # # LOG tcp -- * * 192.168.EDIT.44 0.0.0.0/0 state \
    RELATED tcp spts:1024:65535 dpts:1024:65535 LOG flags 0 level 4 \
    prefix `HiPortREL '
    # # ACCEPT udp -- * * 192.168.EDIT.44 0.0.0.0/0 state \
    ESTABLISHED udp spts:1024:65535 dpts:1024:65535
    # # LOG udp -- * * 192.168.EDIT.44 0.0.0.0/0 state \
    RELATED udp spts:1024:65535 dpts:1024:65535 LOG flags 0 level 4 \
    prefix `HiPortREL '
    # # LnRf tcp -- * * 192.168.EDIT.44 0.0.0.0/0

    --
    buck

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: Say What? (110:300/1.1@linuxnet)
  • From Trevor Hemsley@1:0/0 to All on Sat Jun 22 21:29:47 2013
    On Sat, 22 Jun 2013 18:01:19 UTC in comp.os.linux.security, buck <buck@private.mil> wrote:

    # # ACCEPT tcp -- * * 192.168.EDIT.44 0.0.0.0/0 \
    tcp spts:1024:65535 mport dports 80,110,443

    If I'd wanted to read them in an unreadable format, I wouldn't have asked you for the output of `iptables-save`.


    --
    Trevor Hemsley, Brighton, UK
    Trevor dot Hemsley at ntlworld dot com

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: The Kofo BBS MBSE - telnet://fido1.kofobbs.ne