Closed markusjunior closed 2 years ago
Hi, @markusjunior. Thanks for providing interesting detailed information; we may need to dig out. One question, did it change the behaviour after yesterday's fix? or did it exist with the old query?
Hi Raj, to be perfectly honest, I am not sure.
We have about 700 VPCs in AWS. Yesterday (because I did not configure the regions in aws.spc) we just get a tiny report of just a few us-east-1 deployed VPCs. After editing the aws.spc, we reveived all 700 VPCs, 90% of them "RED". Afterwards I try to figure out the false positives with the shared VPC which you already could fix. Afterwards, we went down to 370 REDS (of 700). However, most of them are still false positives if you ask me as mentioned in this thread.
Hi, @markusjunior disappointing that you are still facing the issue; we have limited VPC resources to check for the updated query if you can try it. We made some changes to keep the simple PostgreSQL CTE section, you need to replace the new query in vpc_flow_logs_enabled.sql.
with vpc_with_active_flow_logs as (
select
resource_id
from
aws_vpc_flow_log
where
flow_log_status = 'ACTIVE'
group by
resource_id
)
select
-- Required columns
arn,
case
when account_id <> owner_id then 'skip'
when f.resource_id is not null then 'ok'
else 'alarm'
end as status,
case
when account_id <> owner_id then vpc_id || ' is a shared VPC.'
when f.resource_id is not null then vpc_id || ' flow logging enabled.'
else vpc_id || ' flow logging disabled.'
end as reason,
-- Additional columns
region,
account_id
from
aws_vpc as v left join vpc_with_active_flow_logs as f on v.vpc_id = f.resource_id
Thanks a lot. However I am afraid there is something missing in the new query. I replaced query/vpc/vpc_flow_logs_enabled.sql with your query and now I've got the error message: ERROR: prepared statement "aws_compliance_cis_v140_3_9_cfc60" does not exist (SQLSTATE 26000)
I guess there is something missing at the top of your statement like:
with vpc_with_active_flow_logs as (
So, after adding this line at the top, the previous error is gone however the control starts and tanks forever. After quitting the process (strg + c) I do get " ERROR: control result is missing required column: [resource]"
Hey there,
I did a deep dive into the Postgre DB with steampipe query. I found a really weird issue what I think is the root cause of this bug.
First of, I used a simple left join between aws_vpc and aws_vpc_flow_log:
Select aws_vpc.vpc_id,aws_vpc_flow_log.resource_id,aws_vpc.region,aws_vpc.account_id FROM aws_vpc LEFT JOIN aws_vpc_flow_log ON aws_vpc.vpc_id=aws_vpc_flow_log.resource_id;
This query is basically an outtake of your query for control_3_9, just simplified.
This is the result:
So it looks like that only for one VPC the left join found a match and therefore an active flow log. This would match with the reported issue (false-positive).
OK, let's take a look to the table aws_vpc:
We see a bunch of VPCs.
Now let's do the cross check to the table aws_vpc_flow_logs. Remember, the field resource_id contains. the VPC_id.
Well, this is strange isn't it ? In the table aws_vpc_flow_logs we have in every single region an active flow log. A short comparision of the resource_id and. vpc_id. looks exactly the same. A left join shall actually work.
Conclusion: The scan job works at least in that way, that all flow logs are added to the Database. Queries to both single tables work fine as well. A left join however doesn't work for whatever reason
Any ideas?
Please note:
Therefore we would expect just an alarm for that region.
@markusjunior exciting details, we will keep posted.
@markusjunior We have figured out this is a bug in the AWS plugin side; this is the reference PR. This will be released tomorrow.
Appreciate your contribution to it and helping us to fix this issue š
Hi Guys,
Just a question. If the fix is about to deploy the approved query update :
I just test this new query and as said already in this thread above, the control 3_9 will stuck and freeze up forever. If I trigger only this control, this is what it looks like:
Running 1 control. (0 complete, 0 running, 0 pending, 1 error)
A complete scan (all cis 1.4 controls) will work, however this partical control 3_9 will respond null results in the json output:
{
"summary": { "alarm": 0, "ok": 0, "info": 0, "skip": 0, "error": 1 }, "results": null, "control_id": "control.cis_v140_3_9", "description": "VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. After you've created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs. It is recommended that VPC Flow Logs be enabled for packet \"Rejects\" for VPCs.", "severity": "", "tags": { "category": "Compliance", "cis": "true", "cis_item_id": "3.9", "cis_level": "2", "cis_section_id": "3", "cis_type": "automated", "cis_version": "v1.4.0", "plugin": "aws", "service": "AWS/VPC" },
So, maybe I am to quick but if this is the supposed solution, it doesn't work.
Fun Fact:
If I trigger the new query directly via steampipe query, at least no freeze up, the response is there immediately. However, all still false positive.
So, maybe there is besides the new query more to come?
@markusjunior, Yes, apart from the new query, which will probably release tomorrow. Today, we will release the AWS plugin with this fix. So you need to update the AWS plugin once the new plugin version is released.
perfect, appreciate your awesome work!
Just give it a try, updating everything. It works like a charm for the very first 10 AWS accounts, brilliant! I assume that my loop will now work for every account, otherwise I will let you know. Thanks for the fix.
So, after intense testing, everything looks smooth. Thanks again, issue can be closed.
Thanks @markusjunior for your constant help with testing and quick feedback š .
Please do let us know in case you run into any more issues, happy to help š .
Did you check out our AWS insights mod ? Please do give it a go and let us know how your experience is?
Describe the bug Control 3_9 raises alarms even if a flow log is configured and active. It seems to be a false-positive
Steampipe version (steampipe -v) steampipe version 0.15.0
Plugin version (steampipe plugin list) | hub.steampipe.io/plugins/turbot/aws@0.57.0 | 0.57.0 | hub.steampipe.io/plugins/turbot/aws@latest | 0.68.0 | aws steampipe-mod-aws-compliance ## v0.38 [2022-07-07]
To reproduce steampipe check aws_compliance.control.cis_v140_3_9
Actual Scan Result:
Logfile / Json outtake:
{ "group_id": "root_result_group", "title": "", "description": "", "tags": {}, "summary": { "status": { "alarm": 16, "ok": 1, "info": 0, "skip": 0, "error": 0 } }, "groups": [], "controls": [ { "summary": { "alarm": 16, "ok": 1, "info": 0, "skip": 0, "error": 0 }, "results": [ { "reason": "vpc-0baef-xxxxxx flow logging disabled.", "resource": "arn:aws:ec2:ap-south-1:241xxxxxxxx:vpc/vpc-0baef-xxxxxx", "status": "alarm", "dimensions": [ { "key": "region", "value": "ap-south-1" }, { "key": "account_id", "value": "241xxxxxxxx" } ] }, ], "control_id": "control.cis_v140_3_9", "description": "VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. After you've created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs. It is recommended that VPC Flow Logs be enabled for packet \"Rejects\" forVPCs.", "severity": "", "tags": { "category": "Compliance", "cis": "true", "cis_item_id": "3.9", "cis_level": "2", "cis_section_id": "3", "cis_type": "automated", "cis_version": "v1.4.0", "plugin": "aws", "service": "AWS/VPC" }, "title": "3.9 Ensure VPC flow logging is enabled in all VPCs", "run_status": 4, "run_error": "" } ] }
If we do the same via AWS CLI against the same account and Region, we do get completely different results. Instead of a disabled flow log, it is enabled and active:
` aws ec2 describe-flow-logs --region ap-south-1 --profile 241xxxxxxxx
{ "FlowLogs": [ { "LogDestinationType": "cloud-watch-logs", "ResourceId": "vpc-0baef-xxxxxx", "CreationTime": "2018-12-04T14:02:38.035Z", "LogGroupName": "vpcfl-vpc-0baef-xxxxxx", "TrafficType": "ALL", "FlowLogStatus": "ACTIVE", "LogFormat": "${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}", "FlowLogId": "fl-0573-xxxxxxx", "DeliverLogsPermissionArn": "arn:aws:iam::241xxxxxxxx:role/flowlogs-role", "DeliverLogsStatus": "SUCCESS" } ] } `
Further Info:
this example VPC in ap-south-1 is not a shared VPC (nor owner nor participant)
the VPC above is the only VPC in this region
ALL other regions above mentioned as Not OK (alarm) actually does have an active flow log like the example region ap-south-1 (so, the false positive is not limited to ap-south-1)
the "successful" reported region eu-west-1 looks exactly the same (same type, same role etc). Absolutely no clue why this is reported as OK and all the others as Not OK.
aws ec2 describe-flow-logs --region eu-west-1 --profile 241xxxxxxxx "FlowLogs": [ { "LogDestinationType": "cloud-watch-logs", "ResourceId": "vpc-97xxxx", "CreationTime": "2018-06-28T09:40:59.150Z", "LogGroupName": "vpcfl-vpc-97xxxx", "TrafficType": "ALL", "FlowLogStatus": "ACTIVE", "LogFormat": "${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}", "FlowLogId": "fl-88fxxxxx, "DeliverLogsPermissionArn": "arn:aws:iam::241xxxxxxxx:role/flowlogs-role", "DeliverLogsStatus": "SUCCESS" } ] }
Expected behavior Well, actually we expect no false-positive...
Question: Any chance to debug this any further?