08-05-2017 02:44 AM
I wonder if there is some built in functinality or how to guide to implement such scenario:
DNS request comming from given IP and MAC
IP is checked if provided by DHCP (so active lease exist) or defined as Static
MAC checked if match lease or static definition
Lease checked if there is match between request MAC and MAC in lease
If any above test fails then response is blocked and alert/notification created. If possible additionaly info about where in the infrastrucutre given MAC is connected (switch port, router ingress interface etc.)
08-08-2017 11:48 AM
just to make sure I understand corretly, are you trying to define a rule to detect and block ip spoofing? Thanks. Philip
08-08-2017 09:59 PM
We can call it IP spoofing. I would like to find out if it is possible to detect source of DNS request for two cases:
Request comming from IP not provided by DHCP or not defined as static
Request is comming from IP for which DHCP lease exists (or there is static entry or host defined) but MAC is not matching one defined.
09-19-2017 09:55 PM
1. You can try to use OutboundAPI triggered by lease event, to automatically populate ACLs. Performance will really depends on LPS. With a high LPS I'll not recommend to use is;
2. As an alternative you can monitor syslog messages on a remote system and use API, to update ACL. The performance will depends how many and how often you need to do API requests;
3. You can use previous solution but manage ACLs on a firewalls if you have any protecting DNS service.
09-20-2017 12:31 AM
Thanks for suggestions but it looks like there is some misunderstanding here.
Why use OutboudAPI for described functionalities? If I am not wrong OutboundAPI allows Infoblox to send info/trigger actions on external systems.
I was wondering about functionality built in or possible to be implemented on Infoblox itself (sore if I was not clear enough).
So DNS service can automaticaly (or using RPZs) deny answer to DNS query from IP that is not Infoblox DHCP database, or when DHCP lease for this IP is for different MAC than MAC DNS request is comming from.
So no external services should be necessary for that, just some smart config/scripting on Infoblox system itself.
At least that is my impression.
09-25-2017 06:17 PM
I think what Vadim is trying to say is to use the Outbound API feature to automatically update the ACL when new DHCP leases are handed out. The ACL is then applied to the DNS view/zone to restrict responses to IP addresses not in the ACL list.
In essence, you can use the Outbound API to send an API call to itself (not necessarily an external system).
Trying to map the MAC to IP and deny it may not be a good use case, for example if the query goes through other DNS forwarders and therefore you lose MAC address/L2 context.
What problem are you trying to solve? You have listed a technical problem, but I'm curious to understand what business problem that translates to and why the requirement. There could be better ways of doing this.
09-27-2017 05:03 AM
Sorry for misunderstanding. I was just reading examples for Outbound API to communicate with external systems, did not know (or figure out :-) that it can be used to communicate/reconfigure Infoblox system itself - great hint!
Well, sure if DNS requests are comming from another DNS services that would be stupid to check IP/MAC mapping but let's assume this is not a case (or those requests are somehow whitelisted) - so we are talking only about end nodes directly requesting DNS resolution from Infoblox DNS service (integrated with DHCP).
Idea is quite easy - at least I tought so :-) - to be able to discover and act in case when potentially roque endpoints are trying to perform DNS resolution.
- All DHCP leases are handled by Infoblox DHCP - and all end point using DHCP has to request IP from Infoblox DHCP
- All static MAC/IP mappings are handled as well by Infoblox
- Source IPs not assigned via DHCP or recorded as static/host are considered unsafe
- Source IP to MAC not matching DHCP lease or static entry is considered unsafe
Implementation should allow to at least detect and report attempts that are violating above policies. In best scenario allow to as well act on violation by for exapmple updating RPZs or do any other action - like informing security team or some external system.
Hope it makes sense,
10-01-2017 10:47 AM
I think the problem with any solution like this is the HUGE overhead it will have on Processing the data.
You're essentially asking for every query to be checked against a valid DHCP lease, Which would mean 100's of lookups per second being matched against 1000's leases.
Transforming the problem into an ACL that is updated on a regular basis is the only way to really make this efficient.
this is the generalised problem with BYOD : too may devices, too much traffic to monitor.
A possibly better approach is to only act on devices that start to violate a policy. If the device is rogue, but benign, then ignore it for the moment. But let device discovery and conflict resolution (via network insight) pick it up on the next pass.
If the device triggers an RPZ rule, then one of the actions could be to verify if it has a active lease, or is rogue, and add that to the metadata on the alert.
At least that way you've reduced the volume of data in the problem set.
10-03-2017 12:57 AM
Thanks for alternative solution. I can understand that it can be havy on the resource side. But I hoped that because all necessary data is internal to the system (leases, static entries, replying to DNS query) then it will not be so problematic performance wise - only exception I can see is checking MAC/IP match against leases/static entries.
I was hoping that data already in the system can be used as kind of whitelist - everything registered by the system is considered as safe, everything not in the system is considered suspicious.
Anyway, if doing something like that is risky considering potential load then is there any easy way to generate report that shows queries performed by devices with no/wrong data in the system?