Dynamic IP hostmasks

[MONGi]

Hello,

I have the problem that change the complete ip-ranges of users, not just the first two blocks as I had first suspected.

Now i`ve activate the following lines to fix the problem (but the changes not work):

Secure_Ip_3 = 1 1 0 G1M
Dynamic_DNS_Lookup = ALWAYS


I write following in the GUI:

TEST123@name.dyndns.org
or
TEST123@HOSTNAME \\the real hostname of the Server


In FlashFXP im write TEST123 under ident_user_id and would connect to the ftp, but get this error-log:

530 Login failed: Your IP/hostname is not authorized.


Can someone give me the error cause?

In the middle of this thread already exists a similar question that had not helped me.
I have used search function ;)

I am grateful for all advices.

[Yil]

Moved this here as this is an ioFTPD question and not a ioNiNJA question...

I'm not sure what problem you are trying to solve but I assume it's using a dynamic dns address so I'll address that. It looks like you already have Dynamic_DNS_Lookup = ALWAYS which is the first thing you need.

To enable normal SiteOps to use dynamic hostname lookups you need to allow that with a Secure_Ip rule. Check out rule #4 in the default .ini file.
# Allow dynamic :ident@foo.bar.com style masks
Secure_Ip_4 = 1 2 0 G1M

NOTE: You must have rules 1-3 active before it, if you don't just go ahead and rename this to the next free number so it might end up being Secure_Ip_2 or whatever. M flagged users can always set any hostmask (you will see an override message when you do this).

KEY POINT: Pay special attention to the very first character (the ":"). That's what tells the server it must lookup the IP address of the hostname for that user every time they login since it might be different each time...

The user's hostmask in your example should be ":TEST123@name.dyndns.org". Check out 'site help addip' which I believe has more info and examples. Also be aware that the Reject_Unknown_Ips option doesn't play well with dynamic hostmasks so that's why I invented the knock feature if you really have to lock down the server.

[MONGi]

Hi Yil, thank you for your quick support :)

i`ve tested your instructions, but i get always the same error at login: 530 Login failed: Your IP/hostname is not authorized.

