Date: Mon, 20 Mar 2000 23:12:25 +0000 (GMT) From: Paul Robinson <wigstah@akitanet.co.uk> To: Alexander Langer <alex@big.endian.de> Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw fwd to requester's ip Message-ID: <Pine.BSF.4.21.0003202245070.31205-100000@jake.akitanet.co.uk> In-Reply-To: <20000320183644.J2721@cichlids.cichlids.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Mar 2000, Alexander Langer wrote: > Hello! Hi, > What does one have to use to fwd an tcp/udp packet to a given port > back to the requester's address? OK, I'll sort of answer this, but please read all the mail, because what I think you're proposing is bad for soooooo many reasons. Well, I read about 3 screens down the ipfw man page, and found a useful section on fwd ipaddr [,port], although how you would specify the sender's ip address and port in here dynamically is unknown to me at the moment, and I suspect it can't be done. If you can find a way of logging the packet (bad idea, see below), then you could have something watching the log output, then fires off a script. You can use IPFIREWALL_VERBOSE to help you do this, if you really want to, which you don't as I'm about to explain: :) > I'm getting a whole bunch of 1234, 27374 and other trojaner's attacks > these days, and I want to fwd back these packets to the attackers :-) > (I want to see her faces :P) OK, this is possibly the worst thing you can do in this situation. I have an IDS in place which throws up scans every now and again, and by far the best way to do this is to capture the packets with accurate timestamps using something like snort (http://www.clark.net/~roesch/security.html) which will happily capture full packets that match the patterns you describe. You then find out the administrators responsible for the IP address you are looking at (whois -h whois.ripe.net XXX.XXX.XXX.XXX in Europe, and IIRC it's whois.arin.net for US?), and send to abuse@domainname.com... You see there are several reasons for doing this. First of all administrators like me understand our users misbehave, and are of course happy to scrape them over the hot coals as a result. Yes it's extra workload, but in the same way I'll deal with my users, other admins will deal with their users when they continually prod my servers for Back Orifice. Also, it can actually signal a compromised server, i.e. it's one of the admins servers that has been hacked, and this sort of prompting will help them enormously. There is also the legal implications of what you're suggesting. In the UK at least, a probe to a port that is not advertised as being available to the public is illegal. In fact, it's the onus of the connector to a host to show they are authorised to do so in a given manner. I.e, anybody in the UK doing scanning can, theoretically, be prosecuted. If I start firing packets back at them, they can prosecute them. It's best I just let the packet get logged, and complain to their admins as netiquette suggests. Also, let's talk about the security implications in terms of Denial-of-Service attacks here. I compromise box A, and I don't like you who owns box B, so I start sending you 1,000 SYNs/sec to 31337 on box B from box A. Not only do I run a good chance of DoS'ing you, because you're processing and handling all this in the kernel in a special manner, but I also DoS box A. Nice. Logging of these packets alone is mildly risky, as theoretically filling up /var could be done by an attacker, but this is nowhere near as bad as DoS'ing not only your own box, but somebody elses, for which you will be blamed, you'll be the one that gets pulled off the network, etc.... In short, yes it can theoretically be done, but you haven't looked hard enough at the options available to you to do this, you haven't thought about the implications, and when you do, you'll realise this is actually quite a bad idea. Please, for your own sake, go and download and install snort. It has the disadvantage of having to put the NIC into promiscuous mode (which requires bpf devices to be enabled in the kernel and MAKEDEV'd), which *slightly* slows the stack down, but otherwise it helps you produce hard evidence to complain with in style about these morons. :) Although it would be nice to 'see their faces', you won't because they're miles away. What you will see is your box grind as it starts doing all this dynamic processing, and lots of e-mail telling you you're a very naughty man, and you're no better than the rest of the prats who do this. :) -- Paul Robinson - Developer/Systems Administrator @ Akitanet Internet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0003202245070.31205-100000>