Vanilla Netrek Server Development Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[VANILLA-L:706] Re: [VANILLA-L:705] "forging" source addresses
Bob Tanner wrote:
> Forgive me a topic not directly related to the server developement but
> I am getting desperate.
It would help you to know that I am a firewall product support person.
I've just forwarded you an article on smurf defense.
> How does one change the source addresses of a packet? I want to know
> so I understand the attack better and thus try to formulate a solution
> to prevent this attack.
Very easily. You just write (or borrow) code that will compose IP
packets directly, and then inject them onto an ethernet device without
going through the IP stack.
I'm sure I could whip one up from scratch in about an hour. I could
probably find one in half an hour on the web.
The socket layer is not necessarily involved.
> Can anyone think of a way to trace where they attacks are going from?
> Without the source address I am really at a lose.
The key to solving these attacks is cooperation. You gain the
cooperation of the organisation you are connected to. Then both of you
use tcpdump to grab a sample of the packet streams, at the same time.
It helps to have both machines synchronised using NTP.
Then you identify the packets and the path they took to get _into_ the
organisation you are connected to.
Then repeat with the next organisation.
> Finally is there any way to prevent this sort of attack. A
> random source address, random procotol and hitting random ports all
> makes for a difficult firewall.
Yes, I agree.
Other things you can try ...
- check your TCP/IP stack for the ability to change the number of
outstanding unacknowledged SYN packets. If you are experiencing large
numbers of connect attempts, this queue can fill. Increase the queue
depth.
- have two or three apparently unrelated people post to
rec.games.netrek that your server is wonderful and connections are now
perfect. See if anybody replies. ;-)
- use this list of replies and your ban file to trace the source of the
packets at the next organisation level.
- read that doc ... I haven't read it yet. ;-)
--
James Cameron (cameron@stl.dec.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800
+
++ Vanilla-l Mailing List ++
To unsubscribe: send "unsubscribe vanilla-l" to majordomo@real-time.com
For more information: http://archives.real-time.com
References: