Recent Posts

Pages: [1] 2 3 ... 10
1
Was looking at production. Bit of a weird request, I know.

I spent all day on this yesterday, reading docs and following some examples online and adding what I had learnt from the docs. I found that yes, we can authenticate the client by username and password only but the next problem is openvpn is either TCP or UDP only. Unlike Cisco's SSL VPN where the authentication is done on TCP and then a DTLS UDP data channel is opened up.

So I thought some more and I think it's best to run a VPN from an upstream device like a router and then the phone will simply do SCCP only to CUCM. I could splash out and set up a asav or csr virtual router, but the minimum specs for those is overkill for me. This in turn makes it expensive for licensing and cloud VM running costs. At the moment I literally have three telephones that I want to connect to a VPN in the cloud. I have another idea, so going to look into that today.

Thanks for the information dlots :)
2
Routing and Switching / Re: Get. The. Packet. Capture.
« Last post by deanwebb on May 22, 2018, 06:05:00 PM »
Evidence based assessment? Blasphemy!!!  :)

Hey, welcome back!  8)
3
TA18-141A: Side-Channel Vulnerability Variants 3a and 4

[html]Original release date: May 21, 2018 | Last revised: May 22, 2018

         

Systems Affected


         

CPU hardware implementations

         
         

Overview


         

On May 21, 2018, new variants of the side-channel central processing unit (CPU) hardware vulnerabilities known as Spectre and Meltdown were publicly disclosed. These variants—known as 3A and 4—can allow an attacker to obtain access to sensitive information on affected systems.

         
         

Description


         

Common CPU hardware implementations are vulnerable to the side-channel attacks known as Spectre and Meltdown. Meltdown is a bug that "melts" the security boundaries normally enforced by the hardware, affecting desktops, laptops, and cloud computers. Spectre is a flaw that an attacker can exploit to force a CPU to reveal its data.

Variant 3a is a vulnerability that may allow an attacker with local access to speculatively read system parameters via side-channel analysis and obtain sensitive information.

Variant 4 is a vulnerability that exploits “speculative bypass.” When exploited, Variant 4 could allow an attacker to read older memory values in a CPU’s stack or other memory locations. While implementation is complex, this side-channel vulnerability could allow less privileged code to

  • Read arbitrary privileged data; and
  • Run older commands speculatively, resulting in cache allocations that could be used to exfiltrate data by standard side-channel methods.

Corresponding CVEs for Side-Channel Variants 1, 2, 3, 3a, and 4 are found below:

  • Variant 1: Bounds Check Bypass – CVE-2017-5753
  • Variant 2: Branch Target Injection – CVE-2017-5715
  • Variant 3: Rogue Data Cache Load – CVE-2017-5754
  • Variant 3a: Rogue System Register Read – CVE-2018-3640
4
Routing and Switching / Re: Get. The. Packet. Capture.
« Last post by shortstop20 on May 22, 2018, 12:18:24 PM »
I don't know why people put off getting the packet capture... it's going to work, it's going to solve the problem, it's going to be the best thing you do all day. So why waste time with anything else?

I submit that the people that don't go directly to setting up a capture are either just being lazy, don't know how to do it, or are a combination of the two.

Lazy I can't help.

Not knowing how to do it? Google up "tcpdump", load Wireshark, and get busy.

Just had a case yesterday, lots of finger pointing, everybody blaming everyone else. The arguing had been going on for HOURS. I got parachuted in and asked the question, "What does the packet capture show?"

Silence.

Next thing I said was, "Get the packet capture on the server and it will show if there's any attempt to connect with the remote host."

They got the packet capture.

One hour later, they had the fix in place.  :smug:

If they had gone for the capture instead of the political posturing bullcrap, they would have had the fix, less arguing, and no need to make everyone mad with accusatory finger-pointing.

Evidence based assessment? Blasphemy!!!  :)
5
Routing and Switching / Re: What Causes a Switch to Crash?
« Last post by shortstop20 on May 22, 2018, 12:15:05 PM »
are you sure it was a bit flip or was that a random guess by a TAC guy wanting to close it out?

I still have the SP and RP crashfiles... here are the relevant bits from the SP crashfile:

Code: [Select]
Cache error detected!
  CPO_ECC     (reg 26/0): 0x00000089
  CPO_CACHERI (reg 27/0): 0xA0000000
  CP0_CAUSE   (reg 13/0): 0x00001C00

Real cache error detected.  System will be halted.

