Re: amcheck and ports?

2000-12-02 Thread Alexandre Oliva

On Dec  1, 2000, Tom Hudak <[EMAIL PROTECTED]> wrote:

> tcpdump: listening on eth0
> 15:40:32.168288 fry.sistina.com.64280 > bender.sistina.com.amanda: udp 176
> 15:40:32.175191 bender.sistina.com.amanda > fry.sistina.com.64280: udp 49
> 15:40:32.177088 bender.sistina.com.amanda > fry.sistina.com.64280: udp 101
> 15:40:32.208256 fry.sistina.com.64280 > bender.sistina.com.amanda: udp 49

IIRC, bender is outside your firewall, so you're looking at the wrong
end of the connection to see if Amanda is using the right ports.  Look
at what homer (the tape server) is sending out, and you'll see the UDP
ports it uses are in the range you have specified.  (note that the
ports are the numbers or names that follow the hostname, not the
number that follows `udp').

It appears that your problem is that the firewall is masquerading the
ports, which it shouldn't.  But I'm afraid I have no idea about how to
tell it not to do it.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me



amcheck and ports?

2000-12-01 Thread Tom Hudak

After much brain storming and headaches, I have come to 1 conclusion, amcheck
is opening and transferring data on a (range) port(s) that are separate from
what I have specified during configure. This occured to me after studying my
known goods, port-port links are all ok, tested both directions with netcat
(still not sure how masq does its masquerading...), verified perms on all
affected binaries (amandad, amcheck) but only after running tcpdump | grep -e
".*amanda.*" was I able to know for a fact amcheck DOES NOT exclusively use
the assigned port ranges! That is what is mucking up the process of amcheck
successfully checking the remote hosts through a masquerading firewall. The
output I received from tcpdump | grep -e ".*amanda.*" is below.

tcpdump: listening on eth0
15:40:32.168288 fry.sistina.com.64280 > bender.sistina.com.amanda: udp 176
15:40:32.175191 bender.sistina.com.amanda > fry.sistina.com.64280: udp 49
15:40:32.177088 bender.sistina.com.amanda > fry.sistina.com.64280: udp 101
15:40:32.208256 fry.sistina.com.64280 > bender.sistina.com.amanda: udp 49

the only port above that *should*(?) be used by amcheck is the hostname
service (port 101), which is the one port that I would assume is necessary to the
function of amcheck and it's security measures, but in turn screws the ability
to function via a masqueraded firewall without the proper rules. The others
seem to be opened intentionally (as opposed to randomly) but do not follow the
udp port restrictions I specified at compile time. Is this a bug? is this a
feature? is this functionality simply unintentional? Whatever the reason,
those ports are what cause the otherwise properly forwarded communications
pathways to get hosed while running amcheck. If anyone has a
fix/patch/update/suggestion/whatever for how to force amcheck to strictly use
the specified udpportrange I would love to know. I am not a programmer or I
would start digging through source to find the answers I need. Also, if
someone could clear up the tcpdump output as I'm not fully sure that I
understand *exactly* what each line means, but vaguely I understand that data
from homer (behind the masq/firewall), since there is no input policy or
forwarded port, is masquerading the data to bender, which intern see's it as
an insecure port (due to masq) and responds appropriately. Again, this is all
just an educated guess with some logged info to give me a known good. If
anyone can clear up what amcheck is doing on those ports, or why, please let
the list know. I have been searching through the mailing list archives for
both users and hackers, and this has apparently been an issue for a while
with no resolution currently available.

*note: tcpdump results are the same ports EVERY time I've run it and I have
not yet gotten any of the ipchains/ipmasqadm portfw rules to successfully
avoid masqerading that data.
Thanks ahead of time for any answers/suggestions given, this has been an issue
for a while that I'm sure many people would love to see resolved.
I hope this helps a little bit.
-- 
Thomas J. Hudak
Jr. Systems Administrator
Sistina Software Inc.
Phone: 612.379.3951 Fax: 612.379.3952

 PGP signature