NIS yppasswd command and iptables?? RPC: unable to receive

I was wondering how to set up the iptables on an NIS server so the
yppasswd command will work form a NIS client. Currently with the
iptables on I can invoke the yppasswd command and enter the passsword
information but i get a RPC: Unable to receive error. Witht the
iptables off I no longer get this problem. Can someone help me out.
Thanks

--ERROR--
Changing NIS account information for <USER> on <HOST>.
Please enter old password:
Changing NIS password for <USER> on <HOST>.
Please enter new password:
Please retype new password:
RPC: Unable to receive

Ryan Hubbard wrote:

> I was wondering how to set up the iptables on an NIS server so the
> yppasswd command will work form a NIS client. Currently with the
> iptables on I can invoke the yppasswd command and enter the passsword
> information but i get a RPC: Unable to receive error. Witht the
> iptables off I no longer get this problem. Can someone help me out.
> Thanks
>
> --ERROR--
> Changing NIS account information for <USER> on <HOST>.
> Please enter old password:
> Changing NIS password for <USER> on <HOST>.
> Please enter new password:
> Please retype new password:
> RPC: Unable to receive
My /etc/services shows rpc to use port 111; so modify your iptables early on
to jump to accept for port 111. THEN use tcp wrappers (host allow/deny) to
limit what ypserv listens to.

(E-Mail Removed) (Ryan Hubbard) wrote in message news:<(E-Mail Removed). com>...
> I was wondering how to set up the iptables on an NIS server so the
> yppasswd command will work form a NIS client. Currently with the
> iptables on I can invoke the yppasswd command and enter the passsword
> information but i get a RPC: Unable to receive error. Witht the
> iptables off I no longer get this problem. Can someone help me out.

Not without seeing your iptable's rules ...

> Thanks
>
> --ERROR--
> Changing NIS account information for <USER> on <HOST>.
> Please enter old password:
> Changing NIS password for <USER> on <HOST>.
> Please enter new password:
> Please retype new password:
> RPC: Unable to receive

Sure by now that others have requested your iptables -L output.

My question is more along the lines of, "why does he run iptables on
this NIS server"?

NIS/rpc can get a little tricky to filter effectively -- in fact, it's
hard enough that no one recommends exposing this service to the
internet partly for this difficulty. Sure there's not a better
"solution" to your problem/concerns?

prg
email above disabled

Thanks for the replies. Well I already have the appropiate ips in the
host allow/deny and I already have the 111 rule in there. Prg do you
know if it is possible to restrict NIS to only bind to a specific
adapter? Say eth0 and eth1 are the adapters would it be possible to
say to only allow it to bind to eth1? I know this isn't really
securing it since I have heard of hacks to gain access to eth1 through
eth0 but just out of curousity?

(E-Mail Removed) (P Gentry) wrote in message news:<(E-Mail Removed). com>...
> (E-Mail Removed) (Ryan Hubbard) wrote in message news:<(E-Mail Removed). com>...
> > I was wondering how to set up the iptables on an NIS server so the
> > yppasswd command will work form a NIS client. Currently with the
> > iptables on I can invoke the yppasswd command and enter the passsword
> > information but i get a RPC: Unable to receive error. Witht the
> > iptables off I no longer get this problem. Can someone help me out.
>
> Not without seeing your iptable's rules ...
>
> > Thanks
> >
> > --ERROR--
> > Changing NIS account information for <USER> on <HOST>.
> > Please enter old password:
> > Changing NIS password for <USER> on <HOST>.
> > Please enter new password:
> > Please retype new password:
> > RPC: Unable to receive
>
> Sure by now that others have requested your iptables -L output.
>
> My question is more along the lines of, "why does he run iptables on
> this NIS server"?
>
> NIS/rpc can get a little tricky to filter effectively -- in fact, it's
> hard enough that no one recommends exposing this service to the
> internet partly for this difficulty. Sure there's not a better
> "solution" to your problem/concerns?
>
> prg
> email above disabled