Error: Primary data cache, fields: data,
Actual physical addr 0x00000000,
virtual address is imprecise.

 Imprecise Data Parity Error

 Imprecise Data Parity Error

 08:58:20 PDT Wed Jul 13 2011: Interrupt exception, CPU signal 20, PC = 0x40FEA860



--------------------------------------------------------------------
   Possible software fault. Upon reccurence, please collect
   crashinfo, "show tech" and contact Cisco Technical Support.
--------------------------------------------------------------------


-Traceback= 417BEE50
$0 : 00000000, AT : 42640000, v0 : 52D11A90, v1 : 45BF04F8
a0 : 52D11AC4, a1 : 52D44E3C, a2 : 40FEA848, a3 : 52D44E3C
t0 : 408B5698, t1 : 3400FF01, t2 : 3400F100, t3 : FFFF00FF
t4 : 417B13A8, t5 : 0000FFFF, t6 : 00000004, t7 : 0000030D
s0 : 52D44E3C, s1 : 00000002, s2 : 40FEA848, s3 : 52D44E3C
s4 : 43ECEF90, s5 : 00000004, s6 : 00000000, s7 : EFFFFFFA
t8 : 55BB5088, t9 : 00000000, k0 : 55B8DC94, k1 : 408EAE50
gp : 42647238, sp : 52D44D90, s8 : 9FBF04BE, ra : 40FEA860
EPC  : 417BEE50, ErrorEPC : 40FEA860, SREG     : 3400FF05
MDLO : 3B13B68E, MDHI     : 00000719, BadVaddr : 00000000
DATA_START : 0x42322420
Cause 00000000 (Code 0x0): Interrupt exception


The SP crash forced the RP to reload and then all hell broke loose....   more info

How is it possible when Cisco equipment uses ECC memory?

I can't answer that question but we have seen the parity errors on a Catalyst 6807, twice.
6
TA18-141A: Side-Channel Vulnerability Variants 3a and 4

Original release date: May 21, 2018 | Last revised: May 22, 2018

   

Systems Affected


   

CPU hardware implementations

   
   

Overview


   

On May 21, 2018, new variants—known as 3A and 4—of the side-channel central processing unit (CPU) hardware vulnerability were publicly disclosed. These variants can allow an attacker to obtain access to sensitive information on affected systems.

   
   

Description


   

Common CPU hardware implementations are vulnerable to the side-channel attacks known as Spectre and Meltdown. Meltdown is a bug that "melts" the security boundaries normally enforced by the hardware, affecting desktops, laptops, and cloud computers. Spectre is a flaw that an attacker can exploit to force a CPU to reveal its data.

Variant 3a is a vulnerability that may allow an attacker with local access to speculatively read system parameters via side-channel analysis and obtain sensitive information.

Variant 4 is a vulnerability that exploits “speculative bypass.” When exploited, Variant 4 could allow an attacker to read older memory values in a CPU’s stack or other memory locations. While implementation is complex, this side-channel vulnerability could allow less privileged code to

  • Read arbitrary privileged data; and
  • Run older commands speculatively, resulting in cache allocations that could be used to exfiltrate data by standard side-channel methods.

Corresponding CVEs for Side-Channel Variants 1, 2, 3, 3a, and 4 are found below:

  • Variant 1: Bounds Check Bypass – CVE-2017-5753
  • Variant 2: Branch Target Injection – CVE-2017-5715
  • Variant 3: Rogue Data Cache Load – CVE-2017-5754
  • Variant 3a: Rogue System Register Read – CVE-2018-3640  
  • Variant 4: Speculative Store Bypass – CVE-2018-3639
   
   

Impact


   

Side-Channel Vulnerability Variants 3a and 4 may allow an attacker to obtain access to sensitive information on affected systems.

   
   

Solution


   

Mitigation

NCCIC recommends users and administrators

  • Refer to their hardware and software vendors for patches or microcode,
  • Use a test environment to verify each patch before implementing, and
  • Ensure that performance is monitored for critical applications and services.
    • Consult with vendors and service providers to mitigate any degradation effects, if possible.
    • Consult with Cloud Service Providers to mitigate and resolve any impacts resulting from host operating system patching and mandatory rebooting, if applicable.

The following table contains links to advisories and patches published in response to the vulnerabilities. This table will be updated as information becomes available.

Link to Vendor InformationDate Added
AMDMay 21, 2018
ARMMay 21, 2018
IntelMay 22, 2018
MicrosoftMay 21, 2018
RedhatMay 21, 2018
   
   

