What you found is a known bug in version 3.1 and earlier sensors.
The sensor did not track which port was the server and which port was the client.
So if your analysis is correct that this is a normal HTTP connection, then the HTTP client randomly chose the 12345 port which a Netbus server usually runs on. The HTTP client then sent a request to the webserver that contained "netbus" in the request.
The signature looks for the regular expression: [Nn][Ee][Tt][Bb][Uu][Ss] from a server running on ports 12345,12346 or 20034
So you may want to verify that it is a legitimate web request containing "netbus" in the request or some variant like "netbusiness" which would make the alarm a false positive alarm.
In version 4.0 of the sensor we have addresses these false postives where clent ports are being confused with server ports. The 4.0 sensor is able to track the direction of the connection in order to determine which of the 2 ports is the server port and which is the client port. So in 4.0 you would not have this false positive.
Here is the signature definition on a 4.0 sensor in case you are interested:
SIGID: 3116
SubSig: 0
AlarmDelayTimer:
AlarmInterval:
AlarmSeverity: high
AlarmThrottle: Summarize
AlarmTraits:
ChokeThreshold:
Direction: FromService
Enabled: True
EndMatchOffset:
EventAction:
FlipAddr:
MaxInspectLength:
MaxTTL:
MinHits: 1
MinMatchLength:
Protocol: TCP
RegexString: [Nn][Ee][Tt][Bb][Uu][Ss]
ResetAfterIdle: 15
ServicePorts: 12345-12346,20034
SigComment:
SigName: NetBus
SigStringInfo: NetBus
SigVersion: S37
StorageKey: STREAM
StripTelnetOptions:
SummaryKey: AaBb
ThrottleInterval: 15
WantFrag
