Wielding the Automated Banhammer with Fail2Ban

Found amongst the security section of Linode's site (https://www.linode.com/docs/security), I decided to test out Fail2Ban in spite of having no valuable data stored on my VPS. I started with a simple installation :
                                     


apt-get update && apt-get upgrade -y

apt-get install fail2ban

apt-get install sendmail-bin sendmail



In /etc/fail2ban the fail2ban.local file is created using the 'touch' command, to enable local logging.
The settings in this file, edited with the 'nano' command, override the entries in the program's .conf file :

The four values in the 2nd picture are explained as following on Linode's site :

• loglevel: The level of detail that Fail2ban’s logs provide can be set to 1 (error), 2 (warn), 3 (info), or 4 (debug).
• logtarget: Logs actions into a specific file. The default value of /var/log/fail2ban.log puts all logging into the defined file. Alternately, you can change the value to STDOUT, which will output any data; STDERR, which will output any errors; SYSLOG, which is message-based logging; and FILE, which outputs to a file.
• socket: The location of the socket file.
• pidfile: The location of the PID file.
  
  
  
  
  The jail.conf file enables Fail2ban for SSH. In order to override this & edit its configuration, a jail.local file can be created, as before with the Fail2Ban.local file. Below are some           configuration options edited with nano, with explanations above the console window :

Finally, in var/log/fail2ban.log, with a simple 'cat' command, we can see a number of failed login attempts from 2 different ips, which resulted in their banning for a very short (obviously extendable) period of 10 seconds, showing it's now operational :                                                                              

Malware Traffic Analysis - A Very Special One

Networks being my primary locus of study, I'm delving into the excellent exercises on the malware traffic analysis blog (http://www.malware-traffic-analysis.net/2017/02/11/index.html). What follows is my attempt at solving one titled, 'A Very Special One'. For this excercise, we get a packet capture file of network traffic during the incident occurrence, & an IDS alert to help us figure out what's going on. My initial speculations follow :



Multiple ip addresses are masked under the same MAC address, a cisco device, and 10.3.14.134 begins continuously sending TCP packets of byte-size 54 to these addresses. Both 10.3.14.254 and 10.3.14.1 appear to share this MAC too...10.3.14.254 is the device which begins with this MAC...it is soon adopted by 10.3.14.254 which begins acting as a DNS server for 10.3.14.135...'Simons-Mac' is 10.3.14.135...as indicated by MAC address & dns broadcast traffic (MDNS)


Http traffic shows download of application/exe by 10.3.14.134 from 104.155.4.180. This triggered an alert in the IDS. One of the ips, 91.119.56.0 has triggered an alert in the IDS. This ip seems to have stolen the MAC address of the victims' gateway. Interaction with 54.87.5.88 also triggered the IDS, with 'Cerber Blockchain Query'. Upon inspecting http traffic from 217.12.208.17, an html page was reassembled showing ransomware infection and a bitcoin address to which it was requested money be sent :

1F7siW4UN4dmSjgeRhJBxSdNbaBeoCkSBV

User at 10.3.14.131 seems to have signed up for a bitcoin service which does the following, after inspecting http traffic to 186.2.163.47 :

 1. You need to refill your deposit Bitcoin wallet to restore all data<br><br>2. You can choose different exchange markets to buy Bitcoins (see Help)<br><br>3. System will automatically fill up your balance once transaction will be executed.<br><br>4. Use calculator to understand the exact amount, which will be filled to your account. Obviously this is to pay off the ransomware...but wasn't it 10.3.14.134 that was infected? I'm guessing that 134 is the kid's computer, and 131 is the parent angrily agreeing to pay...


With some filtering & by displaying some of the traffic in html format, what I did find for sure was that, the 10.3.14.131 host appeared to be the victim of a redirection (302) which may have lead to its infection of a ransomware known as Spora :







The infection of 10.3.14.131 was evident by the reassembled page I later found asking for bitcoin payment, as it happens, this host had actually viewed a compromised website known as 'Holiner Group', which caused the redirection :





