Scott C. Best wrote:
> Lonnie:
>
> You can best find echoWall on freshmeat.net. The blurb
> there is fairly accurate. :)
>
> http://freshmeat.net/projects/echowall/
>
> cheers,
> Scott
Scott!
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.
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....
The whole rest of this post could be explained by user error,
but I'd like to think I spotted a few issues. I just tried your
lastest EchoWall-1.40 on Oxygen-1.6.0.
> EchoWall Firewall Package for LEAF/LRP
> Version 1.40
> 06 Jan 2002
> ------------------------
>
> EchoWall is a firewall configuration package, meant for
> LEAF/LRP Linux (kernel 2.2.x) systems acting as IP-masquerading
> firewall/routers. It was built and tested for both the ES2B and
> Dachstein releases.
Here in the readme, you even say that it's for ES2B and DF.
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)
-p select by process ID (minimal ps only accepts one)
-A all processes (same as ax)
-e all processes (same as ax)
a all processes w/ tty, including other users
x processes w/o controlling ttys
-f full format
-j,j job control format
v virtual memory format
-l,l long format
u user-oriented format
-o user-defined format (limited support, only "ps -o pid=")
h no header
c true command name
-w,w wide output
....Done.
Services enabled:
FTP on <10.1.1.1>.
PASVFTP on <10.1.1.1>.
SSH_CUSTOM on <10.1.1.1>.
HLIFE on <10.1.1.1>.
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. 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.
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.
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.
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.
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.
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?
0 0 ACCEPT udp ------ 0xFF 0x00 * 0.0.0.0/0 63.194.213.179 * -> 28900
0 0 ACCEPT udp ------ 0xFF 0x00 * 0.0.0.0/0 63.194.213.179 * -> 6003
0 0 ACCEPT udp ------ 0xFF 0x00 * 0.0.0.0/0 63.194.213.179 * -> 7002
and they get portforwarded. So they must be HLIFE or something:
PortFW:
prot localaddr rediraddr lport rport pcnt pref
UDP 63.194.213.179 10.1.1.1 28900 28900 10 10
UDP 63.194.213.179 10.1.1.1 7002 7002 10 10
UDP 63.194.213.179 10.1.1.1 6003 6003 10 10
but I don't think CERT likes it when people make 6003 available. They
recommend blocking 6000:6010 for tcp and udp to protect X and whatnot.
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?
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.
Well I hope this didn't sound like I was upset at all. Actually I was really
happy to see that the scripts didn't bomb out like in the past. It's mostly
that I have no idea what that ps and ipfwd problem breaks, and I'm really
sick of everyone's refering to lrp this and lrp that, being that it's been
almost 2 years since we bailed on "Kill-a-Cop" Cinege for supporting terrorism.
Regards,
Matt
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
