IoT, the importance to secure your connected infrastructure

This week I’ve read a good article on a French IT News website (Zdnet FR) regarding a Cloud provider / ISP that has been victim of a major DDOS attack. This time, the devices that flooded OVH (French ISP/ Cloud Provider) servers were not computers but CCTV cameras.

Wouaaahhh!! πŸ™‚ πŸ™‚ New kind of attackers?

Yes indeed, but it was predictable!

But before going further, the best option is to permit you to read the source article:

Zdnet FR: DDoS attack against OVH

Sorry, for those people who don’t speak French but here is a quick extract from the CTO of OVH that will help to understand the situation:

zdnet_ddos

What about the context?

Since several years ago, we saw an exponential emergence of connected devices or smart devices, it started with phones, TV and now, almost everything is smart:

  • SmartPhones
  • Smart TV
  • Smart Fridges
  • Smart Watches
  • Smart Cars
  • Smart blabla …. πŸ™‚ πŸ™‚

The announced arrival of all these devices pushed ISP to adopt IPv6 because they received directly Public IP when they’re connected to mobile carrier via 3G, GPRS, 4G,…

The fact that all these devices can get directly public IP, expose them to outside world and of course to hackers.

For this new generation of fully connected devices that represent a new ecosystem, marketers found a bright new acronym: IoT (Internet Of Things).
This new ecosystem is the new playground of hackers as they represent an impressive source of compute power and network bandwidth for massive DDoS.

The weak point of most of these devices is that the security has been left behind during the development because implementing high-level of security is a cost generator and competition to get the lowest price of the market is very aggressive.

As a technologist, I’m happy about the advantages some of these devices can afford us but unfortunately there’s a drawback: The security-How these devices are secured by their manufacturers?

As system administrator, I’m forced to notice that the security is not a top priority when all these devices are implemented. That’s why we need to stop security breaches before they reach those devices to prevent the OVH scenario. But this is not the worth scenario.

We can imagine that instead of flooding a 3rd party, it steals our personal data which can seriously impact us badly.

 

What this scenario teach us?

In today’s world securing connected devices (smart devices, IT infrastructures, Private and Public Cloud) is becoming more and more complex. At firewall level, we cannot just open and block ports as now the hackers try to find security breach at OS and application level. Nowadays, even user identity is compromised which is one of the most damageable security issue a company can live today.

In my consultant job, a big challenge when I’m facing customers for the implementation of security is the budget.

What I’ve often heard about new firewalls, centralized Antivirus Solutions, Antispam Gateways and so on:

  • The firewall you propose is too sophisticated for the size of our company. We are not a bank
  • Are you sure, you’re not exaggerating the risks?
  • We have a free version of a named antivirus solutions, everything seems nice, why we should pay?
  • In case of data loss we have a backup solution!
  • Do you have some products that afford me central monitoring, efficient anti-spam solution, protect my network perimeter efficiently for the lowest cost. We have tight budget.

All of these arguments make me confident that they don’t realize how much they’re exposed. Sometimes, they realized after their lost their data because they never tested their backup before the issue.

As I explain to customers, potential customers, more devices you have connected to Internet, more your surface attack is important. The damages can be more than the price of a new firewall with a full UTM suite. The risks are not limited to the enterprise perimeter but also at home where the security measures are most of the time very limited or nonexistent.

Fortunately for most of the people, the law is 2 or 3 wars behind the IT security world.
When I say fortunately, I’m thinking about the owners of devices infected by a botnet participating in DDoS attack. For the moment, concerning the law, nothing is planned here in Belgium, France. If you have more info about this topic feel free to comment πŸ˜‰

Only the hacker is punished, but when he is identified, most of the time, the guy was acting alone and generated a DoS and not a DDoS attack.

Maybe the day the law will generate fins against the infected devices participating in DDoS attacks, the mentalities will change and people will secure their infrastructure (even at home).

It’s just a thought, I’m not for, I’m not against this thought :-). It’s just an analysis !!!

My conclusion.

In each IT infrastructure, security should be design as a basement not as an option.
As the user in the enterprise needs to be more and more mobile, more devices he is susceptible to use, more the risks are present.
The budget should not be a brake as the risk and its consequences are real.
Don’t hesitate to buy a good antivirus on your smartphones, when you host risky devices like CCTV camera don’t forget IPS, restrict the number of hosts from where they’re reachable. When hosting e-commerce think about WAF and DDoS counter-measures.

All of these measures will save your money on the long term view.

 

 

Advertisements

How to Diagnose Traffic issue between 2 hosts with a Fortigate Firewall?

Context of a real-life scenario:

For one of my customers, I needed to configure strict Firewall rules between VLANS. In VLAN A had an Exchange Server and in VLAN B, a Veeam Server that needed to backup the Exchanger server VM.

