Security in routers2.cgi v2.14.1 ------------------------ Security is always a grey area -- you have to balance the useability against the sensitivity of the data. Only you can choose how sensitive the data in question is, and so only you can choose which additional methods, if any, you choose to follow. Listed here are a few of the optional security changes and loopholes the software currently has. 1) SNMP Community This one involves the program revealing the SNMP community string via the Extension scripts. If you call an Extension script with the 'insecure' option set, then it will pass the SNMP community string in the URL. This can easily be seen by a user. To protect against this, firstly only use 'insecure' if you really need it. Secondly, make sure your SNMP strings are read-only, and restricted to just your routers.cgi/MRTG server. 2) Hidden .cfg file targets If you use the 'allowexplore' option in the routers2.conf, remember that it is only a 'security by obscurity'. People who know the names of your .cfg files can still view their graphs, if given a complete URL for that graph. To prevent this, use authentication and restrict the .cfg files by user. 3) Authentication. If you use internal authentication (as opposed to letting your web server take care of it) then note that the cookie-based system is vulnerable to a number of attacks. A replay attack from the same client workstation is possible, if a user is modifying expire times. Also, you should change the value of CHOCOLATE_CHIP in the script in order to make it harder for people to create their own fake cookies. Web server-based authentication is a much more secure way to achieve this, and you should run through https SSL in order to prevent password sniffing. A session-based authentication system patch has been provided by a user submission, and should be available from v2.15. If you choose to use web server authentication (recommended), then don't forget to set the authentication on the graphpath directory IN ADDITION to setting it on the routers2.cgi script itself. Use the same Realm and authentication parameters so that they only have to sign in once, of course. Failing to do this allows people to sneak looks at graphs in the graphpath. You may also want to put the same requirements on any extension scripts you use, such as the trending module trend.cgi 4) Shared graphs directory The working directory, graphpath, is used for all temporary graphs. This allows the system to be more efficient, since if userA asks for a graph recently sent to userB, the system will not need to regenerate it. However, this gives the possibility that a user can directly request a graphic file that they would not normally have access to, if they know the internal naming pattern. This is not currently fixable, but a patch in a user submission due to be incorporated soon will allow separate graphpath directories on a per-user basis, solving this issue. See version 2.15. As mentioned in (3), dont forget to put authentication on this directory as well as on the routers2.cgi script, if you are using webserver based authentication. 5) SpeedyCGI If using speedyCGI, note that it will put parameters into the ARGV line. This can potentially allow people with system access to find out the .cfg file names and target names. A small risk, although it helps them to exploit (4). 6) GET rather than POST in URL syntax. This is unavoidable in most cases. Although login is done via POST, the script needs to use GET syntax in many places -- workarounds would require large amounts of javascript and decrease portability and browser support. This allows users to find out .cfg filenames and target names by exploring the web browser history -- not a problem in itself, but it helps them with other exploits such as (4). The worst case of this is (1) where it can reveal the SNMP community string. 7) Filesystem space denial-of-service If you give your users access to the Archive feature, then they could potentially call it repeatedly to archive every minute. This will fill up the filesystem where the graphpath resides. To fix this, I would suggest restricting users to read-only, and only allowing certain authenticated users access to add an archive. Also, a periodic clean-up job should be run on the archive path. Note that, if you have a lot of targets, you can potentially have 4 graphs (dwmy), 8 styles, 3 rescales = 96 graphs average 8k = 0.8Mb per target in the graphs directory. A medium site with 1000 targets would be pushing 1Gb for graphs alone! You should be running a periodic job to clean up your graphs directory of no longer required graphs -- even run this every 10 mins to clean up old 'daily' graphs, if you need to. A bug in versions before V2.14beta5 makes this vulnerabilty worse. You should upgrade or patch as soon as possible if your server is visible from the internet. This should not be seen as a complete list of potential vulnerabilities. However, for the vast majority of people, none of these would be concerns. There are a number of additional features in the code to give you extra control over security, and to hide portions of the system from selected users. 1) Builtin authentication This is not perfect, but will allow you to grant access to various .cfg files on a per-user basis. It is better to use the web server's own authentication, though, if you can, and let the CGI interface pass the authenticated username to the script. 2) Security levels You can define a default and per-user security level number. This is used to decide whether or not to display Extension links (and [menu] links). This is, however, only for display purposes -- the Extension script is expected to handle its own securtiy! Therefore, if using web server authentication, you should set the same requirements on the extension script as on routers.cgi itself and the graphs directory (use the same Realm name so that the password authenticates to all of them at once). 3) allowexplore You can disable the Devices and Targets menus, if you want, through the routers2.conf file. This only controls the menus, though, and knowledge of the file and targets names will still give you access (provided they are not blocked by the cfgfiles and confpath of course). 4) Graph archiving This can be switched to read-only mode in the default or per-user defninitions. In read-only mode you cannot create or delete graph copies. Steve Shipway, 2004