As you probably know, most of IT providers (Microsoft, VMware, Cisco, and many others) that delivers certifications with a limited lifetime. VMware is not an exception.
The main reason invoked everywhere: The rapid change of the technologies put in places.
Recently, I’ve passed my VCP6-DCV as I needed to renew my VCP5-DCV before its expiration. It’s a good way to stay in the train and prove to customers and yourself that you know what you’re talking about.
BUT to achieve this statement, you need to prepare yourself seriously, I mean:
- Read official Study guides
- Read un-offcial Study guides
- Read Documentation and books related to the technology
- Train yourself with the practice exams delivered with the official VMware Study Guide
- If you don’t have hands-on experience with vSphere 6, build your lab or use VMware Hands-On labs
After passing my exam, I can say you that this exam is not the easiest one. It’s a good mixture of memory questions and practice questions. For some questions, you need to put in practice what you’ve learned from the theory (which are my prefered).
My personal preparation:
- VMware Press: VCP6-DCV Official Cert Guide
- Sybex: Mastering VMware vSphere 6
- Vlandan.fr: Vladan VCP6-DCV study guide (Vladan made an amazing job with this study guide! Thanks to him)
- Real-life experience (thanks to my job 🙂 )
This is the worst error because your browser is unable by default to return you an error code more detailed about the issue that could put you on a track.
After much research, I enabled debugging and I read more consistent IIS logs. These logs in matters related to me the error 500.19. Ahhh !!! Finally a track.To get more details on this error 500.19, I launched an HTTPS connection on the same server and here’s what it returned me:
IIS is constructed in the following manner:
The default web content: C:\inetpub\wwwroot
The IIS Engine: C:\%windir%\ system32\Inetsrv\
The global configuration file: C:\% windir%\system32\inetsrv\config\ ApplicationHost.config (regains all your IIS configuration)
The websites hosted configuration file:%PhysicalPath_website%\web.config (specific configuration website)
The AppPool related to hosted website:%PhysicalPath% AppPool (the AppPools load the complementary modules in IIS and for the proper functioning of Apps-There are AppPools as for SMEX Trend, Exchange, and many others.)
According to the error returned, the problem could come from two main files:
• The web.config Site
• The ApplicationHost.config
To ogo further in the dignostic, I based my investigations on the following points:
With this page, I knew which module was the guilty one. With the error code returned by the webpage, I was able to define the origin of the issue with my friend Google 🙂
I could find what I was looking for via this website : https://support.microsoft.com/en-us/kb/942055
The “web.config” file being very limited with its content, It was an evidence for me that there wasn’t any references to the « DynamicCompression » module. So, I edited the file “ApplicationHost.config” file and I started a search on the concerned module.
Here the guilty line. The one that gave me headaches!
<scheme name=”xpress” doStaticCompression=”false” doDynamicCompression=”true” dll=”C:\Program Files\Update Services\WebServices\suscomp.dll” staticCompressionLevel=”10″ dynamicCompressionLevel=”0″ />
The Exchange website and all its loaded modules called a DLL file that was not there anymore.
After deleting this line, saving the modifications in “ApplicationHost.config” and finally applying an “IISreset” command, everything came back!
So, if you are in a similar scenario than me, Exchange 2013 that is no more functional after removing WSUS role on the server, take a in the “ApplicationHost.config” file and check any references related to WSUS.
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:
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:
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:
- 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 !!!
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.
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:
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
- open the URL of your firewall
- Login to the web interface
- click on CLI Widget as show here
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
- Run Putty or any other SSH client from your server
- Connect to the Fortigate by entering its IP
- Type your credentials
- 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
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
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
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)