IP blocked in Rules but still accessing FTP



  • I have an alias for IPs I want to manually block.  Lets just call it "Bad Guys".    My rule set has "Bad Guys" near the top of the rules. The only rules above it are other blocks and a white listed IP of mine.   
    So I've had this guy the past few weeks logging onto my FTP server trying to guess his way in.  He hits me several times a day but stops guessing before the FTP's autoban feature kicks in.  I see several IPs in the same range listed for days.

    So I started adding his IPs to my "Bad guys" list.  I've entered about 80 of them now but today I noticed that one of the IPs he's using in a recent attempt is an IP that's already blacklisted on the "Bad guys" alias.  I checked the rule and it's active and set to block.

    How can he be getting in with an IP that's blacklisted at the top of the rule set before any pass rules (other than my own IP)?



  • He can't if your rules are correct.  Post a screencap of your WAN rules.



  • The only thing I can think of would be to check and make sure you don't have any floating rules that allow traffic.


  • Rebel Alliance Global Moderator

    Without your rules there is no way for us to help you - clearly your doing it wrong or it would be blocked is the simple answer.

    Please post your floating tab if anything is in there and you wan tab.  And your port forwards would be helpful in seeing how your forwarding ftp into your network in the first place.



  • I've attached the two screens requested.





  • Rebel Alliance Global Moderator

    Well looks like your missing some stuff in your wan..  And what is in remote management and remotemangement ports?



  • RemoteManagement is an alias with a couple of fixed IP addresses we use to access pfsense from outside our LAN (setup by pfSense support btw).

    What's missing from the WAN?  pfSense is running in transparent mode (bridge mode?) and not as a router.  That may be why it looks like it's missing some things.


  • Rebel Alliance Global Moderator

    well for one rule that would even allow ftp?  Looks like that is not the full rule set..  Looks like there more under that from the bottom of that screenshot.

    And why would you allow to wan net??  Seems odd - shouldn't it be wan address?



  • Yes there were more rules.  I only copied the rules set down to the level that showed the block for "Badguys". The IP I'm trying to block is listed in that alias so it should stop at that point regardless of the rules below it.  I was just showing that there weren't any rules above it that should have allowed it to pass. Once it hits this block the rest of the rules don't matter.

    WAN net (set up by pfSense support) allows access to the pfSense settings when in transparent mode.  Should it be an IP? I don't know.  Since pfSense support set it up and they're smarter than I am, I left it the way they had it.



  • From my FTP server.  I get hit every few min.


    (001914)5/7/2015 15:47:34 PM - (not logged in) (71.232.46.105)> 220-Thank you for visiting namehere ftp server.
    (001914)5/7/2015 15:47:34 PM - (not logged in) (71.232.46.105)> 220 All actions are logged.
    (001914)5/7/2015 15:47:34 PM - (not logged in) (71.232.46.105)> SSH-2.0-libssh2_1.4.1
    (001914)5/7/2015 15:47:34 PM - (not logged in) (71.232.46.105)> 500 Syntax error, command unrecognized.
    (001914)5/7/2015 15:47:37 PM - (not logged in) (71.232.46.105)> disconnected.
    (001915)5/7/2015 15:54:15 PM - (not logged in) (157.7.237.232)> Connected on port 22, sending welcome message…

    And from my "badguys" alias as seen on the rules, they're blocked.  So how did they get to the FTP?  They should have been blocked long before they got down to the port settings for the FTP connection.



  • Banned

    Dude. FTP is NOT SSH. Sigh. WTF.

    (001914)5/7/2015 15:47:34 PM - (not logged in) (71.232.46.105)> SSH-2.0-libssh2_1.4.1
    (001915)5/7/2015 15:54:15 PM - (not logged in) (157.7.237.232)> Connected on port 22, sending welcome message…



  • WAN net is the entire subnet your WAN interface is part of.  WAN address is just the IP address used by your WAN.

    My personal view is that you should ignore this guy or you will be playing whack-a-mole with him and other bots forever.  Let them knock on your door.  Just ignore them.  However, the challenge in this situation is how is he getting in in the first place?  We still haven't seen anything that shows the link between pfSense and your FTP server, no FTP rule, no port-forward.  Are you using an IP alias or is your FTP server listening on your WAN IP address?

    Dude. FTP is NOT SSH. Sigh. WTF.

    Regardless, how is this IP getting past the firewall?


  • Banned

    @KOM:

    Dude. FTP is NOT SSH. Sigh. WTF.

    Regardless, how is this IP getting past the firewall?

    How? Because the "remotemanagement" allow rule is before "badguys" block. Useless.



  • @doktornotor:

    Dude. FTP is NOT SSH. Sigh. WTF.

    Of course not.  He's connected to my FTP server already when he's entering the SSH command.  He should have never been able to connect to my FTP server if his IP was blocked.  He should have never been able to get to the FTP prompt to attempt to enter the SSH command.


  • Banned

    Kindly go Google the difference between SSH and FTP. You don't have any FTP server there. libssh is not FTP and port 22 is not FTP either. Also your rules ordering is wrong, as noted above.



  • @doktornotor:

    @KOM:

    Dude. FTP is NOT SSH. Sigh. WTF.

    Regardless, how is this IP getting past the firewall?

    How? Because the "remotemanagement" allow rule is before "badguys" block. Useless.

    I don't understand. Remotemanagement only lists two fixed IPs for granting access.  He isn't from either of those IPs.  How is that making it useless?


  • Banned

    @cdsJerry:

    I don't understand. Remotemanagement only lists two fixed IPs for granting access.

    Apparently not. Also, those pfBlocker rules are just whacky. I really don't think you have a clue what you are doing.



  • OK, I've attached more rules. You will see the bottom on is FTP but by being on the bottom, only access that hasn't already been blocked should get down the rule set this far.  And yes, there is an FTP server, and yes, I know the difference, and yes, he's attempting to enter SSH commands on and FTP connection, and no, he shouldn't have gotten that far to do so and that's what I'm trying to figure out. How did he get to the bottom of the rule list if there's a specific block for his IP at the top of the list (right below Remotemanagement which only passes two IPs).




  • @doktornotor:

    @cdsJerry:

    I don't understand. Remotemanagement only lists two fixed IPs for granting access.

    Apparently not. Also, those pfBlocker rules are just whacky. I really don't think you have a clue what you are doing.

    The pfBlocker rules are created by pfBlocker, not me.  None of them are giving a pass to this guy's IPs. They're all blocks.


  • Banned

    Let me repeat the port 22 is NOT FTP and libssh does NOT support FTP at all. What server are those logs from?

    @cdsJerry:

    The pfBlocker rules are created by pfBlocker, not me.  None of them are giving a pass to this guy's IPs. They're all blocks.

    Yeah. Based on your whacky misconfiguration that's apparently trying to block the entire world.

    @cdsJerry:

    OK, I've attached more rules.

    Yeah. Looking at that censored mess… humble suggestion: go ditch that frenzy and restart from scratch. Or perhaps better hire someone for the job.



  • Port 22 is indeed routed to the FTP server and the FTP server is listening on that port as well as others.  FTPFileZilla is the FTP server running.

    And while you call this a "whacky misconfiguration", I'll point out again that support from pfSense has reviewed the configuration. Chris himself set up parts of it.

    And yes, blocking most of the world would be just fine with me because our business isn't a world-wide business.


  • Banned

    Sigh.
    1/ No, port 22 is NOT routed to the FTP server. Not per the rules you posted.
    2/ Oh, sure. Call me dalai lama.
    3/ No. There's this implicit block all rule. Allow what you need from where you need ONLY. The rest is blocked. Not this ridiculous overhead with millions of table entries.

    Of course, when you keep sticking allow everyone from everywhere to anywhere any protocol in random places between some more random disabled rules, throw in a bunch of inexplicable rules with some random IP as destination, mix that with bunch more aliases to obfuscate the whole mess, then this most likely won't work properly, and you'll get people accessing what they shouldn't.

    Those rules are frickin' unmaintainable mess with no logical ordering.



  • Yeah. Looking at that censored mess… humble suggestion: go ditch that frenzy and restart from scratch. Or perhaps better hire someone for the job.

    LOL. So I should hire someone better than the guy who wrote pfsense?  Right.  Look, I get it, you enjoy punking up on me. Fine.  But what you say sorta falls apart when you say things like Chris doesn't know how to setup his own software.  If you think that little of him, why are you running his software in the first place?    Can we stop the bully-bash and get back to the question of how an IP is able to reach the FTP server to even attempt his SSH command there?  Of course it won't work, it's an FTP sever. That's beside the point.



  • @doktornotor:

    Sigh.
    1/ No, port 22 is NOT routed to the FTP server. Not per the rules you posted.
    2/ Oh, sure. Call me dalai lama.
    3/ No. There's this implicit block all rule. Allow what you need. The rest is blocked. Not this ridiculous overhead with millions of table entries.

    The alias FTPFilezilla passes port 22 to the server at that IP.  The server on that IP is set to listen to port 22 for FTP.  It's routed via the FTPFilezilla alias.

    You don't like the pfBlocker package. I hear that. Don't install it then.


  • Banned

    Don't pull Chris or anyone else into this shit. You cannot tell SSH from FTP and those rules are frickin' unmaintainable mess with no logical ordering, randomly plopped together. Ditch this crap. Noone will waste time debugging this mess with tons of inexplicable aliases and random allow entire world to anywhere rules in between.

    As for pfBlocker, I was one of the pfBlockerNG beta testers. What I don't like is clueless people doing clueless things with that.

    Flush the mess down the drain. Enough said.



  • @doktornotor:

    Of course, when you keep sticking allow everyone from everywhere to anywhere any protocol in random places between some more random disabled rules, throw in a bunch of inexplicable rules with some random IP as destination, mix that with bunch more aliases to obfuscate the whole mess, then this most likely won't work properly, and you'll get people accessing what they shouldn't.

    Those rules are frickin' unmaintainable mess with no logical ordering.

    There are no random IPs as destinations. Yes I use aliases to keep the rule set simple.  Yes there are some disabled rules which do nothing except for when enabled for short term use.  There are no rules that allow all traffic from anywhere to anywhere except the one that limits the IPs themselves which is a rule put in by pfsense to restrict traffic to IPv4.

    I could explain each rule in turn if you want, but since the rule in question is at the top as a block, the rules that follow it should be irrelevant to the problem.


  • Banned

    @cdsJerry:

    I could explain each rule in turn if you want

    No, thanks. The censored aliases and destinations and random disabled junk in between with blocks in completely whacky places are the exact opposite of simple.  Get paid support.

    (As a closing note, once you move your wide open FTP from the most targetted port in the world where it does not belong in the first place, you won't see people trying to breaking into your god knows what because they've mistaken it for SSH.)



  • @doktornotor:

    Don't pull Chris or anyone else into this shit. You cannot tell SSH from FTP and those rules are frickin' unmaintainable mess with no logical ordering, randomly plopped together. Ditch this crap. Noone will waste time debugging this mess with tons of inexplicable aliases and random allow entire world to anywhere rules in between.

    As for pfBlocker, I was one of the pfBlockerNG beta testers. What I don't like is clueless people doing clueless things with that.

    Flush the mess down the drain. Enough said.

    I'm just saying, you want to call it all crap but Chris worked on it and he didn't think it was crap.  Many of the rules and aliases there were set up by him. I'm not "pulling" anyone into anything.  I'm just saying, it made sense to him.

    The rest is just name calling.  You honestly think I don't know FTP from SSH? Come on!  And the ports are routed for that.  Could that port be routed to something else on a different server? Sure it could.. but it's not on this server.  It's routed to the FTP server.  That's beside the point. The point is he shouldn't be able to get to any port at all if he's blocked in a rule above that, and he is.


  • Banned

    You just don't get it. Noone can see what's routed where, since you censored most of the stuff, you even censored the entire descriptions, and noone knows your aliases. There are no NAT rules shown anywhere. There's just giant disorganised mess. To each their own.



  • @doktornotor:

    @cdsJerry:

    I could explain each rule in turn if you want

    No, thanks. The censored aliases and destinations and random disabled junk in between with blocks in completely whacky places are the exact opposite of simple.  Get paid support.

    (As a closing note, once you move your wide open FTP from the most targetted port in the world where it does not belong in the first place, you won't see people trying to breaking into your god knows what because they've mistaken it for SSH.)

    I did pay for support.  As I've said, even Chris looked at it. They fixed the issue I was having at the time (DNS attack) and reviewed the entire system including all rules and all aliases.


  • Banned

    Sure thing. If you pay 10 times that amount, maybe they'll redesign it from scratch. Unlike fixing your wide open DNS on WAN, that would take many hours.



  • @doktornotor:

    You just don't get it. Noone can see what's routed where, since you censored most of the stuff, you even censored the entire descriptions, and noone knows your aliases. There are no NAT rules shown anywhere. There's just giant disorganised mess. To each their own.

    Since  you asked so kindly, here's my outbound NAT.  Keep in mind again, that this pfsense is in transparent mode.  Port 22, while used for SSH is used for other things as well. For example it's the default SFTP port which is what it's used for on this server as well.  That port is routed via the FTPFilezilla Alias and is only allowed on one IP address, that of the FTP server as defined by the very last rule in the rule set.





  • Banned

    Sigh. No, SFTP is NOT FTP. It's a completely different protocol. Terminology wrong, aliases confusing like hell, totally atypical configuration with NAT completely disabled or god knows what and probably some public subnet on LAN, messy rules, most information censored. How on earth you expect people to debug this? We don't have crystall balls. WTH is FTP doing the this thread's subject?! You know, you are confusing people that were trying to help and are wasting their time with this.

    Look, dude, you are getting targetted exactly because "Port 22, while used for SSH is used for other things as well". When you open port 22 to the world, you'll get shitload of hits on it with people trying to bruteforce your SSH server. DUH! Move that Filezilla or god knows what shit where it belongs, as already suggested above.


  • Banned

    Now, pretty damn convinced that your "WAN Net" rule (already mentioned), combined with the "wonderful" idea of putting FTP server on SSH port and your managenetports alias allows the traffic which you see. Fix that, or stick to WAN address, or move your pfSense SSH out of 22 and fix the alias.



  • When I posted it I really didn't expect anyone to need the full rules or aliases since the one rule should be blocking the traffic and that rule is before any pass rules other than the remotemanagement rule (put in by Chris).  I didn't think the rest of the rules would matter since that traffic should never be getting past the block.  It's one specific blacklisted IP I'm asking about, not all IPs accessing port 22.

    FTP is in the subject because it's an FTP server. It also accepts SFTP and FTPS connections since there are a lot of file transfer clients that only support one or the other and many still use port 22 to create an SSH tunnel for the file transmission.  Port 22 is the proper port for such connections and while technically an SSH connection the intent is to transfer a file in the secure tunnel rather than for command line access.  But certainly if I close port 22 I will stop SSH command attempts, but I will also block some customers who need the SSL connection but have clients that do not support FTPS.

    And doing so still wouldn't answer the question.. how did that specific blacklisted IP get past the block?



  • @doktornotor:

    Now, pretty damn convinced that your "WAN Net" rule (already mentioned), combined with the "wonderful" idea of putting FTP server on SSH port and your managenetports alias allows the traffic which you see. Fix that, or stick to WAN address, or move your pfSense SSH out of 22 and fix the alias.

    Chris put in the WAN net rule.  You're right in that I don't know what it does, but Chris put it there so I left it there. In the notes he only put "Allow remote administration".


  • Banned

    Fsking hell. When you write FTP, people look for port 21. Drop this ball already. You've wasted everyone's time with this nonsense, end of story.

    You don't block anyone by closing port 22, you can use any port for SFTP, or SSH, or FTP. But mainly, the suggestions were

    • to move the "badguys" block rule above the "remotemanagement" one - ignored
    • move the FTP server where it belongs - ignored
    • move the pfSense SSH port somewhere else and change the alias accordingly - ignored
    • change the destination in the "remotemanagement" rule to WAN address instead of WAN net - ignored.

    Come back with your findings after you've tested those suggestions. Absolutely no interest in discussing FTP vs. SFTP and Filezilla crap further.


  • Rebel Alliance Global Moderator

    As dok has so eloquently stated over and over that is a MESS..  And your full of shit that Chris did that mess.  If he did he was drunk or stoned or both..

    So your telling me Chris put in all those any any rule on your wan? For employees to access what?  So your not doing any sort of nat on this system?

    Why would cloudflare need a any any rule into your network???

    And then you have a ipv4 alllow rule but don't even show what it is you have dest and port blocked out?  How do you expect anyone to help you with that mess and no explanation of your network..  That any any rule public ports sure looks like it would let anything in that wanted to get in for example to anything listening on those ports whatever they might be.


  • Banned

    BTW, I definitely don't exclude the possibility that there's a bug somewhere related to the "transparent" firewall and the "WAN net" destination in particular - esp. since it's something extremely rarely used. Anyway, to confirm, you need that freaking mess reduced to absolute minimum ruleset that can reproduce the issue.

    And on generic note:

    • similar mess is extremely error prone and giant PITA to use. Very easy to insert inadvertent rule that totally exposes things that never should be exposed. And very easy to lock yourself out by mistake as well.
    • just think about the poor guys that are gonna inherit this when you leave. There's no way they'd understand this. What are they supposed to do? Tell customers "sorry, no network services, closed for business for a couple of days, since we don't understand our own setup at all and need to redo it from scratch"?


  • I never said Chris set up all the rules. He did not. But he did set up some of them including the ones I said he did (he and Stephen both worked on this).  Those are some of the rules I've been bashed for in the thread.

    I haven't ignored what was said. I have made some changes based on those comments but again, the question was how can an IP get past the block rule when there is only one pass rule above the blocks and it's for two specific IPs?  The rest of the rules, while they may need some work, should have never been reached due to the block rule above it.  I didn't provide details on those following rules because it should have never gotten to them.  The lack of information on those rules that should have never been reached seems to be the basis for much of the flaming.

    I really do listen, but I admit that I hear better when the attack is not against me but rather the focus is on building a better rule set.  I have made no claim to be the keeper of all knowledge.  It is not required to point out that I don't know everything because I have never made such a claim and never will.  I'm not an expert.  I'm just a small business owner struggling to make ends meet as best I can with what I have. I am far from rich but I'm happy to be able to provide jobs for the other four people who work here.  None of us are getting rich, but we have jobs.

    I came here for help with something I don't have a great knowledge of, but or which I'm the best person I have to do the job.  I have paid for support and received it. I think Chris and Stephen did a good job but maybe not based on the criticisms of their rules.  I'm not in a position to say as both you and they are far smarter than I am.  I had hoped for assistance rather than assassination.  I thought that's what this forum was for.

    As for the other rules, I'll explain them and listen to comments even though I don't understand why they matter if the higher placed rule should have blocked the specific IP in question.

    All the pfb rules at the top were added automatically by pfBlocker. As our tiny company only deals with customers and vendors in the USA. Using pfBlocker reduces the attacks on all our servers thus lowing the chance of someone being successful.  I'm aware of the debate questioning the value of the pfBlocker package but it certainly lessens the load on my mail server.

    RemoteManagement is a rule put in high so that we could be assured we have access to pfSense in case we do something stupid lower that would lock us out of our own firewall.  Because the firewall is in transparent mode it can not be reached from a LAN address inside our network, only by the WAN IP.

    Badguys is a list of IPs I manually enter when I've noticed someone is pesky and keeps hitting my servers.  If everything is working the way it should this block isn't needed. It just feels better to know I've stopped them before they reach the servers.  It's an alias.

    PHillOffice is a pass for a router located behind pfsense.  We had some problems with valid traffic being blocked between pfsense and the router.  I don't remember the specifics any more as that's been several years ago now.

    ServerIPs was added by the person hired to set up pfSense the first time. It's an alias which sets a pass for traffic to our public IPs and allows only IPv4 traffic into the network since that's all we're set up for.  An Alias lists the IP addresses used.

    The next rule, WAN address, was put in by Chris to stop a DNS attack.

    Employee is for a handicapped employee who often can only work from home. I installed an internet connection at her house just for company use. We had problems with her not being able to access some items such as phones until we added this rule.  She still has to connect via a VPN (rule later) to get into the router that's located behind pfSense.  There's surely a better way than a . pass here but my limited knowledge of the VOIP traffic limited me and since I already allow her access to this information it didn't seem like an additional risk to add this liberal rule which is limited to her IP address in the alias which is only gives access to a router.

    Cloudflare, this rule might not be needed.  Cloudflare had said we need to whitelist their IPs but I'm not sure we actually would as they're only hitting port 80 anyway.  I will disable that rule now and delete it later if there are no problems.  We were having issues with Cloudflare not caching our pages and this was done in an effort to see if it was an issue at the pfSense level while talking to their tech support.

    The next rule is the VPN that passes the port I use for our VPN to the internal router that builds the VPN tunnel. Since we're in transparent mode this isn't done on pfSense.

    The next rule is also is part of our VPN limiting traffic to a specific IP to a specific protocol in an effort to lower the chances of someone breaking into that router.  I forget who set it it up, but it was one of the three experts I'd hired to help me so it was Chris, Stephen, or Glenn.

    The next rule is Public ports.  It's an alias of the ports used by the various servers we have behind pfsense including ports for mail servers, web servers etc.  except for the ports used by the FTP server.

    Finally there's the Filezilla ports for FTP, SFTP, FTPS.  These ports are only used on that specific machine so it's listed as a separate rule so that only traffic on that one IP with those ports passes.  No need to expose those ports on any other server IPs.

    In the floating rules there's a rule that allows only SIP traffic from our providers IP to pass.  A second rule allow outbound traffic to the same IP.  The rules were put in by the setup wizard.  All the other rules in the floating list were put in by the QoS wizard. I blocked out the ports rather than post them because it seemed safer, but I know what each of them is used for.