rvs4000 1.3.1.0 new user experience - part two

Unanswered Question
Mar 31st, 2010

thorough documentation - too much to ask for?

besides the lack of explaining what the log levels are, why not fully disclose reference info on the various messages one might see with an explanation of how one might use them to administer one's network?

for example, what are these security warnings telling me?

Mar 30 23:54:01  - ipt_tcpmss_target: bad length (48 bytes)
Mar 30 19:57:07  - 23 DPT#0 WINDOWX40 RES=0x00 SYN URGP=0

nrf

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Alejandro Gallego Wed, 03/31/2010 - 19:39

OK, I just spent a fair amount of time writing a response and when I went to post.... got logged out and lost it. So here it goes again much edited.

First it is not possible to explain in an admin guide the TCP packet structure, which is what we are looking at in the example you posted. I will do my best to explain what you are seeing.

ipt_tcpmss == relates to IP Tables (Linux, the routers OS) and says "TCP Maximum Segment Size" is not a valid length (48bytes) which should be a security log entry because it could mean an attack

23 DPT#0 WINDOWX40 RES=0X00 SYN URGP=0

this may be a partial entry, but shows a source port of 23 (Telnet) to a destination port of 0 which is a reserved port. Because of this action it should raise a flag and be entered in the security log.
The rest is directly looking at the TCP header which shows our window size (part of the TCP protocol "Windowing"); RES (I believe this should be RST) which is the reset bit for ending the connection, but it is set to 0 as it should be since this is a SYN packet. As with your earlier post this is the beginning of the conversation and the last part of the header URGP; Urgent Pointer which is also set to 0.

So, I hope you can see that this is not an easy thing to document because the TCP protocol would have to be explained. This is not something that can be done in an admin guide. I agree that documentation can be improved, but I hope you understand that is not practical to document all aspects of a log entry. I do hope your post will assist with GUI and admin guide clarification, as you bring up very good points.

Thanks and I hope this helps.

nealrfildes Thu, 04/01/2010 - 05:24

thanks for the details. seeing those, I think some key data is missing in the messages thus making them insufficient for taking any action. You have also demonstrated that it is possible to document how to read them (reference manual along with admin guide?). For example, a reference guide could include drawings of the headers and fields, and explanations of the types of errors that are noted. Granted, attack types change over time but some must be long standing, documentable issues. In addition, some of these error messages might relate to hardware problems or misconfigurations that could receive some troubleshooting assistance. (what will show up if one side is using HDX and the other FDX? other mismatches, etc?)

I think there is a major difference between a somewhat cryptic syslog message and what one should be putting in an email. So this happened, which IP address attempted to do the deed? if you are going to send me email, please include enough information to act on it! otherwise it is no better than spam.

Given that IPS is noting, repelling, and counting attacks, shouldn't this be handled just as some other attacks would? or did these mean some of the thresholds in the setup page were exceeded triggering the email? If that is the case, then the email ought to say which one of those thresholds was exceeded as well.

finally, I would expect any messages important enough to go out through email to also appear in the 'local log'.

nrf

Alejandro Gallego Thu, 04/01/2010 - 09:10

Yeah, Neal I understand what you mean as far as having some mechanism to translate the messages to a more readable format. The problem with that would require more code to be included in the firmware and more CPU power to process the information. This would cause the device to be more expensive and also slow down the processing of packet information. The log system is made up of different code modules that are designed to inspect different parts of network traffic which adds more complexity. Just to follow one of your examples given concerning NIC duplex, if the NICs do not negotiate proper speed / duplex there would be no readable traffic passing through because we would have collisions. So it would be impossible to get information from the other NIC. All we would be able to capture is the default negotiation of our own NIC and nothing else.

Some of the message outputs are built into the code and relate directly to the TCP information. So taking these messages and translating them would mean more code and even then it would be extremely difficult to execute. What would be nice is if the log told us in a more readable format what "Threshold"; as you stated, was breached to at least point the administrator in the right direction.

The problems you are mentioning are not specific to our equipment however, this will hold true accross other manufacturers and you will also be able to see similarities with logging on a Linux box with IP Tables.

I know I am not really answering your concerns directly, but I can tell you that Cisco does look at the forums and suggestions posted are taken into account. What you can do, is do a google search or look into the O'Riley books for a more in depth look at the TCP packet structure. I do not mean for this to come accross in a rude or "blowing you off" manner, just as a personal suggestion.

nealrfildes Thu, 04/01/2010 - 09:32

right, google is one's friend. no offense taken.

  • suppose we relegate cryptic log-like messages to the syslog, make the local log work, and restrict email to messages that make sense to be in email?
  • for those looking at the logs, suppose we make them numbered into categories that make sense so they can be filtered and examined without poring over an endless surge of useless data? right now it is all or nothing - if 4 is turned on you get it all, if not you get a few dribs and drabs now and again. putting the right log level on a log message couldn't cause too much extra code, someone is already setting '4' and why not a reasonable value in its place?
  • hex / unprintable binary codes in messages may be indicative of some issue with bad pointers or heap corruption, so in general, paying attention to symptoms can lead to a better product if one is wanting a better product.
  • improved paper/pdf documentation costs zero firmware, can reduce customer inquiries, or if the customer won't read it you can quickly point them to the appropriate material.
  • to the extent that a reference manual or help page documents a screen section by repeating what the screen already says, it is not doing anyone a favor.

I really like that IPS counts and categorizes events without making you pour through tons of log entries the way other routers might make you do. And when I want to review who is attacking me, I get a short list of IPs to look up without scanning logs.

At this point Cisco seems to be the place to go if one wants SNMP and more advanced network capabilities such as VLAN, The only question is whether the bottom line of quality, price, and frustration index are a good match.

nrf

nealrfildes Sun, 04/11/2010 - 03:42

ok, forums seem to have little impact on product support/quality, but at least I can dump...

Just got a WNDR3300 wireless router, as I set it up with the vendor firmware I was reminded of the slowness of setting up this rvs4000. every time you 'save' the settings, you get a slow reboot. deja-vu!

then I moved it to dd-wrt, and what a difference! Folks, if you want to see what a truly user-friendly router setup looks like, I suggest experiencing this. On each and every page you can 'save' settings, resulting frequently in additional gui items added related to extra abilities of the saved changes. When you have done all the change you want to make, then you hit a "apply changes" button and get a SINGLE REBOOT!  It can be done better, it has been done better,

get a clue!

nrf

nealrfildes Mon, 04/12/2010 - 11:38

I am attaching a document so you can see the odd hex data in the 'security emails'.

apparently, both sending the ntp request (not in attached file) and receiving a ntp reply is a security violation.

it also appears to be triggering some other stuff which is then logged as a security violation.

later, followed by some cryptic syslog stuff that is further masked by unprintable data and/or evidence of a loose pointer.

see attached.

while using free stuff to make money sounds great, if you are not contributing to making the free stuff better you are essentially a leach.

nrf

Attachment: 
nealrfildes Mon, 04/19/2010 - 10:10

if you are going to bug me for IPS data being > 30 days old, why are you not updating it at that interval? or better yet, how about a button that checks to see if there is anything newer?

or stop bugging me please!

nrf

Your Signature Version is beyond 30 days. Please Update it!


Web site shows last update oct 2009, but you bug me to update it!   AAAAAAARGGGGHHH@!

Actions

This Discussion