I want, if a user receives a new ip by his provider, ioftpd the ip updated independently.
Since then i`ve used the entry f.e. *@234.12.*.* but after a indefinite time he get a complete new ip-adress.
Can you look on my ioftpd.ini file, maybe i set wrong settings?


[Network]
# list of services (you just defined them above!) to start
Active_Services = FTP_Service

# If Ident_Timeout set to 0 the server won't send any IDENT requests,
# in which case you'll need "*@..." for all user hostmasks or you need
# to enable the Ignore_Hostmasks_Idents option.
Ident_Timeout = 5 # Set ident timeout (10)
Hostname_Cache_Duration = 1800 # Seconds cached hostname is valid
Ident_Cache_Duration = 600 # Seconds cached ident is valid (1800)

# Ignore ident portion of hostmasks. If you set this to true then the system
# will ignore any ident difference and just examine the host/IP portion of
# the hostmask.
Ignore_Hostmask_Idents = False

# To be removed from the ban list a user MUST NOT attempt to connect during
# the temp ban time else he'll just keep pushing the ban farther out...
Connections_To_Ban = 50 # 6 connections without a reset and
# IP is temp banned (5)
Ban_Counter_Reset_Interval = 60
Temporary_Ban_Duration = 300 # 300 Seconds host remains banned

# Maximum time to suppress log entries for the same reason from the same IP.
# Default is 10.
;Max_Log_Suppression = 10

# Number of minutes to increase the delay between each suppressed message
# until Max_Log_Suppression is reached. Default is 1 additional minute per.
# You can now array to get 1,2,etc messages per Max_Log_Suppression window
# which with large values means you can reduce logfile spam if needed.
;Log_Suppression_Increment = 9

# this controls how often the socket bandwidth scheduling thread is run. If
# you are not limiting bandwidth then this can be disabled.
# Valid values: HIGH/NORMAL/LOW/DISABLED
Scheduler_Update_Speed = HIGH

# List of space separated wildcard IP/hosts that are immune from banning.
# NOTE: There is a difference between IP addresses and hostname masks. The
# decision about whether to reject an address for too many connection
# attempts (i.e. auto-ban) is made immediately after the connection is
# established. This means that the reverse DNS lookup to get the
# fully qualified hostname hasn't even started yet (unless a cached
# answer is still around and valid). This is usually fine since you
# obviously can't be banned on the first attempt, but if you tried 10
# connection attempts all at the same time this might result in a ban
# and rejection for some of them until the name finally resolves.
# Once the name has been resolved the next connection attempt will
# ignore and clear the temp ban.
# NOTE: 127.0.0.1 is always immune.
;Immune_Hosts = 192.168.0.*


# Permission list for user's whose IP/host masks should be immune from auto-
# banning. Essentially this is the same as collecting up all the IP/host
# parts of the matching user's hostmasks and automaticaly specifying them as
# Immune_Hosts. The user list and associated IP/hosts are only updated at
# startup and rehashes.
# WARNING: just one user with *@* or something similiar (or changed to that
# later on!) will effectively turn off auto-banning and thus use of
# this option is discouraged!
;Immune_Users = I


# Requirements/rules for adding IP masks by the specified users. You can
# have up to 20 consecutive entries starting at 1 which will be processed in
# numerical order with the first satisfied rule allowing the change. If
# no rule is matched then the change is prohibited and the user shown a list
# of valid rules for them. If Secure_Ip_1 is not defined everything is
# acceptable for backwardward compatibility.
#
# Format: <ident> <type> <min-fields> <users>
# <ident> = 0 -> User ident not required (*@...)
# 1 -> User ident must be supplied (ident@...)
# <type> = 0 -> Only sets of numeric IPs allowed
# 1 -> Allow fully qualified hostnames (...@hostname)
# 2 -> Allow fully qualified hostnames that will be resolved
# at login time allowed (:ident@hostname).
# 3 -> any hostname/IP (may include wildcards OR be dynamic)
# <min-fields> = Minimum number of non-wildcard fields separated by periods.
# NOTE: A fully qualified hostname doesn't need to pass the minimum field
# test so <type>'s 1 and 2 ignore the <min-fields> argument.
#
# Master accounts can do whatever they want, but if they don't match a rule
# the log entry and status message will indicate that a "master override"
# was used.
#
# If you want to support *@* and other such things without that message
# set this rule to match M (or whoever else) accounts instead of nobody (!*).
;Secure_Ip_1 = 0 3 0 !*

# Allow *@1.2.*.* or ident@1.2.*.* or more specific style masks
;Secure_Ip_2 = 0 0 2 G1M

# Allow ident@foo.bar.com style masks
;Secure_Ip_3 = 1 1 0 G1M

# Allow dynamic :ident@foo.bar.com style masks
Secure_Ip_4 = 1 2 0 G1M

# Allow ident@*.bar.com style masks
;Secure_Ip_5 = 1 3 2 G1M

# NOTE: Only M accounts can set *@* with these defaults


# Maximum number of worker threads to use to resolve hosts. If you raise
# this make sure to raise the number of Worker_Threads at the top of the
# file to a larger value to keep from creating/destroying threads.
Max_Resolver_Threads = 2

# If a user hostmask begins with a colon ":" and is a hostname without any
# wildcards then during the login event you can control what happens.
# undefined -> do nothing
# "NEVER" -> do nothing
# "KNOCKED" -> only do lookups if the user has successfully KNOCKED.
# "ALWAYS" -> always lookup the specified hostname
Dynamic_DNS_Lookup = ALWAYS

# If Dynamic_DNS_Lookup is set to KNOCKED/ALWAYS or you are using an external
# user module then in theory someone could watch for delayed responses to
# the login command and try to statistically determine usernames. To prevent
# this you can set this to the maximum number of seconds to randomly delay
# all responses to the login command.
;Random_Login_Delay = 5

# Set this to true to automatically disconnect connections from hosts who
# do not match any user's IP/host mask.
Reject_Unknown_Ips = True

# When using Reject_Unknown_Ips there is no way to even get to a login prompt
# if your IP has changed. This can now be a common problem for people using
# dynamic hostmasks. The solution is a very simple knock-knock system which
# will add the knocking IP to a temporary list so you can connect.
# Knocking essentially means connecting via TCP to between 1 and 5 ports in a
# short amount of time (60 seconds per). This can easily be done in most FTP
# programs by just setting up fake ftp servers on the knock ports and trying
# to connecting in order, or by using the ioKnock GUI on windows machines.
#
# NOTE: You must connect in order! Thus using at least 3 non-sequential ports
# means a sequential port scan won't trigger the knock and produce a
# prompt on the real FTP port.
;Knock_1 = 15121
;Knock_2 = 11123
;Knock_3 = 12123

# How many elements of the dotted IP address should be obscured with * in
# the logfiles. IP=1.2.3.4 with 1 -> 1.2.3.*, 2 -> 1.2.*.*, 3 -> 1.*.*.*
# and 4 -> -hidden-.
;Obscure_IP = 2

# How many elements of the dotted hostname should be obscured with * in
# the logfiles. NAME=baz.foo.bar.com with 1 -> *.foo.bar.com, 3 -> *.*.*.com
# and if the name is totally obscured -hidden- will be shown instead.
;Obscure_Host = 2

# Log OpenSSL library errors during transfer to Debug.log. Default is false.
Log_OpenSSL_Transfer_Errors = True


I`ve tested the knocking-feature too, but the error are the same...

