Wednesday, 22 August 2012

[Technical] - Bluecoat ProxyAV failes to get Kaspersky engine after upgrade

I have just resolved the following issue on a Bluecoat ProxyAV running 3.4.1.4.

After an software upgrade the AV wouldn't scan traffic and the Kaspersky AV engine couldn't be downloaded even if forced.
  The system was showing the error "Some files that are required by Antivirus were not found on your system. ProxyAV will attempt to update the files the next time you connect to the Internet." on the GUI and trying to download the engine would most times fail after 15mins.


No traffic was being scanned and the Internalinfo diagnostic log was showing;

2012-08-22 22:40:36+00:00UTC AV Updater: "get filelist" state, full AV update chosen
2012-08-22 22:47:06+00:00UTC AV Updater: "get full" state, 'BackgroundUpdaterThread' started
2012-08-22 22:47:09+00:00UTC AV Updater: "local file 'kaspersky_1xxx9931.zip' decrypted
2012-08-22 22:47:15+00:00UTC AV Updater: Files are present,test the new AV engines...
2012-08-22 22:47:15+00:00UTC AV Updater: starting test...
2012-08-22 22:48:05+00:00UTC AVScanner: eicar scanning failed MP_ERROR=29
2012-08-22 22:48:05+00:00UTC
2012-08-22 22:48:05+00:00UTC file d:\ositis\Temp\kaspersky_1xxx931.zip successfully backedup as DLxxx01378.log
2012-08-22 22:48:05+00:00UTC AV Updater: failed to scan eicar, re-copying backup engines...

The key here is the "eicar scanning failed MP_ERROR=29" which forces a restore from a non-existant backup..

After a number of attempted fixes, the solution was to downgrade to 3.3.1.2 then upgrade to 3.4.1.1 and finally to 3.4.1.4 whilst forcing the engine updats at each point.
 This worked for us, hope it helps for you.

Sunday, 19 February 2012

[Technical] - Checkpoint/Nokia Firewall SFP - NIY4437

The Nokia 5048 - NIY4437 SFP (OEM Part Number FTLF1319P1BTL-NK) is stated on Checkpoints website as a 1000Base-SX SFP, this implies that its a Multimode SFP operating at a 850nm wavelength.




However this is misleading, (or outright wrong) the SPF operates at 1310nm and is compatable with other LH GBICs like the Cisco SFP-GE-L or GLC-LH-SM.

So its a Single-Mode SFP (SMF) rather than a Multi-Mode SFP.

Tuesday, 16 September 2008

[Technical] - ACS 'Server Secret Mismatch' Error.

I saw an issue where the following error was being displayed even when the shared key matched. (Or seemed to..)

"Authentication Server not responding: AAA decode failure.. server secret mismatch"

This was seen on an Cisco ASA firewall running 8.0.4 code. The ACS log would either show "Key Mismatch" or "CS password invalid" (using Radius)

The shared key was the same as that in the Network Configuration of ACS, however "Network Device Groups" were being used and the default key for the network device group was different to the specific device key and took priority.


Use the network device group (NDG) key or don't set a NDG key.


Bob

Thursday, 11 September 2008

[Technical] - Error Message 'External DB is not operational' seen on Cisco ACS appliance. Wireless users fail to authenticate.

The following is a bit of advice on how to troubleshoot the error message 'External DB is not operational' or the error "Connection to Windows authentication agent established; Failed to connect to any Windows authentication agent." on a CiscoSecure ACS appliance.

This will most likely occur when authentication is being backed off to a Windows Active Directory from a CiscoSecure ACS appliance. The authentication agent software is a small application that's ideally loaded onto a Domain Controller that accepts authentication requests from the ACS and responds after querying the AD.

This issue above will most likely occur where the ACS appliance can't communicate with the agent because;

- The domain controller hosting the agent software is down.
- The agent service "csagent" has stopped responding.
- A firewall is blocking traffic between the ACS and Domain Controller.
- The IP address of the domain controller hosting the agent has changed.
- The software version of ACS and the agent need to match.
- The certificate has expired on the ACS appliance or is now invalid for the domain.



The above error message will likely be seen in the ACS "failed attempts" log file.

To troubleshoot this issue do the following;

1 - Check connectivity from the ACS appliance to the domain controller.
2 - Check that the csagent service is running on the domain controller.
3 - Stop the csagent service and restart it from DOS in debug mode.

To use debug mode open a command prompt and go to the csagent directory. Then start the agent with the -z and -p options.

C:\Program Files\Cisco\CiscoSecure ACS Agent\bin>csagent -z -p

Two windows will open, a successfully communication will look as follows:

C:\Program Files\Cisco\CiscoSecure ACS Agent\bin>csagent -z -p
Running ACSRemoteAgent server from command line..
Debug printing on..
ACSRemoteAgent server starting ==============================
Running as console application.
Will listen on port 2004
Configuration will be fetched from 192.x.x.103:2003
Agents: CSWinAgent
CSWinAgent File: ..\bin\CSWinAgent.exe
CSWinAgent Port: 2005
1 agents configured
Permitted CSAgent Clients: *.*.*.*
Hit Return/Enter to stop...

Listener activated
Watchdog activated
CSWinAgent launched
Client connecting from 192.x.x.103:1159
RPC: Info request received
RPC: Info reply sent
Client disconnected, thread 2628 terminating

--------- In the second window ----------

CSWinAgent server starting ==============================
Running as console application.
Will listen on port 2005
Permitted CSWinAgent Clients: *.*.*.*
NTLIB: Library behaviour mode 2
NTLIB: Initialising locally
NTLIB: The local computer name is MYDC12
NTLIB: The 'insist on domain' feature is enabled
NTLIB: We ARE a domain controller
NTLIB: We are a backup domain controller for domain MY.COM
NTLIB: Found 0 trusted domains
Listener activated
Client connecting from 192.x.x.103:1160
RPC: NT_MSCHAPAuthenticateUser received
NTLIB: Attempting Windows authentication for user JIM.SMITH$
NTLIB: Windows authentication SUCCESSFUL (by MYDC12)
RPC: NT_MSCHAPAuthenticateUser reply sent


Please feedback any other experiences.

Some useful URLs are;


Bob

Wednesday, 5 March 2008

CCIE Security Anyone?

[Technical] – Unable to define a source-interface with TACACS+ on the Cisco ASA/PIX

We had a requirement to have an ASA authenticate with 2 geographically dispersed ACS servers for resilience.

  • ACS1 is connected via the dmz1 interface.
  • ACS2 is connected via the dmz2 interface.
  • ACS1 replicates to ACS2.

The Cisco ASA/PIX doesn’t support using a source-interface for TACACS+ like a Cisco IOS based router does. So the ACS sees the request as coming from the IP address of the outgoing interface on the ASA.

The only solution is to configure two IPs within ACS per ASA one that relates to the dmz1 and one that relates to the dmz2 interfaces.

[Technical] - “Flow is denied by configured rule” message with ASA packet-tracer and traffic being dropped at the VPN phase.

I came across an interesting issue today where traffic wasn’t passing across a new IPSec Lan-to-Lan VPN correctly. On both sides were Cisco ASA firewalls 8.0(2), with the local one managed by me and the remote by a 3rd party.

Some traffic was flowing correctly and some wasn’t. A packet trace of a failing stream showed the following:


ASA#packet-tracer input inside tcp 10.1.1.65 16664 20.1.1.1 http

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Additional Information:
in 0.0.0.0 0.0.0.0 outside

Phase: 5
Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Config:
nat (inside) 0 access-list inside_nat0_outbound
match ip inside 10.1.1.64 255.255.255.192 outside 20.1.1.0 255.255.255.0
NAT exempt
translate_hits = 3, untranslate_hits = 0

Phase: 6
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Clearly the VPN phase shouldn’t have been dropping the traffic.

This was confusing there were no ACLs blocking traffic, the route, nat and crypto acl were all ok. However upon investigation the remote crypto ACL didn’t have an entry for this stream.

Upon modifying them so they were symmetrical the issue was resolved.