References


   
   
   

Revision History


   

           
  • May 21, 2018: Initial version

  •        
  • May 22, 2018: Added information and link to Intel in table

  •        

   

   

This product is provided subject to this Notification and this Privacy & Use policy.

   

Source: TA18-141A: Side-Channel Vulnerability Variants 3a and 4
7
Is this just for testing?  Or is it going into production?

If it's just for testing you can probably setup a virtual ASA in GNS3
8
Security / Re: so much for your Cisco Digital Network Architecture
« Last post by wintermute000 on May 22, 2018, 05:05:29 AM »
that's actually stealthwatch and/or tetration
9
Everything Else in the Data Center / Re: Vendor HA Recommendations vs. Reality
« Last post by Dieselboy on May 22, 2018, 01:58:14 AM »
It seems like a misunderstanding... This is where I start asking questions and annoying people (as a consequence of asking questions and probing). But how else can you say "what do you mean you only support direct HA connection... Can you tell me why?" One could take it as though they are implying that they are not using Ethernet as a mechanism to communicate between the two devices, ie a switch wouldn't work; or the keepalive timeout value is so low that they can't have latency. But the vendor should be able to give parameters to allow a design to be built. One of the possible problems I can foresee is if there was such an outage event and then it came to light that the equipment was set up in a non-supported way, the vendors like a 'get out clause'...

There's a few instances in my place that are running fine that the vendor has said is not supported or not possible, although nothing to do with HA. In those cases I try and test, and see if it performs as expected.
10
TA18-141A: Side-Channel Vulnerability Variants 3a and 4

Original release date: May 21, 2018

   

Systems Affected


   

CPU hardware implementations

   
   

Overview


   

On May 21, 2018, new variants—known as 3A and 4—of the side-channel central processing unit (CPU) hardware vulnerability were publically disclosed. These variants can allow an attacker to obtain access to sensitive information on affected systems.

   
   

Description


   

CPU hardware implementations—known as Spectre and Meltdown—are vulnerable to side-channel attacks. Meltdown is a bug that "melts" the security boundaries normally enforced by the hardware, affecting desktops, laptops, and cloud computers. Spectre is a flaw that an attacker can exploit to force a CPU to reveal its data.

Variant 3a is a vulnerability that may allow an attacker with local access to speculatively read system parameters via side-channel analysis and obtain sensitive information.

Variant 4 is a vulnerability that exploits “speculative bypass.” When exploited, Variant 4 could allow an attacker to read older memory values in a CPU’s stack or other memory locations. While implementation is complex, this side-channel vulnerability could allow less privileged code to

  • Read arbitrary privileged data; and
  • Run older commands speculatively, resulting in cache allocations that could be used to exfiltrate data by standard side-channel methods.

Corresponding CVEs for Side-Channel Variants 1, 2, 3, 3a, and 4 are found below:

  • Variant 1: Bounds Check Bypass – CVE-2017-5753
  • Variant 2: Branch Target Injection – CVE-2017-5715
  • Variant 3: Rogue Data Cache Load – CVE-2017-5754
  • Variant 3a: Rogue System Register Read – CVE-2018-3640  
  • Variant 4: Speculative Store Bypass – CVE-2018-3639
   
   

Impact


   

Side-Channel Vulnerability Variants 3a and 4 may allow an attacker to obtain access to sensitive information on affected systems.

   
   

Solution


   

Mitigation

NCCIC recommends users and administrators

  • Refer to their hardware and software vendors for patches or microcode,
  • Use a test environment to verify each patch before implementing, and
  • Ensure that performance is monitored for critical applications and services.
    • Consult with vendors and service providers to mitigate any degradation effects, if possible.
    • Consult with Cloud Service Providers to mitigate and resolve any impacts resulting from host operating system patching and mandatory rebooting, if applicable.

The following table contains links to advisories and patches published in response to the vulnerabilities. This table will be updated as information becomes available.

Link to Vendor InformationDate Added
AMDMay 21, 2018
ARMMay 21, 2018
MicrosoftMay 21, 2018
RedhatMay 21, 2018
   
   

References


   
   
   

Revision History


   

           
  • May 21, 2018: Initial version

  •        

   

   

This product is provided subject to this Notification and this Privacy & Use policy.

   

Source: TA18-141A: Side-Channel Vulnerability Variants 3a and 4
Pages: [1] 2 3 ... 10