Okay, thanks!
So, if J Random Prober were to try to ping any address in your
range on that link, he'd see no machines there. (The only populated
addresses are the router interface and the IPSEC box, and with your
ACLs he shouldn't see those either.)
Then, so far as he's concerned, packets bound for those addresses
just fall off some router that has nowhere to send them, or bounce
around the net until their TTL runs out. He probably has no idea
that they're being blocked by your ACLs and logged.
So, from his perspective, these look like unused source addresses.
There are basically five scenarios:
1. Connectionless attacks such as ICMP (Ping of Death?), UDP (DDoS?)
etc. If these generate response packets to the spoofed source, he
doesn't care.
2. "Smurf" DDoS attack, where he sends a subnet broadcast request
with your address forged at the source, hoping the responses will
overwhelm your line/router.
3. Probes such as ICMP and port scans. He needs to see the response
packes for these to be useful, but perhaps he has installed sniffer
software on a compromised router or ISP server. As long as the
response packets come *past* his sniffer, he doesn't care where they
eventually get routed to. [If his ISP/targets are alowing surce-
dictated routing, he can improve the odds that return traffic will
pass his sniffer; for all we know, maybe you only see his traffic
when that doesn't work.]
4. To fully spoof TCP, he needs eveything in #3 above, plus his
compromised machine needs to be able to send additional spoofed
packets to extablish and use the connection -- and this probably
won't work if he spoofs using a source address that responds to
unexpected traffic with, say, an RST.
5. Somebody has, probably by accident, told a group of machines (or
a DHCP server) that your address range is his. His local machines
can see each other, but when they try to talk to the Internet, the
responses get routed to you. The BGP traffic you've seen may be a
misguided attempt to fix this, not realizing that he's using
addresses he's not entitled to. (Perhaps his ISP gave him that range
in error.)
[Egress filtering, as we were discussing recently here, should stop
his original packets from reaching their targets -- although, if he
has already compromised a machine at an ISP, he might be able to
bypass that -- or he might even be an ISP employee/ex.]
It would be *nice* to track this guy down and stop him. But (a)
that may not be possible from your end, and (b) he doesn't sound like
he's actually hurting you *unless* it's scenario #2 or #5 above, or
in scenario #4 he manages to frame you for his activity.
David Gillett
On 15 Jun 2001, at 10:53, Norris, Wayne wrote:
> David,
>
> Apologies for the lack of info.
>
> The VPN is set up as an IPSEC tunnel providing transatlantic site to site
> connectivity running on cisco ios (UK to Canada). There are no machines on
> the address range, and no references to these addresses are configured on
> any of the routers / firewalls in our organisation. This link is used for
> the VPN only. There are also no DNS entries for these addresses.
>
> The hostile traffic's destination addresses are in the far/middle east.
> Beirut, Colombia, Korea, Malaysia and recently France.
>
> The ACL's are blocking this traffic inbound from our ISP. today, I have also
> seen some BGP packets destined for another ISP claiming to be from us. The
> ACLs are configured to only allow AHP and ISAKMP from the Canadian Peer,
> plus the valid Remote RFC1918 addresses.
>
> The IPSEC box is on a switched DMZ. Layer 2 filtering is applied such that
> the box can only speak to the Firewalls looking after this area.
>
> Regarding Routing, the internal infrastructure has the default route out of
> an entirely seperate building, and the IPSEC router (Where we are seeing the
> logs) has a default route to Null0. If i traceroute to any of these
> addresses assigned to us, the packets go out to the ISP via the correct
> link, traverse their backbone, and then hit the ACL's on the IPSEC box. IP
> accounting shows no traffic internally heading outbound for any of these
> addresses (only valid traffic to the RFC1918 addresses the other side of the
> tunnel).
>
> What I don't understand (and my experience is limited) is how this traffic
> is routing to us.
>
> I have informed our ISP, and they are also investigating.
>
> Thanks for your time.
>
> Wayne
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 10:08 AM
> To: Norris, Wayne; [EMAIL PROTECTED]
> Subject: Re: Strange Logs.
>
>
> You haven't really given us much to go on -- no clue what the
> address range is, whether there are other machines on it, what
> make/model/version VPN it is, whether it's being used to provide site-
> to-site connectivity or remote individual connectivity. Not even
> what the geographical region is.
> In fact, we can't even tell wheter you're seeing outbound packets,
> or inbound packets apparently trying to reply to outbound traffic
> that shouldn't and doesn't exist.
>
> Sure, it could be a smurf attempt, or side-effects of someone
> spoofing you as the source address. (There are a couple of ways a
> spoofer might be managing to sniff the return traffic.)
> But it could just as easily be one of your own users with an
> incorrect default gateway set, or perhaps leakage of route
> information for this link to other routers within your
> organization....
>
> David Gillett
>
>
> On 15 Jun 2001, at 8:17, Norris, Wayne wrote:
>
> > Hi,
> >
> > Can anyone shed some light on the following.
> >
> > We have multiple connections to the internet, One of which is used purely
> as
> > a VPN connection. It is not used for Mail, browsing etc etc. I recently
> > noted some strange activity on in the logs on the perimiter router.
> >
> > IP addresses supposedly coming from our registered address space assigned
> to
> > this link, are trying to access various remote sites, FTP, WWW, RPC etc.
> >
> > There is not a great deal of activity like this, but the destinations
> always
> > seem to be in the same geographic areas.
> >
> > The question is, how are the packets trying to route via this link, if the
> > destination addresses he/she is trying to get to are not in any way
> > connected to our organisation, and the source addresses are supposedly
> ours
> > ?
> >
> > And what would be the point, as the traffic back would route to us ?
> >
> > Could this be part of a DDOS ?
> >
> > Many thanks
> >
> > Wayne
> >
> >
> >
> >
>
>
> EUROPEAN FINANCIAL DATA SERVICES (UK) LTD Tel: +44 1277 84 2700
> ********************** N O T I C E *********************************
>
> This message and any attachments is intended only for the individual or company to
>which it is ad
dressed and may contain information which is privileged, confidential or prohibited
from disclosure
or unauthorised use. If the recipient of this transmission is not the intended
recipient, or the e
mployee or agent responsible for delivering such materials to the intended recipient,
you are hereb
y notified that any use, any form of reproduction, dissemination, copying, disclosure,
modification
, distribution and/or publication of this e-mail message or its attachments other than
by it's inte
nded recipient is strictly prohibited by the sender. If you have received it in error,
please notif
y us immediately by telephone on the number above and destroy the message and all
copies in your po
ssession.
>
> This footnote also confirms that this email message has been swept by MIMEsweeper
>for the presenc
e of computer viruses.
>
> **********************************************************************
>
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
