Re: overcome NIS - Security

This is a discussion on Re: overcome NIS - Security ; On 2005-12-01, Jan Pompe wrote: > Ther are a few other services which are equaaly insecure like nfs for > instance which should aslo not run a network Sorry, I've gotta ask... How and why would you run nfs *NOT* ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 58

Thread: Re: overcome NIS

  1. Re: overcome NIS

    On 2005-12-01, Jan Pompe wrote:

    > Ther are a few other services which are equaaly insecure like nfs for
    > instance which should aslo not run a network


    Sorry, I've gotta ask...

    How and why would you run nfs *NOT* on a network?

    --

    John (john@os2.dhs.org)

  2. Re: overcome NIS

    On Sat, 03 Dec 2005 00:05:10 +0000, John Thompson wrote:

    > AFAIK, NIS doesn't transmit passwords over the network,


    It does when changeing passwords (although there are workarounds to this,
    ofcource.)

    > just the hashes


    Which i'd still consider rather risky ...

    > so each machine can use the hashes to authenticate.


    /Only/ to autenticate users against! (Master and slave servers don't
    autenticate eachother at all, nor do they clients, or clients them.)

    > If someone has the access to sniff these NIS exchanges


    Let me guess: they'll race (or MITM) the server's replys and inject
    packets to put themselfs into whatever groups they like?

    > to pick up the hashes,


    They need not even sniff the wire for this (mitigating antisniff here.)
    They'd only need administrative access to the host thier connecting to the
    subnet with, and know your master and donainname ...

    > there's somethimg else seriously wrong with your security that isn't
    > directly related to NIS,


    How so?

    > and that person still needs to crack the hash (no trivial task) to find
    > the password.


    A matter of time (if there are many accounts, probably not much though.)

    --
    -Menno.


  3. Re: overcome NIS

    John Thompson wrote:

    > On 2005-12-01, Greg Metcalfe wrote:
    >
    >> If the Network Information Service shouldn't be used on a network, where,
    >> pray tell, *should* it be used? Ever worked in an environment with
    >> firewalled subnets, serious security policies, etc.? Where NIS might just
    >> be easy and cool, in the subnet where you need it? Where the subnet IDS
    >> can spot NIS exploits like water rolling off a duck's butt? I'm guessing
    >> no.

    >
    > AFAIK, NIS doesn't transmit passwords over the network, just the hashes so
    > each machine can use the hashes to authenticate. If someone has the access
    > to sniff these NIS exchanges to pick up the hashes, there's somethimg else
    > seriously wrong with your security that isn't directly related to NIS, and
    > that person still needs to crack the hash (no trivial task) to find the
    > password.
    >

    I think a lot of people are probably reacting to the NIS-that-was, half a
    dozen years ago. Authentication issues, buffer overflows, rogue server
    attacks, etc. Modern versions are much better, as you know.

    I still wouldn't deploy it on a banking transaction processor--I dumped
    default NIS on such a system (not Linux) not that long ago. But that's an
    environment where you clearly want to harden the system to the
    hilt--billions of dollars in assets to protect. Literally. Tweak the TCP/IP
    stack, rewrite /etc/skel files, etc. Pretty much the whole catastrophe, as
    servers in an environment like that are probably a large proprietary Unix
    server surrounded by pizza boxes running all sorts of weird stuff, and
    talking to third parties. CRM interfaces, credit card processors, check
    imaging services, etc.

    NIS can still be an easy way to get things done, on appropriate subnets. It
    all depends on the threat model. It gets my back up when people don't take
    that first vital step, and issue blanket statements without actually
    considering a threat model. Tons of man-hours down the tubes.

    Heavy sigh, and end rant.

    --
    Greg Metcalfe
    GPG fingerprint: 95B3 2BDD 9152 1E7D A240 37C1 7AE2 9B71 0065 F029

  4. Re: overcome NIS

    John Thompson wrote:

    > On 2005-12-01, Jan Pompe wrote:
    >
    >> Ther are a few other services which are equaaly insecure like nfs for
    >> instance which should aslo not run a network

    >
    > Sorry, I've gotta ask...
    >
    > How and why would you run nfs *NOT* on a network?
    >

    Shades of a previous post of mine, regarding NIS not being run on a network.
    And yet I dorked, and completely missed this. Nice catch,
    John. Though I suspect Jan just misspoke, and actually knows how useful NFS
    can be, in appropriate environments.

    --
    Greg Metcalfe
    GPG fingerprint: 95B3 2BDD 9152 1E7D A240 37C1 7AE2 9B71 0065 F029

  5. Re: overcome NIS

    On Fri, 02 Dec 2005 17:22:58 -0800, Greg Metcalfe wrote:
    > John Thompson wrote:


    >> AFAIK, NIS doesn't transmit passwords over the network, just the hashes
    >> so each machine can use the hashes to authenticate. If someone has the
    >> access to sniff these NIS exchanges to pick up the hashes, there's
    >> somethimg else seriously wrong with your security that isn't directly
    >> related to NIS, and that person still needs to crack the hash (no
    >> trivial task) to find the password.
    >>

    > I think a lot of people are probably reacting to the NIS-that-was, half
    > a dozen years ago.


    I can only speak for myself and indeed that's probably in the back of the
    mind (as with say sendmail) none the less i try and look at later
    revisions objectively. And even Usenet though threads tent to drift in
    some direction or other, it's still about NIS security AFAICT.

    > Authentication issues,


    To a lesser extent: still there.

    > buffer overflows,


    Provided the OpenBSD folks audited some versions, if one uses that code,
    there shouldn't be many (any) problems in that recart anymore (although it
    takes just one error, and most of the NIS services runsas/needs root)

    > rogue server attacks, etc.


    Forgive my ignorance, but how is this protected against? TCP rather then
    UDP? RPC_GSS?

    > Modern versions are much better, as you know.


    Sure. But correct me if i'm wrong: this isn't about "better" it's about
    "any hole in NIS" ...

    > I still wouldn't deploy it on a banking transaction processor--


    There you go ...

    [ Snip. (Me too is a part-time server jockey for a living.) ]

    > NIS can still be an easy way to get things done, on appropriate subnets.


    Sure. I might even _recomment_ it for home networking, small offices,
    departments that share password post-ads in the first place (i.e.: users
    administrate stuff themselfs), or between just info servers, for instance.

    I wouldn't though recoment it for a bank, hospital, or large school, say.

    > It all depends on the threat model.


    But is *that* what this discussion is about?
    (If so, i would have / will decline(d)).

    > It gets my back up when people don't take that first vital step,


    The OP would to have to provide data on this in the first place ... There
    is no required context of user privileges , network topology , or whatever
    else specified so: one is forced to conclude the security required for
    his/her conclusion to be met _was_ in fact met OR his/her research skills
    are lacking ...

    > and issue blanket statements without actually considering a threat
    > model.


    I don't know if you adress me with this statement, but "considering a
    threat model" can only be done if one knows about the precise threats to
    anything in the first place.

    Weaknesses can only be accepted or mitigated if one knows about them in
    the first place (one may run stunnel here or there, or switch to
    SASL/Kerberos frontented LDAP, or IPSec the basterds or whatever, or not.)

    > Tons of man-hours down the tubes.
    >
    > Heavy sigh, and end rant.


    --
    -Menno.


  6. Re: overcome NIS

    matt_left_coast wrote:
    > Jan Pompe wrote:
    >
    >
    >>matt_left_coast wrote:
    >>
    >>>Jan Pompe wrote:
    >>>
    >>>
    >>>
    >>>>You are a poor logician. "It was not designed to run without a
    >>>>firewall" is logically equivalent to "it was designed to run with a
    >>>>firewall" it's quite irrelevent whether it was specifically done that
    >>>>way or not.
    >>>
    >>>
    >>>No, it is NOT. What you are saying does not even make sense.
    >>>
    >>>"Not designed" Could mean total lack of any design regarding the issue.
    >>>Something could "not designed to run without a firewall" without ANY
    >>>intent to design it to run WITH a firewall.
    >>>
    >>>Is:
    >>>
    >>>My car was not designed to run without a iceberg.
    >>>
    >>>equivalent to:
    >>>
    >>>My car was designed to run with a iceberg?
    >>>

    >>
    >>That's right and both your statements are nonsense.

    >
    >
    > I did not think you were smart enough to understand.


    Probably not but I don't there are many people about who claim to
    understand how a double does not make a positive as you seem to claiming
    it does, so I'd be in good company at least.

    > Your claim that "not designed to run without a firewall" and "it was
    > designed to run with a firewall" are logically the same is just plain
    > BS.


    (sic)
    >


  7. Re: overcome NIS

    Greg Metcalfe wrote:
    > John Thompson wrote:
    >
    >
    >>On 2005-12-01, Jan Pompe wrote:
    >>
    >>
    >>>Ther are a few other services which are equaaly insecure like nfs for
    >>>instance which should aslo not run a network

    >>
    >>Sorry, I've gotta ask...
    >>
    >>How and why would you run nfs *NOT* on a network?
    >>

    >
    > Shades of a previous post of mine, regarding NIS not being run on a network.
    > And yet I dorked, and completely missed this. Nice catch,
    > John. Though I suspect Jan just misspoke,


    You may be right, I really should brush up my irony/sarcasm skills it's
    obviously not working as well as I'd like.

    > and actually knows how useful NFS
    > can be, in appropriate environments.
    >


    Indeed I do though I have no used for it at present I have used it in
    the past behind a solid and layered firewall. Never had any problems,
    but then I never had to administer a network in a school where there be
    students who might think it clever to break it.

  8. Re: overcome NIS

    John Thompson writes:

    >AFAIK, NIS doesn't transmit passwords over the network, just the hashes so
    >each machine can use the hashes to authenticate. If someone has the access
    >to sniff these NIS exchanges to pick up the hashes, there's somethimg else
    >seriously wrong with your security that isn't directly related to NIS,


    You mean, like they've plugged a laptop into your network and used arp cache
    poisoning to get the switch to go into broadcast mode.

    But they don't need to be that clever. There's no authentication on NIS. Anyone
    on the network can download your password hashes.

    > and
    >that person still needs to crack the hash (no trivial task)


    *ONLY* if you ruthlessly enforce strong password discipline. I've never been
    anywhere where it happens.


    --
    "Other people are not your property."
    [email me at huge [at] huge [dot] org [dot] uk]



  9. Re: overcome NIS

    On 2005-12-03, Menno Duursma wrote:

    > On Sat, 03 Dec 2005 00:05:10 +0000, John Thompson wrote:
    >
    >> If someone has the access to sniff these NIS exchanges
    >> to pick up the hashes,


    > They need not even sniff the wire for this (mitigating antisniff here.)
    > They'd only need administrative access to the host thier connecting to the
    > subnet with, and know your master and donainname ...


    Seems to me if they have administrator access, they can pretty much do
    what they want already, without having to go through the bother of
    sniffing nfs packets.

    >> there's something else seriously wrong with your security that isn't
    >> directly related to NIS,


    > How so?


    See above.

    --

    John (john@os2.dhs.org)

  10. Re: overcome NIS

    Jan Pompe wrote:
    > matt_left_coast wrote:
    >
    >> Jan Pompe wrote:


    [...] snip

    >
    > That's right and both your statements are nonsense.
    >


    Jan, in case it hasn't occured to you by now, binky-boy Matt doesn't
    have all of his oars in the water.

  11. Re: overcome NIS

    On Sat, 03 Dec 2005 22:05:08 +0000, John Thompson wrote:
    > On 2005-12-03, Menno Duursma wrote:
    >> On Sat, 03 Dec 2005 00:05:10 +0000, John Thompson wrote:
    >>
    >>> If someone has the access to sniff these NIS exchanges
    >>> to pick up the hashes,

    >
    >> They need not even sniff the wire for this (mitigating antisniff here.)


    man ypcat

    >> They'd only need administrative access to the host thier connecting to
    >> the subnet with, and know your master and donainname ...


    s/donainname/domainname/

    > Seems to me if they have administrator access, they can pretty much do
    > what they want already,


    Locally, on the machine (laptop?) thier connecting with: yes. That's fully
    under thier control already. Access to server resources however they
    _shouldn't_ have at thier disposal without authenticating (unless it's a
    public service anyway.)

    > without having to go through the bother of sniffing nfs packets.
    >
    >>> there's something else seriously wrong with your security that isn't
    >>> directly related to NIS,

    >
    >> How so?

    >
    > See above.


    Well, between servers (that provide autenticated services) where you have
    only non-root users on: there isn't a problem with using NIS (and plain
    ol' NFS for that matter.) In which case any and all machines connected to
    that network segment are trusted to behave (e.g.: *not* provide root to
    untrusted users.)

    But if this cannot be guaranteed (i.e.: there are workstations on) NIS
    cannot be used without accepting a relatively big risk in so doing.

    --
    -Menno.


  12. Re: overcome NIS

    On 03.12.2005, Menno Duursma wrote:
    > On Sat, 03 Dec 2005 22:05:08 +0000, John Thompson wrote:
    >> On 2005-12-03, Menno Duursma wrote:
    >>> On Sat, 03 Dec 2005 00:05:10 +0000, John Thompson wrote:
    >>>
    >>>> If someone has the access to sniff these NIS exchanges
    >>>> to pick up the hashes,

    >>
    >>> They need not even sniff the wire for this (mitigating antisniff here.)

    >
    > man ypcat
    >
    >>> They'd only need administrative access to the host thier connecting to
    >>> the subnet with, and know your master and donainname ...

    >
    > s/donainname/domainname/
    >
    >> Seems to me if they have administrator access, they can pretty much do
    >> what they want already,

    >
    > Locally, on the machine (laptop?) thier connecting with: yes. That's fully
    > under thier control already. Access to server resources however they
    > _shouldn't_ have at thier disposal without authenticating (unless it's a
    > public service anyway.)


    Do you really let in laptops into your internal network? Or maybe you
    connect with bridge/switch wireless network with stationary network?
    This _is_ serious design flaw. So now we now that you don't let laptops
    in. Which other systems can "they" posses? Your desktop systems? Then
    you failed as system admin.
    Where is root access to systems in internal network _now_?

    >> without having to go through the bother of sniffing nfs packets.
    >>
    >>>> there's something else seriously wrong with your security that isn't
    >>>> directly related to NIS,

    >>
    >>> How so?

    >>
    >> See above.

    >
    > Well, between servers (that provide autenticated services) where you have
    > only non-root users on: there isn't a problem with using NIS (and plain
    > ol' NFS for that matter.) In which case any and all machines connected to
    > that network segment are trusted to behave (e.g.: *not* provide root to
    > untrusted users.)
    >
    > But if this cannot be guaranteed (i.e.: there are workstations on) NIS
    > cannot be used without accepting a relatively big risk in so doing.


    Do you give to workstation user root access to that workstation? I don't
    think so. Can you explain then, how your user could get administrative
    rights? There're no private boxes nor root on workstations.

    --
    Feel free to correct my English
    Stanislaw Klekot

  13. Re: overcome NIS

    base60 wrote:
    > Jan Pompe wrote:
    >
    >> matt_left_coast wrote:
    >>
    >>> Jan Pompe wrote:

    >
    >
    > [...] snip
    >
    >>
    >> That's right and both your statements are nonsense.
    >>

    >
    > Jan, in case it hasn't occured to you by now, binky-boy Matt doesn't
    > have all of his oars in the water.


    I can be a bit slow about such things but it was begining to dawn on me.

    I left IT sometime ago to work in rehabilitating people with
    shizophrenia + drug abuse problems and given that environment he seems
    almost high functioning.

    Thanks.

  14. Re: overcome NIS

    On Sun, 04 Dec 2005 00:54:03 +0000, Stachu 'Dozzie' K. wrote:
    > On 03.12.2005, Menno Duursma wrote:
    >> On Sat, 03 Dec 2005 22:05:08 +0000, John Thompson wrote:


    > Do you really let in laptops into your internal network?


    Well the only network i own is my home LAN and yes i have a laptop.

    > Or maybe you connect with bridge/switch wireless network with stationary
    > network?


    Wouldn't this effectively make it /one/ network above the media level?

    > This _is_ serious design flaw.


    ???

    > So now we now that you don't let laptops in.


    On other networks then mensioned above: i have no say in such things,
    above and beyond consultancy. But assume it possible and in most places
    not even far fetched ...

    > Which other systems can "they" posses? Your desktop systems?


    Probably: given some effort. But they need not even try that (just
    crosslink a laptop to one desktop systems NIC, fail a login on it
    logging results on the laptop, spoof thier settings to those and connect
    it to the network - and this is when they'd even care for going undetected.)

    [ Snip. ]

    > Do you give to workstation user root access to that workstation?


    What's with all the personal questions? Thier irrelevant to the discussion
    as far as i'm concerned.

    > I don't think so.


    In providing NIS services one iplicitly trusts this to be so. Other
    systems, providing similar functionality, take into account the
    alternative possibility could conceivably be the case, if only for a small
    timeframe. Protecting assets even from legit users with local root access
    on client machines (say tech support admins.)

    > Can you explain then, how your user could get administrative rights?


    Read above (ofcource there are more ways to skim a cat, use your
    imagination.) You can tunnel/wrap/firewall/whatever sure, that's not my
    point. Point though is: NIS doesn't savely account for the possibility...

    > There're no private boxes nor root on workstations.


    How do you know this is so?
    And has been so always?

    --
    -Menno.


  15. Re: overcome NIS

    On 04.12.2005, Menno Duursma wrote:
    > On Sun, 04 Dec 2005 00:54:03 +0000, Stachu 'Dozzie' K. wrote:
    >> On 03.12.2005, Menno Duursma wrote:
    >>> On Sat, 03 Dec 2005 22:05:08 +0000, John Thompson wrote:

    >
    >> Do you really let in laptops into your internal network?

    >
    > Well the only network i own is my home LAN and yes i have a laptop.
    >
    >> Or maybe you connect with bridge/switch wireless network with stationary
    >> network?

    >
    > Wouldn't this effectively make it /one/ network above the media level?
    >
    >> This _is_ serious design flaw.

    >
    > ???


    We're talking about networks where NIS can do some work, that is
    networks requiring some directory services, aren't we? Otherwise NIS is
    unnecessary service and leaving it running is exactly the same "good"
    idea as leaving Samba, Apache or any other useless service (providing
    it's useless in particular case).

    >> So now we now that you don't let laptops in.

    >
    > On other networks then mensioned above: i have no say in such things,
    > above and beyond consultancy. But assume it possible and in most places
    > not even far fetched ...
    >
    >> Which other systems can "they" posses? Your desktop systems?

    >
    > Probably: given some effort.


    Then the system admin failed.

    > But they need not even try that (just
    > crosslink a laptop to one desktop systems NIC, fail a login on it
    > logging results on the laptop, spoof thier settings to those and connect
    > it to the network - and this is when they'd even care for going undetected.)


    As I said, there're no laptops. Laptops are left at the entrance.
    Netadmin should provide clear and forcable policy.

    >> Do you give to workstation user root access to that workstation?

    >
    > What's with all the personal questions? Thier irrelevant to the discussion
    > as far as i'm concerned.


    Right. I've taken you on my sight just because it's easier to me to form
    a sentence (at the language level; I don't speak English natively).
    Nothing personal. I apologize if you feel offended.

    >> I don't think so.

    >
    > In providing NIS services one iplicitly trusts this to be so. Other
    > systems, providing similar functionality, take into account the
    > alternative possibility could conceivably be the case, if only for a small
    > timeframe. Protecting assets even from legit users with local root access
    > on client machines (say tech support admins.)


    Serving root through any directory service isn't too smart, I think.
    One might try to intercept messages exchanged in authentication
    procedure and crack root password offline. I can hardly imagine the
    situation _requiring_ serving root account through DS.

    >> Can you explain then, how your user could get administrative rights?

    >
    > Read above (ofcource there are more ways to skim a cat, use your
    > imagination.) You can tunnel/wrap/firewall/whatever sure, that's not my
    > point. Point though is: NIS doesn't savely account for the possibility...


    Of course it doesn't. It wasn't designed to address these possibilities
    (NIS+ reportedly was, but there's no NIS+ servers for Linux out there).
    It's just its property. But it is not a security flaw itself. The flaw
    is not to take this NIS property into an account. I suppose both of us
    can agree with that.

    --
    Feel free to correct my English
    Stanislaw Klekot

  16. Re: overcome NIS

    Jan Pompe wrote:
    > base60 wrote:
    >
    >> Jan Pompe wrote:
    >>
    >>> matt_left_coast wrote:
    >>>
    >>>> Jan Pompe wrote:

    >>
    >>
    >>
    >> [...] snip
    >>
    >>>
    >>> That's right and both your statements are nonsense.
    >>>

    >>
    >> Jan, in case it hasn't occured to you by now, binky-boy Matt doesn't
    >> have all of his oars in the water.

    >
    >
    > I can be a bit slow about such things but it was begining to dawn on me.
    >
    > I left IT sometime ago to work in rehabilitating people with
    > shizophrenia + drug abuse problems and given that environment he seems
    > almost high functioning.


    From that perspective, think coke-head syndrome.

    Couldn't do that job... you're a better man than I, Gunga Din.


  17. Re: overcome NIS

    Stachu 'Dozzie' K. wrote:
    > On 04.12.2005, Menno Duursma wrote:
    >
    >>On Sun, 04 Dec 2005 00:54:03 +0000, Stachu 'Dozzie' K. wrote:
    >>
    >>>On 03.12.2005, Menno Duursma wrote:
    >>>
    >>>>On Sat, 03 Dec 2005 22:05:08 +0000, John Thompson wrote:

    >>
    >>>Do you really let in laptops into your internal network?

    >>
    >>Well the only network i own is my home LAN and yes i have a laptop.
    >>
    >>
    >>>Or maybe you connect with bridge/switch wireless network with stationary
    >>>network?

    >>
    >>Wouldn't this effectively make it /one/ network above the media level?
    >>
    >>
    >>>This _is_ serious design flaw.

    >>
    >>???

    >
    >
    > We're talking about networks where NIS can do some work, that is
    > networks requiring some directory services, aren't we? Otherwise NIS is
    > unnecessary service and leaving it running is exactly the same "good"
    > idea as leaving Samba, Apache or any other useless service (providing
    > it's useless in particular case).
    >
    >
    >>>So now we now that you don't let laptops in.

    >>
    >>On other networks then mensioned above: i have no say in such things,
    >>above and beyond consultancy. But assume it possible and in most places
    >>not even far fetched ...
    >>
    >>
    >>>Which other systems can "they" posses? Your desktop systems?

    >>
    >>Probably: given some effort.

    >
    >
    > Then the system admin failed.
    >
    >
    >>But they need not even try that (just
    >>crosslink a laptop to one desktop systems NIC, fail a login on it
    >>logging results on the laptop, spoof thier settings to those and connect
    >>it to the network - and this is when they'd even care for going undetected.)

    >
    >
    > As I said, there're no laptops. Laptops are left at the entrance.
    > Netadmin should provide clear and forcable policy.


    I for one can't see how this will make a significant difference given
    access to desktops on the network. Memory sticks and floppy disks quite
    concealable. If you are administering a network where you have users you
    can't trust you need added layers of protection or alternative setups.

    >
    >
    >>>Do you give to workstation user root access to that workstation?

    >>
    >>What's with all the personal questions? Thier irrelevant to the discussion
    >>as far as i'm concerned.

    >
    >
    > Right. I've taken you on my sight just because it's easier to me to form
    > a sentence (at the language level; I don't speak English natively).


    Neither does Menno. It's not my native language either. I didn't see the
    questions as particularly personal though just a way of asking opinion.

    > Nothing personal. I apologize if you feel offended.
    >
    >
    >>>I don't think so.

    >>
    >>In providing NIS services one iplicitly trusts this to be so. Other
    >>systems, providing similar functionality, take into account the
    >>alternative possibility could conceivably be the case, if only for a small
    >>timeframe. Protecting assets even from legit users with local root access
    >>on client machines (say tech support admins.)

    >
    >
    > Serving root through any directory service isn't too smart, I think.
    > One might try to intercept messages exchanged in authentication
    > procedure and crack root password offline. I can hardly imagine the
    > situation _requiring_ serving root account through DS.
    >
    >
    >>>Can you explain then, how your user could get administrative rights?

    >>
    >>Read above (ofcource there are more ways to skim a cat, use your
    >>imagination.) You can tunnel/wrap/firewall/whatever sure, that's not my
    >>point. Point though is: NIS doesn't savely account for the possibility...

    >
    >
    > Of course it doesn't. It wasn't designed to address these possibilities
    > (NIS+ reportedly was, but there's no NIS+ servers for Linux out there).
    > It's just its property. But it is not a security flaw itself. The flaw
    > is not to take this NIS property into an account. I suppose both of us
    > can agree with that.
    >


  18. Re: overcome NIS

    On 04.12.2005, Jan Pompe wrote:
    >>>>Which other systems can "they" posses? Your desktop systems?
    >>>
    >>>Probably: given some effort.

    >>
    >>
    >> Then the system admin failed.
    >>
    >>
    >>>But they need not even try that (just
    >>>crosslink a laptop to one desktop systems NIC, fail a login on it
    >>>logging results on the laptop, spoof thier settings to those and connect
    >>>it to the network - and this is when they'd even care for going undetected.)

    >>
    >>
    >> As I said, there're no laptops. Laptops are left at the entrance.
    >> Netadmin should provide clear and forcable policy.

    >
    > I for one can't see how this will make a significant difference given
    > access to desktops on the network. Memory sticks and floppy disks quite
    > concealable. If you are administering a network where you have users you
    > can't trust you need added layers of protection or alternative setups.


    Isn't the BIOS and boot protection obvious? It's a part of defending
    single workstation against root privileges takeover.
    Unless I miss something. (Protection against bringing SUIDed binaries is
    just another obviousness, so don't count it.)

    --
    Feel free to correct my English
    Stanislaw Klekot

  19. Re: overcome NIS

    Stachu 'Dozzie' K. wrote:
    > On 04.12.2005, Jan Pompe wrote:
    >
    >>>>>Which other systems can "they" posses? Your desktop systems?
    >>>>
    >>>>Probably: given some effort.
    >>>
    >>>
    >>>Then the system admin failed.
    >>>
    >>>
    >>>
    >>>>But they need not even try that (just
    >>>>crosslink a laptop to one desktop systems NIC, fail a login on it
    >>>>logging results on the laptop, spoof thier settings to those and connect
    >>>>it to the network - and this is when they'd even care for going undetected.)
    >>>
    >>>
    >>>As I said, there're no laptops. Laptops are left at the entrance.
    >>>Netadmin should provide clear and forcable policy.

    >>
    >>I for one can't see how this will make a significant difference given
    >>access to desktops on the network. Memory sticks and floppy disks quite
    >>concealable. If you are administering a network where you have users you
    >>can't trust you need added layers of protection or alternative setups.

    >
    >
    > Isn't the BIOS and boot protection obvious? It's a part of defending
    > single workstation against root privileges takeover.
    > Unless I miss something.


    You don't need root privileges to run 'ypcat'.


    > (Protection against bringing SUIDed binaries is
    > just another obviousness, so don't count it.)


    This NFS does protect against by changing ownership of root owned files
    to nfsnobody (or something like that - it's been a while since I've used
    anything like that).

    Point is of course one should tailor the network to optimise utility and
    security
    and try to achieve a balance between minimising the risks and optimising
    utility (production).
    If you are in a situation where you feel it's necessary to ban laptops I
    might even suggest that you look for alternative solutions to raw NIS & NFS.


  20. Re: overcome NIS

    "Stachu 'Dozzie' K." writes:

    [25 lines snipped]

    >Do you really let in laptops into your internal network?


    How are you going to stop it?


    --
    "Other people are not your property."
    [email me at huge [at] huge [dot] org [dot] uk]



+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast