Nmap/Updater Design And Requirements

From SecWiki
Jump to: navigation, search
  1. Portability -- should work on at least Linux, Windows, and Mac
  2. [REQRUIRED] May need to support authentication -- so users can sign up for an account to use the updater. This helps with tracking, reducing various types of abuse (like people setting cron to update every 20 mins), etc. The idea is to make a web page where people can register an account, and then when they try to update for the first time, it requests their username and password. If we decide not to require registration at first, we could use default credentials instead. Perhaps this could be done with http digest auth or something. Making sure the system can support this if needed at least makes it more future proof. There has to be a web form for making new user accounts.
  3. Security: Nmap is a security tool, so updater must offer a high level of security. But at the same time it needs to be practical and convenient enough that people use it and that Nmap project is able to maintain it. Our thoughts are:
    1. [REQUIRED] Transit security - users should be able to trust that the downloads they receive cannot be modified in transit. Nmap should ship with the key/fingerprint information necessary to validate starting with first update.
    2. [REQUIRED] MITM attacker can not force downgrade to legitmate, but earlier state of Nmap code than the user already has.
    3. [NICETOHAVE] MITM attacker cannot (without updater being able to detect the problem and warn user) cause a user to think there are no new updates when there actually are some. This could be done by, for example, replaying old metadata. Of course an MITM attacker can generally stop an update by preventing/destroying the connections to server, but this can be detected.
    4. [NICETOHAVE] If distribution server is compromised, prevent attacker from changing the updates. In practice, this probably means signing them on another machine before moving them to the distribution server. Problems here are that it will introduce delay, makes the system more complex, may require manual signing, etc. But it still would be a nice defense-in-depth security benefit. We do currently offered the Nmap packages themselves offline-signed (though very few people verify them).
  4. Must at least include the platform-indepdendent files.
    1. Would probably include pretty much everything that Nmap uses which is platform-independent. In particular: NSE scripts; libraries; data files like nmap-os-db, nmap-service-probes, nmap-services, nmap-mac-prefixes; the nse_main.lua, etc.
    2. If we ONLY include the platform independent files, need to have a mechanism for client to tell its "version number" and then the server only gives updates if the version number is new enough to use them. There will be a setting on the server which tells therequired version number. If the client is too old, the server passes a message which is then passed back to the client. Something like "Sorry, your version of Nmap ($Version) is too old to utilize the latest updates. Please update to a newer version of Nmap at [download or update instruction url]"
    3. Note that we'll need to think about what to use as "version number". There is the official Nmap version number, or we could use the svn number at time of build, or something else.
    4. nmap --version (and maybe other places) should tell the revision number of last update. This helps with debugging problem reports, among other things.
  5. Nmap must be able to print a warning if:
    1. The server says that a newer Nmap is required in order to do updates
    2. No platform-independent updates have been done in at least (X time period)
    3. And maybe if the binaries haven't been updated in a long time. Perhaps this warning could happen during update process (e.g. give a warning of Nmap is old, even if not so old that updates are refused).
    4. We'll need to decide on the appropriate time periods. We could either have a set number of days baked into the client, or we could have the server have a WARN mechanism which still allows updates, but prints a warning, and it could base that on the Nmap client version. This would be in addition to the ERROR system which refused to update and tells the client it is too old.
  6. Regarding updates of platform-specific files like nmap.exe, ncat.exe (including executables on non-Windows systems)
    1. PROs:
      1. Users have easier access to newest performance and features, including things like recent IPv6 raw packet stuff, upcoming IPv6 OS detection, new scan types, etc.
      2. Resolves, for the most part, the mismatch problem -- users get new binaries along with new platform independent files, so they should hopefully always work together
      3. Easier for us to support users since they get newest binaries so bugs are fixed right away rather than have them continue to be reported over and over, also means we don't have to worry about as many combinations of binary files + platform indepenent stuff since they get it together
    2. CONs:
      1. We'd need build systems for the various platforms, or we'd have to just do manually compiled updates on an as-needed basis.
      2. More complex to set up and maintain.
    3. We've decided that we don't require this capability for the first version, we still have some related requirements
    4. [REQUIRED] For any proposed/chosen system, we need a document/description of if and how it would be extended to handle binaries if we decided that we needed that in the future.
    5. [NICETOHAVE] Ideally the document above will be a smooth and relatively painless process which allows us to provide binaries (maybe only for one or two platforms at first) without needing dramatic changes and while preserving the work we did on the initial system. Preferably it would keep working in platform-independent-only mode for platforms which we don't yet support with binaries.
  7. Open source
    1. The updater system (e.g. the client we ship) must be under an acceptable open source license -- e.g. MIT, BSD, etc.
  8. Maintained
    1. The infrastructure we use for the updating system (e.g. the updater framework itself) should ideally be actively maintained and widely used so that we don't get stuck maintaining it.

