ioFTPD v7.0.3 Released

[dr.owned]

Yil

yep, seems like if I just return resolved links from the script in all cases, everything works just fine.

as of the rest - you're the boss and i'm just a humble user i can't make you do what you think shouldn't be done

p.s. crash report.
1. virtual directory script returns resolved link to existing file.
2. this file is then RETR-ed (i'm not sure whether REST 0 or REST >0 in this case)
3. in pre_retr event i decide to decline RETR request by saying:

iputs -noprefix "550 $fname: No such file or directory."
set ioerror 1
return 1

4. ioftpd goes away.
5. note - same works fine for non-virtual transfers

who's guilty?

[dr.owned]

hm... looks like if I return resolved link to a subdirectory when generating virtual directory contents, i can CWD into generated item, but ioGui shows that i'm not inside the virtual directory but inside a linked one. which makes sense but kinda spoils the fun because you can't distinguish between being in a virtual directory and being in its linked counterpart.

[dr.owned]

and a final noob question - how do you make a mountpoint that is hidden (from everybody, except maybe only M-s) but still accessible for everyone. so users can't see it but are able to cwd into it and from there do what they want.

[Yil]

dw.owned: There really isn't any way to hide a directory and yet have it still be accessible. You can use private settings [chattr 0] to specify who can see/access a private directory via "1 !A =group" type settings but if the user matches they can see it. I presume you want to do something like have a /_real normal users can't see and yet make everyone access stuff through virtual directories like /music or something?

You could try creating a 000 permissions directory that would show up like d--------- so it wouldn't really be hidden. Nobody but VM flagged users could enter it normally because they are immune to +r checking. The tricky part is you couldn't make normal symbolic links into that directory because access requires +r to the entire directory path. You can however try returning links into there via virtual directories. I believe I was smart though and as a safety check resolved paths from virtual directories are fed back into the system to verify +r for the whole path. I haven't tested that though so it's worth a shot...

I don't suggest VFS mountfile tricks, because I'm working on a reverse resolver to take real paths and turn them back into VFS paths as both a useful feature for scripts and as a safety feature for NTFS symbolic and junctions that could expose parts of the filesystem that shouldn't be visible.

I'm open to suggestions like 000 dirs marked as Private and thus only accessible to VM flagged users that start with a "." (to prevent exposing dirs on existing setups when upgrading by accident) should be hidden from user listings for regular users but ignore +r checks in path resolving or something. I would guess that would be similiar to -r+x style unix dirs and would suffer from user's being able to guess at names as well. If you have a suggestion feel free to chime in!

[dr.owned]

Originally Posted by Yil

I presume you want to do something like have a /_real normal users can't see and yet make everyone access stuff through virtual directories like /music or something?

exactly my thoughts

Originally Posted by Yil

The tricky part is you couldn't make normal symbolic links into that directory because access requires +r to the entire directory path.

yep, it was my first thought. there is a trick with ntfs where you can deny directory listing permissions for the higher-level directory without applying them to lower-level children and thus hiding its contents from any unnecessary recursive searches while keeping files accessible from a lower-level directory using full path to it. it seemed pretty natural and i presumed ioftpd would do the same. but no, the server verifies read permissions for all directories in the path... too bad maybe it's worth being configurable? ) like FullVirtualPathCheck = TRUE/FALSE

i also learned that there are some "undocumented" features in ioftpd like !vfs:add. judging by the name it should alter current connection's mountpoint list by adding one on the fly. and the next LIST command would already output new directory structure. i'd like a comment on that. what does it actually do? and if i'm correct, would there be a !vfs:remove or something like that?
i suppose you already see where i'm going with this !vfs:add -> process symlinks -> do file ops -> !vfs:remove -> i'm happy

[Yil]

My ISP is having issues with it's FTP server at the moment... Here's a forum link to the new version.

[Yil]

v7.0.3 Release Notes:

1) Files in \System:
   Changed : ioFTPD.[exe,pdb] - Version 7.0.2.0.

