Securely forward a TCP service with SSH

Sometimes you want to directly access a server on a remote LAN beyond a firewall and you don’t want to set up a VPN, or maybe you want to encrypt an unencrypted service in simple and easy way. If you can contact a [remote] SSH server, then you only need a ssh client, and that’s all!

Let’s see it more in deep:
ssh -fn -N -L 1080:remote_www.server.com:80 root@remote-ssh-proxy.server.com

The -N -L switches do the trick! The first parameter to the L siwtch (1080 in this example) will be the local port you will use to direct connect to the remote service, located at remote_www.server.com address on port 80. So, for example, you can point your browser to http://localhost:1080 and magically you will have established an encrypted connection to that web server (well, if you have a user/password for remote-ssh-prxy ;)
The -N switch is mandatory in this use case because it will disable the need of a program to be passed as an argument to ssh, permitting the tunnel-only connection.
The -fn is to put in background the connection, so the tunnel will stay open and your console won’t be blocked.

You can change the -L for -R which will do just the reverse. It will forward a port from the remote proxy to a local machine.

FreeBSD6 and nfsd gotchas

If you’re using FreeBSD6 as NFS server, you may find useful these quick tips related to /etc/export syntax, because otherwise you will be stuck with a generic

mountd[321]: bad exports list

in your logs.
So, what went wrong here?
One possible cause is that in your exports file you’re trying to export as shared NFS resource a symlink and not a real directory. NFS doesn’t like it at all and will simply no work.
One other, curious, glitch I found is that if you have two resource in two separate lines with the same options, the latter will fail.
Example of /etc/exports:

/path/share1
/path/share2 -network 192.168.1.0
/path/share3 -network 192.168.1.0

in this case share1 and share2 will work, while share3 won’t work and you’ll get a

mountd[321]: can't change attributes for /path/share3
mountd[321]: bad exports list line /path/share3

but if you change the network value in share3 (and only this), it will work!
Maybe there’s an explanation for this (I didn’t read all the exports(5) manpage) but anyway it’s a little bit strange.

HOWTO: Managing Active Directory users under Linux with adtool

Usually people manages Linux boxes using Windows clients but sometimes, someone (like me, for example) needs to manage a Windows server from a Linux host (it could be a normal client or another server which wants to talk to Windows).

IMO, Active Directory is one of the best product from Microsoft, since it’s based on a well known standard like X.500 (aka LDAP) and it has a good interoperabilty (although it could be better, see all the problems Samba people had in the past).  So, even if there are tools like PHPLdapAdmin which are pretty good, if you need to automate users and groups management, there’s nothing better than a command line tool. Enter adtool.

adtool is very simple to use, but it’s not so simple to have it up&running, because this involves, amongst other things, to activate Secure LDAP in your Active Directory installation. To do this, you can follow this guide which will lead you through all the steps you have to do to enable LDAPS in Windows Server 2003. It may look scary but it works indeed, I used it myself.

Then, install adtool. In Debian/Ubuntu

# aptitude install adtool


Probably adtool is already present in your distribution’s repositories, so use your package manager. In the case it’s not present, simply download the adtool tarball from its homepage and do the usual

$ tar xzvf adtool-1.3.tar.gz
$ cd adtool-1.3
$ ./configure
$ make
# make install


It should be quite straightforward.
Now we have everything installed, so we can configure adtool.
Create /etc/adtool.cfg or, even better $HOME/.adtool.cfg because it will contain sensitive information, so lock it up to the user you’re willing to employ to modify Active Directory.
Put this in the config file (adapt to your needs)

uri ldaps://domain-controller.domain.tld
binddn cn=Administrator,cn=Users,dc=domain,dc=tld
bindpw $ADMIN_PASSWORD
searchbase dc=domain,dc=tld


As you can see we are using LDAPS here, because otherwise some adtool features like changing users’ passwords wouldn’t be available.
You don’t necessarily have to use the Administrator account, you can use whatever account you want, it just needs to have the right permissions (create user, change passwords etc).

So you can start poking your AD from the Linux command line, like this:

# create a new user with a dn like cn=$NAME,ou=$DEP,dc=domain,dc=tld
$ adtool usercreate "$NAME" "ou=$DEP,dc=domain,dc=tld"

# set user logon password
$ adtool setpass "$NAME" $my_secret_password

# to unlock the account (locked by default)
$ adtool userunlock "$NAME"

# to disable all the "account options" in the user's account tabe. Amongst them the "Password never expires" which is again enabled by default
$ adtool attributereplace "$NAME" userAccountControl 512

# to set user's mail address
$ adtool attributeadd "$NAME" mail user@domain.tld

# add the user to a group of users
$ adtool groupadduser $my_group "$NAME"

This could be very useful for user scripting and system integration if you’re in a mixed environment, just like we are.

Create/modify user passwords in batch mode

Hello again,

Sometimes, you need to put a non-interactive passwords using scripts, as you can see, you can’t use passwd tool, because it only works using interactive way.

On Debian, and of course lot of distros, you can use chpasswd instead (create, update & modify)

From chpasswd manual:

chpasswd reads a list of user name and password pairs from standard input and uses this information to update a group of existing users, so you can update passwords in batch mode.

echo “user:pass” | chpasswd

Regards,

Running out of TCP/IP ports in your Linux box?

If you have a Linux box acting as transparent/reverse/cache proxy and you see something like this in your squid logs:

squid[24228]: commBind: Cannot bind socket FD 91 to *:0: (98) Address already in use

and moreover you’re noticing that the load value is increasing too much, you are running out of available TCP/IP ports in your Squid IP address.
This is due to the fact that by default Linux 2.6 reserves about 30.000 ports (from 32768 to 61000) as local ports. Considering that a closed connection stays in the TIME_WAIT status for 60 seconds (hardcoded value in the Linux kernel), you can have ~600 TCP connections per second in your box before starting to see this problem (at least with that particular IP).
A temporary solution it is to increase the local ports range with the following command:

echo "10000   61000" > /proc/sys/net/ipv4/ip_local_port_range

giving in this case Squid a range of ~50.000 ports.

.forward and /dev/null

Just a quick tip for you out there and a reminder for me. If you are using .forward files with your MTA (so, real users, not virtuals) and you want to discard everything received by that user, just put in his/her .forward


"|cat > /dev/null"


Remember that the quotes, they are mandatory (if you’re copy’n'pasting this, change the quotes because WordPress loves to change things)