Followup, resolution, and further questions ;> * On 2005:03:22:12:32:39-0600 I, Michael D Schleif <[EMAIL PROTECTED]>, scribed: > I am stymied by my inability to establish the simplest connection with > my test Bering-uClibc system: > > /var/log/shorewall.log: > > Mar 22 00:38:35 PlatinumWALL Shorewall:net2all:DROP: IN=eth0 OUT= > MAC=00:50:04:20:ec:d1:00:01:02:6c:6b:4b:08:00 SRC=192.168.123.150 > DST=192.168.123.30 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=31774 DF > PROTO=TCP SPT=57576 DPT=22 SEQ=721372925 ACK=0 WINDOW=5840 SYN > URGP=0 > > > For those who miss the significance of this log entry, > /usr/share/shorewall/rfc1918 has 192.168.0.0/16 commented OUT. > > Default /usr/share/shorewall/action.AllowSSH: > > ACCEPT - - tcp 22 > > > Nearest I can tell, with my limited Shorewall experience, is this from > `shorewall show': > > Chain net2all (2 references) > pkts bytes target prot opt in out source destination > 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state > RELATED,ESTABLISHED > 812 125K Drop all -- * * 0.0.0.0/0 0.0.0.0/0 > > > I do not understand how these packets get to this point, much less what > is `net2all' in the first place? Am I missing some critical > documentation?
OK, as a newbie to Bering-uClibc, and to Shorewall, I was bitten by two
(2) gotchas that remain un-intuitive to me:
[1] The Shorewall documentation explains much about `actions'; but, I
cannot find documentation about HOW they are used. In my case,
I assumed AllowSSH was automatically invoked, and assumed that `-'
was shorthand for `all' ;<
My test Bering-uClibc system sits inside my office LAN, hence the
temporary comment on 192.168.0.0/16, because my internal LAN is
192.168.123.0/24. ALL of my testing has been from outside of the
Bering-uClibc system, including trying to ssh INTO it. By default,
Bering-uClibc only provides for internal LAN ssh access to the
firewall.
I solved this part of the problem in /etc/shorewall/rules by
replacing this:
ACCEPT loc fw tcp 22
with this:
AllowSSH all fw
[2] I wonder why anybody would compile sshd for tcp wrappers? Do they
think that sshd is not secure enough, that this provides an
additional source of security? Please, somebody explain this to me?
In DCD, I have always compiled my own sshd, and I forgot that
wrappers is probably the default. I would much rather let Shorewall
handle ssh access, because at least then I can control what nmap
sees on tcp port 22 ;>
I solved this part of the problem in /etc/hosts.allow by adding
this:
sshd: ALL
and, in /etc/hosts.deny by commenting OUT this:
# ALL: PARANOID
Did I miss these items in the extant documentation? If so, pointers are
welcome. Thank you.
I wonder why I have *not* seen my original post on the list today?
Thank you, all of you, for your continued support.
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know. The more I know, the more I know I don't know . . .
--
signature.asc
Description: Digital signature
