Filtering verbose alerts
Greetings all. I'm having some difficulties implementing event filters for a 4215 running 5.0.4.
1. I've globally enabled verbose alerting via the CLI by doing
# service event-action-rules rules0
# overrides produce-verbose-alert
2. I want to filter 'TCP SYN Port Sweep' (3002 0) so it doesn't get logged to the idsEventStore. I've created the following single filter,
# service event-action-rules rules0
# filters insert foo begin
# signature-id 3002
# subsignature-id-range 0-10
# actions-to-remove produce-verbose-alert
# filter-item-status Enabled
# stop-on-match True
I save my changes and when running local scans I see the event still being logged but WITHOUT the triggerPacket info. OK, I edit the rule and change to
# actions-to-remove produce-alert
run scans again and the event appears in the idsEventStore WITH the triggerPacket.
It appears I have to create two identical filter rules, first one with
# actions-to-remove produce-verbose-alert
next one with,
# actions-to-remove produce-alert
in order to completely filter 'TCP SYN Port Sweep' from the idsEventStore and I don't see it. So my question to the group is,
How does one create a single event filter rule to drop verbose alerts? Note: I need to have produce-verbose-alert set globally for troubleshooting.
Thanks in advance for the assistance.
When creating a filter you can specify multiple actions to remove. In IDM you hold down the control key to select each additional action. In IDM I think you put a "|" between each action you want to remove: "produceAlert|produceVerboseAlert".
You will need to use the one filter to remove All actions that produce any kind of alert.
So you need to remove the following actions at a minimum:
produceAlert
produceVerboseAlert
requestSnmpTrap
logAttackerPackets
logVictimPackets
logPairPackets
The last 5 actions above will force an alert to be produced Even if produceAlert has been filtered out. So you have to remove them as well. This is sort of stated in the IDM guide:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids11/idmguide/dmevtrul.htm#wp1062278
But was not made clear in the CLI guide.
If you want to prevent all the actions (including those that don't produce an alert) then enter every action in the actions to remove section.
(NOTE: This is much easier to do in IDM. You select the top action, Hold down Shift key, and select the last action, and all the actions will be selected for removal).
It sounds like you are not interested in the 3002 signature at all. If this is the case, then the simplest thing to do is to just Disable the signature, and not worry about the filters.
The filters shoudl really only be used if you want to filter for specific address ranges, or want to filter out some but not all of the actions.
If you want to filter out All actions for All ip addresses, then just Disable the signature instead.
It will save on internal processing within the sensor.
Similar Messages
-
Produce-verbose-alert & performance
...wanted to pose a general question to the forum.
If I configure/enable 'produce-verbose-alert' as an event action override (globally), will this cause any peformance issues with an IPS v 5.0 sensor? I understand that there are other variables such as amount of traffic on the monitoring interface, number of active signatures, etc but just wanted to get a general sense. Thank you."Produce Verbose Alert" is the equivalent of the 4.1 "capture trigger packet". It won't have any significant affect on the performance of the sensor. It will increase the size of each alert record, so the eventlog may fill faster...which could lead to your needing to pull events slightly more often. That will depend on network traffic and alarm rates though.
-
Customizable Email Filters w/ Alerts in IOS8?
Hi, I have an iphone5s which I bought after I lost my BB10 powered Z10. On the Z10, there was an app that let me customize alerts according to filters I could set, either according to email address of the incoming email, or things like text strings found in the body or subject. To some degree you could do this in the OS as it came.
I have an online business for which I need to know about specific communications during the day, but don't want to be distracted by all of them. For example, one email account might receive messages with "contact form" in the subject from my "info@[mywebsite]", and I want to hear a specific alert for this. Another address receives two forms of communication from a specific email address (the payment gateway). One is the daily settlement report. The other is whenever a transaction fails. I want to play different alerts according to the text in the email -- ie, does it contain "settlement report" or does it contain "transaction failed"-- and play different alerts depending on the situation. I also have a few customers who are volunteering to be "testers" who send feedback and others who are special cases for whom I often need to review their orders before they get filled by some other people. I need to intercept these.. if only I could play an alert according to the text "order #" for example, or a regular expression in general.
I'm really surprised that in 2014 I could not find a way to do this in IOS7 and I'm hoping that Apple will start adding feature conducive to business. I can't imagine holding out any longer when I upgrade in a few months. Apple if you're listening, what wins me over are features and the ability to customize. These are so easy to implement, why not just do it? I'm such a low-hanging-fruit easy sale if you would just copy what's been done already on BB and Android. Please support filtering according to regular expression filter syntaxThis is a user-to-user support forum and not the best way to give a request or suggestion to Apple. You may want to make the suggestion at: https://www.apple.com/feedback/iphone.html
-
Customizable Email Filters w/ Alerts - App Failure!
Does this make the iPhone almost useless to anyone else? I would expect after the amount of time that the iPhone has been out that the developers would have added some sort of feature to create custom alerts for emails using filters.
I work for a large corporation and use my phone as a pager to wake me up when I get certain emails or pages.
I recently purchased an iPhone to use as my work phone only to find that there is no way to do this other than an app like MailTones which requires that you forward your emails through their server which I do not feel comfortable doing. This should be a built in feature!
Does anyone know if this is going to be added, or if it is even being considered for the future?You are correct that I should have checked into it a bit more and there are various ways around it that I can use such as setting alerts to all of the messages in my inbox to wake me up but that will wake me more than I would like.
There are others in our company using their iPhone as their work phone/pager and it works for them but I guess our group is more attentive to some of the alerts we get. If I wait long enough, these alerts can turn into a real problem and I will get a call from our Network Operations Center. I would simply like to avoid the NOC ever knowing that there is an issue. We like to fix things before they impact users.
I for for a major news company. We support the application layer of functionality that is behind everything that gets videos, stories, content, etc... to the public and onto the web or TV.
We have automated monitoring systems that send us alerts which we filter prior to getting them on the iPhone. So even being able to make one folder alert differently from another would be sufficient.
I'm sad to hear that we do not have any official apple support on this forum. I was in hopes of hearing from a developer or someone of the like...
Don't get me wrong, I love the iPhone. I have a Pre as my personal phone and I love them both but it just seems that they would have added this feature by now. Also being able to mark all messages as read seems like a elementary feature that should be included. -
Alerts are LOST somewhere in Action Override Stage...
I have very, very strange statistics on my sensor. I cleared it few minutes ago and now it is as follows:
SigEvent Preliminary Stage Statistics
Number of Alerts received = 60
Number of Alerts Consumed by AlertInterval = 0
Number of Alerts Consumed by Event Count = 0
Number of FireOnce First Alerts = 0
Number of FireOnce Intermediate Alerts = 0
Number of Summary First Alerts = 8
Number of Summary Intermediate Alerts = 43
Number of Regular Summary Final Alerts = 8
Number of Global Summary Final Alerts = 0
Number of Active SigEventDataNodes = 10
Number of Alerts Output for further processing = 60
SigEvent Action Override Stage Statistics
Number of Alerts received to Action Override Processor = 60
Number of Alerts where an override was applied = 0
Actions Added
deny-attacker-inline = 0
deny-attacker-victim-pair-inline = 0
deny-attacker-service-pair-inline = 0
deny-connection-inline = 0
deny-packet-inline = 0
modify-packet-inline = 0
log-attacker-packets = 0
log-pair-packets = 0
log-victim-packets = 0
produce-alert = 0
produce-verbose-alert = 0
request-block-connection = 0
request-block-host = 0
request-snmp-trap = 0
reset-tcp-connection = 0
request-rate-limit = 0
SigEvent Action Filter Stage Statistics
Number of Alerts received to Action Filter Processor = 0
Number of Alerts where an action was filtered = 0
Number of Filter Line matches = 0
Number of Filter Line matches causing decreased DenyPercentage = 0
Actions Filtered
deny-attacker-inline = 0
deny-attacker-victim-pair-inline = 0
deny-attacker-service-pair-inline = 0
deny-connection-inline = 0
deny-packet-inline = 0
modify-packet-inline = 0
log-attacker-packets = 0
log-pair-packets = 0
log-victim-packets = 0
produce-alert = 0
produce-verbose-alert = 0
request-block-connection = 0
request-block-host = 0
request-snmp-trap = 0
reset-tcp-connection = 0
request-rate-limit = 0
SigEvent Action Handling Stage Statistics.
Number of Alerts received to Action Handling Processor = 1
Number of Alerts where produceAlert was forced = 0
Number of Alerts where produceAlert was off = 0
Actions Performed
deny-attacker-inline = 0
deny-attacker-victim-pair-inline = 0
deny-attacker-service-pair-inline = 0
deny-connection-inline = 0
deny-packet-inline = 0
modify-packet-inline = 0
log-attacker-packets = 0
log-pair-packets = 0
log-victim-packets = 0
produce-alert = 1
produce-verbose-alert = 0
request-block-connection = 0
request-block-host = 0
request-snmp-trap = 0
reset-tcp-connection = 0
request-rate-limit = 0
Per-Signature SigEvent count since reset
Sig 60000.0 = 1
Yes, single signature fired, but the number of "Preliminary Stage Alerts" was 60 !? What happened with other 59 alerts ???Only when the alert has at least one action will it be passed to the event action handler.
So the other 59 alerts did not have any event action. Either no action was added directly from the signature definition, or the alerting type actions were removed because of summarization, or the actions were removed by filters.
There are several signatures that are intentionally created without actions. These signatures are what we call meta component signatures. On their own they don't mean much and so we remove all actions and they do not generate alerts into the eventstore. They trigger internally in sensorApp but do not get written to the eventstore. These alerts are internally monitored by Meta signatures. When multiple component signatures are triggered, then a Meta signature may trigger and it is the Meta signature that would have a produce-alert event action and be written to the eventStore.
With summarization the signature has a produce-alert action, but the summarizer routines see that the signature is being triggered multiple times with same addresses. The summarizer will allow through an alert on the first triggering. Later triggerings with the same address set will cause the summarizer to automatically remove the produce-alert action (and other alert causing actions). So the summarized alerts will not get written to the eventStore.
NOTE: In your output this happened for at least 43 of these alerts.
Filters may also be matching the alerts, and the filters may be removing the event actions.
So if the event actions have all be removed (or none were ever added), then the alert will not be passed to the event action handler.
In your output only 1 of the 60 alerts wound up with any actions needing to be executed. -
Issue with applying Event Action filters
Dear friends,
A general question on Event Action filters. There is a signature with sig ID 6257.
The following is the event action filter configuration:
service event-action-rules rules0
filters edit DHCP
signature-id-range 6257
subsignature-id-range 0
attacker-address-range 172.20.20.10,172.20.20.11
actions-to-remove produce-alert
filter-item-status Enabled
stop-on-match True
os-relevance not-relevant
exit
Even though a valid DHCP offer is being given by the DHCP server, this alert is getting fired.
We have even excluded the IP's of the DHCP Servers - 172.20.20.10 and 172.20.20.11 from the Attacker Address range parameter in the signature but still this alert gets fired.
evIdsAlert: eventId=1204853641442197329 vendor=Cisco severity=low
originator:
hostId: IDSM2Core1
appName: sensorApp
appInstanceId: 592
time: April 7, 2008 5:46:48 AM UTC offset=180 timeZone=1
signature: description=DHCP Client DoS id=6257 version=S316
subsigId: 0
sigDetails: Server Offered a Malicious IP Address
marsCategory: DoS/Host
interfaceGroup: vs0
vlan: 200
participants:
attacker:
addr: 172.20.20.10 locality=OUT
port: 0
target:
addr: 10.1.1.78 locality=OUT
port: 0
os: idSource=unknown type=unknown relevance=unknown
summary: 4 final=true initialAlert=1204853641442197267 summaryType=Regular
alertDetails: Regular Summary: 4 events this interval ;
riskRatingValue: 25 targetValueRating=medium
threatRatingValue: 25
interface: ge0_7
protocol: udp
Looking forward to your kind help and advise on this.
Thanks a lot
GautamSome things to check:
1) Is the filter in the active list? Filters can be enabled or disabled, but they can also be active ro inactive. You've only show a part of your configuration so I can't tell if the filter is part of the active list.
2) Are there actions other than produce-alert for the signature? Or is an event action override adding other actions?
Produce-alert is not the only action that can cause an alert to be generated. The produce-verbose-alert, request-snmp-trap, log-attacker-packets, log-victim-packet, and log-pair-packets will also cause alerts to be generated. Modify the filter to also remove these actions.
3) The alert you've shown is a Summary Alert. There may be an issue with Summarization and the Filters. Try modifying the signature to set it to FireAll with no summarization.
4) If you have multiple filters then check the order of the filters. If the event is matching an earlier filter where the stop-on-match is set to True, then it will not check the event against this filter. Either move this filter up higher in the filter list, or change earlier filters to be "stop-on-match false".
5) Also check to see if you are running the latest 5.1(7) or 6.0(4) Service pack. If running earlier 5.1 or 6.0 versions you might be hitting a bug that could have already been fixed.
If none of the above help, then contact the TAC. It could be that you may have foung a bug that the sensor development team is unaware of.
To help in identifying the problem take a packet capture of the packets from 172.20.20.10 for several minutes around the time when the sensor is generating these alerts.
This way the team can both check if the signature is firing correctly, and if the filters are working correctly for that signature. -
IDS 5.x sig tuning event filters still showing in MARS
I have configured an event action filter on the IDS for a signature, and for my actions to subtract I have selected Log Attacker, Victim, and both, produce alert, and produce verbose alert. I am still getting alerts from my MARS box about this signaure from the IDS box. Any ideas as to why this is not getting filtered by my IDS?
Can you paste a copy of the alert as seen from "show events" on the sensor CLI?
Feel free to replace the IP addresses or other confidential information with XXX when posting the response.
My best guesses are:
1) An SNMP trap is being generated which forces an alert to be produced. If so then you also need to filter the requestSnmpTrap event action.
2) Your filter is not matching on the alert.
a) This can happen when a prior filter is matching the alert and the prior filter has "stop-on-match" set to "True". When set to "True" the "stop-on-match" parameter woudl prevent any later filters from being checked for that alert.
b) This can also happen when the fields in the alert are not an exact match to those in the filter. This is often the case when the alert is for a sweep of multiple addresses. Or if the alert is a Summary alert with the source or victim addresses and/or ports are not in the alert (or marked as 0.0.0.0). -
IPS 5.0 event filtering
I have an IPS v5 running on my network and now on the process of tuning signatures.
Event filter is one of the option that I am working now but it seems that it does not work.
I want some of the signatures on my sensor to only trigger on my specified range of ip's (network servers). That is it should work in a manner that signature will only fire on any attacker address and on a range of specified destination ip range.
Anyone have an idea how to do it?
ex.
Signature 3030
Attacker address = any
destination address = 10.10.10.1 - 10.10.10.10
*condition - trigger only when 10.10.10.1-10 is attack. I should only see this ip's from the show events or event viewer and no other ip outside this range.If this was not a Host Sweep signature then the answer would be to generate 2 filters.
The first filter would match the 3030 SigId, and the 10.10.10.1-10.10.10.10 Destination Address. The key to making this work is to leave the "actions-to-remove" blank, and to set "stop-on-match" to "true".
This way when it is matched the sensor will stop checking additional filters and go ahead and execute any actions on the signature (like the produce-alert action).
The second filter would then be created to match everything else for that signature and remove all actions. Match the Sigid 3030, and leave the default to match all destination addresses. This time select every action in the "actions-to-remove" field, and once again select true for the "stop-on-match" field. This way all other triggerings of the signature would be fitlered out by this second filter.
NOTE: Filters are checked in order, so the 2 filters must be in the exact order above to work properly.
HOWEVER, the 3030 is a sweep signature.
Sweep signatures have an interaction with filters that most users are not expecting.
There are multiple destination addresses being targeted in a Host Sweep. The expectation of most users is that the filter would be able to filter on each target address indpendantly.
Unfortunately this is not the case. In fact it is Only the last destination address targeted that will be checked against the filters. What makes it often more confusing is that this last address is not seen in the alert itself. Instead to see this last address being checked against the filter the signature shoudl have the "produce-verbose-alert" action selected so that the trigger packet is attached to the alert. Ethereal would then need to be used to view the trigger packet and determine the final destination address triggering the alert, It is that address that would be used to check against the filters.
So I generally do not recommend filters to do what you are asking. If you try to generate a filter to only allow 3030 to fire when it is targeting the 10.10.10.1-10.10.10.10 address range you won't get what you want.
Let's say for example that 3030 fires when 10 SYN packets are seen. If the first 9 SYN packets go to the 172.1.1.0 network, and the 10th SYN packet goes to the 10.10.10.2 address, then the signature will still create an alert. You will only see the first 9 addresses on the 172.1.1.0 network in the alert itself, but you will see the 10.10.10.2 address in the trigger packet and it is that trigger address that forced the alert to be created.
Or the opposite may happen where the first 9 SYN packets are for addresses 10.10.10.1-10.10.10.9, the 10th packet is, however, to 172.1.1.1. The signature will not fire because you will have filtered out the 172.1.1.1 address as the destination address. Even if the 11th packet goes then to 10.10.10.10 it still won't create an alert because of the counting mechanism used in the sensor.
This issue is being addressed in the upcoming IPS version 5.1 release.
It is not a change to the Filter functionality in event-action-rules. Instead there is a new parameter as part of the signature definition itself.
Beginning with version 5.1 you can configure the signature itself to tell the sensor to only look for packets destined to 10.10.10.1-10.10.10.10 when doing analysis for the signature. This way the signature itself ignores packets destinated to other IPs and the signature will only ever fire fire for the 10.10.10.1-10.10.10.10 destination addresses.
In affect we added address filtering capability directly into the signature definition to control what the signature even looks at rather than trying to filter it after having been triggered. -
Filtered interface in DFM 3.2
Hi
I need filtered those Alerts:
ALERT ID = 00000S2
TIME = Fri 16-Sep-2011 05:59:08 MSD
STATUS = Active
SEVERITY = Critical
MANAGED OBJECT = 10.65.240.5
MANAGED OBJECT TYPE = Routers
EVENT DESCRIPTION = IF-10.65.240.5/7 [Fa0/3/4] [To Internal voice and Data]:OperationallyDown; IF-10.65.240.5/9 [Fa0/3/6] [To Internal voice and Data]:OperationallyDown; IF-10.65.240.5/4 [Fa0/3/1] [To Internal voice and Data]:OperationallyDown; IF-10.65.240.5/6 [Fa0/3/3]
Key words for filtering are "Internal" or "Fa0/3/1".
I use Customizable Interface Group with rules: Interfaces.Description contains "FastEthernet0/3/1"
But nothing interface found in Customizable Group.
But I see nedded interface in "DFM.System Defined Groups.Interface Groups.10MB-100MB Ethernet".
Please, get me help.
AndreyI recommend you use the bulk unmanage scripts for this
http://www.cisco.com/en/US/docs/net_mgmt/ciscoworks_device_fault_manager/3.2/user/guide/useAAD.html#wp1433848 -
Hey, for a while I'd see packets from an IP and assume it was http. But I found some IP's that give us traffic but they are not making any logs in my access.log (so probably not http). What way can I filter my logs or using CLI diagnoze what ports this IP is using? Or trying to us?
Tia
ChuckChuck -
Were you getting hits on an http signature? If you want more information about the traffic round a signature hit to perform a good analysis, enable logging of victim and attacker traffic. If you just want to see what port is involved in the packet that caused thsi signature to fire, enable "produce verbose alert", thiswill give you a partial packet capture in the alert message.
You can watch your traffic via the CLI too, check out the "packet display" and "iplog" commands.
http://www.cisco.com/en/US/docs/security/ips/6.0/configuration/guide/cli/cliIPLog.html -
Tuning SIG 5583 - SMB Remote SAM Service Access Attempt
We are running Active Directory and this sig is firing 30000+ times a day. I do not want to disable the sig as we would likt to watch for external IP's as the source or destination.
Trouble is I cannot get an event filter to work for this beast and I cannot filter it at the sig level since there is no source/destination IP settings in the sig itself (SMB Engine).
Here is the event filter definition:-
NAME: InsideSAM_SMB
signature-id-range: 5583,5579 default: 900-65535
subsignature-id-range: 0-255 default: 0-255
attacker-address-range: $Inside default: 0.0.0.0-255.255.255.255
victim-address-range: $Inside default: 0.0.0.0-255.255.255.255
attacker-port-range: 0-65535 <defaulted>
victim-port-range: 139,445 default: 0-65535
risk-rating-range: 1-100 default: 0-100
actions-to-remove: produce-alert|produce-verbose-alert default:
deny-attacker-percentage: 100 <defaulted>
filter-item-status: Enabled default: Enabled
stop-on-match: True default: False
user-comment: <defaulted>
os-relevance: not-relevant default: relevant|not-relevant|unknown
The $Inside variable is 10.0.0.0-10.255.255.255
basically our entire internal network.
The events I am being flooded with are single events and not summarized.
Here is an example of an alert:-
evIdsAlert: eventId=1192231627181681635 vendor=Cisco severity=informational
originator:
hostId: IDS
appName: sensorApp
appInstanceId: 571
time: 11 February 2008 15:59:52 UTC offset=0 timeZone=GMT00:00
signature: description=SMB Remote SAM Service Access Attempt id=5583 version=S262
subsigId: 0
sigDetails: SMB Remote SAM Service Access Attempt
marsCategory: Info/Misc/NetBios
interfaceGroup: int8
vlan: 36
participants:
attacker:
addr: 10.36.3.52 locality=Inside
port: 2956
target:
addr: 10.11.1.63 locality=Inside
port: 445
os: idSource=learned type=windows-nt-2k-xp relevance=relevant
riskRatingValue: 25 targetValueRating=medium
attackRelevanceRating=relevant
threatRatingValue: 25
interface: ge0_8
protocol: tcp
As you can see BOTH the source and destination are within the ranges specified in the filter but the event is still firing.You mean replace the $Inside with a specific range like 10.0.0.0-10.255.255.255.
Hmm. Nope. I have tried that and I have even tried specific IP addresses for the source/destination but still get alerts with exactly those two addresses getting through.
Filtering is working though as I have a filter active also for the 'DHCP offer' sig in that I have filtered out all our 'expected' DHCP sources, and SMTP filters for 'expected' SMTP sources.
Why can I not filter out SMB sources/ destinations such as Windows Servers and/or M$ Domain Controllers.
Come on Cisco, event filtering was so easy in IDS4, why complicate it so much in IPS6. -
Reconfiguring the engine | CPU @ 100% | AIP-5
It seems that almost everytime I log into the IPS Manager for the ASA-SSC-AIP-5 that it is reconfiguring the engine and the CPU is at 100%. I am on sig version 625.0 and I knwo the current should be like S632. Basically, this thing always seems to be in bypass mode so what is the point? It's frustrating.
Has anyone else experienced this? Is there somethign that should be done for performance, or do I need to look at my configurationg for something?
Maybe I am just checking for updates too often?
I'm looking for any suggestions or best practices for using these.
Thanks.Quite long, but here goes:
IPS_Sensor# show tech
System Status Report
This Report was generated on Thu Mar 15 09:54:38 2012.
Output from show version
Application Partition:
Cisco Intrusion Prevention System, Version 6.2(4)E4
Host:
Realm Keys key1.0
Signature Definition:
Signature Update S632.0 2012-03-13
OS Version: 2.4.30-IDS-smp-bigphys
Platform: ASA-SSC-AIP-5
Serial Number: JAF1442BDBN
Licensed, expires: 07-Jan-2013 UTC
Sensor up-time is 36 days.
Using 350920704 out of 489398272 bytes of available memory (71% usage)
application-data is using 42.4M out of 166.8M bytes of available disk space (27% usage)
boot is using 40.8M out of 68.6M bytes of available disk space (63% usage)
MainApp E-ECLIPSE_624_2011_JUN_23_00_20_6_2_3_17 (Ipsbuild) 2011-06-23T00:24:58-0500 Running
AnalysisEngine E-ECLIPSE_624_2011_JUN_23_00_20_6_2_3_17 (Ipsbuild) 2011-06-23T00:24:58-0500 Running
CLI E-ECLIPSE_624_2011_JUN_23_00_20_6_2_3_17 (Ipsbuild) 2011-06-23T00:24:58-0500
Upgrade History:
* IPS-sig-S631-req-E4 18:03:37 UTC Tue Mar 13 2012
IPS-sig-S632-req-E4.pkg 18:03:38 UTC Wed Mar 14 2012
Recovery Partition Version 1.1 - 6.2(4)E4
Host Certificate Valid from: 14-Jan-2011 to 14-Jan-2013
Output from show interfaces
Interface Statistics
Total Packets Received = 0
Total Bytes Received = 0
Missed Packet Percentage = 0
Current Bypass Mode = Auto_off
MAC statistics from interface GigabitEthernet0/0
Interface function = Sensing interface
Description =
Media Type = backplane
Default Vlan = 0
Inline Mode = Unpaired
Pair Status = N/A
Hardware Bypass Capable = No
Hardware Bypass Paired = N/A
Link Status = Up
Admin Enabled Status = Enabled
Link Speed = Auto_1000
Link Duplex = Auto_Full
Missed Packet Percentage = 0
Total Packets Received = 163575210
Total Bytes Received = 100243725586
Total Multicast Packets Received = 0
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 0
Total Receive Errors = 0
Total Receive FIFO Overruns = 0
Total Packets Transmitted = 163575006
Total Bytes Transmitted = 100243542691
Total Multicast Packets Transmitted = 0
Total Broadcast Packets Transmitted = 0
Total Jumbo Packets Transmitted = 0
Total Undersize Packets Transmitted = 0
Total Transmit Errors = 0
Total Transmit FIFO Overruns = 0
MAC statistics from interface Management0/0
Interface function = Command-control interface
Description =
Media Type = TX
Default Vlan = 0
Link Status = Up
Link Speed = Auto_1000
Link Duplex = Auto_Full
Total Packets Received = 8837748
Total Bytes Received = 1105352880
Total Multicast Packets Received = 0
Total Receive Errors = 0
Total Receive FIFO Overruns = 0
Total Packets Transmitted = 9435508
Total Bytes Transmitted = 1410112517
Total Transmit Errors = 0
Total Transmit FIFO Overruns = 0
Output from show statistics authentication
General
totalAuthenticationAttempts = 29
failedAuthenticationAttempts = 2
Output from show statistics analysis-engine
Analysis Engine Statistics
Number of seconds since service started = 3195884
The rate of TCP connections tracked per second = 0
The rate of packets per second = 46
The rate of bytes per second = 1071
Receiver Statistics
Total number of packets processed since reset = 150102196
Total number of IP packets processed since reset = 150102196
Transmitter Statistics
Total number of packets transmitted = 151226612
Total number of packets denied = 70
Total number of packets reset = 80
Fragment Reassembly Unit Statistics
Number of fragments currently in FRU = 0
Number of datagrams currently in FRU = 0
TCP Stream Reassembly Unit Statistics
TCP streams currently in the embryonic state = 0
TCP streams currently in the established state = 0
TCP streams currently in the closing state = 0
TCP streams currently in the system = 0
TCP Packets currently queued for reassembly = 0
The Signature Database Statistics.
Total nodes active = 1634
TCP nodes keyed on both IP addresses and both ports = 357
UDP nodes keyed on both IP addresses and both ports = 0
IP nodes keyed on both IP addresses = 134
Statistics for Signature Events
Number of SigEvents since reset = 473321
Statistics for Actions executed on a SigEvent
Number of Alerts written to the IdsEventStore = 673
Inspection Stats
Inspector active call create delete createPct callPct
AtomicAdvanced 1 150092178 1 0 0 14
Fixed 40 8387783 5498552 5498512 3 5
MSRPC_TCP 15 5787118 1093973 1093958 0 3
MSRPC_UDP 0 2156196 1071260 1071260 0 1
MultiString 410 24911947 3282530 3282120 2 16
MultiStringSP 0 2031 822 822 0 0
ServiceDnsUdp 1 2156196 1 0 0 1
ServiceDnsTcp 0 290 146 146 0 0
ServiceFtp 0 1513 88 88 0 0
ServiceGeneric 3 152319935 2228468 2228465 1 15
ServiceHttp 254 2488814 1199894 1199640 0 1
ServiceMsSql 0 7497 4 4 0 0
ServiceNtp 0 4312392 2142520 2142520 1 2
ServiceP2PUDP 0 86926 80336 80336 0 0
ServiceP2PTCP 2 4897360 2228465 2228463 1 3
ServiceRpcUDP 1 2156196 1 0 0 1
ServiceRpcTCP 356 18860022 2224579 2224223 1 12
ServiceSMBAdvanced 2 2189269 10389 10387 0 1
ServiceSnmp 1 2156196 1 0 0 1
ServiceTNS 0 2211389 2203383 2203383 1 1
String 502 37492887 4282235 4281733 2 24
SweepICMP 11 1113830 75054 75043 0 0
SweepTCP 270 293642888 874680 874410 0 23
SweepOtherTcp 134 146821444 449914 449780 0 11
Output from show statistics denied-attackers
Statistics for Virtual Sensor vs0
Denied Attackers and hit count for each.
Denied Attackers with percent denied and hit count for each.
Output from show statistics event-server
Statistics not available: event-server is disabled.
Output from show statistics event-store
Event store statistics
General information about the event store
The current number of open subscriptions = 5
The number of events lost by subscriptions and queries = 0
The number of filtered events not written to the event store = 323047
The number of queries issued = 1
The number of times the event store circular buffer has wrapped = 0
Number of events of each type currently stored
Status events = 15070
Shun request events = 0
Error events, warning = 72
Error events, error = 571
Error events, fatal = 2
Alert events, informational = 346
Alert events, low = 462
Alert events, medium = 7
Alert events, high = 21
Alert events, threat rating 0-20 = 0
Alert events, threat rating 21-40 = 346
Alert events, threat rating 41-60 = 479
Alert events, threat rating 61-80 = 7
Alert events, threat rating 81-100 = 4
Cumulative number of each type of event
Status events = 11532
Shun request events = 0
Error events, warning = 63
Error events, error = 437
Error events, fatal = 1
Alert events, informational = 287
Alert events, low = 360
Alert events, medium = 5
Alert events, high = 21
Alert events, threat rating 0-20 = 0
Alert events, threat rating 21-40 = 287
Alert events, threat rating 41-60 = 377
Alert events, threat rating 61-80 = 5
Alert events, threat rating 81-100 = 4
Output from show statistics external-product-interface
No interfaces configured
Output from show statistics host
General Statistics
Last Change To Host Config (UTC) = 07-Feb-2012 15:03:14
Command Control Port Device = Management0/0
Network Statistics
= ma0_0 Link encap:Ethernet HWaddr 00:4D:79:4D:41:43
= inet addr:10.1.2.2 Bcast:10.1.2.7 Mask:255.255.255.248
= UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
= RX packets:8837838 errors:0 dropped:0 overruns:0 frame:0
= TX packets:9435686 errors:0 dropped:0 overruns:0 carrier:0
= collisions:0 txqueuelen:1000
= RX bytes:1105359006 (1.0 GiB) TX bytes:1410145705 (1.3 GiB)
NTP Statistics
= remote refid st t when poll reach delay offset jitter
= *10.x.x.5 130.126.24.53 3 u 299 1024 377 3.915 11.079 18.216
= LOCAL(0) 73.78.73.84 5 l 3 64 377 0.000 0.000 0.002
= ind assID status conf reach auth condition last_event cnt
= 1 28364 b6e4 yes yes none sys.peer reachable 14
= 2 28365 90e4 yes yes none reject reachable 14
status = Synchronized
Memory Usage
usedBytes = 350998528
freeBytes = 138399744
totalBytes = 489398272
Summertime Statistics
start = 03:00:00 UTC Sun Mar 11 2012
end = 01:00:00 GMT-06:00 Sun Nov 04 2012
CPU Statistics
Usage over last 5 seconds = 27
Usage over last minute = 21
Usage over last 5 minutes = 27
Memory Statistics
Memory usage (bytes) = 350998528
Memory free (bytes) = 138399744
Auto Update Statistics
lastDirectoryReadAttempt = 09:03:29 UTC Thu Mar 15 2012
= Read directory: https://198.133.219.25//cgi-bin/front.x/ida/locator/locator.pl
= Success: No installable auto update package found on server
lastDownloadAttempt = 13:03:27 UTC Wed Mar 14 2012
lastInstallAttempt = 13:13:49 UTC Wed Mar 14 2012
nextAttempt = 11:03:17 UTC Thu Mar 15 2012
Auxilliary Processors Installed
Output from show statistics logger
The number of Log interprocessor FIFO overruns = 0
The number of syslog messages received = 95
The number of events written to the event store by severity
Fatal Severity = 1
Error Severity = 437
Warning Severity = 158
TOTAL = 596
The number of log messages written to the message log by severity
Fatal Severity = 1
Error Severity = 437
Warning Severity = 63
Timing Severity = 0
Debug Severity = 0
Unknown Severity = 0
Blank Messages = 64132
TOTAL = 64633
Output from show statistics network-access
Current Configuration
LogAllBlockEventsAndSensors = true
EnableNvramWrite = false
EnableAclLogging = false
AllowSensorBlock = false
BlockMaxEntries = 250
MaxDeviceInterfaces = 250
NeverBlock
IP = 10.x.x.8
IP = 10.x.x.69
State
BlockEnable = true
Output from show statistics notification
General
Number of SNMP set requests = 0
Number of SNMP get requests = 0
Number of error traps sent = 497
Number of alert traps sent = 19
Output from show statistics os-identification
Statistics for Virtual Sensor vs0
OS Identification
Configured
Imported
Learned
IP = 10.x.x.69 (windows-nt-2k-xp)
IP = 10.x.x.117 (windows-nt-2k-xp)
IP = 10.x.x.229 (windows-nt-2k-xp)
IP = 10.x.x.230 (windows-nt-2k-xp)
IP = 10.x.x.231 (windows-nt-2k-xp)
IP = 10.x.x.232 (windows-nt-2k-xp)
IP = 10.x.x.233 (windows-nt-2k-xp)
IP = 10.x.x.234 (windows-nt-2k-xp)
IP = 10.x.x.235 (windows-nt-2k-xp)
IP = 10.x.x.236 (windows-nt-2k-xp)
IP = 10.x.x.238 (windows-nt-2k-xp)
IP = 10.x.x.240 (windows-nt-2k-xp)
IP = 12.120.129.206 (linux)
IP = 50.22.26.153 (linux)
IP = 50.22.26.155 (linux)
IP = 50.23.216.69 (linux)
IP = 50.57.22.5 (linux)
IP = 64.70.9.195 (linux)
IP = 64.208.138.145 (linux)
IP = 65.42.26.130 (bsd)
IP = 66.117.14.61 (linux)
IP = 66.147.244.114 (linux)
IP = 67.192.92.227 (linux)
IP = 68.142.213.143 (linux)
IP = 69.12.162.28 (linux)
IP = 69.64.250.20 (linux)
IP = 69.172.216.56 (linux)
IP = 70.98.35.165 (linux)
IP = 71.13.87.218 (linux)
IP = 72.22.182.37 (windows-nt-2k-xp)
IP = 72.34.62.119 (linux)
IP = 72.44.91.208 (linux)
IP = 72.251.194.171 (linux)
IP = 74.125.214.21 (linux)
IP = 74.125.214.114 (linux)
IP = 74.201.0.130 (linux)
IP = 75.126.109.204 (linux)
IP = 98.129.229.53 (linux)
IP = 98.138.47.199 (linux)
IP = 98.139.225.43 (linux)
IP = 107.20.134.231 (linux)
IP = 107.21.238.22 (linux)
IP = 107.22.217.227 (linux)
IP = 107.22.230.44 (linux)
IP = 129.143.116.113 (linux)
IP = 132.237.253.49 (linux)
IP = 143.227.55.17 (linux)
IP = 162.128.70.19 (linux)
IP = 170.218.216.73 (linux)
IP = 173.45.246.12 (linux)
IP = 173.201.185.43 (linux)
IP = 174.46.100.100 (hp-ux)
IP = 174.129.1.166 (linux)
IP = 184.72.226.104 (linux)
IP = 192.168.168.135 (windows-nt-2k-xp)
IP = 195.24.232.205 (linux)
IP = 199.59.149.198 (linux)
IP = 204.11.208.168 (linux)
IP = 204.145.83.230 (linux)
IP = 204.145.176.90 (linux)
IP = 205.251.253.141 (linux)
IP = 208.28.202.43 (linux)
IP = 208.65.147.170 (linux)
IP = 209.59.132.242 (linux)
IP = 209.85.239.19 (linux)
IP = 209.126.151.246 (linux)
IP = 209.126.179.3 (linux)
IP = 216.8.161.98 (bsd)
IP = 216.75.16.204 (linux)
IP = 216.129.117.152 (linux)
IP = 216.138.155.154 (linux)
IP = 216.231.189.130 (linux)
Output from show statistics sdee-server
General
Open Subscriptions = 1
Blocked Subscriptions = 1
Maximum Available Subscriptions = 5
Maximum Events Per Retrieval = 500
Subscriptions
sub-9-19a8e927
State = Read Pending
Last Read Time = 14:54:38 UTC Thu Mar 15 2012
Last Read Time (nanoseconds) = 1331823278914523000
Output from show statistics virtual-sensor
Virtual Sensor Statistics
Statistics for Virtual Sensor vs0
Name of current Signature-Defintion instance = sig0
Name of current Event-Action-Rules instance = rules0
List of interfaces monitored by this virtual sensor = GigabitEthernet0/0 subinterface 0
General Statistics for this Virtual Sensor
Number of seconds since a reset of the statistics = 3195885
MemoryAlloPercent = 72
MemoryUsedPercent = 67
MemoryMaxCapacity = 300000
MemoryMaxHighUsed = 319840
MemoryCurrentAllo = 218439
MemoryCurrentUsed = 203388
Processing Load Percentage = 5
Total packets processed since reset = 151232133
Total IP packets processed since reset = 151232133
Total IPv4 packets processed since reset = 151232133
Total IPv6 packets processed since reset = 0
Total IPv6 AH packets processed since reset = 0
Total IPv6 ESP packets processed since reset = 0
Total IPv6 Fragment packets processed since reset = 0
Total IPv6 Routing Header packets processed since reset = 0
Total IPv6 ICMP packets processed since reset = 0
Total packets that were not IP processed since reset = 0
Total TCP packets processed since reset = 147952089
Total UDP packets processed since reset = 2156214
Total ICMP packets processed since reset = 1123830
Total packets that were not TCP, UDP, or ICMP processed since reset = 0
Total ARP packets processed since reset = 0
Total ISL encapsulated packets processed since reset = 0
Total 802.1q encapsulated packets processed since reset = 5009
Total GRE Packets processed since reset = 0
Total GRE Fragment Packets processed since reset = 0
Total GRE Packets skipped since reset = 0
Total packets with bad IP checksums processed since reset = 0
Total packets with bad layer 4 checksums processed since reset = 0
Total number of bytes processed since reset = 90811729021
The rate of packets per second since reset = 47
The rate of bytes per second since reset = 28415
The average bytes per packet since reset = 600
Denied Address Information
Number of Active Denied Attackers = 0
Number of Denied Attackers Inserted = 0
Number of Denied Attacker Victim Pairs Inserted = 0
Number of Denied Attacker Service Pairs Inserted = 0
Number of Denied Attackers Total Hits = 0
Number of times max-denied-attackers limited creation of new entry = 0
Number of exec Clear commands during uptime = 0
Denied Attackers and hit count for each.
Denied Attackers with percent denied and hit count for each.
The Signature Database Statistics.
The Number of each type of node active in the system
Total nodes active = 1634
TCP nodes keyed on both IP addresses and both ports = 357
UDP nodes keyed on both IP addresses and both ports = 0
IP nodes keyed on both IP addresses = 134
The number of each type of node inserted since reset
Total nodes inserted = 10505094
TCP nodes keyed on both IP addresses and both ports = 2317586
UDP nodes keyed on both IP addresses and both ports = 988001
IP nodes keyed on both IP addresses = 685950
The rate of nodes per second for each time since reset
Nodes per second = 3
TCP nodes keyed on both IP addresses and both ports per second = 0
UDP nodes keyed on both IP addresses and both ports per second = 0
IP nodes keyed on both IP addresses per second = 0
The number of root nodes forced to expire because of memory constraints
TCP nodes keyed on both IP addresses and both ports = 26357
Packets dropped because they would exceed Database insertion rate limits = 0
Fragment Reassembly Unit Statistics for this Virtual Sensor
Number of fragments currently in FRU = 0
Number of datagrams currently in FRU = 0
Number of fragments received since reset = 10018
Number of fragments forwarded since reset = 10018
Number of fragments dropped since last reset = 0
Number of fragments modified since last reset = 0
Number of complete datagrams reassembled since last reset = 5009
Fragments hitting too many fragments condition since last reset = 0
Number of overlapping fragments since last reset = 0
Number of Datagrams too big since last reset = 0
Number of overwriting fragments since last reset = 0
Number of Inital fragment missing since last reset = 0
Fragments hitting the max partial dgrams limit since last reset = 0
Fragments too small since last reset = 0
Too many fragments per dgram limit since last reset = 0
Number of datagram reassembly timeout since last reset = 0
Too many fragments claiming to be the last since last reset = 0
Fragments with bad fragment flags since last reset = 0
TCP Normalizer stage statistics
Packets Input = 146821876
Packets Modified = 0
Dropped packets from queue = 0
Dropped packets due to deny-connection = 0
Duplicate Packets = 0
Current Streams = 357
Current Streams Closed = 0
Current Streams Closing = 0
Current Streams Embryonic = 0
Current Streams Established = 0
Current Streams Denied = 0
Total SendAck Limited Packets = 0
Total SendAck Limited Streams = 0
Total SendAck Packets Sent = 0
Statistics for the TCP Stream Reassembly Unit
Current Statistics for the TCP Stream Reassembly Unit
TCP streams currently in the embryonic state = 0
TCP streams currently in the established state = 0
TCP streams currently in the closing state = 0
TCP streams currently in the system = 0
TCP Packets currently queued for reassembly = 0
Cumulative Statistics for the TCP Stream Reassembly Unit since reset
TCP streams that have been tracked since last reset = 0
TCP streams that had a gap in the sequence jumped = 0
TCP streams that was abandoned due to a gap in the sequence = 0
TCP packets that arrived out of sequence order for their stream = 0
TCP packets that arrived out of state order for their stream = 0
The rate of TCP connections tracked per second since reset = 0
SigEvent Preliminary Stage Statistics
Number of Alerts received = 473321
Number of Alerts Consumed by AlertInterval = 55
Number of Alerts Consumed by Event Count = 30
Number of FireOnce First Alerts = 158
Number of FireOnce Intermediate Alerts = 255
Number of Summary First Alerts = 78928
Number of Summary Intermediate Alerts = 372829
Number of Regular Summary Final Alerts = 20879
Number of Global Summary Final Alerts = 0
Number of Active SigEventDataNodes = 6
Number of Alerts Output for further processing = 473236
Per-Signature SigEvent count since reset
Sig 3002.0 = 187
Sig 3653.0 = 28
Sig 5474.0 = 183
Sig 5575.0 = 423
Sig 5581.0 = 408
Sig 5591.0 = 6
Sig 5595.0 = 15
Sig 5606.0 = 21
Sig 5903.2 = 505
Sig 6061.0 = 5
Sig 6131.6 = 13
Sig 6187.0 = 6
Sig 6403.1 = 26
Sig 6409.1 = 22
Sig 6409.2 = 370
Sig 6984.2 = 92
Sig 7241.1 = 3
Sig 7264.1 = 13
Sig 11233.3 = 1
Sig 16297.0 = 21
Sig 19219.1 = 6
Sig 20059.1 = 7950
Sig 21539.1 = 7
Sig 21619.1 = 257
Sig 23782.2 = 461703
Sig 25022.1 = 26
Sig 27839.2 = 928
Sig 30260.1 = 9
Sig 30459.1 = 9
Sig 41846.1 = 78
SigEvent Action Override Stage Statistics
Number of Alerts received to Action Override Processor = 473236
Number of Alerts where an override was applied = 98
Actions Added
deny-attacker-inline = 0
deny-attacker-victim-pair-inline = 0
deny-attacker-service-pair-inline = 0
deny-connection-inline = 0
deny-packet-inline = 93
modify-packet-inline = 0
log-attacker-packets = 5
log-pair-packets = 5
log-victim-packets = 5
produce-alert = 0
produce-verbose-alert = 5
request-block-connection = 0
request-block-host = 0
request-snmp-trap = 0
reset-tcp-connection = 0
request-rate-limit = 0
stop-flow-inspection = 0
SigEvent Action Filter Stage Statistics
Number of Alerts received to Action Filter Processor = 0
Number of Alerts where an action was filtered = 15
Number of Filter Line matches = 15
Number of Filter Line matches causing decreased DenyPercentage = 0
Actions Filtered
deny-attacker-inline = 0
deny-attacker-victim-pair-inline = 0
deny-attacker-service-pair-inline = 0
deny-connection-inline = 0
deny-packet-inline = 0
modify-packet-inline = 0
log-attacker-packets = 0
log-pair-packets = 0
log-victim-packets = 0
produce-alert = 15
produce-verbose-alert = 0
request-block-connection = 0
request-block-host = 0
request-snmp-trap = 0
reset-tcp-connection = 0
request-rate-limit = 0
stop-flow-inspection = 0
Filter Hit Counts
3 = 15
SigEvent Action Handling Stage Statistics.
Number of Alerts received to Action Handling Processor = 1310
Number of Alerts where produceAlert was forced = 0
Number of Alerts where produceAlert was off = 15
Number of Alerts using Auto One Way Reset = 89
Actions Performed
deny-attacker-inline = 0
deny-attacker-victim-pair-inline = 0
deny-attacker-service-pair-inline = 0
deny-connection-inline = 89
deny-packet-inline = 89
modify-packet-inline = 0
log-attacker-packets = 5
log-pair-packets = 5
log-victim-packets = 5
produce-alert = 673
produce-verbose-alert = 5
request-block-connection = 0
request-block-host = 0
request-snmp-trap = 0
reset-tcp-connection = 0
request-rate-limit = 0
stop-flow-inspection = 0
Deny Actions Requested in Promiscuous Mode
deny-packet not performed = 0
deny-connection not performed = 0
deny-attacker not performed = 0
deny-attacker-victim-pair not performed = 0
deny-attacker-service-pair not performed = 0
modify-packet not performed = 0
Number of Alerts where deny-connection was forced for deny-packet action = 89
Number of Alerts where deny-packet was forced for non-TCP deny-connection action = 0
Output from show statistics transaction-server
General
totalControlTransactions = 2840
failedControlTransactions = 16
Output from show statistics web-server
listener-443
session-4
remote host = 10.x.x.69
session is persistent = yes
number of requests serviced on current connection = 1
last status code = 200
last request method = POST
last request URI = cgi-bin/transaction-server
last protocol version = HTTP/1.1
session state = processingActionsState
session-6
remote host = 10.x.x.69
session is persistent = no
number of requests serviced on current connection = 1
last status code = 200
last request method = GET
last request URI = cgi-bin/sdee-server
last protocol version = HTTP/1.1
session state = processingGetServlet
session-5
remote host = 10.x.x.69
session is persistent = yes
number of requests serviced on current connection = 1
last status code = 200
last request method = POST
last request URI = cgi-bin/transaction-server
last protocol version = HTTP/1.1
session state = processingActionsState
number of server session requests handled = 629400
number of server session requests rejected = 0
total HTTP requests handled = 629696
maximum number of session objects allowed = 40
number of idle allocated session objects = 7
number of busy allocated session objects = 3
summarized log messages
number of TCP socket failure messages logged = 0
number of TLS socket failure messages logged = 1
number of TLS protocol failure messages logged = 0
number of TLS connection failure messages logged = 0
number of TLS crypto warning messages logged = 0
number of TLS expired certificate warning messages logged = 0
number of receipt of TLS fatal alert message messages logged = 0
crypto library version = 6.2.1.0
Output from show health
Overall Health Status Green
Health Status for Failed Applications Green
Health Status for Signature Updates Green
Health Status for License Key Expiration Green
Health Status for Running in Bypass Mode Green
Health Status for Interfaces Being Down Green
Health Status for the Inspection Load Green
Health Status for the Time Since Last Event Retrieval Green
Health Status for the Number of Missed Packets Green
Health Status for the Memory Usage Not Enabled
Security Status for Virtual Sensor vs0 Green
Output from show configuration
! Current configuration last modified Tue Feb 07 09:04:20 2012
! Version 6.2(4)
! Host:
! Realm Keys key1.0
! Signature Definition:
! Signature Update S632.0 2012-03-13
service interface
bypass-mode auto
exit
service authentication
exit
service event-action-rules rules0
overrides log-attacker-packets
override-item-status Enabled
risk-rating-range 70-89
exit
overrides log-victim-packets
override-item-status Enabled
risk-rating-range 70-89
exit
overrides log-pair-packets
override-item-status Enabled
risk-rating-range 70-89
exit
overrides produce-alert
override-item-status Enabled
risk-rating-range 70-89
exit
overrides produce-verbose-alert
override-item-status Enabled
risk-rating-range 70-89
exit
filters edit Ignore_two_hosts
signature-id-range 3030
subsignature-id-range 0
attacker-address-range 10.x.x.0-10.x.x.255
actions-to-remove produce-alert
os-relevance relevant|not-relevant|unknown
exit
filters edit Q00000
signature-id-range 11226,11228
subsignature-id-range 0
victim-address-range 10.x.x.69
actions-to-remove log-attacker-packets|log-victim-packets|log-pair-packets
os-relevance relevant|not-relevant|unknown
exit
filters edit Q00001
signature-id-range 5595
subsignature-id-range 0
attacker-address-range 10.x.x.220-10.x.x.245
actions-to-remove produce-alert
os-relevance relevant|not-relevant|unknown
exit
filters edit Q00002
signature-id-range 2100
subsignature-id-range 0
attacker-address-range 10.x.x.86
actions-to-remove produce-alert
os-relevance relevant|not-relevant|unknown
exit
filters move Ignore_two_hosts begin
filters move Q00000 after Ignore_two_hosts
filters move Q00001 after Q00000
filters move Q00002 after Q00001
exit
service host
network-settings
host-ip 10.1.2.2/29,10.1.2.1
host-name IPS_Sensor
telnet-option disabled
access-list 10.x.x.5/32
access-list 10.x.x.69/32
access-list 10.x.x.86/32
access-list 10.x.x.117/32
exit
time-zone-settings
offset -360
standard-time-zone-name GMT-06:00
exit
ntp-option enabled-ntp-unauthenticated
ntp-server 10.x.x.5
exit
summertime-option recurring
summertime-zone-name UTC
exit
auto-upgrade
cisco-server enabled
schedule-option periodic-schedule
start-time 09:03:17
interval 2
exit
user-name markpiontek
cisco-url https://198.133.219.25//cgi-bin/front.x/ida/locator/locator.pl
exit
exit
exit
service logger
exit
service network-access
general
never-block-hosts 10.x.x.8
never-block-hosts 10.x.x.69
exit
exit
service notification
trap-destinations 10.x.x.86
trap-community-name public
trap-port 162
exit
error-filter warning|error|fatal
enable-detail-traps false
enable-notifications true
enable-set-get true
read-only-community nagioscheck
read-write-community c5c6692a461c537f8cd37b2eb7bec9fb
trap-community-name public
exit
service signature-definition sig0
signatures 1004 0
status
enabled true
exit
exit
signatures 1225 0
status
enabled true
exit
exit
signatures 1316 0
status
enabled true
exit
exit
signatures 1406 0
status
enabled false
exit
exit
signatures 1408 0
status
enabled true
exit
exit
signatures 1604 0
status
enabled true
exit
exit
signatures 1611 0
status
enabled true
exit
exit
signatures 1623 0
status
enabled true
exit
exit
signatures 1627 0
status
enabled true
exit
exit
signatures 1701 0
status
enabled true
exit
exit
signatures 1703 0
status
enabled true
exit
exit
signatures 1706 0
status
enabled true
exit
exit
signatures 1725 0
status
enabled true
exit
exit
signatures 2011 0
status
enabled true
exit
exit
signatures 2152 0
status
enabled true
exit
exit
signatures 2200 0
status
enabled true
exit
exit
signatures 3030 0
status
enabled true
exit
exit
signatures 3128 1
status
enabled true
exit
exit
signatures 3142 3
status
enabled true
exit
exit
signatures 3143 3
status
enabled true
exit
exit
signatures 3143 4
status
enabled true
exit
exit
signatures 3151 0
status
enabled true
exit
exit
signatures 3220 0
status
enabled true
exit
exit
signatures 3323 0
status
enabled true
exit
exit
signatures 3325 0
status
enabled true
exit
exit
signatures 3357 0
status
enabled true
exit
exit
signatures 3537 1
status
enabled true
exit
exit
signatures 4001 0
status
enabled true
exit
exit
signatures 4068 0
status
enabled true
exit
exit
signatures 4602 3
status
enabled true
exit
exit
signatures 4602 4
status
enabled true
exit
exit
signatures 4607 6
status
enabled true
exit
exit
signatures 4607 7
status
enabled true
exit
exit
signatures 4607 8
status
enabled true
exit
exit
signatures 4607 9
status
enabled true
exit
exit
signatures 4609 1
status
enabled true
exit
exit
signatures 4615 2
status
enabled true
exit
exit
signatures 4615 3
status
enabled true
exit
exit
signatures 4704 0
status
enabled true
exit
exit
signatures 5055 0
status
enabled true
exit
exit
signatures 5176 0
status
enabled true
exit
exit
signatures 5448 0
status
enabled true
exit
exit
signatures 5449 0
status
enabled true
exit
exit
signatures 5450 0
status
enabled true
exit
exit
signatures 5451 0
status
enabled true
exit
exit
signatures 5478 0
status
enabled true
exit
exit
signatures 5513 0
status
enabled true
exit
exit
signatures 5538 0
status
enabled true
exit
exit
signatures 5546 0
status
enabled true
exit
exit
signatures 5648 0
status
enabled true
exit
exit
signatures 5653 0
status
enabled true
exit
exit
signatures 5654 0
status
enabled true
exit
exit
signatures 5663 0
status
enabled true
exit
exit
signatures 5710 0
status
enabled true
exit
exit
signatures 5726 0
status
enabled true
exit
exit
signatures 5726 1
status
enabled true
exit
exit
signatures 5739 0
status
enabled true
exit
exit
signatures 5930 7
status
enabled true
exit
exit
signatures 6007 0
status
enabled true
exit
exit
signatures 6066 0
status
enabled true
exit
exit
signatures 6155 0
status
enabled true
exit
exit
signatures 6155 1
status
enabled true
exit
exit
signatures 6408 0
status
enabled true
exit
exit
signatures 6462 0
status
enabled true
exit
exit
signatures 6462 1
status
enabled true
exit
exit
signatures 6462 2
status
enabled true
exit
exit
signatures 6522 0
status
enabled true
exit
exit
signatures 6996 0
status
enabled true
exit
exit
signatures 7104 0
status
enabled true
exit
exit
signatures 7201 0
engine service-p2p
event-action deny-connection-inline|produce-alert
exit
exit
signatures 7202 0
engine service-p2p
specify-service-ports yes
service-ports 1-1024
exit
exit
status
enabled true
exit
exit
signatures 9401 2
status
enabled true
exit
exit
signatures 9403 2
status
enabled true
exit
exit
signatures 9412 1
status
enabled true
exit
exit
signatures 9418 1
status
enabled true
exit
exit
signatures 9430 1
status
enabled true
exit
exit
signatures 9433 1
status
enabled true
exit
exit
signatures 9515 0
status
enabled true
exit
exit
signatures 9516 0
status
enabled true
exit
exit
signatures 9583 0
status
enabled true
exit
exit
signatures 11001 0
engine string-tcp
event-action produce-alert|deny-packet-inline
exit
exit
signatures 11001 1
engine service-p2p
event-action deny-packet-inline|produce-alert
exit
exit
signatures 11005 1
engine service-http
event-action produce-alert|deny-packet-inline
exit
exit
signatures 11005 2
engine service-p2p
event-action deny-packet-inline|produce-alert
exit
exit
signatures 11007 0
engine string-tcp
event-action produce-alert|deny-packet-inline
exit
exit
signatures 11007 1
engine service-p2p
event-action deny-packet-inline|produce-alert
exit
exit
signatures 11018 0
engine string-tcp
event-action produce-alert|deny-packet-inline
exit
exit
signatures 11019 0
status
enabled true
exit
exit
signatures 11019 1
status
enabled true
exit
exit
signatures 11020 1
engine service-p2p
event-action produce-alert|reset-tcp-connection
exit
exit
signatures 11024 0
status
enabled true
exit
exit
signatures 11030 0
engine service-http
event-action produce-alert|reset-tcp-connection
exit
exit
signatures 11031 0
engine service-http
event-action produce-alert|reset-tcp-connection
exit
exit
signatures 11202 0
status
enabled true
exit
exit
signatures 11211 0
status
enabled true
exit
exit
signatures 11211 1
status
enabled true
exit
exit
signatures 11214 0
status
enabled true
exit
exit
signatures 11216 0
status
enabled true
exit
exit
signatures 11219 0
status
enabled true
exit
exit
signatures 11221 0
status
enabled true
exit
exit
signatures 11226 0
status
enabled false
exit
exit
signatures 11228 0
status
enabled false
exit
exit
signatures 11231 0
status
enabled true
exit
exit
signatures 11233 2
status
enabled false
exit
exit
signatures 11233 3
status
enabled true
exit
exit
signatures 11238 0
status
enabled false
exit
exit
signatures 11252 0
status
enabled true
exit
exit
signatures 11252 1
status
enabled true
exit
exit
signatures 12704 0
status
enabled true
exit
exit
signatures 12711 0
status
enabled true
exit
exit
signatures 15235 0
status
enabled true
exit
exit
signatures 15235 1
status
enabled true
exit
exit
signatures 15235 2
status
enabled true
exit
exit
signatures 15393 0
status
enabled true
exit
exit
signatures 15816 0
status
enabled true
exit
exit
signatures 17269 0
status
enabled true
exit
exit
signatures 17397 0
status
enabled true
exit
exit
signatures 50013 2
status
enabled true
exit
exit
exit
service ssh-known-hosts
exit
service trusted-certificates
exit
service web-server
exit
service anomaly-detection ad0
exit
service external-product-interface
exit
service health-monitor
exit
service analysis-engine
virtual-sensor vs0
physical-interface GigabitEthernet0/0
exit
exit
Output from cidDump
cidDiag
CID Diagnostics Report Thu Mar 15 09:56:45 UTC 2012
exec: cat /usr/cids/idsRoot/etc/VERSION
6.2(4)E4
exec: /usr/cids/idsRoot/bin/ceGrep -e .*<\/defaultVersions> /usr/cids/idsRoot/etc/config/signatureDefinition/default.xml
632.0
2012-03-13
exec: cat /usr/cids/idsRoot/etc/VERSION_RP
1.1 - 6.2(4)E4
exec: cat /proc/version
Linux version 2.4.30-IDS-smp-bigphys (@zunix) (gcc version 2.95.3 20010315 (release)) #2 SMP Mon Dec 15 17:53:56 UTC 2008
exec: uptime
09:58:34 up 36 days, 23:50, 1 user, load average: 4.11, 2.07, 1.18
exec: ps -ew f
PID TTY STAT TIME COMMAND
1 ? S 0:28 init
2 ? S 0:00 [keventd]
3 ? SN 0:00 [ksoftirqd_CPU0]
4 ? S 0:00 [kswapd]
5 ? S 0:00 [bdflush]
6 ? S 0:00 [kupdated]
50 ? S 0:01 [kjournald]
75 ? S 0:00 [kjournald]
108 ? Ss 0:00 /sbin/syslogd -m 0
111 ? Ss 0:00 /sbin/klogd
123 ? Ss 0:00 /usr/sbin/inetd
127 ? Ss 0:01 /sbin/sshd
32127 ? Ss 0:03 \_ sshd: cisco@pts/0
32147 pts/0 Ss+ 0:01 \_ -cidcli
32151 pts/0 S+ 0:00 \_ -cidcli
32152 pts/0 SN+ 3:45 \_ -cidcli
32161 pts/0 SN+ 0:00 \_ -cidcli
634 pts/0 SN+ 0:00 \_ -cidcli
317 ? S< 0:00 /usr/cids/idsRoot/bin/SSM_control_proc
343 ? Ss 0:31 /usr/cids/idsRoot/bin/mainApp -d -c 0
346 ? S 0:27 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
347 ? SN 2:03 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
460 ? SN 0:02 | \_ /usr/cids/idsRoot/bin/sensorApp -z 347
487 ? SN 0:00 | \_ /usr/cids/idsRoot/bin/sensorApp -z 347
488 ? SN 12:22 | \_ /usr/cids/idsRoot/bin/sensorApp -z 347
505 ? SN 72:38 | \_ /usr/cids/idsRoot/bin/sensorApp -z 347
1656 ? S< 2346:40 | \_ /usr/cids/idsRoot/bin/sensorApp -z 347
348 ? S 65:11 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
413 ? SN 141:59 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
635 ? SN 0:00 | \_ /bin/bash /usr/cids/idsRoot/bin/cidDump -text -wxml -nostatus -stdout
714 ? RN 0:00 | \_ ps -ew f
414 ? S 0:00 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
420 ? S 6:13 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
433 ? SN 0:20 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
434 ? SN 0:01 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
435 ? SN 0:00 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
436 ? SN 0:02 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
437 ? SN 0:00 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
438 ? RN 3:23 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
439 ? SN 3:01 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
440 ? SN 2:58 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
441 ? RN 2:59 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
442 ? RN 3:00 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
443 ? SN 3:29 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
444 ? RN 3:03 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
445 ? SN 2:59 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
446 ? SN 2:59 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
447 ? SN 3:03 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
448 ? SN 2:42 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
452 ? SN 0:00 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
461 ? SN 0:22 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
462 ? RN 0:06 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
463 ? SN 0:04 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
464 ? SN 0:07 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
465 ? SN 12:01 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
699 ? SN 0:00 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
700 ? SN 0:00 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
703 ? SN 0:00 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
704 ? SN 0:00 \_ /usr/cids/idsRoot/bin/mainApp -d -c 0
384 tty1 Ss+ 0:00 /sbin/getty 38400 tty1
385 tty2 Ss+ 0:00 /sbin/getty 38400 tty2
386 ttyS0 Ss+ 0:00 /sbin/getty -L ttyS0 9600 vt100
426 ? SNLs 16:53 ntpd
exec: cat /usr/cids/idsRoot/tmp/top.log
top - 09:56:47 up 36 days, 23:49, 1 user, load average: 1.50, 1.00, 0.78
Tasks: 69 total, 3 running, 66 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.0% user, 23.5% system, 3.3% nice, 71.2% idle
Mem: 477928k total, 445572k used, 32356k free, 6412k buffers
Swap: 0k total, 0k used, 0k free, 101912k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
644 root 20 5 508 508 432 R 51.9 0.1 0:01.09 grep
636 root 17 5 920 920 732 R 23.0 0.2 0:00.75 top
638 root 13 5 520 520 448 S 7.2 0.1 0:00.27 vmstat
1656 cids 5 -9 22828 346m 332m S 2.0 74.2 2346:33 sensorApp
1 root 8 0 572 572 488 S 0.0 0.1 0:28.91 init
2 root 9 0 0 0 0 S 0.0 0.0 0:00.00 keventd
3 root 18 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd_CPU0
4 root 9 0 0 0 0 S 0.0 0.0 0:00.09 kswapd
5 root 9 0 0 0 0 S 0.0 0.0 0:00.00 bdflush
6 root 9 0 0 0 0 S 0.0 0.0 0:00.00 kupdated
50 root 9 0 0 0 0 S 0.0 0.0 0:01.10 kjournald
75 root 9 0 0 0 0 S 0.0 0.0 0:00.05 kjournald
108 root 9 0 580 580 500 S 0.0 0.1 0:00.09 syslogd
111 root 9 0 564 564 488 S 0.0 0.1 0:00.03 klogd
123 root 9 0 704 704 608 S 0.0 0.1 0:00.01 inetd
127 root 9 0 852 852 732 S 0.0 0.2 0:01.05 sshd
317 root 5 -9 708 708 612 S 0.0 0.1 0:00.15 SSM_control_pro
343 cids 9 0 14316 13m 9596 S 0.0 3.0 0:31.11 mainApp
346 cids 8 0 14316 13m 9596 S 0.0 3.0 0:27.20 mainApp
347 cids 13 5 14316 13m 9596 S 0.0 3.0 2:03.26 mainApp
348 cids 9 0 14316 13m 9596 S 0.0 3.0 65:11.30 mainApp
384 root 9 0 536 536 456 S 0.0 0.1 0:00.04 getty
385 root 9 0 536 536 456 S 0.0 0.1 0:00.04 getty
386 root 9 0 544 544 464 S 0.0 0.1 0:00.04 getty
413 cids 13 5 14316 13m 9596 S 0.0 3.0 141:59.42 mainApp
414 cids 9 0 14316 13m 9596 S 0.0 3.0 0:00.00 mainApp
420 cids 9 0 14316 13m 9596 S 0.0 3.0 6:13.39 mainApp
426 root 13 5 2504 2504 1820 S 0.0 0.5 16:53.79 ntpd
433 cids 13 5 14316 13m 9596 S 0.0 3.0 0:20.64 mainApp
434 cids 13 5 14316 13m 9596 S 0.0 3.0 0:01.66 mainApp
435 cids 17 15 14316 13m 9596 S 0.0 3.0 0:00.01 mainApp
436 cids 13 5 14316 13m 9596 S 0.0 3.0 0:02.37 mainApp
437 cids 13 5 14316 13m 9596 S 0.0 3.0 0:00.01 mainApp
438 cids 15 10 14316 13m 9596 S 0.0 3.0 3:23.64 mainApp
439 cids 15 10 14316 13m 9596 S 0.0 3.0 3:01.15 mainApp
440 cids 15 10 14316 13m 9596 S 0.0 3.0 2:58.92 mainApp
441 cids 15 10 14316 13m 9596 S 0.0 3.0 2:59.74 mainApp
442 cids 15 10 14316 13m 9596 S 0.0 3.0 3:00.58 mainApp
443 cids 15 10 14316 13m 9596 S 0.0 3.0 3:29.60 mainApp
444 cids 15 10 14316 13m 9596 S 0.0 3.0 3:03.72 mainApp
445 cids 15 10 14316 13m 9596 S 0.0 3.0 2:59.21 mainApp
446 cids 15 10 14316 13m 9596 S 0.0 3.0 2:59.60 mainApp
447 cids 15 10 14316 13m 9596 S 0.0 3.0 3:03.92 mainApp
448 cids 13 5 14316 13m 9596 S 0.0 3.0 2:42.38 mainApp
452 cids 17 15 14316 13m 9596 S 0.0 3.0 0:00.17 m -
TCP flow get slower with IPS 4255 5.1(3) in inline mode
I have an IPS 4255 with 5.1(3).
The logical setup is the following:
Internet
|
ServerA --- IPS --- PIX --- IPS --- ServerB
The physical setup is the following:
ServerA --- SwitchA --- IPS --- SwitchB --- PIX --- Internet
ServerB ---/
(ServerA and ServerB are in different DMZs -> in different VLAN-s)
My goal is to protect many segments by one inline IPS, therefore the connection
between SwitchA and SwitchB is an ethernet trunk (for performance reasons this is
an etherchannel trunk (load sharing is src-dst-ip)).
The problem is that ServerA and ServerB have to communicate, and this is done via the PIX.
The communication is very slow and there are many fired TCP Drop and TCP normalization related
signatures. When the IPS is in bypass on mode or one of ther server segment is not watched by the
IPS the communcation speed is ok. I think the speed degradation is because every packet between ServerA and
ServerB travels through the IPS twice. It seems to me that altough they are in seperate VLANs the IPS can not handle
them.
Has someone idea how to solve this issue?Hello,
The traffic is about 1-2 megabit/sec through the IPS, so this does not count.
I tried to use the norandomseq but it does not help.(Is it ok that the norandomseq does not appear in the configuration? - I used in this form: nat (APPL) 0 access-list ACL_NONAT_APPL norandomseq).
I switched off all of the signatures except the normalizers. I switched them just to produce alert and verbose alert no to drop or modify packet.
The two relevant server are Takson (172.31.5.1) and Keve (172.31.6.1)
The alarms are attached. I see that there is alarm between them :TCP session tracking stopped due to timeout
It seems to me very strange.
Akos -
Hi,
I've got most of my devices spouting SNMP traps for various different things, and Ciscoworks forwards these traps on via email, as you do.
For most things it works great, however since we've created a script to pull on the configs off the devices (Simply don't trust Ciscoworks), we're always spammed with SNMP traps like the one below:
ALERT ID = 000071P
TIME = Mon 10-Jan-2011 16:19:07 GMT
STATUS = Active
SEVERITY = Critical
MANAGED OBJECT = lrouter-loo-0.mwam.local
MANAGED OBJECT TYPE = Switches and Hubs
EVENT DESCRIPTION = router1-loo-0.mwam.local: Cisco Configuration Management Trap:InformAlarm; PORT-lon-cr1-loo-0.mwam.local/10113 [Gi1/0/13] [Trunk to router2-gig-1-0-24]:OperationallyDown;
CUSTOMER IDENTIFICATION = networks-info
I know one port is down, and that's expected, I just haven't cleared the alert and turned off the monitoring in DFM.
We're using:
snmp-server enable traps config-copy
snmp-server enable traps config
on all of our devices, but only 4 out of 80+ devices throw this trap out when their config is copied by the script.
I've googled extensively, but I haven't come across any real help.
Has anyone got any idea what the situation is with this? I'm getting bored of deleting a bunch of emails every time our script runs, and I don't want to create a rule for fear of filtering real alerts.
Any ideas would be appreciated
CheersThis isn't a trap. This is a DFM alert, which consists of multiple atomic events. In this case, it looks like the alert consists of two events. The first is a CISCO-CONFIG-MAN-MIB trap (i.e. ciscoConfigManEvent). If you look at the associated event in the DFM Alerts and Acitivities Display, I'll bet it will indicate the configuration was copied (per your script). The other event indicates that port Gi1/0/13 is operationally down on this switch. The two events are unrelated, but apply to the same device.
-
Non-SMTP Session Start Question
I'm getting hundreds of triggers on signature 5748 Non-SMTP Session Start. When I put a block host on this signature I stop getting e-mail. Should this be considered normal traffic.
Hi,
Regarding signature 5748 firing SMTP session initiation with something other than HELO or EHLO. See below for MySDN link on this
signature
http://tools.cisco.com/MySDN/Intelligence/viewSignature.x?signatureId=5748&signatureSubId=0
I'm assuming subsig 0. Is this true?
This is likely a type of reconnaissance attack to see if you are running
an smtp service at this IP address and what type and version number of
smtp software you're running (i.e., Sendmail, Postfix, Microsoft
Exchange, etc.) as they'll get the smtp banner after their initial
connect.
When you see the signature alert, who's the attacker?
You can turn on 'produce verbose alert' to see more information.
Thank you.
Edward
Maybe you are looking for
-
PCMCIA firewire card for G4 laptop (follow-up to excessive timecode breaks)
1.) It was recommended that I get a new firewire bus to resolve excessive timecode breaks when importing from a Canon camcorder to an external hard drive. I've been reading through posts on this topic...and saw getting a new firewire port mentioned a
-
ITunes and Apple TV not playing well with one another?
I updated to the latest version of iTunes and can no longer "share" any more with Apple TV. When I do get it to work,which is seldom, it will do so only very briefly before stopping in the middle of a song. Even then, the transmission is of poor qua
-
How do I update itunes on MAC OS X 10.5.8?
how do I update itunes on a Power Mac G5, MAC OS X 10.5.8? thanks
-
I Earlier today I purchased Adobe ExportPDF Annual and I need help with using this ptrogram.
-
How to set the #HELPLINK# for a page
I tried to find, how or where can I set the #HELPLINK# for each individual page/application component?