Five years ago …

Five years ago I opened this blog to write about networking and security, and because I wanted to improve my writing skills and this was a good idea to be updated about technologies, standards, protocols, attacks, etc. In addition, I’ve been writing in English language for two years and I want to keep writing in English language because I don’t want to forget this language. Who knows if I’m going to be writing in French language in the future because I really love languages and I've started to learn French as well.

What have I done in the last year? I’ve done many things, as always, and I like it. I’ve been reading, studying, testing and teaching new datacenter technologies like Shortest Path Bridging (SPB), Virtual Extensible LAN (VXLAN) and Software-Defined WAN (SD-WAN). On the other hand, I’ve also installed, configured and/or supported load balancer appliances, SIEM appliances and firewall appliances, even I’ve been at FortiXpert (again) and ForoCiber conferences. Everybody has heard about WannaCry, which was just another cyberattack, and the Apache Struts Vulnerability, that I analysed and read about them to know how they work. Troubleshooting network performance issues and improving SSL VPN performance with DTLS are another two things which are improved my knowledge about networking, as well as studying the DTLS protocol for configuring SSL VPN over UDP. In addition, I’ve also been reading a lot about CIA hacking tools, the Security Directives for the EU, the cyber rights from the new GDPR, or books like the Steve Jobs biography and the truth about you future. So much reading and studying have done that I achieved the level of F5 Certified BIG-IP Administrator. What’s more, once again, I’ve been abroad in a workcamp for two weeks, working for free, in a small town of Czech Republic where I met interesting and kind people. Finally, I would also like to highlight the speech at CUM University where I returned to speak about security.

An overview about the most widely read posts in the last five years is the next:

With regard about from where the blog is visited, we can find the statistics next:

Last and not less important, I would like to thank to everybody who read this blog and support me because they are the main reason why I have already written 244 posts with almost 180000 views. If someone has something to say for improving this blog, it is welcome.

Regards my friends and I hope to see you again back in September after a great holiday.

Throw away your firewalls!!

I usually install firewall appliances with UTM (Unified Threat Management) features to protect the network and the information of our customer against virus, malicious websites, spam, attacks, etc. Most of these firewalls are installed in the perimeter of the network and most of them have VPN capabilities as well. Therefore, SSL VPN or IPSec VPN are used to connect to the organization from untrusted networks like coffee shops, airports, hotel, etc. Actually, this is a good way to give to remote users access to internal services.

However, Google wants to break the schemas, architecture and design that we are used to seeing with a new concept called BeyondCorp. They are working with a new approach to enterprise security where everything is untrusted, also called Zero Trust, and where access control are shifted from the perimeter to individual devices and users allowing employees to work securely from any location without the need for a traditional VPN. As a result, employees don’t have to install any VPN client, which is a great benefit, and internal services are no longer internal services but they are accessible from any location, even from Internet.

BeyondCorp components and access flow

 

As we can see, this new approach has many components. As it trusts in individual devices and users instead of networks, there are two important databases, device inventory database and user/group database, where trustworthy users and devices are stored. However, the trust of a user or device can change over the time, for example if the device doesn’t have applied the last OS patch, the device doesn’t have the last antivirus signatures or the certificate is in the blacklist, that device is not trustworthy and it’s moved to untrusted network. All of these tasks are done by the trust inference component, the certificate issuer and the pipeline. On the other hand, the access control engine along with the access proxy provides service-level authorization to enterprise applications on a per-request basis. This new security model also has a Radius component to move users and devices from one VLAN to another inside Google buildings, and a Single Sign-On component for user authentication to all applications.

This new security approach of protecting our corporate security perimeter without firewalls has to publish all our internal services to Internet. As we can see, Google has resources like codereview.corp.google.com domain name registered in public DNS with a CNAME pointing to the access proxy:

DNS Intranet resources

Moma is the Intranet of Google employees and lots of resources are accessible from Internet through the access proxy with BeyondCorp:

MOMA Single Sign-On

From my point of view, firewalls aren’t going to disappear yet but we’ll go to the 4^th generation of firewalls where we’ll configure firewall policies by users and devices easily instead of networks because any location and network will be untrusted. In addition, we’ll have better integration between all IT devices (servers, desktops, BBDD, WiFi, switches, mail, web, firewall, etc) for better security protection such as Fortinet is doing with his Fortinet Security Fabric.

