:evil:
LOCAL IT MANAGER: We're using 192.168.100.0/24 at every site as the local manufacturing line network. It's non-routable.
ENGINEER: Well, we need to make those routable so the vendor can do maintenance on the equipment on the production line.
LOCAL IT MANAGER: Oh, OK. You can make it routable. Just be sure to permit the traffic on the firewall, so we'll be good to go.
ENGINEER: Well, to make it routable, we need to change the IP range being used.
LOCAL IT MANAGER: Re-IP all the devices? Well, we can put it to the change committee for discussion ahead of the next available change window.
ENGINEER: That's the December change window this year?
LOCAL IT MANAGER: No, we have that full up with other work. This would have to wait until December *next* year.
ENGINEER: :rage:
***
What's *your* story about those duplicate IP ranges that aren't supposed to be routable? I got more stories because of NAC... :-\
Customer reused address space for all their /30s. So you would hit NYC-R1, and it would have 192.168.1.1/30, 192.168.1.5/30, and 192.158.1.9/30 on the interfaces. Go to CHI-R1, and find 192.168.1.1/30, 192.168.1.5/30. Go to MIA-R1, and it had 192.168.1.1/30, 192.168.1.5/30, 192.168.1.9/30. They figured those addresses were "link-local" so they didn't care if you could reach them remotely or not. Everything used loop backs for management stuff. When I asked about it they said it was to conserve address space. Apparently at some point all the links were in public space, they did this to save space. No clue if that was ever fixed or not.
Kind of similar to Mr. Webb's story. This is on a very specialized piece of hardware. The management interface for this system is hard coded to a specific /24. You can change the last octet, but not the rest. Also no default gateway is configured. They never expected anyone would want to manage the system remotely. Last I talked to them they didn't plan on changing this because their biggest customer didn't care.
Last one. A vendor used real public IPs on the back plane of their device. These IPs do not belong to them. If you try to connect to these box from one of these IPs it will not respond as it tries to respond on the local internal interface. You have to add a /32 route to the IPs you want to be reachable externally, and only if those IPs aren't actually in use internally on the box. Originally I think they had an entire /16 on this (maybe a /8). Newer releases have it down to a /28 which they then leased from the real owner of the space. I complained originally because we had a customer in the original space. That is why they moved it to a /28. I tried to point out 127.0.0.0/8 was a really good space to use for this, but they didn't care. While we waited for a fix I was doing a source NAT on traffic for this box so our customer could access it. I just checked after I wrote this. The most current software actually uses 169.254 space. So much better.
-Otanx
169.254? That's the Microsoft "I can't get a real IP, so I'll just make one up" address range.
:facepalm1:
169.254/16 is actually defined in RFC 3927 as link-local address space. So an internal isolated network is a valid use for the space. Microsoft is just the most visible use of this space, and in this instance is actually doing the right thing, and following RFC.
-Otanx
techhies call that APIPA
Just use IPv6. You could build a totally new address range, with hookers! and Blackjack!
(ducks)
Is it wrong for me to be gleaning security ideas from this thread? :twitch:
Quote from: Dieselboy on August 28, 2019, 12:09:18 AM
Is it wrong for me to be gleaning security ideas from this thread? :twitch:
Not at all, as long as you share them. :smug:
Quote from: wintermute000 on August 27, 2019, 05:18:13 PM
Just use IPv6. You could build a totally new address range, with hookers! and Blackjack!
(ducks)
Your ideas intrigue me, and I would like to subscribe to your newsletter... :D
IPv6? I haven't even started rolling out IPv5 yet. I should get busy with that instead of posting here.
-Otanx
Quote from: Otanx on August 28, 2019, 10:39:05 AM
IPv6? I haven't even started rolling out IPv5 yet. I should get busy with that instead of posting here.
-Otanx
you should jump ahead and start rolling out IPv8, See RFC 1621 to get started.
a real eye opener.. :eek:
I got a short way into RFC 1621 when I saw the requirement for a server to broker transactions... I'm now on the fence between "intrigued" and "WTF!"...
I wouldnt worry about IPv6 too much. This whole `internet` thing is just a fad. It will soon pass and we can get on with our lives. :P
Quote from: Dieselboy on August 28, 2019, 08:05:25 PM
I wouldnt worry about IPv6 too much. This whole `internet` thing is just a fad. It will soon pass and we can get on with our lives. :P
Will we be able to have our brains uploading into AI? Join the collective? So we can have instant access to everything?, and unlimited life span?
Quote from: ristau5741 on August 29, 2019, 06:09:01 AM
Quote from: Dieselboy on August 28, 2019, 08:05:25 PM
I wouldnt worry about IPv6 too much. This whole `internet` thing is just a fad. It will soon pass and we can get on with our lives. :P
Will we be able to have our brains uploading into AI? Join the collective? So we can have instant access to everything?, and unlimited life span?
I'm going to need some SLAs defined before I upload my employees into the collective. Also DLP in place.
Cloud AI is just someone else's computer brain.
-Otanx
Update... found a customer network where, somehow, devices with 192.168 addresses were gettin' around. Customer was supposed to only be using addresses in the 10 range, but we just discovered a writhing mass of home devices, with traffic routing around on the internal network.
Where are the devices? Hard to say, since so many have duplicate addresses...
Easy. Configure the customers edge with routes to `null0` for the other networks that are outside of the customers 10.x.x.x range. Then go pull yourself a beer, safe in the knowledge your customer is secure once again :eek:
Quote from: Dieselboy on September 12, 2019, 11:36:50 PM
Easy. Configure the customers edge with routes to `null0` for the other networks that are outside of the customers 10.x.x.x range. Then go pull yourself a beer, safe in the knowledge your customer is secure once again :eek:
That was my recommendation, since the whole environment was constantly in flux.
Quote from: Dieselboy on September 12, 2019, 11:36:50 PM
Easy. Configure the customers edge with routes to `null0` for the other networks that are outside of the customers 10.x.x.x range. Then go pull yourself a beer, safe in the knowledge your customer is secure once again :eek:
We do this with all RFC1918 space, and bogon stuff. We have a pair of Quagga servers that peer with all our edge devices, and hand out those, and any malicious IPs supplied by our cyber team.
-Otanx
Quote from: Otanx on September 16, 2019, 08:36:09 AM
Quote from: Dieselboy on September 12, 2019, 11:36:50 PM
Easy. Configure the customers edge with routes to `null0` for the other networks that are outside of the customers 10.x.x.x range. Then go pull yourself a beer, safe in the knowledge your customer is secure once again :eek:
We do this with all RFC1918 space, and bogon stuff. We have a pair of Quagga servers that peer with all our edge devices, and hand out those, and any malicious IPs supplied by our cyber team.
-Otanx
Thought Bogons were a thing of the past, at least for IPv4, since all the IP space is now exhausted.
Still got to check for Martians.
I guess it depends on how you define Bogons vs Martians. I had to look it up. Team Cymru (who I kind of see as the experts) list Bogons as including all Martians plus unallocated space. So Martians are a type of Bogon address. However, other references I found flip that and say Bogons are just the unallocated space, and that Bogons are a type of Martian. However, I will say I have not heard of anyone calling these Martian filters even if that is what they are.
To be more specific we include all RFC 1918, CGNat, and all the other IPs from different RFCs that should not be on the internet. We also filter out all "Class D" and above. Multicast shouldn't be hitting our edge. Also 127.0.0.0/16. We also have uRPF configured so the filters will drop traffic with those as source addresses as well. This lets us detect mis-configurations on our gear (wrong NAT statements usually), and/or weird traffic from the internet like someone trying to DoS us with a source of 127.0.0.1.
-Otanx
Nice! :)
I have configured firepower to do something similar but it's about time for me to go and eval the config and tweak.
On the edge routers/ASAs I do this:
route Null0 10.0.0.0 255.0.0.0 254
route Null0 172.16.0.0 255.240.0.0 254
route Null0 192.168.0.0 255.255.0.0 254
I took that from Cisco's config guide for VTI tunnel IPSEC. The guide said to do that so when the VTI tunnel is down, the ASA does not just send the traffic out to the internet unencrypted 🙈 I Thought "yea good point" :mrgreen:
This is some great tips and info in this thread. Basically, a panel discussion on how to deal with IP ranges that devices and/or users bring with them to your network.
Quote from: Dieselboy on September 16, 2019, 09:08:26 PM
Nice! :)
I have configured firepower to do something similar but it's about time for me to go and eval the config and tweak.
On the edge routers/ASAs I do this:
route Null0 10.0.0.0 255.0.0.0 254
route Null0 172.16.0.0 255.240.0.0 254
route Null0 192.168.0.0 255.255.0.0 254
I took that from Cisco's config guide for VTI tunnel IPSEC. The guide said to do that so when the VTI tunnel is down, the ASA does not just send the traffic out to the internet unencrypted 🙈 I Thought "yea good point" :mrgreen:
Yep that is basically what happened to us, but on a DMVPN router. We fixed it by using a VRF for the internet facing interfaces, and then added the drops as a way to alert.
Because you brought it up. One other place I have seen the duplicate IP issue is with IPSec tunnels. The VTI needs a /30 for the tunnel. You don't really use these IPs for anything except next hops. A lot of people I have had to deal with like using RFC1918 space for this. The problem is trying to de-conflict address space not just between us and them, but us, them, and all the other "thems" we have tunnels with. We force using public space for that now (and /31 if possible).
-Otanx