Each time I tried to run a backup of the Exchange server Veeam returned me a network error (RPC Unavailable). Even if I authorized the predefined RPC service in the Firewall Policy Rule, it didn’t work.

The best thing to permit understand what’s going wrong is to use built-in sniffer of the Fortigate Unit. Depending of the Fortigate Unit model you have the sniffer utility is available in the GUI or via CLI or both. More your unit is near from entry level model, more you will need to run advanced tools from CLI.

In all cases, my preferred way for Troubleshooting is the CLI. Let’s begin with it.

Run the Fortigate Sniffer utility from the CLI:

  1. How to access the CLI on the fortigate unit?

You have 2 options:

  • in the GUI interface (Yes Yes!!! from the GUI πŸ™‚ )
  • run an SSH session from any SSH client (Putty stays the most current and most used)

For more information on Putty, please go on the official website (Putty Website)

If you want to keep a log of what you’ve done and be able to display a big quantity of information, I strongly recommend you to use Putty instead of the CLI integrated by default in the GUI interface.

From the GUI

  1. open the URL of your firewall
  2. Login to the web interface
  3. click on CLI Widget as show here
fortigate-clifromgui
WebInterface

From the SSH client

Prerequisite: Enable SSH Server on the Interface of the Fortigate Unit from where the SSH Client will run.

Example: Your server where Putty is installed has IP 10.0.0.23 and your Fortigate unit has an IP of 10.0.0.1. Be sure to enable SSH on the interface where the Fortigate has its IP 10.0.0.1 via the GUI

fortigategui_enablessh

Procedure:

  1. Run Putty or any other SSH client from your server
  2. Connect to the Fortigate by entering its IP
  3. Type your credentials
  4. Launch a sniffer session by typing the following command:

diag sniffer packet <interface_name> <β€˜filter’> <verbose> <count>

in real case scenario here is what you should type if you want to see the traffic between host A 192.168.0.229 and host B 172.17.0.35

diag sniffer packet any ‘src host 172.17.0.35 and dst host 192.168.0.229’ 1

Command Explanation:

diag sniffer packet: Is the sniffer running
any: is the interface name on which the sniffer should listen for traffic that needs to be monitored. In my case I’ve chosen ANY as the hosts are located on 2 different interfaces.
‘src host 172.17.0.35 and dst host 192.168.0.229’: is the filter. I want to see only the traffic between host A & B with no protocol filtering
1: is the verbose level of the sniffer

Note: Concerning the verbose level of the sniffer you have 6 levels. Choose the appropriate one depending of the issue you need to resolve

Verbosity levels:

1: print header of packets
2: print header and data from IP of packets
3: print header and data from Ethernet of packets
4: print header of packets with interface name
5: print header and data from IP of packets with interface name
6: print header and data from Ethernet of packets with interface name

Output:

144.718932 192.168.0.229.64314 -> 172.17.0.35.135: psh 3914262130 ack 63685806
144.718952 192.168.0.229.64314 -> 172.17.0.35.135: psh 3914262130 ack 63685806
144.720622 192.168.0.229.64316 -> 172.17.0.35.11500: syn 2197328095
144.755747 192.168.0.229.64314 -> 172.17.0.35.135: ack 63685886
144.755805 192.168.0.229.64314 -> 172.17.0.35.135: ack 63685886
144.755825 192.168.0.229.64314 -> 172.17.0.35.135: ack 63685886
147.708245 192.168.0.229.64316 -> 172.17.0.35.11500: syn 2197328095
153.708268 192.168.0.229.64316 -> 172.17.0.35.11500: syn 2197328095
174.760978 192.168.0.229.64314 -> 172.17.0.35.135: rst 3914262210 ack 63685886
174.761066 192.168.0.229.64314 -> 172.17.0.35.135: rst 3914262210 ack 63685886
174.761090 192.168.0.229.64314 -> 172.17.0.35.135: rst 3914262210 ack 63685886
174.761393 192.168.0.229.64315 -> 172.17.0.35.20553: rst 780143497 ack 3214492343
174.761460 192.168.0.229.64315 -> 172.17.0.35.20553: rst 780143497 ack 3214492343
174.761481 192.168.0.229.64315 -> 172.17.0.35.20553: rst 780143497 ack 3214492343
188.353298 192.168.0.229.64313 -> 172.17.0.35.445: rst 2393120380 ack 3596781657
188.353391 192.168.0.229.64313 -> 172.17.0.35.445: rst 2393120380 ack 3596781657
188.353414 192.168.0.229.64313 -> 172.17.0.35.445: rst 2393120380 ack 3596781657

In my case, I could determine that some RPC ports and CIFS ports were blocked as the firewall returned me some rst (reset from source commands)