Improving Security for Kiwi Syslog Server

Many of the products in the SolarWinds^® product lineup have been around for decades now. One of these products, SolarWinds Kiwi Syslog^® Server, continues to be the top Google search hit when one is looking at managing their own syslog collector solution. Despite its long-running product success (and possibly due to its age), we realize there’s much room for security improvements in the product. This blog briefly explores a few of the improvements we’re actively working on.

Principle of Least Privilege

At the inception of Kiwi Syslog Server, the desktop application had no authentication or authorization. The user of the application was allowed full administrative privilege over all operations. This meant any type of Windows user account on the Kiwi server had full control over the product. Only a short while after the acquisition of Kiwi Syslog Server by SolarWinds, the product evolved to offer something providing user access in a feature called Web Access. Kiwi Syslog Web Access is a web-based portal one can use to view, filter, and highlight syslog messages logged by the Kiwi Syslog Server. It provides user management with two roles (standard users and administrators). It’s important to note, though, an administrator in Web Access has fewer privileges than a user running the desktop application. This is because in Web Access, there are no features other than event viewing, filtering, and highlighting (which only occurs in the Web Access layer). In Web Access, the only difference between these two roles is an administrator can additionally create and manage the Web Access user accounts.

The next version of Kiwi Syslog Server will change all this. Instead of a product with a home-grown authentication and authorization model with no direct communication to the syslog service—Web Access only manages the viewing of events the syslog service has fed into a Microsoft SQL Server Compact Edition (aka SQL CE) database—all queries, operations, and subscriptions to the syslog service will go through our GraphQL layer using the ASP.NET Core authorization model. The bearer JWT tokens provided to the GraphQL layer will also be generated by the use of IdentityServer (an OpenID Connect identity layer built on the OAuth 2.0 protocol). Both are tried-and-true industry-standard technologies actively tested and maintained by Microsoft, the .NET foundation, and the community, and they will likely be supported long into the future.

Removal of Visual Basic 6

The Kiwi Syslog desktop application and most of its services are still written in Visual Basic 6 (VB6). Though Microsoft has committed to supporting the VB6 runtime for the support lifetime of Windows 10, to the extent of addressing "serious regressions and critical security issues," the VB6 IDE hasn’t been supported since 2008. Furthermore, VB6 is known for its use of the Component Object Model (COM) programming model, which a VB application leverages to make calls to any of the libraries it needs. Both VB6 and COM have serious flaws when it comes to security and should be deprecated when possible. To address this, the Kiwi Syslog engineering team has been actively developing the next version of Kiwi Syslog Server using .NET 6. This long-term support release of .NET ensures Microsoft will address security vulnerabilities in a timely manner.

Furthermore, the VB6 removal gave the team the chance to reimagine the UI for the product. The functions the desktop and Web Access serve are being consolidated into one web console built on ASP.NET Core and Angular. Besides giving the UI a full refresh, this truly forces an architecture for the UI built on modern-age security.

Conclusion

Hopefully, this small insight into what the Kiwi Syslog team has been up to indicates how important security is to the folks over here at SolarWinds. We’re working on so much more with regard to further securing Kiwi.