(E-Mail Removed) (Ryan Hubbard) wrote in message news:<(E-Mail Removed). com>...
> Thanks for the replies. Well I already have the appropiate ips in the
> host allow/deny and I already have the 111 rule in there. Prg do you
> know if it is possible to restrict NIS to only bind to a specific
> adapter? Say eth0 and eth1 are the adapters would it be possible to
> say to only allow it to bind to eth1? I know this isn't really
> securing it since I have heard of hacks to gain access to eth1 through
> eth0 but just out of curousity?
[snip]

Get a handle on rpc and the portmapper and you'll understand (kinda
sorta) the problems when filtering NIS.

The same problems crop up re: trying to "bind" the apps (ie., port #s)
to a particular interface. With policy routing -- using multiple
routing tables with rulesets "bound" to particular interfaces -- you
can get more control for routing/filtering net traffic.
http://lartc.org/howto/
http://linux-ip.net/
http://www.policyrouting.org/PolicyR...NLINE/TOC.html

But the rpc/NFS (portmapper/NFS) ports are the only ones
pre-determined (by default) with apps registering _random_ port
numbers with the portmapper. There's not really enough info (known
beforehand) in the packet headers to provide effective, granular
filtering of apps that run behind the port mapper.

You can "fix" the ports to pre-determeined #s for some of the apps.
Look here:
http://ike.room17.com/pipermail/ale/...30/002564.html
for an NFS example with iptables (it's for RH though).

These may be useful also:
http://www.lowth.com/LinWiz/nfs_help.html
http://www.redhat.com/docs/manuals/l...erver-nis.html
http://nfs.sourceforge.net/nfs-howto/security.html

With this and policy routing you can get "more" control, but whether
it's enough I can't say. With the other access controls it could work
OK for you. But know that I've never tried to run NFS/NIS on a
multi-homed host /:-)

hth,
prg
email above disabled

Thanks for the explanation. Can't say that I'm going to try it (most
likely cause I'll mess something up), but I greatly appreciate the
explanation and links.

(E-Mail Removed) (P Gentry) wrote in message news:<(E-Mail Removed). com>...
> (E-Mail Removed) (Ryan Hubbard) wrote in message news:<(E-Mail Removed). com>...
> > Thanks for the replies. Well I already have the appropiate ips in the
> > host allow/deny and I already have the 111 rule in there. Prg do you
> > know if it is possible to restrict NIS to only bind to a specific
> > adapter? Say eth0 and eth1 are the adapters would it be possible to
> > say to only allow it to bind to eth1? I know this isn't really
> > securing it since I have heard of hacks to gain access to eth1 through
> > eth0 but just out of curousity?
> [snip]
>
> Get a handle on rpc and the portmapper and you'll understand (kinda
> sorta) the problems when filtering NIS.
>
> The same problems crop up re: trying to "bind" the apps (ie., port #s)
> to a particular interface. With policy routing -- using multiple
> routing tables with rulesets "bound" to particular interfaces -- you
> can get more control for routing/filtering net traffic.
> http://lartc.org/howto/
> http://linux-ip.net/
> http://www.policyrouting.org/PolicyR...NLINE/TOC.html
>
> But the rpc/NFS (portmapper/NFS) ports are the only ones
> pre-determined (by default) with apps registering _random_ port
> numbers with the portmapper. There's not really enough info (known
> beforehand) in the packet headers to provide effective, granular
> filtering of apps that run behind the port mapper.
>
> You can "fix" the ports to pre-determeined #s for some of the apps.
> Look here:
> http://ike.room17.com/pipermail/ale/...30/002564.html
> for an NFS example with iptables (it's for RH though).
>
> These may be useful also:
> http://www.lowth.com/LinWiz/nfs_help.html
> http://www.redhat.com/docs/manuals/l...erver-nis.html
> http://nfs.sourceforge.net/nfs-howto/security.html
>
> With this and policy routing you can get "more" control, but whether
> it's enough I can't say. With the other access controls it could work
> OK for you. But know that I've never tried to run NFS/NIS on a
> multi-homed host /:-)
>
> hth,
> prg
> email above disabled