Adding/Manage rules to the firewall via Virtualmin

gaia · **Joined:** Tue Jun 09, 2009 12:57 pm **Posts:** 134

1) Can add rules to the firewall via virtualmin? I'm more comfortable with the interface there.

2) Somehow I have two rules in the filter>input regarding SSH:
If protocol is TCP and destination port is 22
If protocol is TCP and destination port is 22 and state of connection is NEW
Can I drop the first one?

Thanks

mikeshinn · **Posted:** Mon Jun 18, 2012 12:39 pm

Quote:

1) Can add rules to the firewall via virtualmin? I'm more comfortable with the interface there.

Its not supported, but it may work.

Quote:

2) Somehow I have two rules in the filter>input regarding SSH:
If protocol is TCP and destination port is 22
If protocol is TCP and destination port is 22 and state of connection is NEW
Can I drop the first one?

Can you send the output of this command run as root:

iptables -L -n

It sounds like you may have rules in there from another tool (like virtualmin).

gaia · **Joined:** Tue Jun 09, 2009 12:57 pm **Posts:** 134

mikeshinn wrote:

Quote:

1) Can add rules to the firewall via virtualmin? I'm more comfortable with the interface there.

Its not supported, but it may work.

Quote:

2) Somehow I have two rules in the filter>input regarding SSH:
If protocol is TCP and destination port is 22
If protocol is TCP and destination port is 22 and state of connection is NEW
Can I drop the first one?

Can you send the output of this command run as root:

iptables -L -n

It sounds like you may have rules in there from another tool (like virtualmin).

Code:

> iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ASL-BLACKLIST  all  --  192.162.19.0/24      0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:20 
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:21 
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:53 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:10000 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:20 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:21 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:53 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:587 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:25 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:30000 
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain ASL-ACTIVE-RESPONSE (0 references)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain ASL-BLACKLIST (1 references)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0   

mikeshinn · **Posted:** Mon Jun 18, 2012 5:09 pm

OK, so the differences between these two:

ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22

Thats a non-stateful rule. Not a good way to allow connections to a TCP port, you should always track state. Failure to track state is a big hole in your firewall, always always always use stateful rules.

ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22

Thats a stateful rule. Thats a good firewall rule. Thats allowing connections to the port, and tracking state.

You need to drop the one thats not tracking state for sure, and you need to change all your other rules to use state tracking as well.

gaia · **Joined:** Tue Jun 09, 2009 12:57 pm **Posts:** 134

mikeshinn wrote:

You need to drop the one thats not tracking state for sure, and you need to change all your other rules to use state tracking as well.

Should the state for ALL other rules be the same (NEW)?

Thanks Mike.

mikeshinn · **Posted:** Mon Jun 18, 2012 5:40 pm

Yes. That means allow in new connections that are "NEW".

You will also need a general rule to allow in "ESTABLISHED" connections, which you already have (two actually, you can drop one of those, and generally put the established rule first). The "RELATED" rule tells the kernel to work with its helper modules to figure out if it needs to automatically open and close other ports that more complex protocols use, like FTP. If you dont use protocols like FTP you dont need that rule.

Obligatory plug: We wrote a book about all of this you can pick up on Amazon, real cheap too looks like used copies are under $3:

http://www.amazon.com/Troubleshooting-L ... +firewalls

gaia · **Joined:** Tue Jun 09, 2009 12:57 pm **Posts:** 134

mikeshinn wrote:

Yes. That means allow in new connections that are "NEW".

You will also need a general rule to allow in "ESTABLISHED" connections, which you already have (two actually, you can drop one of those, and generally put the established rule first). The "RELATED" rule tells the kernel to work with its helper modules to figure out if it needs to automatically open and close other ports that more complex protocols use, like FTP. If you dont use protocols like FTP you dont need that rule.

Obligatory plug: We wrote a book about all of this you can pick up on Amazon, real cheap too looks like used copies are under $3:

http://www.amazon.com/Troubleshooting-L ... +firewalls

weird, the EDIT RULE button has no effect. nothing happens. do I have to delete and re-create?

thanks

gaia · **Joined:** Tue Jun 09, 2009 12:57 pm **Posts:** 134

still havent been able to edit the rules...

thanks

gaia · **Joined:** Tue Jun 09, 2009 12:57 pm **Posts:** 134

I get an OSSEC warning and it makes me wonder if any part of ASL resets the open ports to

Code:

ossec: output: 'netstat -nltp  | grep LISTEN | egrep -v "127.0.0.1|\[1-9][1-9][1-9][1-9].*ftp"  | awk '{print $1"\t"$4"\t"$5"\t"$6}'':
tcp   0.0.0.0:3306   0.0.0.0:*   LISTEN
tcp   0.0.0.0:587   0.0.0.0:*   LISTEN
tcp   0.0.0.0:10000   0.0.0.0:*   LISTEN
tcp   0.0.0.0:22   0.0.0.0:*   LISTEN
tcp   0.0.0.0:25   0.0.0.0:*   LISTEN
tcp   :::587   :::*   LISTEN
tcp   :::80   :::*   LISTEN
tcp   :::30000   :::*   LISTEN
tcp   :::21   :::*   LISTEN
tcp   :::22   :::*   LISTEN
tcp   :::25   :::*   LISTEN
tcp   :::443   :::*   LISTEN

because I dont need 587 or 25 (no mail being handled on this server).

please advise

mikeshinn · **Posted:** Tue Jun 26, 2012 6:53 pm

Those are not open ports, those are ports where a service is listening. ASL does not control that, that means you have a process listening on that port.

mikeshinn · **Posted:** Wed Jun 27, 2012 4:44 pm

OK, so we have a fix for your edit issue as well. Its in the 3.0.27-.03 testing build. If you want to try it, please run this command as root:

yum --enablerepo=asl-3.0-testing upgrade asl asl-web asl-waf-module

gaia · **Joined:** Tue Jun 09, 2009 12:57 pm **Posts:** 134

mikeshinn wrote:

OK, so we have a fix for your edit issue as well. Its in the 3.0.27-.03 testing build. If you want to try it, please run this command as root:

yum --enablerepo=asl-3.0-testing upgrade asl asl-web asl-waf-module

This is a production server and I am not willing to test anything, thanks. I dont even need to edit the rules via ASL anymore, as I will stick to virtualmin to do that when needed.

mikeshinn · **Posted:** Wed Jun 27, 2012 6:03 pm

OK, you'll have to wait for the stable release then (which will be identical to the current build, which extended support customers already have). We just do not release stable builds in the evening, only in the morning, for our standard support customers.

gaia · **Joined:** Tue Jun 09, 2009 12:57 pm **Posts:** 134

mikeshinn wrote:

OK, you'll have to wait for the stable release then (which will be identical to the current build, which extended support customers already have). We just do not release stable builds in the evening, only in the morning, for our standard support customers.

i dont see an option to purchase extended support in https://www.atomicorp.com/amember/signup.php

mikeshinn · **Posted:** Wed Jun 27, 2012 11:57 pm

Quote:

i dont see an option to purchase extended support in https://www.atomicorp.com/amember/signup.php

Please see the FAQ:

https://www.atomicorp.com/wiki/index.ph ... ed_Support

And here is the FAQ included for your convenience:

Quote:

Extended support is available with an extended support contract.

Extended support is available 24 hours a day, 7 days a week. Extended support contract holders are also covered during company holidays.

If you need extended support please contact us! Just send an email to sales@atomicorp.com.

Please contact sales if you wish to purchase an extended support contract.

Adding/Manage rules to the firewall via Virtualmin

Who is online