Backup Program With Push Architecture - Storage

This is a discussion on Backup Program With Push Architecture - Storage ; Is there a decent Windows based backup program that allows clients to push their backups to a central server using an agent technolgy rather than having the central server contact the distributed agents and pull the data? The problem with ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Backup Program With Push Architecture

  1. Backup Program With Push Architecture

    Is there a decent Windows based backup program that allows clients to push
    their backups to a central server using an agent technolgy rather than
    having the central server contact the distributed agents and pull the data?

    The problem with the pull model is that you often end up having a shared
    account with administrative access to each computer, which creates a
    security hole. You also have an open server running on every computer that
    can be potentially exploited by buffer overruns, or subject to other direct
    attacks. In the push model you at least protect all of the remote
    computers being backed up, and you can focus the protection efforts on the
    one machine that is the server for the backups.

    I'm trying to keep the cost under $3K with server and clients, for about 20
    computers, but I want to identify packages with good security models first,
    worry about cost later.

    I would prefer to not use SMB since that opens up other access to the server
    I don't want to deal with. I don't have enough drives at each computer
    being backed up to stage data locally then migrate later over something like
    SFTP using SCP, so I would prefer to first identify a decent agent based
    backup technology.

    --
    Will



  2. Re: Backup Program With Push Architecture

    On Feb 6, 8:43 pm, "Will" wrote:
    > Is there a decent Windows based backup program that allows clients to push
    > their backups to a central server using an agent technolgy rather than
    > having the central server contact the distributed agents and pull the data?
    >
    > The problem with the pull model is that you often end up having a shared
    > account with administrative access to each computer, which creates a
    > security hole. You also have an open server running on every computer that
    > can be potentially exploited by buffer overruns, or subject to other direct
    > attacks. In the push model you at least protect all of the remote
    > computers being backed up, and you can focus the protection efforts on the
    > one machine that is the server for the backups.
    >
    > I'm trying to keep the cost under $3K with server and clients, for about 20
    > computers, but I want to identify packages with good security models first,
    > worry about cost later.
    >
    > I would prefer to not use SMB since that opens up other access to the server
    > I don't want to deal with. I don't have enough drives at each computer
    > being backed up to stage data locally then migrate later over something like
    > SFTP using SCP, so I would prefer to first identify a decent agent based
    > backup technology.
    >
    > --
    > Will


    While I cant name any products that do this push scheme, I cant think
    of any security holes with existing products that wouldnt have been
    raised by real security experts... I think you may be assuming some
    scenario to justify a different model.... in a push based scheme for
    instance, how do these clients get corporate policies as to when they
    need to push? Some dissemination of information may still be needed
    and cause other issues...

    Having each end server or client have local security can never be
    circumvented.

    I'd never want an unprotected machine pushing data to a central
    server...

    Sorry to not answer your question with a product, but I guess I'm
    trying to point out that asking for a specific product architecture
    because of a perceived problem may not be as ideal as letting the
    product vendors figure out the correct solutions...

    Dvy


  3. Re: Backup Program With Push Architecture

    wrote in message
    news:1170827950.008910.79900@a75g2000cwd.googlegro ups.com...
    > While I cant name any products that do this push scheme, I cant think
    > of any security holes with existing products that wouldnt have been
    > raised by real security experts... I think you may be assuming some
    > scenario to justify a different model.... in a push based scheme for
    > instance, how do these clients get corporate policies as to when they
    > need to push? Some dissemination of information may still be needed
    > and cause other issues...


    Once you have a connection, you can pass control and data equally. In a
    model where a client contacts a central server, it authenticates the host,
    possibly using the Kerberos ticket for the machine, and then the server can
    pass back scheduling and other details. McAfee's managed virus service
    uses a push model, where the client agents contact a central web server, to
    obtain their configuration information as entered onto the web site by an
    admin. That works like a charm.

    Backup and intrusion detection agents that use domain accounts are among the
    favorite methods of intrusions for hackers. Not only is such software
    normally poorly written from the standpoint of security, but a little known
    defect in the Windows OS architecture is that service account passwords are
    stored *unencrypted* in a memory known as the LSA Secrets, and once you do a
    buffer overflow on any service running in SYSTEM context, you can grab those
    passwords and then use them to gain access to other machines. Refer for
    example to pages 52 and 53 of the book "Protect Your Windows Network",
    written by two Microsoft employees, who give an interesting hypothetical
    account of a hack based on intrusion detection software using a shared
    domain account. Those cited pages explain how the LSA Secrets are held in
    memory unencrypted.

    This defect is particularly hideous when they capture the backup account,
    because quite often that user is granted membership to administrators group,
    run as a service, and act as part of operating system user rights.


    > Having each end server or client have local security can never be
    > circumvented.


    You are messing up different concepts. Are you talking about
    authentication of the host? Are you talking about authentication of a
    specific user? I don't remember making a proposal that either end of the
    connection should have no security. Can you cite that back to me because I
    don't think I said it.

    What I did say is that I would rather have one server than having 100
    servers. Servers are targets. Leaving open a port that anyone can
    contact and play with creates just another opportunity for an exploit.


    > I'd never want an unprotected machine pushing data to a central
    > server...


    Conclusion doesn't follow from premise. You cannot conclude that a machine
    is unprotected because it pushes data. I wouldn't want unprotected
    machines pushing data anywhere either. If I knew that premise about a
    specific machine I wouldn't include it in the backup list until it was
    secured.

    The whole point of my wanting a different architecture for backup is that I
    want the machines that push out their backups to be securable in the first
    place. The reason they are unprotected is because they run too much buggy
    software that exposes too many ports that any virus can patiently hack away
    at. In a secure network, clients should not open up any *server* ports to
    at all. When Microsoft administers Group Policy, it's the client that
    grabs the information from the server, not the server that pushes to the
    client.

    Any architecture that uses an agent that opens a server port on client
    machines turns that client into a server, and it is subject to attack that
    cannot be protected by a firewall. You may prefer to protect 100 servers
    used by one client on an end user network, but I would prefer to have one
    well identified server and 100 clients.

    --
    Will




    > Sorry to not answer your question with a product, but I guess I'm
    > trying to point out that asking for a specific product architecture
    > because of a perceived problem may not be as ideal as letting the
    > product vendors figure out the correct solutions...
    >
    > Dvy
    >




  4. Re: Backup Program With Push Architecture

    On Feb 6, 11:37 pm, "Will" wrote:
    > wrote in message
    >
    > news:1170827950.008910.79900@a75g2000cwd.googlegro ups.com...
    >
    > > While I cant name any products that do this push scheme, I cant think
    > > of any security holes with existing products that wouldnt have been
    > > raised by real security experts... I think you may be assuming some
    > > scenario to justify a different model.... in a push based scheme for
    > > instance, how do these clients get corporate policies as to when they
    > > need to push? Some dissemination of information may still be needed
    > > and cause other issues...

    >
    > Once you have a connection, you can pass control and data equally. In a
    > model where a client contacts a central server, it authenticates the host,
    > possibly using the Kerberos ticket for the machine, and then the server can
    > pass back scheduling and other details. McAfee's managed virus service
    > uses a push model, where the client agents contact a central web server, to
    > obtain their configuration information as entered onto the web site by an
    > admin. That works like a charm.
    >
    > Backup and intrusion detection agents that use domain accounts are among the
    > favorite methods of intrusions for hackers. Not only is such software
    > normally poorly written from the standpoint of security, but a little known
    > defect in the Windows OS architecture is that service account passwords are
    > stored *unencrypted* in a memory known as the LSA Secrets, and once you do a
    > buffer overflow on any service running in SYSTEM context, you can grab those
    > passwords and then use them to gain access to other machines. Refer for
    > example to pages 52 and 53 of the book "Protect Your Windows Network",
    > written by two Microsoft employees, who give an interesting hypothetical
    > account of a hack based on intrusion detection software using a shared
    > domain account. Those cited pages explain how the LSA Secrets are held in
    > memory unencrypted.
    >
    > This defect is particularly hideous when they capture the backup account,
    > because quite often that user is granted membership to administrators group,
    > run as a service, and act as part of operating system user rights.
    >
    > > Having each end server or client have local security can never be
    > > circumvented.

    >
    > You are messing up different concepts. Are you talking about
    > authentication of the host? Are you talking about authentication of a
    > specific user? I don't remember making a proposal that either end of the
    > connection should have no security. Can you cite that back to me because I
    > don't think I said it.
    >
    > What I did say is that I would rather have one server than having 100
    > servers. Servers are targets. Leaving open a port that anyone can
    > contact and play with creates just another opportunity for an exploit.
    >
    > > I'd never want an unprotected machine pushing data to a central
    > > server...

    >
    > Conclusion doesn't follow from premise. You cannot conclude that a machine
    > is unprotected because it pushes data. I wouldn't want unprotected
    > machines pushing data anywhere either. If I knew that premise about a
    > specific machine I wouldn't include it in the backup list until it was
    > secured.
    >
    > The whole point of my wanting a different architecture for backup is that I
    > want the machines that push out their backups to be securable in the first
    > place. The reason they are unprotected is because they run too much buggy
    > software that exposes too many ports that any virus can patiently hack away
    > at. In a secure network, clients should not open up any *server* ports to
    > at all. When Microsoft administers Group Policy, it's the client that
    > grabs the information from the server, not the server that pushes to the
    > client.
    >
    > Any architecture that uses an agent that opens a server port on client
    > machines turns that client into a server, and it is subject to attack that
    > cannot be protected by a firewall. You may prefer to protect 100 servers
    > used by one client on an end user network, but I would prefer to have one
    > well identified server and 100 clients.
    >
    > --
    > Will
    >
    > > Sorry to not answer your question with a product, but I guess I'm
    > > trying to point out that asking for a specific product architecture
    > > because of a perceived problem may not be as ideal as letting the
    > > product vendors figure out the correct solutions...

    >
    > > Dvy


    Will... a lot of your objections are well written... almost to the end
    that you are a proponent of a particular product!

    That said, let me ask a naive question... you claim servers are more
    of targets... in my past experience with application attacks, I think
    I can cite as many client problems as server problems... that is, I've
    seen equally dumb client programs susceptible to buffer overruns... so
    I'm not sure I buy the "clients are more secure than server" argument
    as much as "better code is better period" argument and since no one
    can guarantee code is bug free, I just rely on the end point security
    gurus to do their best around the board.

    I've personally in our 10,000 person company ever had a problem with
    our backup s/w ... though we have had other serious security attacks
    in other areas.... usually, in our IT dept we take the approach of "if
    it aint broke, dont fix it":


  5. Re: Backup Program With Push Architecture

    wrote in message
    news:1170919287.828452.207330@l53g2000cwa.googlegr oups.com...
    > Will... a lot of your objections are well written... almost to the end
    > that you are a proponent of a particular product!


    If I could find the product and test it, I would probably become a proponent
    of it. So far it is looking like using the native Windows backup and
    designing a secured file server is going to be safer than what most vendors
    in the backup area are offering.


    > That said, let me ask a naive question... you claim servers are more
    > of targets... in my past experience with application attacks, I think
    > I can cite as many client problems as server problems... that is, I've
    > seen equally dumb client programs susceptible to buffer overruns... so
    > I'm not sure I buy the "clients are more secure than server" argument
    > as much as "better code is better period" argument and since no one
    > can guarantee code is bug free, I just rely on the end point security
    > gurus to do their best around the board.


    Sure, the most dangerous network in any company is the end user network,
    well behind all the firewalls. You browse the wrong web site, pickup up a
    Trojan, and then it goes on the hunt for other machines to control. So,
    would you rather give that Trojan 10000 other targets or a few targets?
    If the client machines are locked down and do not expose server ports, it
    becomes much more difficult for the Trojan to spread.


    > I've personally in our 10,000 person company ever had a problem with
    > our backup s/w ... though we have had other serious security attacks
    > in other areas.... usually, in our IT dept we take the approach of "if
    > it aint broke, dont fix it":


    I don't know your software or your company, but the question is how would
    you know if the backup account on each machine was the method of intrusion
    or not? From what I have seen in most companies, they spend time fighting
    the fire after it happens, and they don't invest a lot of time asking
    themselves if the design of things might contribute to future fires.

    Assuming the backup service account on each client runs as a domain account,
    then you definitely have a risk. Any trojan that breaks into that machine
    as SYSTEM has access to that account and its password, and can spread to
    other machines via SMB, RPC, etc using those credentials. You have to
    worry about buffer overflows on the service directly. Assuming the
    service runs on each client as SYSTEM, then you also have to worry about how
    good is the cryptography between the backup vendor's client and server,
    since some kind of Windows credential might be exchanged from the backup
    server to the client.

    Anyway, in our own case, we are doing a slow migration from Windows 2000 to
    Windows 2003/XP, and I've set a goal that on the new machines no ports are
    listening on any machine that is not a server.

    --
    Will



  6. Re: Backup Program With Push Architecture

    On 2007-02-07, Will wrote:
    > Is there a decent Windows based backup program that allows clients to push
    > their backups to a central server using an agent technolgy rather than
    > having the central server contact the distributed agents and pull the data?


    Yes, CDP for files is such a solution, which IMHO is quite cool:

    http://www.cdp-backup.com/

    Doesn't require any serverside software, except a place to write
    the files (usb-disk, windows file share, WebDAV or a TSM server).


    -jf

  7. Re: Backup Program With Push Architecture

    "Jan-Frode Myklebust" wrote in message
    news:slrnet3dj7.mo3.mykleb@99RXZYP.ibm.com...
    > On 2007-02-07, Will wrote:
    > > Is there a decent Windows based backup program that allows clients to

    push
    > > their backups to a central server using an agent technolgy rather than
    > > having the central server contact the distributed agents and pull the

    data?
    >
    > Yes, CDP for files is such a solution, which IMHO is quite cool:
    >
    > http://www.cdp-backup.com/
    >
    > Doesn't require any serverside software, except a place to write
    > the files (usb-disk, windows file share, WebDAV or a TSM server).


    What's the list price on that per client? Do you know if I it requires
    you to run Tivoli for the core backup to tape?

    I'll be honest that IBM just scares me as a vendor for software. They have
    too many damn options, constantly dropping packages and adding new ones, and
    you need a small team of experts to just figure out what to buy from them.
    I just went to the Tivoli section of their web site, and it has more than
    100 products that have the word Tivoli in them in the product selection
    list!! And to make things even better, none of them is CDP!

    --
    Will



  8. Re: Backup Program With Push Architecture

    On 2007-02-14, Will wrote:
    >
    > What's the list price on that per client?


    The webpage http://www.cdp-backup.com/ says $35.

    > Do you know if I it requires
    > you to run Tivoli for the core backup to tape?


    No it doesn't require anything on that side. It's just
    dumping files to the file server, and you can use anything
    you want to further back that up to f.ex. tape.


    > I'll be honest that IBM just scares me as a vendor for software. They have
    > too many damn options, constantly dropping packages and adding new ones, and
    > you need a small team of experts to just figure out what to buy from them.
    > I just went to the Tivoli section of their web site, and it has more than
    > 100 products that have the word Tivoli in them in the product selection
    > list!! And to make things even better, none of them is CDP!


    Yes, CDPff is quite new, and not typical IBM sw in that it's a
    pure client side solution (even availble in shrink-wrap boxes in Japan :-).
    I think IBM is more marketing this towards large customers that
    wants to re-brand it, and push out pre-configured versions of it to their
    users.


    -jf

+ Reply to Thread