[Yil]

Mongi: Please note that ";" at the start of a line in the .ini means the line is commented out and any default value will be used.......

If you can cover all possible addresses from a user in like 20 hostmasks I'd do that, but if you can't then you need to use the dynamic dns feature :*@hostname.dyndns.org or whatever and they have to keep it updated with their current IP. I believe ioFTPD is the only server to allow such a feature but it can come in handy...

The next problem you have is you ARE using the Reject_Unknown_Hosts feature which means the server is locked down to only respond to servers whose IP/hostname matches a hostmask and in this case the user likely won't match. That's because the server doesn't test every dynamic hostmask on every connection so the user will have to use the knock feature to let it know it should let them try to login.

Just set up a simple knock like:
Knock_1 = 15121
;Knock_2 = 11123
;Knock_3 = 12123

That means they just have to TRY to connect to 15121 once (notice the other 2 lines are commented out still?). No response will happen, it will just drop the connection immediately but the user will get to login to the regular server port next time they try because it now knows to not immediately reject them as not matching any hostmasks.

After that they can try to login and things should work for them.

Having a user with a constantly wildly changing IP address and a locked down server is hard to deal with, but the dynamic hostmask and knock feature is a better solution than anybody else has :)

To try to debug what is going on check the ioftpd.log and/or error.log file. I think one of the logfiles records the dynamic hostmask lookup, and the ip/host the user connected from is important because you can check to see if the dynamic dns name resolves to their current IP address. Normally the dynamic dns entries have 1-5 minute cache times so a user who just updated it might need to wait 5 min before ioFTPD can see the new IP address...

[MONGi]

Hello Yil,


Mongi: Please note that ";" at the start of a line in the .ini means the line is commented out and any default value will be used.......

I know it.


If you can cover all possible addresses from a user in like 20 hostmasks I'd do that, but if you can't then you need to use the dynamic dns feature :*@hostname.dyndns.org or whatever and they have to keep it updated with their current IP. I believe ioFTPD is the only server to allow such a feature but it can come in handy...

Ok, i will use this option.


The next problem you have is you ARE using the Reject_Unknown_Hosts feature which means the server is locked down to only respond to servers whose IP/hostname matches a hostmask and in this case the user likely won't match. That's because the server doesn't test every dynamic hostmask on every connection so the user will have to use the knock feature to let it know it should let them try to login.

You mean, i must coment out Reject_Unknown_Hosts?


Just set up a simple knock like:
Knock_1 = 15121
;Knock_2 = 11123
;Knock_3 = 12123

That means they just have to TRY to connect to 15121 once (notice the other 2 lines are commented out still?). No response will happen, it will just drop the connection immediately but the user will get to login to the regular server port next time they try because it now knows to not immediately reject them as not matching any hostmasks.

After that they can try to login and things should work for them.

Having a user with a constantly wildly changing IP address and a locked down server is hard to deal with, but the dynamic hostmask and knock feature is a better solution than anybody else has :)

The knocking-feature i will testing again.

To try to debug what is going on check the ioftpd.log and/or error.log file. I think one of the logfiles records the dynamic hostmask lookup, and the ip/host the user connected from is important because you can check to see if the dynamic dns name resolves to their current IP address. Normally the dynamic dns entries have 1-5 minute cache times so a user who just updated it might need to wait 5 min before ioFTPD can see the new IP address...

Yes, if i have problems the first way for me is looking in ioftpd.log and/or error.log file.

Is that all that needs to be changed?
All other entrys are ok?

I would also ask if i have understood everything right so far. My english is somewhat broken :)

[Yil]

Go ahead and give it a try it. The only thing wrong in the config file is the Secure_IP stuff but that doesn't matter since you have it effectively disabled which means SiteOps can set any hostmask they want which is fine for the moment.

I find it weird that a server using Reject_Unknown_Ips lets a non-knocking user even get to a login prompt. Either you also have some regular hostmasks for that user covering them, or you have a very permissive hostmask set somewhere... Check out 'site help findip' which will show you which hostmasks of which users would allow a particular IP or non-dynamic hostname to login. Try 'site findip 1.1.1.1' for instance and see what hits you get. If you turn up a *@* or something somewhere you effectively have disabled Reject_Unknown_Ips as that would allow all IPs anyway...

[MONGi]

Hi,

i´ve checked the 'site help addip' and find some interesting informations.
Will test it the next days.

Thanks a lot, i will give a feedback later.

[MONGi]

Hello again,

i´ve read now the instructions and have come to the decisive that no variant is useful for my problem.

Excerpt:

The choice is then to either use 25 hostmasks with some
using only 2 octets (*@1.2.*.*) to try and cover all possibilities,
or to let the user register with a dynamic DNS service like no-ip.com
or dyndns.com and use that dynamic hostname in the hostmask.

