Matt:
Heya. Thanks for the candid feedback. Some replies
to you inline, with gratuitous clipping:
> Let me first say that I like echowall and what you've done with.
> I've said that before and recommended it to others even though I've
> authored my own pfw. Yours is better, more capable, and easier to use.
> You've done an amazing job with it thus far.
Hee. Always worries me when letters start this way. :)
> But I think the statement that "It is optimized for the LEAF/LRP
> distro," is not fair. LRP has one distro and LEAF has at least five
> right now, of which EchoWall probably runs on Dachstein/ES2B only.
> Seeing that and my fresh pot of coffee got me going....
That's a good point. In my language, LEAF/LRP is a distro, of
which there are many different "flavors" (for lack of a better word).
As you got from the README, it was built and tested on ES2B and Dachstein
systems, but it *should* work on Oxygen and 2.9.8 boxes as well. If it
doesn't, it's a coding error, not a misrepresentation.
> Well, it's much better than in the past, imo, and that's neat.
> But it doesn't interact with ps properly (I get a ps usage when
> trying to ./echwall start).
>
> # ./echowall start
> Starting echowall..-C select by command name (minimal ps only
> accepts one)
Yup, that's a bug. Here I think is where echoWall is scanning
'ps' for any ipfwd process that needs to be killed. For ES2B, the "gax"
switch works. What switch works for you in Oxygen?
> It doesn't acknowledge the missing ipfwd. I realize that your files
> say to point to the proper binaries, but David hasn't packaged up ipfwd
> for anyone to use, and you don't include it in the archive.
Interesting, I didn't know that. I should check to see if the
ipfwd statement is valid; if it's not, the IPSec and PPTP stops working.
Does Oxygen use redir instead?
> Is it fair to say, then, that
> echowall wasn't designed to run on LEAF distros but rather to run on DF
> and ES2B. I guess I'm nitpicking on semantics of the words "designed
> for," sorry.
Well...hmmm. Echowall *does* come with two versions of gatping,
one for glibc 2.0 systems (ES2B, DS, etc) and one for glibc 2.1 systems
like Oxygen. I'd argue my intention of supporting that Oxygen flavor
of LEAF/LRP is fairly demonstrated by this.
> It also adds in a strange 10.9.8.7 address, which none of our dns's
> are setup to resolv. So there's that evil 2 min delay to see the output
> of
> ipchains -L -v.
> You might mention that or append an ipaddress/name pair onto the users
> /etc/hosts.
Hadn't thought of that; I never use "ipchains -L" without an
accompanying "-n". But I see your point; I should fix that signature
rule to use a weird port instead of a weird IP address.
> In addition, I don't see the wisdom in this:
>
> # -- For SSH'ing out from firewall, allow responses from SSH servers.
> # -- Configure firewall's SSH client to use 823 to 1023 port range.
> $IPCHAINS -A input -s 0/0 22 -d $IP_EXT/32 823:1023 ! -y -p tcp -j ACCEPT
>
> Those are weird ports and other firewalls certainly don't expect client
> traffic to emerge from 823-1023. Would you explain that a bit? Thx.
I think Charles' explanation here is a good one. Most SSH
clients, by default, use the highest 200 ports of the privileged
port range. Similarly, most firewall packages deny the entire 0:1023
privileged port range without a SYN flag qualifier. I wanted to do
better.
> You also recommend changing the ssh client config. Is it right to
> ask people to change there servers and clients to fit the firewall?
> Indeed you've worked very hard to make services available on the ports
> they normally run, as evidenced by all the portfw services echowall
> supports. So I'm confused.
Yes, that comment is misleading. I should fix that.
> And then there's this:
>
> # -- next, allow the MASQ'd responses in on ports: 61000-65535
> $IPCHAINS -A input -s 0/0 -d $IP_EXT/32 61000:65535 ! -y -p tcp -j ACCEPT
> $IPCHAINS -A input -s 0/0 -d $IP_EXT/32 61000:65535 -p udp -j ACCEPT
>
> which is overly broad, AFAIK. As defined in every kernel I've used
>'till now the masq'd port range is 4096 ports starting at 61000.
> There's nothing going on from 65097-65534, and I'm not sure that 65535
> is even valid. I've seen this reserved on other OS's.
True, RFC-1631 doesn't specify the NAT'ing port range. I've
mostly seen too what you describe: 61000 thru 65095. For NAT'ing
firewalls on other OS's, though (I think the one I saw was for
VxWorks), the other 440 ports were included. Shrug. Minimal exposure
created by doing this, IMO.
> And you let these in, or I forgot to get rid of them. Not sure
> what udp on those ports is for? The HLIFE I let in?
Aye, 28900, 6003 and 7002 were from your HLIFE choice. My
understanding is that the biggest threats to X-Windows stuff is on
the TCP port 600X, not the UDP stuff. Shrug. Reference to this
H-Life setting from:
http://www.practicallynetworked.com/sharing/app_port_list.htm
> Next I noticed that the scripts choked if I used any lowercase
> letters in my mac address specifications. Was that user error or
> something in the script?
Ah, interesting. My grep'ing might need a -i'ing...
> And last, but not least, a small feature request: The ability to
> portforward my SSH_CUSTOM to the port of my choice on the internal comp.
> As is, you have it fixed to use the same port as you let in for this on
> the firewall. I'd like to get 2222 going to the usual 22, so I don't
> have to modify every instance of sshd I run.
Ah, good idea. Thanks for all the good feedback. I'll
be sure to clame version 1.4+x on you. :)
-Scott
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
