[H-GEN] nmap scans

[Tony Nugent]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

On Tue Dec 17 2002 at 13:05, "Harry Phillips" wrote:

> While your at it can you work out how to open port 22 so I can ssh into
> remote boxes.
>
> If the box is on my LAN and I apply the same rules to eth0 instead of
> ppp0, it will drop everything except port 22, as soon as I try to do it
> across the internet it won't let me in.

iptables -I INPUT -i ppp0 --dport 22 -j ACCEPT

(I assume that you want to do something like that, open port 22 to
the internet on your ppp interface).

> I rang and asked my ISP if they block any ports and they said no. Both
> boxes were connected to the same ISP (and dial-up number) so I imagine
> that the traffic was all internal to them.

You can always (crudely but effectively) test if a specific port is
reachable from another by using netcat (nc)...

	nc -v host.some.where.net -z 22

> I will come along on Saturday and see if anyone can help me out.

There are several ways to approach the design of firewalls.  One
that I have used is to first divide traffic at each of the three
"top level" chains (INPUT, FORWARD, OUTPUT) into different subchains
according the possible incoming network interfaces.  For example
(and just as a starting point):

iptables -N in-eth0
iptables -A in-eth0 -j ACCEPT
iptables -N in-eth1
iptables -A in-eth1 -j ACCEPT
iptables -N in-ppp
iptables -A in-ppp  -j ACCEPT
iptables -I INPUT -i eth1 -j in-eth1
iptables -I INPUT -i eth0 -j in-eth0
iptables -I INPUT -i ppp+ -j in-ppp
iptables -I INPUT -i lo -j ACCEPT
iptables -A INPUT -j ACCEPT
watch -n 5 iptables --line-numbers -nvL

This will create a series of chains (or "classes of traffic") in the
parent INPUT chain, with network traffic sorted into them according
to where the packets "physically" came from.  The watch command is
very useful for looking at packet count changes happening "live"
(every 5secs).  (Hint: order the interface chains from busiest to
least used).

  The in-<if> chains are (temporarily) terminated with an ACCEPT
  target, but the idea is to do your main filtering rules in these
  chains (such as filtering for specific ports).  The loopback
  traffic is always accepted outright (why filter this?)

  You (should) already know what sort of traffic to expect on each
  interface, and this is a nice way to apply whole sets of different
  filtering rules without having to worry so much about specific IP
  or network addresses.

  In each subchain you already know what interface the packet came
  from (and just as importantly where it didn't come from), so you
  never have to test for that again.  If the in-ppp chain is the
  internet gateway, then that chain should contain rules that
  protect the local box from untrusted sources.  If eth0 is an
  interface to your LAN, then it should contain rules to permit it
  to talk with it (ie, much less restrictive).  And so on.  You can
  build your entire firewall without having to worry very much about
  any of your IP/network addresses.

  Processing should always terminate in each of these
  "per-interface" subchains (so as not to "spill over" for needless
  checking with other rules, or into the final ACCEPT rule in the
  INPUT chain).  The final accept (or reject/drop) rule in the INPUT
  chain should (theoretically) never see any packet counts, if it
  does then there is either an interface that is being missed for
  traffic processing, or not all packets in at least one of the
  subchains are being terminated within these chains.

  The creation of the rules themselves automatically generates
  packet count statistics, so this design immediately gives you
  useful information about how much traffic is happening on each of
  your network interfaces.

It is a fairly simple scheme to use as a starting point, and I have
used it quite successfully for the INPUT, FORWARD (fwd-eth0 etc) and
OUTPUT (out-eth0 etc) chains.  The FORWARD and OUTPUT tables are
interesting to configure on a per-interface basis... you are also
dealing with output interfaces (eg, "-o eth0"), so you can create
further subchains based on that property.  And the nat and mangle
tables are very different beasts again.

Doing it like this does have some limitations, but overall it has
done me quite well for designing and managing in a sane way
otherwise very complex firewall configurations.  And it does make
things simple for simple configurations too (eg, here at home on my
gateway box).

Very effective firewalling can also be done by only using routing...
using multiple routing tables, default "unreachable" "prohibit"
"blackhole" (etc) route targets, and policy routing rules to enable
it (using "/sbin/ip rule").  But that is another story...

Cheers
Tony

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/