SNMP with Synology NAS

In a post from November I'd mentioned trying to get this to work and failing:

"Update (For the life of me, can't get this to work): http://blog.tafkas.net/2015"/01/15/monitoring-a-synology-diskstation-with-munin/
"

 Now I finally got it working. The key was to make sure that when the article says "Therefor create a file inside /etc/munin/plugin-conf.d/ folder with the name of the host (e.g. diskstation) containing two lines:" that I used the FQDN as returned from a ping. I finally got the pihole working with the Ubiquiti by setting the local LAN to use it directly and the router as secondary DNS, and added some entries to the pihole's /etc/hosts file to map to certain hosts with the domain (e.g. server.homenet). Then the file in /etc/munin/plugin-conf.d/ was named server.homenet and included the following two lines:

[snmp_server.HomeNet_*]
env.community secret_string

I also included the following in munin.conf:


[server.HomeNet]
    address 127.0.0.1
    use_node_name no

And made sure to restart munin-node and munin on the Munin server itself. 

Update: The same process can be followed for any device that supports SNMP, such as a router.

So much yet to learn

A recent pentest exposed to me in more full gory detail how much I still don't know about working in AD and various terminologies. For the first time in a while I was able to successfully capture and crack NetNTLMv2 hashes captured using Responder. However I was stymied by metasploit's psexec not working, until I stumbled across CrackMapExec and found that requests spawned with WMI work but psexec didn't. Then I slowly made my way to various systems and discovered that I don't know nearly enough what can actually be done with Domain Admin. I could even potentially use impersonization/delegation tokens for DAs but decided not to.

So now my priority goals going forward are two-fold:

1. Set up an Active Directory lab at home. There are plenty of guides available. Most likely it would be on my Thinkpad T460p, which was purchased almost specifically for this purpose. (Now if I can just get it to stop shutting off every time the battery wiggles inadvertently...) This gives it the element of portability.

2. Really practice with some VMs. Set up some sort of environment which requires heavy use of Metasploit and meterpreter to obtain elevated privileges/credentials/access/whatever. That way I won't flail around when encountering an AD environment.

Of course I'll also finish setting up the new EdgeRouter X courtesy of this guide: https://github.com/mjp66/Ubiquiti. I would never have managed the job without this document. The only things remaining are resolving some DNS issues, getting the Tor relay back up and running either on its own untrusted network or SSH-limited on the same home network, and changing the Edgerouter to use DNSMasq and getting the pihole to serve DNS requests instead.

 

Installing Veil Evasion in Kali Linux

This issue could be specific to this laptop model - which is an HP Elitebook 8460p, but if not I hope someone will find this information useful. If installing Veil from https://github.com/Veil-Framework/Veil-Evasion, you may encounter a problem after restarting the machine where X (window manager) just won't start. For reference, I use Gnome on Kali 2017.2. The problem is that the installation of Wine performed as part of the Veil install removes three critical packages:

libqt4-opengl-dev libglu1-mesa-dev libgl1-mesa-dev. An apt-get install of these should fix the issue. I would recommend adding these back after the Veil install has finished, or you'll need to boot into safe mode, bring up a network interface (for eth0 on a DHCP-enabled network you can plug in a network cable and start NetworkManager), and then install from there.

First December Post

You can almost track my work based on how much posting happens - more posts equals easier work, fewer posts - hard work. In this case it's very much hard work; as I observed to my mother yesterday it's the hardest projects that expose the gaps in your knowledge, caused by gaps in your knowledge. In this case I'm testing from inside a VM, itself inside a VM, to accomodate a client's two-factor RSA-token based authentication, and all the attacks that rely on having an actual IP while sitting physically plugged in to the client's network can't be done, including any that call back to a SimpleHTTPServer you spin up with python, or anything for MITM-ing traffic.

I'm using the installable version of Burp for the first time in Windows, and it's really a pleasure to use. It's stable and doesn't require allocating extra ram via JRE in the Command Line Interface. It now has 13000 requests stored in the Proxy History, which previously would have required a restart by now, and all those requests take up only 70 MB of the "Save State" file.

Here are some questions I've had about VAPT as a result of recent work:

What's really the goal for a pentest? e.g. I'm great at vulnerability testing, but pivoting, and knowing what's permitted, and not disclosing my hand too early when the client asks for a daily update and I'm the talkative type, that's something to work on. Like, is the difference finding misconfigurations, then tying them together to get higher? Then explaining that to the client? How does tying stuff together help the client, other than emphasizing the need to  patch or configure things properly?

Backing up Pi using Synology and rsync (works for DSM 6)

I followed this guide, but made some changes. For starters, DSM had been updated after the guide was written, so the following link needs to be used to change the root password.

https://superuser.com/questions/1056922/synology-ssh-root-password-does-not-work

Before configuring each Pi for which a backup is desired, make the following temporary change:

sudo nano /etc/ssh/sshd_config
PermitRootLogin yes
sudo /etc/init.d/ssh restart

then change back to "PermitRootLogin without-password" once finished with setup and restart the SSH service.

Additionally, make sure to switch to root on the Pi using sudo -i and create a ".ssh" directory with mkdir .ssh.

Also, use the following "backup_target.sh" because the path to rsync has changed from the original, and because this provides a better log format (imho).

 SERVER=$1  
 ADDRESS=$2  
 NOW=`date +"%Y-%m-%d"`  
 LOGFILE="$SERVER-$NOW-log.txt"  
 ping $ADDRESS -c 10 >> /volume1/backups/logs/$LOGFILE  
 /usr/bin/rsync -av --delete --exclude-from=/volume1/backups/_scripts/rsync-exclude.txt -e "ssh -p 22" root@$ADDRESS:/ /volume1/backups/$SERVER/ >> /volume1/backups/logs/$LOGFILE 2>&1  

Todo: https://unix.stackexchange.com/questions/14191/scp-without-replacing-existing-files-in-the-destination

Update (For the life of me, can't get this to work): http://blog.tafkas.net/2015/01/15/monitoring-a-synology-diskstation-with-munin/