Regards my friends and remember, the world is changing very fast and the IT security as well.

Reverse Engineering Malware

I’m used to work with network devices and security systems to improve network performance and protect the information. However, it seems I’m specialized to the networking and security fields but, in fact, there are lots of subfields inside network and security like forensics, reverse engineering, laws, pentesting, auditing, etc. Therefore, I’m not specialized yet to any field but I would like to write about reverse engineering this week, which is an amazing and very technical field that only few people know how to do it very well. Of course, I’m not one of them. I’m newbie in this field.

Reverse engineering is a field mainly for researches and antivirus companies who are interested in finding exploitation techniques, discover new encryption methods or finding encryption keys. They are also interested in finding new de-obfuscation techniques and investigating C&C communications. Therefore, they know how to do a completely reverse engineering with techniques such as static analysis, dynamic analysis, automated analysis, even manual analysis as well. Thus, knowing and picking the right tools is very important for reverse engineering.

There are many reverse engineering tools, some free and others commercials. For instance, the most popular static analysis tool for reverse engineering is IDA Pro, which is useful for Hex rays decompiling, but if we are newbies, we can use Radare2 for free and Linux commands like strings, file or otool. However, there are many more static analysis tools like PeiD, PEStudio, PE32, etc. On the other hand, there are many dynamic analysis tools like Immutiny debugger, OllyDbg, Sysmon, Regshot or the popular Wireshark/TCPdump.

IDA PRO

 

Sandboxing is another kind of dynamic analysis tool very popular and useful today. There are free online sandboxes like Malwr, Hybrid-analysis, DeepViz or VirusTotal, and there are also commercial sandboxes like FortiSandbox in the cloud or as an appliance on-site. Of course, local sandboxes, or on-premise, are better than online sandboxes because it is faster to upload the file to the sandbox and, as a result, we’ll have the results faster too. In addition, local sandboxes are more customized than online sandboxes because we can choose the language of the operating system and other kind of variables for better analysis.

FortiSandbox

If we don’t have a deep knowledge about malware analysis and we don’t have enough resources either, we can use Cuckoo Sandbox for reverse engineering malware. It is an automated malware analysis system which is able to analyse any malicious file under Windows, OS X, Linux and Android. Cuckoo is a free sandbox and 100% open source that easily integrates with our existing frameworks and storages with the data we want, in the way we want, with the format we want. Therefore, it’s highly recommended to have a Sandbox in our infrastructure then Cuckoo Sandbox is better than nothing. It’s another barrier for better security.

Cuckoo Sandbox

There are many others tools which help us to know what is happening in our infrastructure like OTX, which is the Collective Intelligence Framework of Alienvault and where we can subscribe to Pulses to exchange indicators of compromise with our USM or OSSIM. On the other hand, we can also search for IP or domain reputation in online services like FortiGuard.

OTX

Regards my friends and remember, reverse engineering malware is a subfield inside the security field which should be taken into account to protect our information.

Decrypting DTLS traffic with Wireshark

I’ve written about Improving SSL VPN performance with DTLS recently thus I would like to write about how-to decrypt this traffic with Wireshark. DTLS is a protocol used for encrypting traffic over UDP, which is often used for SSL VPN tunnels, whereas TLS is a protocol used for encrypting traffic over TCP, which has worse performance for SSL VPN tunnels because it encapsulates TCP over TCP and, as a result, we can often encounter retransmissions and packet loss. Therefore, cryptographic knowledge is important to understand the steps needed to decode DTLS traffic.

First, we have to ensure the use of a Diffie-Hellman Ephemeral (DHE/EDH) or RSA Ephemeral cipher suite is not negotiated between server and clients because Wireshark isn’t able to decrypt data where ephemeral ciphers are used. Accordingly, I’ve disabled DH, DHE, ECDH and ECDHE cipher suites from my SSL VPN server to be able to decrypt user traffic.

Control the cipher suites that can be used by an SSL VPN

 

The cipher suite negotiated between SSL VPN server and clients can be checked in the initial DTLS session establishment. In other words, the Client Hello and Server Hello exchange into the handshake protocol. In addition, these initial packets are needed for Wireshark to get the public key used by clients for data encryption.

Cipher Suite

 

