While I’ve browsed the excellent TechCommunity article about custom connectors, until now I’ve used my own HTTP client implementation to implement connectors against Log Analytics HTTP collector.
All I can say that I am getting seriously spoiled by Logic Apps and the Data Collector Connector…
Br, Joosua
If you want to send data from NodeJS application to Log Analytics/Sentinel you can do it by using the HTTP Log Collector API.
Note: If your app is in Azure PaaS solution, you should check out AppInsights first before going to this route 🙂
There we’re some existing examples to do this, but I couldn’t get them to work in quick breeze. Due to this I did my own implementation with some key differences:
Signature generation part is done in two phases to improve readability
Function is bit different with callbacks and try catch logic added
Request Module will handle the Body Payload as non stringified
I did find, that If I sent the body payload stringified, it wouldnt match with the signature. To get the signature to match with the body payload, I added the request option json:true, and sent the non-stringified JSON payload.
The module to be imported
//https://nodejs.org/api/crypto.html
//https://docs.microsoft.com/en-us/azure/azure-monitor/platform/data-collector-api
//https://stackoverflow.com/questions/44532530/encoding-encrypting-the-azure-log-analytics-authorization-header-in-node-js
const rq = require('request')
const crypto = require('crypto')
const util = require('util')
function PushToAzureLogs (content,{id,key,rfc1123date,LogType}, callback) {
console.log(id)
try {
//Checking if the data can be parsed as JSON
if ( JSON.parse(JSON.stringify(content)) ) {
var length = Buffer.byteLength(JSON.stringify(content),'utf8')
var binaryKey = Buffer.from(key,'base64')
var stringToSign = 'POST\n' + length + '\napplication/json\nx-ms-date:' + rfc1123date + '\n/api/logs';
//console.log(stringToSign)
var hash = crypto.createHmac('sha256',binaryKey)
.update(stringToSign,'utf8')
.digest('base64')
var authorization = "SharedKey "+id +":"+hash
var options= {
json:true,
headers:{
"content-type": "application/json",
"authorization":authorization,
"Log-Type":LogType,
"x-ms-date":rfc1123date,
"time-generated-field":"DateValue"
},
body:content
}
var uri = "https://"+ id + ".ods.opinsights.azure.com/api/logs?api-version=2016-04-01"
rq.post(uri,options,(err,Response) => {
//return if error inside try catch block
if (err) {
return callback(("Not data sent to LA: " + err))
}
callback(("Data sent to LA " +util.inspect(content) + "with status code " + Response.statusCode))
})
}
//Catch error if data cant be parsed as JSON
} catch (err) {
callback(("Not data sent to LA: " + err))
}
}
module.exports={PushToAzureLogs}
//Add your other dependencies before this
const logs = require('./SRC/laws')
//define workspace details
const laws = {
id:'yourID',
key:'yourKey',
rfc1123date:(new Date).toUTCString(),
LogType:'yourLogType'
}
app.get('/graph', (request,response) => {
//not related to LA, this the data I am sending to LA
var token = mods.readToken('rt').access_token
mods.apiCall(token,'https://graph.microsoft.com/v1.0/me?$select=displayName,givenName,onPremisesSamAccountName', (data) => {
console.log('reading graph', data)
//LA object
jsonObject = {
WAFCaller:request.hostname,
identity:data.displayName,
datasource:request.ip
}
console.log(jsonObject)
//send data to LA
logs.PushToAzureLogs(jsonObject,laws,(data)=> {
console.log(data)
})
//return original response
response.send(data)
})
})
Once the data is sent, it will take about 5-10 minutes, for the first entries to be popping up
If /when you attach the Log Analytics workspace to Sentinel, you can then use it create your own hunting queries, and combine the data you have with TI-feeds etc
Happy hunting!
This blog post is all about Log Analytics workspace (later referred as LA) permission models which changed at May 2019. The options (at time of writing) for granting permissions are:
These new options gives more granular controls for granting permission to Log Analytics workspaces instead of old model. Anyway, I see still place for granting workspace permissions. It comes back to Log Analytics’ workspace design and organization needs. How operating teams, development teams, and security organization needs to access the performance and security-related events.
There are basically two approaches for Log Analytics design:
If you have chosen the centralized model then more granularity access controls might be needed and you can leverage more about new access control modes table (Resource centric RBAC & Table level RBAC).
The new access model is automatically configured to all workspaces created after March 2019.
Navigate to Azure Log Analytics and overview page where you can find ”access control mode” options for the workspace.
Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {$_.Name + ": " + $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions}
Access model can be changed directory from resource properties and verified from Activity log.
If Powershell is the favorite tool for changes here you go (code from docs.microsoft.com)
$WSName = "my-workspace"
$Workspace = Get-AzResource -Name $WSName -ExpandProperties
if ($Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
{ $Workspace.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
{ $Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $Workspace.ResourceId -Properties $Workspace.Properties -ForceThe scenario
Siloed Log Analytics workspace design is in use and operational team members needs to maintain Virtual Machines. In practical person needs to read Virtual Machine metrics and performance data from LA.
If new access model is in use members of the team can access the needed logs directly from the resource blade. They cannot see the LA at all because they don’t have global read access to the resource. If user browses to Azure Monitor the user can see logs he/she has access to.
When log search is opened from a resource menu, the search is automatically scoped to that resource and resource-centric queries are used. This means that if users have access to a resource, they’ll be able to access their logs.
Azure has two built-in user roles for Log Analytics workspaces:
Members of the Log Analytics Reader role can:
Nothing prevents from using built-in roles but keep in mind that these are top level permissions. If user has Log Analytics reader permission global read permission with the standard Reader or Contributor roles that include the */read action, it will override the per-table access control and give them access to all log data.
More granular controls can be achieved with Table level access in case its needed. If centralized Log Analytics model is chosen scenario it might be necessary to grant permissions to different teams to read data from LA tables. This can be achieved with Table level RBAC permissions.
With table level RBAC you can grant permissions only to needed LA tables depending on your needs.
If a user has global read permission (Reader or Contributor roles) that include the */read action, it will override the per-table access control and give them access to all log data.
If a user has access to specific LA table but no other permissions, they would be able to access log data through the API but not from the Azure portal.
Most cases I have worked with, multi-homing Log Analytics design has been used and workspace centric model is enough to satisfy the needs. If centralized model (as few LA’s as possible) would be in use new access model gives more granularity.
