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.
 
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 apps
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.
 
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;
    }
}
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.
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 list
env | 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 rsa
 

Generating 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.4

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/administrator/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: 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.
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.
netmiko show arp image
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?
How is the problem cleared:
  • 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. 
The system might have been deployed without ever measuring the performance (especially in failure scenarios).
  • Should it work as described as-is?
  • Is there evidence to support the advertised performance numbers?
Marketing is well-known to omit important subtle details. You might find a (hardware or software) limitation exists (that might, or might not have a workaround).

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.
How many occurrences of the problem were seen on each object?
  • 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
Is the problem specific to data plane traffic? Or control plane, or management plane traffic?
  • 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.
Top Down
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.
Use a traffic generator if necessary. iperf, nuttcp, and mz are just some of the open-source tools. Be careful, some of them are better suited for particular traffic characteristic. Get involved in the community and help make the tools better.

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.
Successful people are good communicators. Surround yourself with people that emulate the characteristics you wish to learn from.

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