Once we have, or Wireshark has, the public key, we also need to get the private key to decrypt data traffic. If we manage the SSL VPN server, there are many ways to get it. For instance, next, we can see how-to get the private key from a SSL certificate of a FortiGate appliance, which should be saved as a file from -----BEGIN PRIVATE KEY ----- till -----END PRIVATE KEY-----.

Exporting private key from a SSL certificate

We should save the private key, for instance as private.key, for importing it into the DTLS RSA keylist of Wireshark. Besides, we’ll have to write the IP address of the SSL VPN server, what server port is listening for DTLS traffic, and what kind of traffic is being encapsulated into DTLS.

DTLS RSA Keylist

 

We already have almost everything, we just have to test it and check if DTLS traffic is decrypted. Next, we can see how DTLS traffic is decrypted when I visit a webpage like www.davidromerotrejo.com from a client connected to a SSL VPN server with DTLS support. Actually, we’ll be able to decrypt everything inside the SSL VPN tunnel and not only HTTP traffic but everything else.

Decrypting DTLS packets

 

If we work as security engineers of a company and we manage SSL VPN servers or firewall appliances, we can use this technique to decode encrypted traffic for troubleshooting propose. On the other hand, there are SSL Inspection architectures where firewall appliances are able to decrypt and encrypt traffic, like a Man-In-The-Middle (MITM) attack, with the aim of analysing everything to block malwares and attacks. This can be a big responsibility, and a powerful tool, for security engineers, who should be monitored.

Regards my friends and remember, encrypted traffic can be decrypted if you are in the middle; be careful with your responsibilities.

Improving SSL VPN performance with DTLS

Networks are increasingly faster, mainly, because the method of access to the medium is faster than ever with up to 100 Gigabit Ethernet today. However, protocols are improving too as we saw with Multipath TCP or Moving the Web from TCP to UDP but, today, I would like to highlight how to improve VPN (Virtual Private Networks) because I've already written about VPN Security, Overlay Technologies like PBB, SPB or VxLAN, and Metro Ethernet Services as well like E-Line VPWS and E-LAN VPLS, but I've never written about performance and improvements in Dial-up VPN for remote users.

Using TCP for making SSL VPN isn’t already a good idea because TCP was design for running over unreliable or slow base connection where it is useful with segment retransmission and flow control through windowing. However, if we configure a SSL VPN over TCP and we send TCP traffic to the remote side, we could get a poor performance due to the fact that we are encapsulating TCP over TCP and, as a result, there will be mismatching timers between the upper and the lower layer TCP connection, which will increase retransmission and losing packets.

SSL VPN over TCP with TLS - Stack

How can we improve SSL VPN performance? As TCP over TCP is a bad idea, we can use UDP for VPN tunneling with the DTLS protocol for security. In this way, traffic is protected like the traditional SSL VPN with TLS but, this time, we’ll use DTLS for communications security and UDP for improving networking performance. As a result, the lower layer doesn’t worry about segment retransmission and flow control, because this task is carried out by the upper layer, thus the throughput and performance of the SSL VPN will be much better.

SSL VPN over UDP with DTLS - stack

FortiOS 5.4 and the new FortiOS 5.6 already support SSL VPN over UDP with DTLS to improve SSL VPN performance. If we want to configure it, we need to run the next commands by CLI.

Using DTLS to improve SSL VPN performance

 

Once we’ve enabled dtls-tunnel, the FortiGate opens the UDP port, as well as the TCP port, for SSL VPN.

Local In Policy of FortiGate

 

However, we’ll have to configure the FortiClient as well for using DTLS becuause it only uses TCP by default. If we want to use DTLS tunnels from FortiClient, we’ll have to download a backup configuration from FortiClient and change the parameter preferred_dtls_tunnel to 1. After changing this parameter, we’ll have to upload the configuration to FortiClient. Once this configuration is done, FortiClient will connect to SSL VPN using UDP with DTLS first and if it fails, FortiClient will connect to SSL VPN using TCP with TLS.

FortiClient Configuration

 

Next, we can see a traffic capture using TCP with TLS for SSL VPN.

SSL VPN over TCP with TLS

We can also see a traffic capture using UDP with DTLS for SSL VPN, which offers better performance for remote users.

SSL VPN over UDP with DTLS

 

Regards my friends. I hope you’ve enjoyed with this how-to and you’re planning to migrate to DTLS your SSL VPN.