7 Replies Latest reply on May 10, 2016 11:37 AM by nicole pauls

    How do I harvest Windows syslogs from Kiwi?


      I've been looking at a previous thread (http://thwack.solarwinds.com/message/169428#169428) about pulling Cisco ASA logs from a Kiwi Syslog Server, and I'm trying to do the same with Windows logs that we syslog to Kiwi. Before the obvious reply comes, yes, I know about the LEM agent for Windows, but no, we won't use it (with the exception of the Kiwi server) because we are strongly against having JRE on our servers, especially AD.


      So...I've looked at the "Tools" on the node in LEM, but there isn't a log format for pulling Windows data from a syslog (we use SNARE agents on our hosts to harvest their Windows event logs).




        • Re: How do I harvest Windows syslogs from Kiwi?

          Hello again, Chris.


          I did some checking, and it sounds like this is a feature request. We had another eval customer ask for something similar recently, so I'll send the request up. Let me know if there's anything specific you want me to include.





            • Re: How do I harvest Windows syslogs from Kiwi?



              Yeah, back in 5.3, I think, one of the advertised features was the ability to use Kiwi Syslog Server as your log source, so we assumed that extended to all device types (even those w/ agents).


              For our part, the only reason we'd insist on Kiwi/Windows is the Java dependency of the agents. If those could switch to a non-Java platform, we'd love to roll out the LEM agents. Forgoing that, there aren't any real specifics on the "Tools" addition. Like I said, we use "SNARE" for our syslog agent, so a consideration of how it formats Windows logs would be nice.


              Thanks for all your help, Phil.



                • Re: How do I harvest Windows syslogs from Kiwi?
                  nicole pauls

                  Hey Chris,


                  Out of curiosity, what's the driver behind the Java restriction on the agent systems? The JRE we install is only installed "within" the agent, and not intended to replace or be used as the system JRE. We only install the JRE bits into the agent install directory and use it to bootstrap & run the agent - so it doesn't install any browser plugins or affect the system JRE otherwise. We still encounter people with restrictions and a need for an agentless solution (Kiwi or built-in), so I'm interested in understanding yours.


                  And, thanks for all of the feedback.

                    • Re: How do I harvest Windows syslogs from Kiwi?

                      Hey Colby,


                      I appreciate the inquiry. Part of it may be paranoia or our IT cultural rigidity, but we have a bad impression of and experience with just about all of the Java family of components on systems. Java has tended to be riddled with vulnerabilities for which we then have to push updates. Then when we do, the Java-dependent apps often break because they are coded for a specific rev and either lose compatibility with the latest build or simply error out when they see the build number change. Finally, from a purist point of view, we try to keep our servers as clean as possible (we roll out VMs for single purposes in most instances), so third-party agents are reluctantly accepted.


                      The info you provided is informative and perhaps you can further enlighten me based on the reasons above. The core concerns wrap around Java updating and security. If that's unfounded, perhaps we'll reconsider (though we'd still love Java-independence).




                        • Re: How do I harvest Windows syslogs from Kiwi?
                          nicole pauls



                          From a technical perspective, we use InstallAnywhere, which is a system for packaging up and deploying applications across multiple platforms (hence Java-based). For Java applications like ours, IA packages a JRE in with the installer (to bootstrap itself, so you don't have to have a JRE installed to run their installers), and lets us select a JRE to deploy within our install process. IA also provides a launcher that lets you run a Windows service (or linux/unix daemon) that combines that deployed JRE with the bootstrap requirements of your application. The JRE is effectively only files dropped on the system as a part of an install - nowhere is the system $PATH modified or the full JRE installation ran (no annoying updater, no plugins), it's effectively just files placed on the filesystem. The Launcher then references that JRE directory to launch our application with the right libraries in the right places. If you update the system's JRE, it doesn't affect our JRE unless you intentionally replace ours, which you'd have to be well aware that you were doing (again, it's files on disk, you'd have to intentionally replace them with a new copy).


                          As far as vulnerabilities in the JRE goes, we quite honestly do make an attempt to update JREs regularly and have a system for doing so from the appliance to the agent, but we limit it to only when we update our agents. Our current JRE version is JRE 6u26 on windows, where the current version of 6 is 6u32 (we are not using Java 7 because we like to fully bake our agents to make sure they are rock solid, and Java 7 is a little fresh). (NOTE: As you might expect this info changes over time; as of May 2016 the agent is running Java 7u80, and we are working on moving to Java 8u92.) It is technically possible for customers with serious concerns to update the JRE independent of us, but you may run into compatibility issues that we have not tested, so we don't officially support doing so.


                          Your attack surface with that JRE dropped with the agent would be limited to things ran in that JRE's context. Out of the box, of course, the only thing that runs this JRE would be our agent. Since we don't register to the system environment, the browser, or install the (annoying) auto-updater dealie, it should be difficult without explicitly doing so to have another application run in our JRE.


                          Many JRE exploits these days are:

                          • Java Web Start: In order to be vulnerable here, you'd need a vulnerable JRE to automatically launch JWS ran applications. Since we don't register to the system, you'd have to do this on purpose.
                          • Java Applets: In this case, you'd need to run a vulnerable applet in the browser (or standalone) context. Since we don't register to the browser, you'd really have to work to do this one on purpose.
                          • Running unknown applications inside the JRE (a more generic version of the above): things like Tomcat and other servlet containers can have issues because vulnerable applications can expose the system if exploitable. Since our application is the only thing that runs with the JRE, this wouldn't apply.
                          • Remote vulnerabilities at the protocol or process level: since our agent isn't acting as a "server" for anything, it'd only be a risk if you were using the same JRE as a service for something else. You'd have to work to make this happen.


                          It's worth noting that the agent doesn't listen for inbound connections, it makes an outbound connection to the appliance. The communication between the appliance and the agent is all encrypted.


                          When Java was a big deal in web browsers they used to try to scan the system for available JREs. In that situation, an enterprising user interested in running the latest annoying navbar (it probably blinked in neon green and linked to their webring, too), could have hooked up to an arbitrary JVM. These days, browsers are pretty keen on plug-ins, and have been burned enough by Java to be careful.


                          We have had customers with strict server versioning requirements turn up our JRE in a scan by software inventory or other tools and comment that it's out of date, and like I said we do make an attempt to update it as we can, or address concerns about any potential vulnerabilities specific to the release version we've got on disk.


                          Regardless of all of that, I hear you on the agent vs. agentless issue, which is a time honored debate, and something we do continue to keep our eye on.