So i would like use a hostmask that include ident-function and last two octets (Provider-hostmask).
As additional secure is an authentication with ident-feature!
Example: Jim123@*.*.myprovider.com

It´s possible to use the identification "Jim123" in flasfxp under "side manager/ftp-connection/advanced/ident user id" to identify the right user for connecting? I don´t like only use ".myprovider.com", so anybody can login.
The port 113 are forwarding to the right ip on my router.

Anyway i get always the same error in flashfxp:
530 Login failed: Your user ident response did not match.

In error.log:
03-20-2014 00:56:19 Host '*@xx.xxx.xxx.xxx' (xxx-xxx-xxx-xxx-xxx-xxx.xxxx.xxxxxxxxxxxxxxxxxxx.xx) did not match any of user 'Jim123' allowed ident responses.
In '*@xx.xxx.xxx.xxx' are the ip and in (xxx-xxx-xxx-xxx-xxx-xxx.xxxx.xxxxxxxxxxxxxxxxxxx.xx) are the ip and Provider hostmask.

Have anybody a idea whats are my problem at login-identification?

Many thanks in advance.

[Yil]

If you look at the error.log message: Host '*@xx.xx....' the leading * means the remote machine returned no ident response so there was no chance it could match a hostmask that requires one.

This is usually caused by 2 issues. The first is the remote machine just didn't answer the ident query. The other is a software/hardware firewall prevents ioFTPD from sending the ident request in the first place. Check to see if login messages in ioftpd.log have at least a few hostmasks including idents from remote machines. If so then it's a user problem. If they all have * for the ident field then it's your problem most likely.

This turns out to be a common problem with software firewalls where ioFTPD is run from within a truecrypt filesystem, NAS, etc. The software firewalls can't trust that the ioFTPD.exe is really the same as it was before because it knows it's not a local fixed disk. That's a feature of a good software firewall. I forget what I did in window's firewall, but in comodo I just start ioFTPD up and then immediately connect to it in flashfxp so it asks me if I want to allow incoming connections and then if I want outgoing connections so I can answer yes :)

If you do have an outoing connection issue it probably means FXP will be broken some of the time (when you need to initiate the connection), so you'll want to fix the issue.

[MONGi]

Hello,

hm...what´s to do if i have no software-firewall/antivirus?
In my network works only a hardware-firewall (router) and the port 113 is forwarded.

In a other thread i have found follow information:
Ident is an incoming connection to port 113

The windows firewall are disabled because using vpn-connection on this machine.

So i think we have no matches to your answers.

If it possible to find the problem under the os? (Windows Home Server 2011).

[MONGi]

Hello, i`m again.

Ident is an incoming connection to port 113
Need more ports to be opened unless the tcp-port 113?

Unfortunately it does not work yet.

Thanks for any help.

[Yil]

ioFTPD needs port 113 OUTGOING in order to request ident from a machine logging in. Since outgoing connections are normally allowed by hardware firewalls this is usually only a problem with a software firewall which it looks like you are not using so you should be fine. On the other hand the guy logging in who specifies an ident in their hostmask needs to forward and reply to the request...

Try changing the user's hostmask to *@host.dyndns.com and see if that works. Since this only resolves to 1 IP at a time this should be plenty secure and all that's really needed.

[MONGi]

Hi Yil,

i have one more question:

Try changing the user's hostmask to *@host.dyndns.com and see if that works.

Do I understand something wrong? The address "*@host.dyndns.com", must be a/the hostmask from the user who login or the hostmask to reach ioftpd on the local machine?

I`ve try to set the "local" hostmask, also my one *@host.dyndns.com in my User-Profile

So i get follow error in error.log:
04-03-2014 21:34:47 Host '*@ip.ip.ip.ip' (hoskmast.from.my.provider) did not match any of user 'xxx' allowed hosts.

ioftpd.log don`t create any logs...

I'm totally helpless :(

[Yil]

You need a ":" on the front. :*@host.dyndns.com

That forces the lookup on login attempt which is required for dynamic hostmasks.

[MONGi]

Hello,

this is very strange and don`t really understand.

Changed hostmask:
:*@host.dyndns.com

Error.log file:
04-04-2014 21:10:12 Host '*@ip.ip.ip.ip' () did not match any of user 'xxx' allowed hosts.

Now i can`t login with any other user-account!
I get always the same error as above.

If i change the hostmask to *@ip.ip.*.* the login works.

Whats wrong?
I'm not smart in dealing with hostmask/ip at login.

[Yil]

I don't know what else to tell you. Hopefully someone who uses dynamic hostmasks can chime in with confirmation that things are working. I don't make use of the feature myself so perhaps it's broken, or there is some subtle issue on your end.