Not only was this host a victim though, as 10.3.14.134 was also at the receiving end of a ransomware, albeit
a 'Cerber' one. The following three images show firstly the downloading of a suspicious exe file believed to be the cause of infection, and a webpage subsequently viewed by the user informing them that their files have been encrypted and payment is required to rescue them :
















All in all, a lot of fun! Finally, here are some links to the malwarebytes blog detailing both the Spora & Cerber malware variants :

https://blog.malwarebytes.com/threat-analysis/2017/03/spora-ransomware/
https://blog.malwarebytes.com/threat-analysis/2016/03/cerber-ransomware-new-but-mature/

An HTTP Proxy with Squid

I began this project with the intention of using a linode VPS as a proxy, which has a separate public ip than my home address (obviously). However since this didn't originally function properly due to a lack of foresight regarding iptables rules on both the VPS & firewall configuration on the windows host using the proxy, I switched to having a virtual machine, kali, run the squid proxy. We'll begin with the initial configuration on my VPS, with the steps taken from Linode's instruction page (https://www.linode.com/docs/networking/squid/squid-http-proxy-ubuntu-12-04) :


After the installation, we begin with a quick backup of the original config file :




























Squid has a large config file, so we skip to the end and add two rules, adding a client with a local ip address, and then enabling http access, thereafter restarting squid for the changes to take effect :




























In order to anonymize the ip of the host using the proxy, additional rules can be added to the configuration file, under where we inputted the previous two. these are chronicled on Linode's site :
































Under the 'advanced' tab of the Pale Moon browser's options, the browser is set up to use the proxy just established. However as mentioned before we run into trouble & it fails to work :




























During a later try, I instead routed traffic through a kali VM on my local network, which was set up with squid (ip addr = 192.168.178.60). My windows machine had two new rules added to its firewall configuration & the kali VM had its iptables edited to allow outbound connections. The packet capture shows the vpn in use (traffic moving from .34 to .60 & outbound). First, the firewall rules for our windows host using the proxy :













Now, we allow outbound connections on our virtual machine running squid :





















As before, the Pale Moon browser was configured to use the new proxy. Interestingly, a look at activity on network interfaces using wireshark on the windows host showed zero activity while I was actively browsing websites :



























In order to view the traffic information, I had to run wireshark on the virtual machine running the squid proxy. In spite of some sites being met with a 403, I could access a number of other websites, with the corresponding traffic showing up in the pcap file :

Auditing the VPS Gorgonite Castle With Lynis

Since I've been busy with assignments & exam preparation, this will be just a brief post on a useful system auditing tool I've used before on a VPS I rented.

From the wikipedia :

'Lynis is an extensible security audit tool for computer systems running Linux, FreeBSD, macOS, Solaris and other Unix-derivatives. It assists system administrators and security professionals with scanning a system and its security defenses, with the final goal of something called system hardening.'


Lynis is great & can provide a wealth of information about points in a system which could pose as issues in the realm of security. Running it on my VPS gave me a comprehensive report on its configuration status. I was hesitant at first to produce this here, but upon proper consideration, my linode has since had this specific setup wiped from the drive.

Lynis begins its report with some OS information, & directories to log & report files :






































Next, lynis checks system tools, boot loaders , services & kernel information and configuration :














































































































For the following image, settings for Users & Groups  are displayed, with a 'suggestion' marker beside a few parameters. Recommendations for system hardening related to these will be displayed at the end of the audit, a great feature. Following this, lynis finds 5 valid shells on the system, and whether or not these are vulnerable to a number of CVE's :








































A wealth of other information on system vulnerabilities is subsequently provided & their inclusion here would result in a lengthy tome. The ability to export auditing results to a custom location means that information can be reviewed at a later time instead of just in-shell. Lynis is available in these two places :

https://cisofy.com/lynis/

https://github.com/CISOfy/lynis