Implementation Options

This section lists potential updating systems we could use and how closely they can match the requirements

TUF

  1. Portability: YES
  2. May need to support authentication of users: Not really. It would require a whole web interface and a bunch of work. So it could be done but not out of the box. It seems like if you are worried about DDOS's then you should set up a filter which ignores clients which hit us more often than once a minute over 5 minutes. Thats a much more elegant solution than requiring users who want to update to register which I have never seen before. I know I wouldn't register to get updates. I would just redownload the whole package.
  3. Security: YES thats the whole point of TUF
    1. Transit security: YES current versions already have this.
    2. [REQUIRED] MITM attacker can not force downgrade to legitmate, but earlier state of Nmap code than the user already has.YES
    3. [NICETOHAVE] MITM attacker cannot (without updater being able to detect the problem and warn user) cause a user to think there are no new updates when there actually are some. Sort of. They could serve the current version metadata for about a week. Then it would no longer work.
    4. [NICETOHAVE] If distribution server is compromised, prevent attacker from changing the updates. YES
  4. Must at least include the platform-indepdendent files. Yes current version does this
    1. Would probably include pretty much everything that Nmap uses which is platform-independent. In particular: NSE scripts; libraries; data files like nmap-os-db, nmap-service-probes, nmap-services, nmap-mac-prefixes; the nse_main.lua, etc. YES
    2. If we ONLY include the platform independent files, need to have a mechanism for client to tell its "version number" and then the server only gives updates if the version number is new enough to use them: This is definitively possible. We would need to set up an a manifest and extract the version number from the current nmap install.
    3. Note that we'll need to think about what to use as "version number". There is the official Nmap version number, or we could use the svn number at time of build, or something else.
    4. nmap --version (and maybe other places) should tell the revision number of last update. This helps with debugging problem reports, among other things.
  5. Nmap must be able to print a warning if:
    1. The server says that a newer Nmap is required in order to do updates: Not currently set up but we could do it pretty quickly.
    2. No platform-independent updates have been done in at least (X time period): Not currently set up but we could do it pretty quickly.
    3. And maybe if the binaries haven't been updated in a long time. Perhaps this warning could happen during update process (e.g. give a warning of Nmap is old, even if not so old that updates are refused). Possible.
    4. WARN and ERROR system: Again possible but we are going to need to setup a manifest system and do more work.
  6. Regarding updates of platform-specific files like nmap.exe, ncat.exe (including executables on non-Windows systems)
    1. PROs:
      1. Users have easier access to newest performance and features, including things like recent IPv6 raw packet stuff, upcoming IPv6 OS detection, new scan types, etc.
      2. Resolves, for the most part, the mismatch problem -- users get new binaries along with new platform independent files, so they should hopefully always work together
      3. Easier for us to support users since they get newest binaries so bugs are fixed right away rather than have them continue to be reported over and over, also means we don't have to worry about as many combinations of binary files + platform indepenent stuff since they get it together
    2. CONs:
      1. We'd need build systems for the various platforms, or we'd have to just do manually compiled updates on an as-needed basis.
      2. More complex to set up and maintain.
    3. We've decided that we don't require this capability for the first version, we still have some related requirements
    4. How to add binaries: The easy and painless way is to just have a different binary repository for each installation. 32vs 64 and linux vs windows vs mac. Then you update the updater program to set them up. The trickiest thing is going to be figuring out which repository should be used for each client. But we could add that to the nmap version strings.
      This is actually easy--we already know the platform as part of the configuration process. You can see it with nmap -V; for me it prints x86_64-unknown-linux-gnu. David 22:46, 16 August 2011 (PDT)
    5. Painless Upgrade: When we want to upgrade we just turn on the binary repositories in the updater client. However since the updater client is platform specific: windows vs everything else it will be a little trickier unless we build it in from the beginning. Then it just downloads files from the binary repositories. However the really tricky thing is going to be installing new registry keys and running visual studio redistributables upon installation. It seems like the best way to do windows binary updates is going to be to just download the installer and rerun it.
  7. Open source: YES.
    1. The updater system (e.g. the client we ship) must be under an acceptable open source license -- e.g. MIT, BSD, etc.: Yes.

Links

Retrieved from "https://secwiki.org/mediawiki/index.php?title=Nmap/Updater_Design_And_Requirements&oldid=744"