2) Files in \doc:
   Changed : itcl.txt


*** New Features

3) New iTCL feature for [ioVirtual] command.  The AddLink <Path> argument
   and the AddDir/AddFile <Link> argument may now start with a ":" which
   will be stripped off the string but modify the behavior of directory
   listings so the entry will show up as a plain file/dir instead of as
   a symbolic link while still keeping the linkage internally.

4) Virtual directories can now show symbolic links to files.  Previously
   the only symbolic links were to directories.


*** Bug Fixes:

5) Second try fixing a bug in the EXEC module that would crash the server
   in some cases.

[ArtX]

grrrr yil!!!! i just updated to 7.0.2

[dr.owned]

i'm trying to prevent direct execution of a CWD command and CWD to different directory instead. how can i do it? pre-cwd doesn't seem to help much.
it's an attempt to lock user one level below the root folder to be able to return links to other root-level directories (in virtual directory script) while user is stuck in a separate one.

[Yil]

Originally Posted by dr.owned

i'm trying to prevent direct execution of a CWD command and CWD to different directory instead. how can i do it? pre-cwd doesn't seem to help much.
it's an attempt to lock user one level below the root folder to be able to return links to other root-level directories (in virtual directory script) while user is stuck in a separate one.

I don' t think there is a way you can re-direct the user to a different location for a CWD in the normal filesystem right now. Best bet it to wait a bit for v7.1 where I can find a solution to your problem via hidden pass-through only mountpoints, +x-r dir support, the pre-cmd rewrite idea, or a feature from previous discussions which includes locking users into their home directories. Some variants of locked home dirs make it a VFS path inside a mountfile BUT it acts like '/' and you need to provide links to paths outside of it to expose directory trees. When you CDUP or CWD / you end up back in home as a special cased feature. If coupled with virtual dirs that would allow you to do whatever...

I'm also tempted to support a much more powerful form of pre-cmd. Instead of just being able to accept/reject I think it would be simple to add a new ioTCL command that would allow you to provide replacement text. Thus you could re-write CWD to redirect wherever you wanted and/or do a whole host of other cool things. You would still have to watch out for RETR/STOR/LIST /foo/bar/baz type commands as well but it would allow you to lock down where users could wander which would make it more powerful than -r+x ever could be...

Perhaps I'll have to write a script to shadow a real directory tree virtually as a local test. That might be interesting and see if I can't support virtual directory creation, etc all without too much hassle...

[dr.owned]

wow.. so many doubts there were about my previous suggestions and all of a sudden there's a whole post promising near-ultimate features based of my reports and it's actually your 500-th post. is that the case?
anyway these are great news. can't wait

btw,
var Set variable value
seems to set a variable so global that even scripts triggered by other connections are able to use them. is there a way to declare connection-specific variables?

[dr.owned]

i also often come to a conclusion that there definitely should be a pre-connect event that is triggered on a connection attempt. and from there you can choose to either accept connection (ioerror = 0) or drop (ioerror = 2, reply nothing, like there is no server at all) or reject (ioerror = 1, reply "service unavailable" or like that). because there are cases when extra connections from a certain address shouldn't even be accepted rather than just rejected later on login attempt (and having them logged in ioFTPD.log).

[Yil]

There are a couple of points to consider when handling connections attempts. First off, there is no way short of writing a windows driver to reject a connection completely which is what I would really like to do. There used to be a way to do this years ago with winsock but then people started denial-of-service attacks against machines by initiating the TCP handshake and then not responding so MS changed the way windows works so it now always accepts TCP connections if a socket is listening for them. Therefore the server's only choice is to accept and then terminate the connection which is what happens when you get auto-banned for hammering the server.

I've taken the position that if you get auto-banned the server shouldn't respond with anything and just drop the connection. I've toyed with the idea of responding with a "you've been auto-banned" type message and the duration of the ban (it resets each attempt). I have no problem making the ban reset optional and/or making the reply optional or replying only some of the time, if people want that, but so far nobody's mentioned it. I don't think it would hurt to reply at least once and perhaps every 5 minutes there-after or something with a message to that effect. I don't believe anything should ever be returned in the case where the host is banned in Hosts.Rules.

