Date: Thu, 17 May 2001 22:45:23 -0400 (EDT) From: Bob K <melange@yip.org> To: ports@freebsd.org Subject: socksified client-side identliciousness (fwd) Message-ID: <Pine.BSF.4.21.0105172241250.4022-100000@pi.yip.org>
next in thread | raw e-mail | index | archive | help
I figured this may or may not be of interest to the socks5 port maintainer. Since the Makefile lists ports@freebsd.org, well, here. -- Bob <melange@yip.org> | "Villain, I have done thy mother" - Shakespeare, Titus Andronicus, act IV, scene II ---------- Forwarded message ---------- Date: Tue, 8 May 2001 12:06:43 -0400 (EDT) From: bastard <bastard@yip.org> To: melange@yip.org Subject: socksified client-side identliciousness Hey Bob, I've managed to solve my client-side ident problem, albeit with an assload of work. I thought you might like to know how, since I'm fairly certain only a handful of freebsd users on the planet, if that, have gotten socksified client-side ident working. I've seen no fbsd success stories in any newsgroup or mailing list archives online - only pleas for help. There are a few success stories from linux admins who have gotten it working, but from what they report it seems to have worked for them because the involved compilations completed cleanly without manual intervention. The process to get it working under freebsd was non-existent. Fortunately, I invented it as I went along. Sorry about the length of this mail, but it was a complicated procedure, and I think it'll interest you. Okay, well, socks5 does, in fact, have means of supporting retrieval of ident info from socksified clients which connect to it, but the support is very poorly documented and broken by default (even when explicitly enabled). First of all, libident needs to be installed on the system before compiling socks5, so I made and installed it. Then socks5 need to have it's configuration script passed the "--with-ident" feature. Did that, via the top-level port makefile, then compiled. Didn't work. The script couldn't find ident.h, even though it was in the current path. Had a look the goodies whut makes de script go, and it's statically coded to look for it in /usr/include. ln -s'd it from /usr/local/include. Script then found it, but now ld cannot pass -lident. /usr/local/lib/libident.a is in library path, though, so I untar the socks5 distfile and have a look at the socks5-v1.0r11/server Makefile for goodness. It's looking for the lib statically, of course (yay dumbness, etc.). So, I symlink the real lib to the /usr/lib dir, then try make again. It works. socks5 is now compiled with client-retrieved ident support. I test it, and it works, with this socks5.conf: auth 192.168.0. - n interface 192.168.0. - 192.168.0.1 interface - - ep0 permit n - 192.168.0. - - - - set SOCKS5_BINDINTFC 192.168.0.1:13090 set SOCKS5_DEMAND_IDENT set SOCKS5_IDENTFILE /tmp/socks5.ident At least, it works in that it does what the socks5 server itself is supposed to, but client-side ident is still broken. Next, I need to patch pidentd to interoperate with socks5, or none of this ident goodness will work. The problem with this is that the latest patch is for pidentd-2.8a4. Besides the fact that the current version in the ports collection is 2.8.5, 2.8a4 has security holes. Less than pleased, I grab the 2.8a4 source tarball and apply the socks5 patch to parse.c. Now, the standard pidentd source will not compile on fbsd 3.x or later systems. The ports collection version is extensively patched with natively maintained code before it gets made. This presents a problem, because the 2.8a4 parse.c patch will not be mergeable with the standard 2.8.5 code, LET ALONE the ports-patched version of 2.8.5's parse.c. This pisses me off. A lot. Enough, in fact, that I can't stop thinking about it. Fifteen minutes of frustrated consideration buys me a possible solution. I decide to diff -b -B -c the socks5 patched 2.8a4 parse.c against the ports-patched 2.8.5 parse.c, then patch the latter with with patch thus produced. It works. All hunks succeed. So, I edit the Makefile in /usr/ports/security/pidentd/work/pidentd-2.8.5 so that it passes arguments and variables set in /usr/ports/security/pidentd/Makefile to the gnu tools in use (so I can make from the distfile tarball's top level dir and produce output identical to that reaped from a standard port make, except with all the new parse.c goodies included). I then make clean from the top level dir, and finally make. Success. All the files produced by a /usr/ports/security/pidentd make now sit under that dir's work subdir, where the port Makefile expects to find them. So, I ascend to /usr/ports/security/pidentd and do a make deinstall to remove the standard, nonsocksified version I had previously compiled, then a make reinstall to get down with sum ident gudnezz from mah homie Socks 5. Hoping that everything will actually work, I then fire up the two daemons and configure mIRC to use the firewall. I-MUTHAFUCKIN'-DENT! De client be droppin' sum mad crazy ident blam-blam all over d'irc server! At this point I actually yelled, "Ha! Bitch!" Current socks5 playing nicely with current pidentd! Heh. Sorry about the enthusiasm, but every other instance of this configuration I've come across is using the (buggy) pident-2.8a4 release. I had actually looked into other options before pursuing all this crap. None exist for FreeBSD, other than ident reply randomizers. oidentd will forward ident requests to internal hosts only via IP masquerading, on Linux and OpenBSD, and the method it uses is itself broken in many ways (ipmasq sucks much). A nice thing about the solution I've implemented is that while socks clients will ellicit an identd session to any identd server running on the client host, pidentd will function normally in all other cases, returning standard replies for any other requests (such as those caused by local ircii sessions). So, uh, ya. I need to sleep more now. =) Charlie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" 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.0105172241250.4022-100000>