This is something I’ve been meaning to write about for a while.
If you use pingdom for your monitoring, and you have a requirement to lock down your endpoints to a specific set of clients, you may have a painful job on your hands.
Some engineers I’ve spoken to have implemented a kind of proxy to forward pingdom requests through to their locked-down endpoints. Others rely on User-Agent detection to allow Pingdom probes through while denying other traffic.
In my case, I’ve implemented a powershell script that runs at intervals, checking Pingdom’s published Probe IP List and syncing it to my target Security Group. here’s how it’s done.
The very first thing you’ll need to do, if you haven’t already, is contact AWS Support and get your rules-per-group limit increased. By default, you get 50 (at the time of writing), and that’s not enough for this.
Then the code.
First up, you need a list of the IPs you want to whitelist other than pingdom. Not much use only opening your endpoint to the monitoring service, is it?
$whitelist = @(
"123.123.123.123/32",
"124.124.124.124/32",
"52.52.52.0/24"
)
And so on. You may want to store this differently, but for me it’s just straight in the script. For now.
When you have those, you need to grab Pingdom’s probe IPs from their API
$probeIPs = Invoke-RestMethod https://my.pingdom.com/probes/feed
Excellent. Now, the pingdom addresses aren’t in CIDR format, so you need to convert them to CIDR and add them to the $whitelist array you set up earlier. For that, you need a function that does pipeline input.
Function Join-IPs # pipeline function to append to an incoming array of strings
{
param
(
[Parameter(ValueFromPipeline=$true)]
[string]
$In,
[string]
$JoinTo = "/32"
)
process
{
return ("" + $_ + "" + $jointo + "")
}
}
And then you just stick that in your pipeline and get back an array of al the IP ranges that are meant to be in your security group.
$ranges = $whitelist += ($probeIps | select -expand ip | Join-Ips -JoinTo "/32" )
And there you have a list of all the CIDR ranges that are meant to be in your security group’s ingress rule.
My rule literally only opens one port – 443 – so if you have multiple ports, you may want to do this differently. It also does nothing to try and compress down multiple adjacent addresses into a single CIDR, so if you need that, you’re going to need to do a little extra work.
Now, we compare the sec group’s existing rules, and the array we just obtained, like so
$targetGroup = Get-EC2SecurityGroup -Region $region | `
? {$_.GroupName -eq "s-fictional-svc-WebElbGroup-H97BD3LE36JI"}
$currentranges = $targetgroup.IpPermissions |`
? {$_.FromPort -eq 443} | select -expand IpRanges
$groupID = $targetgroup.GroupId
$diff = Compare-Object $currentranges $ranges
$diff | % {
# If the side indicator is =>, we add it
# if the side indicator is <=, we remove it
if($_.SideIndicator -eq "=>")
{
Write-Host "Granting Ingress perms to" $_.InputObject
Grant-EC2SecurityGroupIngress -GroupId $groupID `
-IpPermission @{
FromPort = 443;
IpProtocol = "tcp";
IPRanges = $_.InputObject;
ToPort = 443
}
}
if($_.SideIndicator -eq "<=")
{
Write-Host "Revoking Ingress perms from" $_.InputObject
Revoke-EC2SecurityGroupEgress -GroupId $groupId `
-IpPermission @{
FromPort = 443;
IpProtocol = "tcp";
IPRanges = $_.InputObject;
ToPort = 443
}
}
}
As you can see, we use Compare-Object to determine what needs to be added and what needs to be removed, and push just that rule up – or rip it out of – to the Security Group.
This technique can be used to whitelist any service that publishes its IPs in an API – in fact, if you’re whitelisting a client, you could get your client to publish their IP list to you and literally just put a script like this in place. Why do this crap manually? Let a script do it for you.