I've also toyed with the idea of a script based accept/deny such as you are suggesting. The reason I decided against implementing it, at least until someone actually asked for it, was because external scripts are expensive to call and it's better left until later. It would be pretty easy to DDoS a server with a script handling raw connection attempts. This would be somewhat mitigated by having auto-bans checked first, but without actually knowing the username/password I figured it's best to avoid calling external scripts so I've tried to handle the common cases of rejecting valid users by allowing you to set for each user the number of connections per IP and the total number of logins.

Right now you can do exotic acceptance of login attempts by using a pre-cmd on the login or pass commands. You might also be able to do something like [iputs -nobuffer] followed by a [client kill $cid] in the OnFtpLogin event so you know you're dealing with a valid user yet you force them off. I'm not sure that's a good idea though as I'm not sure if that would always force the buffer to be completely sent in all cases which could look like a dropped connection rather than seeing a denied/logged off type message.

What I probably should do is test the return value of the OnFtpLogin event if defined and if error code text was output to the user (this would be your response to the PASS command) and an error was returned to gracefully force the user off without generating a login failed log entry as that would be up the script to do. That's going on my TODO list

Having given that rather lengthy response just to cover how things work right now and why, I should mention that also on the TODO list is script based manipulation of the auto-banned and permanent banned lists. I'd really like to be able to automatically add/remove addresses/masks into the server via a script...

Now, let me address the one problem I think you alluded to that might be driving the need for the accept/reject script. The ioftpd.log file is getting spammed? Check out the Max_Log_Suppression and Log_Suppression_Increment features.

Max_Log_Suppression: The maximum time (in minutes) to suppress rejection log entries (auto-banned, unmatched client, or Host.Rules) for the same reason from the same IP.

For some reason the Log_Suppression_Increment option doesn't appear in the .ini file (that's a bug) but it is documented in the Changelog...

Log_Suppression_Increment: the number of minutes to increase the delay between each suppressed message up to Max_Log_Suppression. Default is 1 additional minute per.

If you use an hour for max and an increment of an hour or so I think it should output 1 message per hour for a particular IP for each type of login error...

Would a modified version of OnFtpLogin and the log error suppression features already there solve your problem? Auto-ban manipulation (perhaps even with a limited choice of string responses) help? Should I provide a way to suppress auto-banned rejection messages completely?

I don't have any problem adding an OnConnection event like you requested, but I just want to make sure I'm helping you solve the problem you really want to solve.

--

You can't have connection specific global variables. However you can easily achieve this behavior. In ioYil I used two different methods depending on what I was doing. Just use something like foo-$cid as the name - tada! Or you can use an array of $cid->stuff mappings. However in the array case you must protect the array with a global [waitobject] lock to prevent race conditions on reading and then modifying the value across multiple threads.

[ArtX]

v7.0.3 Release Notes:

1) Files in \System:
Changed : ioFTPD.[exe,pdb] - Version 7.0.2.0.

Little typo there Yil? or has the internal version number not been updated?

[dr.owned]

Yil

no, log file spam in not an issue. but after your exhausting post i realized that scipt-controlled connection handling is really an unstable and vulnerable way to do things.

and what i think i might be off with is a function that puts given ip address to auto-ban list. since i decide to reject connection i'm confident about not having that given host connected to server again for some time.

so an auto-ban feature seems like a solution. but placing ip to auto-ban list is kinda too cruel punishment because there's that ban time auto-prolonging feature and settings in ioftpd.ini are tuned to handle ddos attempts. so maybe there's a point in giving this function parameters that specify same things present in ioftpd.ini concerning auto-ban. that would do. and since it's only about a plain ip addresses list, a function that removes specific ban or all bans should be there too.

as of deciding whether to reply or not during ban period my firm position is not to.

p.s. i found a way to lock user in his home directory virtual dirs are god