Archive for the ‘Logs’ Category

Prevent Analytics From Logging Gigabytes of Data

Wednesday, May 25th, 2011

This one comes courtesy of Fabien Sanglier, a WCI guru of epic proportions (no, he didn’t make me say that…).

At our client site, we noticed that Analytics was logging gigs worth of data to the weblogic.out file – a catch-all file for logging reported via the standard out pipe. Note that IIS doesn’t record logs on this stream, so this is a Weblogic-only problem. The line recorded over and over (one for each hit):

OPENUSAGE(INFO ): ==> Event sent to: //UsageTracking@openusage/ wci-analyticscollector| port=31314/ BYTEARR

To prevent these events from being logged, he suggests updating %PT_HOME%/settings/configuration.xml to reduce logging and turn off console logging:

<component name="analytics-communication:config" type="http://www.plumtree.com/config/component/types/analytics-communication">
<setting name="logging:level">
<value xsi:type="xsd:string">WARN</value>
</setting>
<setting name="console-logging:enabled">
<value xsi:type="xsd:boolean">false</value>
</setting>

</component>

(more…)

Security Reminder: Stay Vigalent!

Tuesday, July 13th, 2010

Government work can be a challenge with all the rules, regulations, and procedures that come with it.  But there’s one thing I have to continually remind myself when dealing with that “way too much paperwork” thing: whether I’m administering a government web site, ALUI portal, or any other web application is that security can and MUST be taken seriously at all times. 

So, consider this a friendly reminder – especially if you’re exposing your portal on the Internet: stay vigalent, and take all threats seriously.  About 18 months ago, I got an alert in the middle of the night that we were out of drive space on a portal server at one of my semi-government clients.  No big deal; it happens all the time.  Only this time it was different.  Overnight, our logs had exploded from roughly 20MB/day to 2GB/day:  something was seriously wrong.  The logs were so big they were hard to even open, but when i did finally crack them open, here’s a snippet of what I found:

Basically, there were GIGABYTES of these requests – someone was scanning our servers, alternating in different object IDs for different spaces, looking for incorrectly secured communities or other portal objects.  They were basically just scanning different activity spaces, making all kinds of semi-random requests with different IDs a couple times a second.

It turned out that these particular baddies weren’t that sophisticated: they were making no effort to conceal their source IPs through some sort of distributed attack, and their algorithm clearly didn’t demonstrate a deep knowledge of how portal URLs are constructed.  And honestly, we were lucky for even finding this attack in the first place because at the time we didn’t regularly audit the logs, and only caught it because of that benign disk space warning.

In the end, we blocked the entire subnet (from China, a notorious hacker hangout), and the attacks stopped.  We should have reported the attempted breach, and I certainly would if it happened again, but I’m sharing this story with a single moral: no matter how “little” you think your site may be or how you think “noone cares about my little corner of the internet”, the bad guys are out there, and they don’t discriminate when they’re looking for victims.

So, take a minute today to check your security settings one more time, and keep an eye on those log files for anything suspicious!