03-31-2010 10:57 AM
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
03-31-2010 07:39 PM
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.
04-01-2010 05:24 AM
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
04-01-2010 09:10 AM
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.
04-01-2010 09:32 AM
right, google is one's friend. no offense taken.
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
04-11-2010 03:42 AM
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
04-12-2010 11:38 AM
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
04-19-2010 10:10 AM
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@!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide