This is Yaseen Zafar. DevOps Engineer from Integrated Dealer Systems. We have multiple customers whose servers are hosted on multiple locations from Canada to America. They are hosted on premises (i.e. they are not currently on Azure). Though we are currently using Microsoft Azure Log Analytics to get some insights of the Windows and Linux Servers. So far it has been a very good experience.
Actually I wanted to know if there is any solution available on Azure that can show me firewall related logs, rules, IP and port details ingested from the Windows and Linux Servers that are hosted on premise location.
Best Regards.
Yaseen Zafar
• Yes, there is a way through which you can forward your on-premises firewall logs to Azure log analytics workspace since almost every firewall device has syslog functionality in built in it to forward logs to a log management server on a specific port. Thus, similarly, on-premises firewall logs that include all data collected related to the traffic passed inbound and outbound to the environment can be forwarded to a Linux virtual machine which then can be forwarded to the Azure Log Analytics.
• Syslog is the cross-platform equivalent of Windows Event log which can be leveraged by forwarding these syslog messages to Azure Log Analytics through Linux machines. This linux system should be deployed as a virtual appliance (VM) in on-premises or in Azure cloud such that the syslog-generating firewalls can communicate directly with them. The Linux forwarder can be on-premises physically near the firewall, or it can be in Azure or another cloud, connected to your firewall by an IPSEC tunnel. The Linux computer has a Log Analytics agent configured to communicate with your Log Analytics workspace.
• Once your firewall is connected to Azure Log Analytics you should create a custom dashboard solution that suits your needs. You will have excellent visibility and gain a lot of insight into your firewall operation by studying the collected and indexed syslog data in the Log search feature of the Azure portal. You will notice which types of data your firewall is delivering and learn what to monitor to meet your business and security needs.
Please find the below links for more information on how to configure the Linux virtual machine as a syslog forwarder and how to implement the above stated solution as a whole: -
https://blog.johnjoyner.net/connect-your-firewall-to-azure-log-analytics-for-security-insights/
https://accountabilit.com/azure-log-analytics-best-syslog-destination/
Related
I am working with Windows IoT core on a Gateway to Run some Edge services, all the ways to connect to the IoT core device is locally, so basically you have to be on the same network, Any possible way to access the device via the internet?
It is a generic network question. There are a two options, depending if this is for private or commercial grade use.
Configure 'port forwarding' on your router.
Using cloud service which have a published IP address. Your device 'publish' on a known location and your clients access a known place. For example, you can use Microsoft Azure IoT Hub. The purpose of remote connection is nothing more than managing the device. You can use Azure IoT Device Management.
On Google Cloud Platform, how can I register/validate my Microsoft Windows machines, in a walled VPC?
For security reasons:
-Every connection goes through a proxy;
-Every Windows machine is not allowed to have an external IP address;
For money reasons:
-No Windows KMS relay server.
I read:
https://cloud.google.com/compute/docs/instances/windows/
https://cloud.google.com/compute/docs/instances/windows/creating-managing-windows-instances
https://cloud.google.com/compute/docs/instances/windows/getting-support-for-windows-instances
Unfortunately, an external IP address is required to activate a Windows instance with Google’s KMS servers. You cannot turn off the external IP for a Windows VM on Google Compute Engine as it requires re-activation every 30 days, however, Google is actively working on a fix to address this issue and to make it so you can activate against VMs with internal IP only.
For the interim, if you wish to restrict outbound communication you can set up egress firewall rules as follows:
Create a deny egress firewall rule for the IP range 0.0.0.0/0 on all ports
Create an allow egress rule to the IP 173.255.119.204 and the port tcp:1688. This will allow the VM to talk to the KMS Servers.
The allow rule should have a higher priority ( i.e. a lower number) than deny rule.
As mentioned earlier, there's a feature request to that is still in development and being tested internally. Unfortunately, there's no ETA at this time.
That being said, I would recommend that you follow the Google Cloud Platform Blog page, so you are aware once the feature is released, or use the above-provided workaround.
Finally, should you decide to continue using Windows OS without activation, keep in mind that the following may occur as per Microsoft Product Activation article in Wikipedia
Windows Server 2016 has a 30-day grace period and if not activated, the operating system may go into what is called Reduced Functional mode which means that certain functionality will be disabled, you may also see a watermark showing the edition of Windows as not activated.
Access to all Windows Updates with confidence that your Windows software has the latest security and reliability enhancements may be removed.
You will be prompted every time you log in to Activate, as well as receive periodic prompts to activate your software.
I hope this information is helpful.
I have a scenario where I have a Windows VM in windows Azure that needs to connect to an external customer network (and connect to a database that is not in Azure).
This traffic is uni-directional in that it is only my VM that needs to connect to the customer's databases and not the other way around. Site to site is managed on Azure, which I cannot really test locally.
Conceptually, connecting to the customer's network via a point-to-site VPN seems more suitable (by creating the VPN connection in Windows itself via the network config).
The customer prefers site-to-site even though they don't need to connect to my VM. Am I missing something?
In point-to-site, you have to connect to the network you want to access manually. Usually, if you log-off or restart the workstation it loses connection, and you have to reconnect every time. It's common to use this type of VPN when we are working remotely, and we need to access our company assets. The channel is bi-directional, but it's 1-to-many.
Site-to-site is used when you want to connect two networks and keep the communication up all the time. It's also bi-directional, but it's many-to-many and stays up no matter if your server/workstation is running or not because the connection is established through a network gateway and not from the computer operating system.
In Azure, the Virtual Network Gateway is the platform providing both functionalities. You can configure site-to-site to connect to your customer network. If this network is not running in Azure, they usually have an appliance to establish dedicated tunnels. As long as it supports IPsec IKE, you are good to go.
If you are using the VM in Azure as a workstation, then point-to-site may be enough, but if your application needs to get data from the customer database automatically with or without someone logged in the VM, then site-to-site is a better approach.
A better explanation can be found here
this is the first time I am trying to host at Iaas level using microsoft azure. I have created a VM, microsoft server 2012. But I cannot access the VM using the DNS name.
Based on the content of the comments, I see three things that could be wrong
1) Apache is not listening on the external IP of the VM
2) Firewall is not configured to allow for access
3) Since you mentioned DNS, is that the *.cloudapp.net hostname or a custom DNS? If it's the latter, maybe it isn't distributed yet or misconfigured?
Which of these did you check already? Then we can guide you through the remaining ones.
Azure Connect is a service found on the older Azure.com portal and allows connectivity between on-premise and cloud servers/roles/resources. It creates a virtual IP (overlay) network - pretty much a VPN.
Azure Virtual Network (found on the new Azure portal) is ALSO touted as a VPN solution for also the same purpose however the configuration seems a lot twisted (although with a pretty UI).
I'm confused how these two product stack up against each other. Googling and searching MSDN didn't reveal much information either.
What are the differences between them and the target use-cases? Are they expected to be merged into one product down the road?
The use case for us is a WebRole that's running as a cloud service, whose REST/Web API services are consumed by machines on a private network. Azure Connect or Azure Virtual Network would (should?) provide the underlying connectivity between them.
Azure Connect allows users to connect Azure applications with on-premise servers in a super simple and quick way. It does not require VPN devices, it does not require user to have network knowledge, it does not require/assume user have access to network infrastructure (e.g. ability to configure the firewall at company's edge firewall). You express your connectivity intent (e.g. Azure service x should connect to a set of machines (machine group) y on-premise) in the management portal, Azure Connect does the rest for you. It is also very flexible in that you can change the network and connectivity policy at any time via the portal, without requiring redeployment of your app or any change on-premise. e.g. you can make Azure service x to connect to machine group z on-premise instead of y, once you make that change in portal, the rest happens automatically, machines in y are not long accessible to/from Azure. Azure Connect uses endpoint software to manage all the network connectivity for users, so you do have to install endpoint software. But it supports many different automatic deployment options including using Microsoft Update.
Azure Virtual Network allows user to extend part of their on-premise infrastructure to your Azure virtual network via standard site-to-site IPSEC connection. You must have an internet facing VPN device at on-premise side. The solution also assumes you have network knowledge - you will be asked to specify the network address range you will be using at both Azure and on-premise sides, you will must launch a VPN gateway at Azure side and manage the IPSEC connection. It does not require install endpoint software on servers, you are responsible for setting up routes to route the traffic from VPN device to servers and vice versa.
The two technologies complement each other, they are suitable for different scenarios.