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.
Wednesday, October 17, 2018
Monitor keypresses in Linux CLI (embedded)
Cmd: showkey -a
Press any keys - Ctrl-D will terminate this program
a 97 0141 0x61
b 98 0142 0x62
c 99 0143 0x63
d 100 0144 0x64
e 101 0145 0x65
f 102 0146 0x66
g 103 0147 0x67
Thursday, October 11, 2018
UK goes on an Arctic mission
Sun 10/08/2018 3:05 PM PDT
This week, the rather effete British Defense Secretary Gavin Williamson – a former fireplace salesman – said he was sending 800 shivering British soldiers to the Arctic to be ready to fight Russia there.
Amidst the snow.
And the ice.
As both Napoleon and Hitler must have said: "What could possibly go wrong?"
======================================================
A note:
>>IMHO<<
I just hope they have a good pair of socks then ... A new Cold-War have started. Again.
But this time our gov's aren't targeting the enemy, but their own civilians - us.
Isn't that illegal and against the "Geneve Convency"?
Have fun and enjoy the "Propagandist Time"!
And Don't Panic! It might get worse...
This week, the rather effete British Defense Secretary Gavin Williamson – a former fireplace salesman – said he was sending 800 shivering British soldiers to the Arctic to be ready to fight Russia there.
Amidst the snow.
And the ice.
As both Napoleon and Hitler must have said: "What could possibly go wrong?"
======================================================
A note:
>>IMHO<<
I just hope they have a good pair of socks then ... A new Cold-War have started. Again.
But this time our gov's aren't targeting the enemy, but their own civilians - us.
Isn't that illegal and against the "Geneve Convency"?
Have fun and enjoy the "Propagandist Time"!
And Don't Panic! It might get worse...
Sunday, October 7, 2018
TACACS+ on Linux -- Server config
Users ,groups, enable = $enab15$
nano /etc/tacacs+/tac_plus.conf
# Created by Henry-Nicolas Tourneur(henry.nicolas@tourneur.be)
# See man(5) tac_plus.conf for more details
#
# Define where to log accounting data, this is the default.
accounting file = /var/log/tac_plus.acct
# This is the key that clients use to access Tacacs+ server
key = "Cisco321"
#You can also use Linux authentication
# /etc/passwd file -- all users added to Linux will be also in TACACS+
#default authentication = file /etc/passwd
# Much more features are availables, like ACL, more service compatibilities,
# commands authorization, scripting authorization.
# See the man page for those features.
#Default Group
group = adminiis {
default service = permit #if deny here-no enable, no priv
service = exec {
priv-lvl = 15
}
}
# to generate MD5 salted password use tac_pwd
# Usage: tac_pwd [-ehm] [
# -e do not echo the password
# -h display this message
# -m generate MD5 crypt
user = administrator {
member = adminiis
login = des $1$Os$YCyHqKOMpDWOW3VArn/wR.
}
#Enable Passworde to gain Privilege 15 !!
##!@ DO NOT CHANGE USER BELOW! @!##
user = $enab15$ {
login = des $1$sZ$/XuPZ.ZEjTenroBEWJEy6.
}
TACACS+ on Linux => AAA Cisco config
Cisco Router AAA Tacacs+ configuration + Banner
aaa new-model
!
aaa local authentication attempts max-fail 5
aaa authentication password-prompt TACACS+Password:
aaa authentication username-prompt TACACS+Username:
aaa authentication login default local group tacacs+ local
aaa authentication enable default enable group tacacs+ enable
aaa accounting exec default start-stop group tacacs+
!
aaa session-id common
!
tacacs-server host 1.2.3.4
tacacs-server key Cisco123
!
!
!
aaa authentication attempts login 5
aaa authentication banner ^CCCCCCCC
*****************************************************************
* *
* PRIVATE PROPERTY -- YOU ARE MONITORED! LEAVE NOW! *
* ------------------------------------------------------------- *
* THIS COMPUTER SYSTEM, INCLUDING ALL RELATED EQUIPMENT, *
* NETWORKS AND NETWORK DEVICES *
* (SPECIFICALLY INCLUDING INTERNET ACCESS) *
* ARE PROVIDED ONLY FOR AUTHORIZED USE. USE OF THIS SYSTEM *
* AUTHORIZED OR UNAUTHORIZED, CONSTITUTES CONSENT TO MONITORING *
* *
* UNAUTHORIZED USE MAY SUBJECT YOU TO CRIMINAL PROSECUTION *
* EVIDENCE OF UNAUTHORIZED USE COLLECTED DURING MONITORING MAY *
* BE USED FOR ADMINISTRATIVE, CRIMINAL OR OTHER ADVERSE ACTION *
* *
* USE OF THIS SYSTEM CONSTITUTES CONSENT TO MONITORING. *
* *
*****************************************************************
^C
!
!
!
!
!
aaa session-id common
ip arp proxy disable
ip arp gratuitous local
!
dummy2tuntap w/BASH --part II
###!! For the rest of us normal vulnerable people with only one
physical network adapter and public IP address on it::
sudo ip link set dummy0 up
sudo ip tuntap add dev TAP0 mode tun
===================================
To make the deployment faster I am using the below BASH scripts
to create and destroy interfaces when needed
=======================================
nano dummy-bridge.sh
#!/bin/sh /usr/sbin/tunctl -t tap0 /sbin/ifconfig tap0 0.0.0.0 promisc up /sbin/ifconfig dummy0 0.0.0.0 promisc up /sbin/brctl addbr br0 /sbin/brctl addif br0 tap0 /sbin/brctl addif br0 dummy0 /sbin/ifconfig br0 172.22.22.22/24 up echo 1 > /proc/sys/net/ipv4/ip_forward =======================================
nano dummy-bridge-stop
#!/bin/sh ifconfig br0 down ifconfig dummy0 down ifconfig tap0 brctl delif br0 tap0 brctl delif br0 dummy0 brctl delbr br0 tunctl -d tap0 tunctl -d tap1 tunctl -d tap2 tunctl -d tap3
======================================
Networking between Containers - NAT, PAT, Bridge & Dummy2tuntap w/BASH script
- install bridge-utils (brctl IMHO more stable, working with old+new Cisco HW too)
- & create a bridge
This is required so containers and VMs can get IPs on startup.
Without this you would need to setup networking manually for each container or VM.
IPtables rule to enable NAT masquerading (in > out)
- containers and VMs can access the Internet
Port forwarding traffic from a host port to a specific container port (PAT)
Typical example of a port forwarding command:
Ntwork interface is eth0. To set a static IP simply specify the IP address+mask+gw
and change dhcp to static as shown below
- & create a bridge
brctl addbr br0
( new method: ip link add br0 type bridge ) #iproute2
A DHCP server like Dnsmasq is run on the host to provide DHCP services and IPs from a preselected subnet range ie 10.0.3.0/24 to any connecting devices.
This is required so containers and VMs can get IPs on startup.
Without this you would need to setup networking manually for each container or VM.
IPtables rule to enable NAT masquerading (in > out)
- containers and VMs can access the Internet
iptables -t nat -A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
Port forwarding traffic from a host port to a specific container port (PAT)
Typical example of a port forwarding command:
iptables -t nat -A PREROUTING -p TCP -i eth0 --dport 80 -j DNAT \
--to-destination 10.0.3.10:80
Host Bridge (Layer 2)
Instead of using the private NAT you can directly bridge one of your hosts physical network interfaces with a bridge to connect containers to it.(Assuming you have a Private IP range allocated. Or many IPv4 addresses...)
In case you don't have physical interface - you can bridge a tap device
with a DUMMY0 interface //see below
...(i knew there will be an usage for it@!)....
brctl addbr br0
brctl addif br0 eth0
#to list all active bridges
brctl showbr
with DHCP the /etc/networking/interfaces file of a container looks like this
auto eth0 iface eth0 inet dhcp
Ntwork interface is eth0. To set a static IP simply specify the IP address+mask+gw
and change dhcp to static as shown below
auto eth0 iface eth0 inet static address 10.0.4.10 gateway 10.0.4.1 netmask 255.255.255.0
==================================
To be continued...
Saturday, October 6, 2018
Nginx web server in a container AKA Port Forwarding
While you can access the Nginx container from within the host, it is not accessible from outside.
To make container accessible from outside the host on port 80 you need to use port forwarding.
On Linux this is easily done with the IPtables utility.
For instance to forward host port :80 to container with IP 10.0.4.5 port 80 we would run the command below.
This works not only on single hosts but also on internal networks. You can have a single Nginx container serving any number of apps from the internal network. So all your PHP, Python or Ruby apps etc can be served to the outside world by Nginx. You can also terminate SSL connections with Nginx.
Let's use a real world example to illustrate this. Suppose you have Wordpress, Minio and Redmine containers running on your host. You can simply configure an Nginx container instance to serve the 3 apps. A typical Nginx configuration to serve a Wordpress container instance for example would look like this.
This is not limited to containers within a single host. You can use Nginx to serve apps from across your internal network.
You can also use Nginx for SSL termination like below.
This is assuming the Minio container IP is 10.0.4.120 and the URL you
would like access the Minio app is myminio.org.
In below examples we used Nginx but You can also use Apache or any other web server.
Below is a typical configuraton for an Nginx load balancer. This is serving 3 backend Redmine container instances defined in 'upstream backend'
You can also use Haproxy to do the same.
A typical Haproxy configuration would look like this.
Flockport has this functionality built in and lets you deploy both Nginx and Haproxy instances to serve your container apps on a single host or across the network.
To make container accessible from outside the host on port 80 you need to use port forwarding.
On Linux this is easily done with the IPtables utility.
For instance to forward host port :80 to container with IP 10.0.4.5 port 80 we would run the command below.
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 10.0.4.5:80
multiple container apps on port 80 you can only port forward to one
container at a time. This is where using a reverse proxy like Nginx becomes useful. Some container platforms refer to this as an ingress controller
but that is needless verbiage. It's just an Nginx reverse proxy or
incase you want to load balance container application instances you
would typically use either Nginx or Haproxy.
Reverse Proxies
You can configure Nginx to serve various container apps on your server or internal network. This way all the containers can continue to be in the private network and you need to only expose the Nginx container. You can of course run apps on other ports but often port 80/443 are usually required for most appsThis works not only on single hosts but also on internal networks. You can have a single Nginx container serving any number of apps from the internal network. So all your PHP, Python or Ruby apps etc can be served to the outside world by Nginx. You can also terminate SSL connections with Nginx.
Let's use a real world example to illustrate this. Suppose you have Wordpress, Minio and Redmine containers running on your host. You can simply configure an Nginx container instance to serve the 3 apps. A typical Nginx configuration to serve a Wordpress container instance for example would look like this.
upstream backend {
server 10.0.4.100:80;
}
server {
listen 80;
server_name mywordpress.org;
access_log /var/log/Nginx/mywordpress.access.log;
error_log /var/log/Nginx/mywordpress.error.log;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header HOST $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;
}
}
This assumes the Wordpress container IP is 10.0.4.100 and the URL you
want to access the Wordpress app is mywordpress.org. You can replicate
the config for each container app you want to serve simply changing the
upstream server IP to your container IP and port, and the server_name.This is not limited to containers within a single host. You can use Nginx to serve apps from across your internal network.
You can also use Nginx for SSL termination like below.
upstream backend {
server 10.0.4.120:9402;
}
server {
listen 80;
server_name: myminio.org;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name myminio.org;
ssl_certificate myminio.org.cert;
ssl_certificate_key myminio.org.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache builtin:1000 shared:SSL:10m;
access_log /var/log/Nginx/myminio.access.log;
error_log /var/log/Nginx/myminio.error.log;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header HOST $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
In below examples we used Nginx but You can also use Apache or any other web server.
Load Balancing
You can also configure an Nginx or Haproxy load balancer on the same principle to load balance multiple instances of apps across a cluster.Below is a typical configuraton for an Nginx load balancer. This is serving 3 backend Redmine container instances defined in 'upstream backend'
upstream backend {
server 10.0.4.140:3000;
server 10.0.5.150:3000;
server 10.0.7.170:3000;
}
server {
listen 80;
server_name myredmine.org;
access_log /var/log/nginx/myredmine.access.log;
error_log /var/log/nginx/myredmine.error.log;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header HOST $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;
}
}
You can also use Haproxy to do the same.
A typical Haproxy configuration would look like this.
global log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid nbproc 1 maxconn 4000 user haproxy group haproxy daemon stats socket /var/lib/haproxy/stats tune.ssl.default-dh-param 2048 defaults mode http log global option httplog option dontlognull option http-server-close option forwardfor except 127.0.0.0/8 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 frontend www-http bind *:80 option forwardfor stats enable stats refresh 10s stats uri /haproxy?stats stats realm "haproxy stats" stats auth admin:password default_backend app #resolvers flockport #frontend www-https backend app balance roundrobin server web01 10.0.4.140:3000 check server web02 10.0.5.150:3000 check server web03 10.0.7.170:3000 check
Flockport has this functionality built in and lets you deploy both Nginx and Haproxy instances to serve your container apps on a single host or across the network.
X-Forwarding via SSH with Win10 and XcSvrc
Linux (Ubuntu) Server Core 16.04
sudo nano /etc/ssh/sshd_config
#add the below 2 lines
X11Forwarding yes X11UseLocalhost no #!restart the SSH server
sudo service sshd reload From the logs of the XcXsrv gather correct DISPLAY= value (II) GLX: Initialized Win32 native WGL GL provider for screen 0
winClipboardThreadProc - DISPLAY=127.0.0.1:0.0 <<<<<<<<<<<<<<<<<<<<<<<<<
OS maintains clipboard viewer chain: yes
Add the X Server value into yours Putty configuration :
env
DISPLAY=hostname:10.0
You can verify with: xauth listenv | grep DISPLAY Unset incorrect enviroment variable: env --unset DISPLAY SSH Keys setup on Linux & export to host
1. Generate keys
ssh-keygen -t rsa 2. Choose a passhprase and where to save them
admin@srv2:~ $ ssh-keygen -t rsaGenerating public/private rsa key pair.
Enter file in which to save the key (/home/administrator/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/administrator/.ssh/id_rsa.
Your public key has been saved in /home/administrator/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:r3UBzHijPvB9W1uHnijOO7tQeoGrkijSNpw0QR1+8 admin@srv2
The key's randomart image is:
+---[RSA 2048]----+
| o... . .|
| o . + . + |
| . .. * . B .|
| . .+ + * +o|
| . ..S . + +.o|
| o . o +E* + +.|
| + * o + * o * .|
| . o o . + o + . |
| . . . |
+----[SHA256]-----+
admin@srv2:~ $
3. Export keys to other host
ssh-copy-id -p 22 uzivatel@1.2.3.4debug3: authmethod_lookup publickeydebug3: remaining preferred: keyboard-interactive,passworddebug3: authmethod_is_enabled publickeydebug1: Next authentication method: publickeydebug1: Offering RSA public key: /home/administrator/.ssh/id_rsadebug3: send_pubkey_testdebug3: send packet: type 50debug2: we sent a publickey packet, wait for repl
Netmiko - Pyhon Library for SSH mgmt
open-source Python library that simplifies SSH
management to network devices. The library is based on the Paramiko SSH
library and is named Netmiko.
Netmiko has support for the following platforms:
You can find the library at https://github.com/ktbyers/netmiko and the latest released version of the software can be
downloaded here.
The purposes of the library are the following:
- Successfully establish an SSH connection to the device
- Simplify the execution of show commands and the retrieval of output data
- Simplify execution of configuration commands including possibly commit actions
- Do the above across a broad set of networking vendors and platforms
Netmiko has support for the following platforms:
- Cisco IOS
- Cisco IOS-XE
- Cisco ASA
- Cisco NX-OS
- Cisco IOS-XR
- Cisco WLC (limited testing)
- Arista EOS
- HP ProCurve
- HP Comware (limited testing)
- Juniper Junos
- Brocade VDX (limited testing)
- F5 LTM (experimental)
- Huawei (limited testing)
As with anything involving programming, test extensively in your own
environment and for your own specific use cases. It is your
responsibility to know what you are doing and to have good testing
processes in place.
Example 1, a simple SSH session to a Cisco router that executes the 'show ip int brief' command.
First, I must import the ConnectHandler factory function from Netmiko.
This factory function selects the correct Netmiko class based upon the
device_type. I then define a network device dictionary consisting of a
device_type, ip, username, and password.
>>> from netmiko import ConnectHandler
>>> cisco_881 = {
... 'device_type': 'cisco_ios',
... 'ip': '10.10.10.227',
... 'username': 'pyclass',
... 'password': 'password',
... }
At this point, I should be able to connect to the device.
Notice above that I have specified the device_type as 'cisco_ios'. The
supported device_type's are cisco_ios, cisco_xe, cisco_asa, cisco_nxos,
cisco_xr, cisco_wlc_ssh, arista_eos, hp_procurve, hp_comware, huawei,
f5_ltm, juniper, and brocade_vdx.
Now in order to connect all I need to do is call the ConnectHandler
factory function and pass in my earlier defined device dictionary:
>>> net_connect = ConnectHandler(**cisco_881) SSH connection established to 10.10.10.227:22 Interactive SSH session established
Alternatively, I could just call the ConnectHandler function directly and not use a dictionary (as follows):
>>> net_connect = ConnectHandler(device_type='cisco_ios', ip='10.10.10.227', username='pyclass', password='password')
Now at this point we have an SSH connection.
I can verify this by executing the .find_prompt() method
>>> net_connect.find_prompt() u'pynet-rtr1#'
I can also send commands down the SSH channel and receive the output
back.
Here, I use the .send_command() method to send the 'show ip int
brief' command:
>>> output = net_connect.send_command("show ip int brief")
>>> print output
Interface IP-Address OK? Method Status Protocol
FastEthernet0 unassigned YES unset down down
FastEthernet1 unassigned YES unset down down
FastEthernet2 unassigned YES unset down down
FastEthernet3 unassigned YES unset down down
FastEthernet4 10.220.88.20 YES NVRAM up up
Vlan1 unassigned YES unset down down
Let's also try to make a configuration change to this router. First, let's look at the current logging configuration:
>>> output = net_connect.send_command("show run | inc logging")
>>> print output
logging buffered 8880
no logging console
Now in order to make configuration changes, I create a list of
configuration commands that I want to execute. This could be a single
command or multiple commands.
>>> config_commands = ['logging buffered 19999']
I then execute the send_config_set() method. This method will enter
configuration mode, execute the commands, and then exit configuration
mode (note, there will be some exceptions to this behavior depending on
the platform--for example, IOS-XR will not exit configuration mode due
to pending changes).
>>> output = net_connect.send_config_set(config_commands) >>> print output config term Enter configuration commands, one per line. End with CNTL/Z. pynet-rtr1(config)#logging buffered 19999 pynet-rtr1(config)#end pynet-rtr1#
I can then verify my change:
>>> output = net_connect.send_command("show run | inc logging")
>>> print output
logging buffered 19999
no logging console
Example 2, executing 'show arp' on a set of networking devices consisting of different vendors and platforms.
First, I need to define the networking devices (real IP addresses and passwords have been hidden):
>>> from netmiko import ConnectHandler
>>> from datetime import datetime
>>> cisco_881 = {
... 'device_type': 'cisco_ios',
... 'ip': '10.10.10.227',
... 'username': 'pyclass',
... 'password': 'password',
... 'verbose': False,
... }
>>>
>>> cisco_asa = {
... 'device_type': 'cisco_asa',
... 'ip': '10.10.10.10',
... 'username': 'admin',
... 'password': 'password',
... 'secret': 'secret',
... 'verbose': False,
... }
>>>
>>> cisco_xrv = {
... 'device_type': 'cisco_xr',
... 'ip': '10.10.10.227',
... 'username': 'admin1',
... 'password': 'password',
... 'port': 9722, # there is a firewall performing NAT in front of this device
... 'verbose': False,
... }
>>>
>>> arista_veos_sw = {
... 'device_type': 'arista_eos',
... 'ip': '10.10.10.227',
... 'username': 'admin1',
... 'password': 'password',
... 'port': 8522, # there is a firewall performing NAT in front of this device
... 'verbose': False,
... }
>>>
>>> hp_procurve = {
... 'device_type': 'hp_procurve',
... 'ip': '10.10.10.227',
... 'username': 'admin',
... 'password': 'password',
... 'port': 9922, # there is a firewall performing NAT in front of this device
... 'verbose': False,
... }
>>>
>>> juniper_srx = {
... 'device_type': 'juniper',
... 'ip': '10.10.10.227',
... 'username': 'pyclass',
... 'password': 'password',
... 'port': 9822, # there is a firewall performing NAT in front of this device
... 'verbose': False,
... }
Next, I need to create a Python list that includes all of these devices:
>>> all_devices = [cisco_881, cisco_asa, cisco_xrv, arista_veos_sw, hp_procurve, juniper_srx]
Now, I will create a for loop that iterates over all of these devices.
Each time through the loop: the code will connect to the device, execute
the 'show arp' command, and then display the output. I will also keep
track of the time that it takes for the code execute.
Note, I have removed a
couple of public IP addresses from the arp output. Additionally, I have
changed the output slightly (so that you can more clearly see what I
pasted in versus the output back from the devices).
>>>
>>> start_time = datetime.now()
>>> for a_device in all_devices:
... net_connect = ConnectHandler(**a_device)
... output = net_connect.send_command("show arp")
... print "\n\n>>>>>>>>> Device {0} <<<<<<<<<".format(a_device['device_type'])
... print output
... print ">>>>>>>>> End <<<<<<<<<"
...
>>> end_time = datetime.now()
>>>
>>> total_time = end_time - start_time
Here is the output from the for loop (i.e. all of the "show arp" output):
>>>>>>>>> Device cisco_ios <<<<<<<<<
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.220.88.1 4 001f.9e92.16fb ARPA FastEthernet4
Internet 10.220.88.20 - c89c.1dea.0eb6 ARPA FastEthernet4
Internet 10.220.88.100 10 f0ad.4e01.d933 ARPA FastEthernet4
>>>>>>>>> End <<<<<<<<<
>>>>>>>>> Device cisco_asa <<<<<<<<<
inside 10.220.88.100 f0ad.4e01.d933 251
inside 10.220.88.31 5254.0001.3737 311
inside 10.220.88.39 6464.9be8.08c8 361
inside 10.220.88.30 5254.0092.13bb 1451
inside 10.220.88.10 0018.fe1e.b020 1700
inside 10.220.88.29 5254.0098.69b6 3071
inside 10.220.88.21 1c6a.7aaf.576c 3431
inside 10.220.88.28 5254.00ee.446c 5111
inside 10.220.88.38 0001.00ff.0001 8231
inside 10.220.88.20 c89c.1dea.0eb6 11081
inside 10.220.88.40 001c.c4bf.826a 12671
>>>>>>>>> End <<<<<<<<<
>>>>>>>>> Device cisco_xr <<<<<<<<<
Wed Dec 30 00:04:47.641 UTC
-------------------------------------------------------------------------------
0/0/CPU0
-------------------------------------------------------------------------------
Address Age Hardware Addr State Type Interface
10.220.88.1 00:04:19 001f.9e92.16fb Dynamic ARPA GigabitEthernet0/0/0/0
10.220.88.10 00:28:28 0018.fe1e.b020 Dynamic ARPA GigabitEthernet0/0/0/0
10.220.88.28 02:54:39 5254.00ee.446c Dynamic ARPA GigabitEthernet0/0/0/0
10.220.88.29 01:37:22 5254.0098.69b6 Dynamic ARPA GigabitEthernet0/0/0/0
10.220.88.30 00:38:28 5254.0092.13bb Dynamic ARPA GigabitEthernet0/0/0/0
10.220.88.31 02:19:09 5254.0001.3737 Dynamic ARPA GigabitEthernet0/0/0/0
10.220.88.38 - 0001.00ff.0001 Interface ARPA GigabitEthernet0/0/0/0
10.220.88.39 00:06:08 6464.9be8.08c8 Dynamic ARPA GigabitEthernet0/0/0/0
>>>>>>>>> End <<<<<<<<<
>>>>>>>>> Device arista_eos <<<<<<<<<
Address Age (min) Hardware Addr Interface
10.220.88.1 0 001f.9e92.16fb Vlan1, Ethernet1
10.220.88.21 0 1c6a.7aaf.576c Vlan1, not learned
10.220.88.28 0 5254.00ee.446c Vlan1, not learned
10.220.88.29 0 5254.0098.69b6 Vlan1, not learned
10.220.88.30 0 5254.0092.13bb Vlan1, not learned
10.220.88.38 0 0001.00ff.0001 Vlan1, not learned
>>>>>>>>> End <<<<<<<<<
>>>>>>>>> Device hp_procurve <<<<<<<<<
IP ARP table
IP Address MAC Address Type Port
--------------- ----------------- ------- ----
10.220.88.1 001f9e-9216fb dynamic 19
>>>>>>>>> End <<<<<<<<<
>>>>>>>>> Device juniper <<<<<<<<<
MAC Address Address Name Interface Flags
00:1f:9e:92:16:fb 10.220.88.1 10.220.88.1 vlan.0 none
00:19:e8:45:ce:80 10.220.88.22 10.220.88.22 vlan.0 none
f0:ad:4e:01:d9:33 10.220.88.100 10.220.88.100 vlan.0 none
Total entries: 3
>>>>>>>>> End <<<<<<<<<
>>> print total_time
0:00:44.791650
>>>
As you can see it took almost 45 seconds for the above for-loop to
execute. This could be significantly improved by executing the SSH
sessions in parallel, for an example of this see the code here
Some Netmiko methods that are generally available to you:
- net_connect.config_mode() -- Enter into config mode
- net_connect.check_config_mode() -- Check if you are in config mode, return a boolean
- net_connect.exit_config_mode() -- Exit config mode
- net_connect.clear_buffer() -- Clear the output buffer on the remote device
- net_connect.enable() -- Enter enable mode
- net_connect.exit_enable_mode() -- Exit enable mode
- net_connect.find_prompt() -- Return the current router prompt
- net_connect.commit(arguments) -- Execute a commit action on Juniper and IOS-XR
- net_connect.disconnect() -- Close the SSH connection
- net_connect.send_command(arguments) -- Send command down the SSH channel, return output back
- net_connect.send_config_set(arguments) -- Send a set of configuration commands to remote device
- net_connect.send_config_from_file(arguments) -- Send a set of configuration commands loaded from a file
Note:
I specified 'arguments' in the above methods if arguments are
required or reasonably common. Some of the other methods also support
arguments, but you typically wouldn't need them.
RouterSploit on Docker
Install RouterSploit vulnerability search-engine on Docker:
git clone https://www.github.com/threat9/routersploit
cd routersploit
docker build -t routersploit . Run RouterSploit in Docker container:
docker run -it --rm routersploit Basic Commands:
use TAB button!!
rsf (AutoPwn) > use scanners/
scanners/autopwn scanners/cameras/ scanners/misc/ scanners/routers/
rsf (AutoPwn) > set target 77.75.79.39
[+] target => 77.75.79.39
rsf (AutoPwn) >
rsf (AutoPwn) > run
[*] Running module...
[*] Starting vulnerablity check...
[*] thread-0 thread is starting...
[*] thread-1 thread is starting...
[*] thread-2 thread is starting...
[*] thread-3 thread is starting...
[-] 77.75.79.39:80 http exploits/generic/heartbleed is not vulnerable
[*] thread-4 thread is starting...
[*] thread-5 thread is starting...
[*] thread-6 thread is starting...
[*] thread-7 thread is starting...
[*] 77.75.79.39:23 custom/tcp exploits/routers/cisco/catalyst_2960_rocem Could not be verified
[*] 77.75.79.39:80 http exploits/routers/cisco/secure_acs_bypass Could not be verified
[-] 77.75.79.39:80 http exploits/routers/cisco/unified_multi_path_traversal is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/movistar/adsl_router_bhs_rta_path_traversal is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/cisco/firepower_management60_rce is not vulnerable
[-] 77.75.79.39:80 http exploits/generic/shellshock is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/cisco/ucs_manager_rce is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/cisco/firepower_management60_path_traversal is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/cisco/dpc2420_info_disclosure is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/huawei/e5331_mifi_info_disclosure is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/huawei/hg866_password_change is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/asmax/ar_804_gu_rce is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/huawei/hg530_hg520b_password_disclosure is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/asmax/ar_1004g_password_disclosure is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/thomson/twg850_password_disclosure is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/belkin/g_plus_info_disclosure is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/belkin/n150_path_traversal is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/belkin/g_n150_password_disclosure is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/belkin/play_max_prce is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/belkin/auth_bypass is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/belkin/n750_rce is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dvg_n5402sp_path_traversal is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dir_300_600_rce is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dns_320l_327l_rce is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dir_825_path_traversal is not vulnerable
[*] 77.75.79.39:80 http exploits/routers/dlink/dsl_2740r_dns_change Could not be verified
[*] 77.75.79.39:80 http exploits/routers/dlink/dsl_2640b_dns_change Could not be verified
[-] 77.75.79.39:80 http exploits/routers/dlink/multi_hedwig_cgi_exec is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dir_300_320_615_auth_bypass is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dsl_2750b_rce is not vulnerable
[*] 77.75.79.39:1900 custom/udp exploits/routers/dlink/dir_815_850l_rce Could not be verified
[*] 77.75.79.39:80 http exploits/routers/dlink/dsl_2730b_2780b_526b_dns_change Could not be verified
[-] 77.75.79.39:80 http exploits/routers/dlink/dir_645_password_disclosure is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/multi_hnap_rce is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dsp_w110_rce is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dir_645_815_rce is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dwr_932_info_disclosure is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dir_850l_creds_disclosure is not vulnerable
[-] 77.75.79.39:80 http exploits/routers/dlink/dir_8xx_password_disclosure is not vulnerable
^C[-] 77.75.79.39:80 http exploits/routers/cisco/ios_http_authorization_bypass is not vulnerable
Thursday, October 4, 2018
Troubleshooting is a lot like storytelling
Define the Problem
A problem definition begins with a comparative analysis, using what, when, where, to what extent.What is not working
- What is the observed behavior?
- How is this different than expected behavior?
When does it happen
- When was the first occurrence? Are there multiple occurrences?
- Any pattern? Any clear trigger event?
- Skim log files for the same time period.
- Does it happen continuously or intermittently?
- Is some action taken by a user?
- Does it clear after some time?
- Does some impacting event reset the environment (crash or reboot event)?
Where in the life-cycle
- Where in the object life-cycle does the problem-state show itself?
- Day-1 issues are usually mis-configurations, design-related, or bugs (hardware or software related)
- Day-2 issues are usually seen after some “change” has taken place. This might be a link flap, or a memory leak over a long time.
- Should it work as described as-is?
- Is there evidence to support the advertised performance numbers?
Extent
How many objects show the problem-state? …out of how many total objects?- Are there some objects that _could_ show the problem but do not show the problem right now? Compare objects that are working versus the problem-state.
- Certain features will influence the forwarding pipeline that a packet would follow through a network device.
- A link that is flapping would usually show similar number of up/down transitions at each side.
- An interface configured with sub-optimal MTU might cause fragmentation in a single direction, especially if there are two exit nodes on the network (traffic could follow an asymmetric forwarding path in/out of the network).
Narrow the Scope
Determine the appropriate method to isolate the problem to a direction, a single object, and then a singular component (hardware or software related).Split the Difference
Imagine you are troubleshooting some connectivity problem with VM hosts that reside in a VXLAN segment- VXLAN is a network virtualization overlay technology comprised of the underlay network (between ingress VTEP and egress VTEP devices) and the overlay network (VM hosts at the outer edge of the network)
- In this type of situation, I start by verifying the underlay reachability. If this fails, then it would be a waste of time to investigate the overlay network.
- If the underlay network is working, then move on to the overlay network.
- Verify connectivity between each VTEP to the locally connected host.
- What direction is packet loss happening? Forward path or the return path? Look at interface counters, ACL counters, aggregate traffic statistics… tcpdump and ERSPAN can help isolate direction of packet loss
- To help determine if hardware is mis-programmed, you can insert special flags (record route option) in an ICMP packet to force the router to punt the packet to CPU at each hop. Not all network vendors act (punt to CPU) upon it though
- Is the problem specific to a type of traffic? IPv4 or IPv6? Unicast or BUM traffic? TCP, UDP or ICMP traffic?
Bottom Up
Physical layer issues fall into this category. Imagine a link is fully inserted, but fails to pass traffic- Check the port is not administratively disabled (yes, we overlook the easy answers).
- What is the hardware state? The switch ASIC must first recognize and program the link.
- If the ASIC has correctly programmed the type of the link (and recognized the transceiver), then what is the software state?
- Assuming optical fiber is in play, what are the light levels from each termination point? The transmit signal on one side corresponds to the receive signal at the remote end. If the signal is too weak, is there a patch panel, or any intermediate transponder equipment? Check the signal at each point where the cable is terminated.
Performance issues fall into this category.
Use packet captures to help tell the story how the system is actually working.
Often we make assumptions, which are sometimes false:
- The environment changed since the last release.
- A new variable was introduced into the environment.
- We’re operating on information that was not carefully validated.
Verify the Hypothesis
Do not skip the verification process — you are here because there is a complex problem in front of you. Problems have a tendency to return if you do not reveal the underlying cause.
A hypothesis is similar to storytelling, where you expect to find a headline and supporting evidence.
- At each step of the process document your steps taken and the outcome.
- Keep asking yourself, “does this finding / deviation explain the problem-state?” If not, then rule it out as a possible cause. Move to the next item on the list.
- Assumptions can be dangerous if not verified. Multicast traffic may be treated differently than unicast traffic at certain points in the forwarding path.
- Start by testing the most probable cause. If this would require a considerable amount of resources (time or money), such as sending a field engineer to an unmanned-site that is far away then try to eliminate the low-hanging fruit (something that can be tested quickly to further bolster your hypothesis or rule it out).
- Keep an open mind when you approach a problem — be willing to broaden your search.
Environment
It’s best to troubleshoot the actual problem-state in a live environment if at all possible. However:- Sometimes it is not possible to leave the system in the problem-state for a long time, and it must be recovered to a normal, working state.
- Hopefully you gleaned enough data points from the problem-state to attempt a lab re-create.
- Often you do not need a scaled setup, and it can be reduced to a small number of devices (physical or virtualized lab environment).
- Traffic generators can introduce new problems. If you are testing with a uni-directional traffic flow, this is different circumstances than most production traffic flows (bi-directional)
The Power of a Team
By working closely with others to solve a problem, all of us benefit in many ways, such as- spot gaps or flaws in your story;
- learn a new way to approach a problem (that saves you time);
- improve the fix to be more efficient.
Tuesday, October 2, 2018
Windows 10 - IP Forwarding / Routing
Win + R
regedit
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Change IP Enable Router from 0 to 1
IPEnableRouter 1
-----------------------------------
Win + R
Services.msc
Routing and Remote Access
Startup Automatic
Start
Subscribe to:
Posts (Atom)