On Thu, Jan 26, 2017 at 10:51:14AM +0000, Stuart Henderson wrote: > On 2017-01-25, C. L. Martinez <carlopm...@gmail.com> wrote: > > On Wed, Jan 25, 2017 at 02:07:55PM +0000, Stuart Henderson wrote: > >> On 2017-01-25, C. L. Martinez <carlopm...@gmail.com> wrote: > >> > Hi all, > >> > > >> > I have received a (maybe) "stupid" request from one of our customers. > >> > We have a pair of public OpenBSD firewalls (CARPed) that our development > >> > team use to access to several customers via VPN IPsec tunnels. But this > >> > morning we have received a request from one of these cutomers to access > >> > to our development servers using only one acl to permit their public IP > >> > address (without using VPN IPsec, or VPN SSL tunnels). > >> > > >> > And my (OT) question: how easy is to do a MITM attack (DNS spoofing > >> > for example, or another type of attack that permits to fake source > >> > public ip address) in this scenario? > >> > >> For an attacker with no access to endpoints or network in between: > >> > >> - For many protocols including UDP, it is absolutely trivial to send > >> traffic from a fake source address. > > > > But, only SYN can be sent, right?? Source's attacker ip address will not > > receive ACK, etc. Is it correct? If it is, he/she/they only can do DoS > > attack, they can't steal information, right? > > > >> - With TCP it depends on various things but sometimes you can predict > >> enough of the IP stack behaviour to spoof blindly and send data. > >> reassemble tcp + random-id can help. > > They won't get any responses, but if an attacker can predict some of > what's in the packets (port numbers, sequence numbers etc), they can > send a bunch of packets that *might* match. If they get lucky and hit > on a correct one, they can handshake and transmit, obviously not > receive data directly on that connection, but sending might be enough > to do damage. > > >> If an attacker can MITM (either by getting $client to send to their > >> machine instead of yours directly, they can obviously log or modify > >> packets before forwarding on to the real server. It depends what > >> you're running over it as to whether this is a problem. > >> > > > > Uhmmm ... but in this case, I don't see how an attacker can fake original > > ip public source address ... Any theorical example? > > If they have access to a machine that the packets pass through, or a > machine that they can be made to pass through (e.g. by DNS manipulation, > or if they're on an unprotected layer-2 network with a real router ARP > attacks etc might work) they can just inspect/modify the packets as > they're passing. > > Even if it's just a router that doesn't let them do much with the > packets directly, they might still be able to forward them over a GRE > tunnel or similar to a machine where they can do this. > > There are enough ISPs and colos around that don't do BCP38 (i.e. don't > check source addresses) that there won't be too much difficulty > re-forwarding packets with the original sender IP address. > > > Many thanks Stuart for your help. > > tl;dr: if VPN isn't suitable, make sure comms are protected by some > other method that includes at least strong authentication and protects > messages against being modified - e.g. modern SSH, TLS or equivalent - > and be careful with certificates (test to make sure that you'll notice > an unexpected change). >
Many thanks for your explained answer Stuart. Fantastic. Only one more question. Due to this access only requires http service, will be sufficient if I try to convince them to use https instead? And in the case that we could use https, a MITM attack would be minimized? -- Greetings, C. L. Martinez
