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).
