asl-firewall and blocking ports

[BruceLee]

I stumbled across one problem and opened a case but maybe someone can shed some light into this earlier.
Quote from wiki:

FW_INBOUND_TCP_SERVICES
List of user configured allowed inbound TCP services, comma delimited. Just provide a list of the ports you want to allow in. Anything not on the list will be denied by default.
Default: ASL does not block any ports by default. By default all ports are open, ports are only closed if the user defines them via this setting.
Example: 22,21,25,53,80,443,465,110,143,993,995,587,8443,30000

Since I want port 22 and 3306 not to be open I have removed them from this setting.
BUT they are still open. Why? It clearly states "Anything not on the list will be denied by default." And " ports are only closed if the user defines them via this setting".
To achieve closing them I had to put a DENY from ANY for TCP 3306 and 22 into filter >INPUT.
The config of asl-firewall is the default from ASL. 100% unchanged except this two ports over config page setting "INBOUND_TCP_SERVICES" and adding some ertain static ip's in input filter to access port 22 from my office.

Thanks

[faris]

Unless it has changed, the structure of the firewall is:
1) allow stuff
2) deny anything else not specified

So it is a bit odd. Now if you had been talking about a service that can be accessed on UDP, I'd suggest you check you have "none" in that box rather than leaving it blank, because it turns out that a blank box means "allow all". And I'd leaft my UDP box blank in the incorrect assumption that meant "allow none".

Right at the bottom of my INPUT chain, you should see

Code: Select all

163K 9289K ASL-Firewall-INPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 0     0 DROP       all  --  !lo    *       0.0.0.0/0            0.0.0.0/0           state INVALID

So at this stage it branches to the ASL-Firewall-INPUT chain.

The ASL-Firewall-INPUT chain is where all the ports you specified in the asl config should be opened.

And right at the bottom of ASL-FIREWALL-INPUT you should see the final drop all:

Code: Select all

 8888  523K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

[BruceLee]

thanks faris. the UDP stuff is set to NO by ASL per defautl so I guess this is fine.

I assumed the "allow stuff and deny anything in end" as well. Wiki tells a differnet story and iit is strangely not working as expected.
my last few lines INPUT CHAIN per default set by ASL:

Code: Select all

DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:30001 state NEW 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:30000 state NEW 
ASL-TORTIXD-ACL  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:30000 state NEW 

my last line of ASL-Firewall-INPUT chain per default set by ASL:

Code: Select all

DROP       all  --  0.0.0.0/0            0.0.0.0/0           

before the drop in the INPUT CHAIN I have added my office IP's to allow ssh.
removed the ports in config and it still was allowing connections.
I wonder why the the 3000X ports rules are set by ASL after the final DROP one.
I needed to explicitly DENY the ports 22 and 3306 in INPUT CHAIN.
Why does this behaviour occur is the big question!?

thanks for any help

[prupert]

Since I want port 22 and 3306 not to be open I have removed them from this setting.
BUT they are still open. Why?

This is working fine for me. Perhaps your firewall configuration got messy after adding custom rules. You can try to clean up the custom rules:

Code: Select all

mv /etc/asl/firewall/running.fw ~/aslfwbackup.running.fw
asl -s -f
service asl-firewall restart

So it is a bit odd. Now if you had been talking about a service that can be accessed on UDP, I'd suggest you check you have "none" in that box rather than leaving it blank, because it turns out that a blank box means "allow all". And I'd leaft my UDP box blank in the incorrect assumption that meant "allow none".

It is the other way around:
FW_INBOUND_UDP_SERVICES="" --> no open UDP ports (= ALL CLOSED)
FW_INBOUND_UDP_SERVICES="no" --> no firewall restrictions on UDP ports (= ALL OPEN)

[BruceLee]

thanks prupert.
then it might be a simple "wrong documenation/definition/wording" case.
wiki clearly states something different with "Anything not on the list will be denied by default.
Default: ASL does not block any ports by default. By default all ports are open, ports are only closed if the user defines them via this setting."

ASL config comment is:

Code: Select all

FW_INBOUND_TCP_SERVICES: Basic list of allowed inbound TCP services, comma delimted. Example: 22,25,80 Default:[no]

Currently I need to set the additional rules. Otherwise it is not being blocked. So there is something not the way it should be if the comments of ASL are right.


edit:corrected wrong quote

[prupert]

thanks prupert.
then it might be a simple "wrong documenation/definition/wording" case.
wiki clearly states something different with "Anything not on the list will be denied by default.
Default: ASL does not block any ports by default. By default all ports are open, ports are only closed if the user defines them via this setting."

The documentation looks correct to me:

- Documentation: "Anything not on the list will be denied by default."
- FW_INBOUND_UDP_SERVICES="" --> no open UDP ports (= ALL CLOSED)
- FW_INBOUND_UDP_SERVICES="53" --> only port 53 open (= ALL CLOSED EXCEPT UDP/53)

- Documentation: "Default: ASL does not block any ports by default. By default all ports are open [...]"
- FW_INBOUND_UDP_SERVICES="no" (default value) --> no firewall restrictions on UDP ports (= ALL OPEN)

Currently I need to set the additional rules. Otherwise it is not being blocked. So there is something not the way it should be if the comments of ASL are right.

There might be something wrong with your custom rules, maybe some rules got at the wrong place rendering other rules useless. Try to clean up and start over. I'm not saying you did something wrong, it may be due to a glitch in ASL or some 'legacy' of a firewall configuration from a previous ASL configuration. I do want to say that the ASL firewall works according to documentation perfectly fine on all ASL machines we've got under our hood (and they are a LOT of machines).

[BruceLee]

thanks. I might wipe it tonight. But if there is something wrong than it is 100% ASL made. I'm going to wait for ASL respond my case.
One thing: you cannot quote just a parts of it. thats even more confusing. so i'm still sure the comments are wrong.

- Documentation WIKI:
"List of user configured allowed inbound TCP services, comma delimited. Just provide a list of the ports you want to allow in. Anything not on the list will be denied by default. Default: ASL does not block any ports by default. By default all ports are open, ports are only closed if the user defines them via this setting.
Example: 22,21,25,53,80,443,465,110,143,993,995,587,8443,30000 "
- FW_INBOUND_TCP_SERVICES="" --> no open TCP ports (= ALL CLOSED) > THIS MIGHT BE CORRECT; is there some setting like "NO" and "NONE" at all?
- FW_INBOUND_TCP_SERVICES="25,80" --> port 25,80 open but 22 AS WELL > So this not according to: "Anything not on the list will be denied by default."

[prupert]

- FW_INBOUND_TCP_SERVICES="25,80" --> port 25,80 open but 22 AS WELL > So this not according to: "Anything not on the list will be denied by default."

That is odd. If you defined only 25 and 80 as open TCP ports, port 22 should be CLOSED. I could not reproduce this error on a test ASL system.

[mikeshinn]

So that means there is a custom rule allowing the connection or an established already existing connection. I believe you opened a case earlier today, and if thats the same case there are a number of custom SSH rules allow connections from specific IPs. If you're testing from those IPs, then the connections should be allowed.

[BruceLee]

worked on it right now.
mv /etc/asl/firewall/running.fw ~/aslfwbackup.running.fw
asl -s -f
service asl-firewall restart

still it is not running smoothly. needed to reload it a couple of times.
those commands will NOT create a new running.fw!! You need to apply some rule change in gui or create it manually.

more updates tomorrow when i'm working on it again. thanks.

[BruceLee]

So that means there is a custom rule allowing the connection or an established already existing connection. I believe you opened a case earlier today, and if thats the same case there are a number of custom SSH rules allow connections from specific IPs. If you're testing from those IPs, then the connections should be allowed.

unfortunately not. the IPs i tested from were NOT in the rules and NOT in the whitelist.

[mikeshinn]

What do your rules look like, can you post your iptables -L -n?

It sounds like you may have a custom rule or something, and that would tell us exactly how your rules are configured.

[faris]

Yeah, that "no" or "" or "none" is totally confusing, even though the words in the explanation, when you read them a few times, do make it relatively clear and do make sense. Sorry for getting it the wrong way round in my original post.

A simple solution when in doubt would be to add 53 to the UDP box, which I guess is a benign port to open unless you don't want the box to do any DNS at all.

Maybe the words could be changed?
Enter the port number(s) you want to block (separate multiple port numbers by commas):
Leave blank to block all ports or enter "no" to open all ports.
Default: no (all ports open).

(although for UDP I'd prefer the default to be to block all ports. You can't do that for TCP because too many of us might accidentally lock ourselves out)

But none of this solves your problem ... sorry. It does look like there's something that's got a bit confused in the firewall config. It almost looks as though there's a bit of the old style firewall still there.

Ah....is the iptables SERVICE still running, by any chance? Could that be it? It might be loading the old config from a saved table set?

But to be honest I don't think it would be right for me to speculate - the ASL support guys may be logged in and investigating, and me suggesting nutty things for you to try may only make things worse

[prupert]

A simple solution when in doubt would be to add 53 to the UDP box, which I guess is a benign port to open unless you don't want the box to do any DNS at all.

I would absolutely advise against opening UDP/53 just because you aren't sure. What if your resolver is listening on that port (most probably) and is incorrectly configured to resolve for others as well? Remember the DNS resolver amplification denial-of-service attacks?

Maybe the words could be changed?
Enter the port number(s) you want to block (separate multiple port numbers by commas):
Leave blank to block all ports or enter "no" to open all ports.
Default: no (all ports open).

+1!

(although for UDP I'd prefer the default to be to block all ports. You can't do that for TCP because too many of us might accidentally lock ourselves out)

A lot of users with a single Plesk/ASL system are using it as an authoritative nameserver as well. Blocking all UDP traffic by default could cause all their domains to become unreachable. Thus, it might not be a good idea to block all UDP traffic by default.

[BruceLee]

Hi everybody,

thanks to Mike & Scott all the problems were solved.
There was some weird misconfiguration that caused some trouble and my rules to solve them made it even look more strange than it was.
Plus it caused some additional misbehaviour.
Clearing the whole config and creating a custom local sshd chain to allow certain IPs solved the problems.
Maybe there was more that Mike did but I think that sums it up.
Mike also wrote that the comments will be changed to make it more clear what to set.

Thanks to all and especially Mike & Scott for the excellent support.