various security issues with Astaro 7.3

Hi Mr-4,

Here are some quick answers to your points.

1. These are dropped because one side of the session has already sent a termination request for the session. Astaro's state table then removes that session from being active, and any further packets in that session are dropped. 

2. Some of the available rules are warn only notifications, and not on by default. If you do not have all of the "Add extra warnings" boxes checked, you won't see all rules enabled. 

3. If you want to allow limited ICMP TO the Astaro, then you can control that with packet filter rules. If you want to allow ICMP FROM the astaro, then you need to enable Ping from firewall, and Traceroute from firewall. These are for outbound requests, not inbound.

4. You may have noticed the notice about making changes from the shell not being supported, when you logged into SSH. Don't count on any changes you make from the cli sticking. Since it's not in webadmin, Astaro doesn't support certs instead of passwords for ssh auth. Also, SSH is listening for 0.0.0.0 because when you enabled SSH, you did not restrict the allowed networks in webadmin. Just change Management >> System Settings > Shell Access > Allowed networks to only be the network range you want to have access.

Also, 

Not sure exactly why Astaro blocks low ports, except that not allowing random ports below 1024 is a standard security restriction. If you really want it listening on a non-standard, low port, you can create a DNAT rule to redirect port 212 to whatever port you set it to listen on.

SMTP will only be accessable to the world if it is enabled under Mail Security >> SMTP, and DNS will only be accessable if under Network >> DNS, set the allowed networks to Any.

Same for NTP. Postgres is not eccessable from the internet, only from the local machine, and webadmin is on and open to Any by default. You can change that under Management >> Webadmin Settings > Access Control

Hi Mr-4,

Here are some quick answers to your points.

1. These are dropped because one side of the session has already sent a termination request for the session. Astaro's state table then removes that session from being active, and any further packets in that session are dropped. 

2. Some of the available rules are warn only notifications, and not on by default. If you do not have all of the "Add extra warnings" boxes checked, you won't see all rules enabled. 

3. If you want to allow limited ICMP TO the Astaro, then you can control that with packet filter rules. If you want to allow ICMP FROM the astaro, then you need to enable Ping from firewall, and Traceroute from firewall. These are for outbound requests, not inbound.

4. You may have noticed the notice about making changes from the shell not being supported, when you logged into SSH. Don't count on any changes you make from the cli sticking. Since it's not in webadmin, Astaro doesn't support certs instead of passwords for ssh auth. Also, SSH is listening for 0.0.0.0 because when you enabled SSH, you did not restrict the allowed networks in webadmin. Just change Management >> System Settings > Shell Access > Allowed networks to only be the network range you want to have access.

Also, 

Not sure exactly why Astaro blocks low ports, except that not allowing random ports below 1024 is a standard security restriction. If you really want it listening on a non-standard, low port, you can create a DNAT rule to redirect port 212 to whatever port you set it to listen on.

SMTP will only be accessable to the world if it is enabled under Mail Security >> SMTP, and DNS will only be accessable if under Network >> DNS, set the allowed networks to Any.

Same for NTP. Postgres is not eccessable from the internet, only from the local machine, and webadmin is on and open to Any by default. You can change that under Management >> Webadmin Settings > Access Control

Thanks for the reply crashtestdummy!

1 - I understand (and suspected that to be the case), however how do I prevent these clogging my logs (see 2nd part of point 1 in my initial post). Currently they occupy about 80% of my log.

2 - Thanks again, got it now - it makes sense!

3 - I did - I created the necessary rules (see my initial post) to allow ping/traceroute from the firewall, however going to the appropriate sections in Support > Tools still gives me this daft message about me having to enable the PING via Network Security >> Packet Filter >> ICMP (well, if I did all other ICMP rules I have created will be gone/ignored) which is not correct as I have a rule created for the firewall.

4 - 

sshd_config changes not sticking - yes, I figured that one out already. The question is - is this possible? I know what/how to change sshd_config to enable this to work, the problem is that it 'restores' itself at every reboot...

sshd listening on 0.0.0.0 - not correct. I do have the network restriction enabled and in place (ssh is restricted to one host on the internal network only), however Astaro is still listening to 0.0.0.0 I can prepare the appropriate snapshots so that I could prove what I am talking about.

sshd listening on low ports is 'standard security restriction' - erm, not really - it listens by default on port 22, which is a low port. As sshd runs as root it can use lower ports, so I don't see why I have to define ports above 1024. Same is valid for the webAdmin port as well.

other services smtp, pop3, postgres, ntp - listening on 0.0.0.0 - apart from postgres (which is used only by Astaro itself - so I don't see why it should be listening to 0.0.0.0!) and ntp (same applies) I have NO other proxies running - both my smtp/pop3 procies and the like are switched OFF. So, why the need for them to listen to these ports? Currently I am running only the Firewall and the Intrusion protection (everything else is off) and this is the relevant section dump of netstat from the cli:

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      

tcp        0      0 0.0.0.0:199             0.0.0.0:*               LISTEN      

tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      

tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN      

tcp        0      0 :53   0.0.0.0:*               LISTEN      

tcp        0      0 :53     0.0.0.0:*               LISTEN      

tcp        0      0 :53     0.0.0.0:*               LISTEN      

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      

tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      

tcp        0      0 0.0.0.0:4444            0.0.0.0:*               LISTEN      

udp        0      0 0.0.0.0:161             0.0.0.0:*                           

udp        0      0 0.0.0.0:32817           0.0.0.0:*                           

udp        0      0 :53     0.0.0.0:*                           

udp        0      0 :53     0.0.0.0:*                           

udp        0      0 :53     0.0.0.0:*                           

udp      300      0 127.0.0.1:53            0.0.0.0:*                           

udp        0      0 0.0.0.0:68              0.0.0.0:*                           

udp        0      0 :123    0.0.0.0:*                           

udp        0      0 :123    0.0.0.0:*                           

udp        0      0 :123    0.0.0.0:*                           

udp        0      0 127.0.0.1:123           0.0.0.0:*                           

udp        0      0 0.0.0.0:123             0.0.0.0:*                           

raw        0      0 0.0.0.0:255             0.0.0.0:*

So:

DNS - why is it listening to my dmz as well as isp (public) ip addresses using both tcp and udp protocols? I have enabled DNS proxy on my internal network only, nothing else...

NTP - why is it listening to 0.0.0.0 and my isp address? Why is it listening on the dmz as I have disabled access to ntp from that net?

Mail (pop, smtp, imap) - why are all these listening on 0.0.0.0 - I have none of these proxies/security enabled?

PostgreSQL - why on 0.0.0.0 when it is ONLY used by Astaro and nothing else? It should be listening on the loopback - 127.0.0.1!

1) What's the destination address of the log entries? can you post a few samples?

3) ok. I get what you're saying now. Try this: Create a new service definition, called ICMP. Type is IP, protocol =1. Then, use that in your pf rules. Leave all boxes unchecked in Packet Filter > ICMP, except for Ping from Firewall, and Traceroute from Firewall. Double checked here, and that lets me use the Support > Tools, and also control who can ping to or through the firewall perfectly. 

4) If you have a support contract, and you plan on calling support, then don't do this: Try editing the sshd_config-default file instead, then restart the SSH service. See if that survives a reboot.

As for SSH port selection, It is what it is. If you think it should be different, you'll need to put in a feature request, or contact support.  

As far as what services are listening, on what interfaces, what does 'iptables -nvL' show? If there are no iptables rules allowing access to the ports listed in netstat, then there is no problem. Can you actually connect to any of the listed ports from outside the firewall? 

SMTP is always listening, because it's use by ASG for notifications. Access is restricted by iptables. From the netstat snip you pasted, I don't see pop3, or imap as mentioned. Astaro doesn't have an IMAP proxy. Not a bad point though about postgres. Though it would take a user created Any >Any> External(Address) pf rule to be dangerous.

1) What's the destination address of the log entries? can you post a few samples?

Sure, here goes:

ulogd[2652]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" dstmac="" srcmac="" srcip="" dstip="" proto="6" length="52" tos="0x00" prec="0x00" ttl="52" srcport="34371" dstport="9897" tcpflags="ACK FIN"

ulogd[2652]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" dstmac="" srcmac="" srcip="" dstip="" proto="6" length="52" tos="0x00" prec="0x00" ttl="52" srcport="34371" dstport="9897" tcpflags="ACK FIN"

ulogd[2652]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" dstmac="" srcmac="" srcip="" dstip="" proto="6" length="52" tos="0x00" prec="0x00" ttl="52" srcport="34371" dstport="9897" tcpflags="ACK FIN"

ulogd[2652]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" dstmac="" srcmac="" srcip="" dstip="" proto="6" length="52" tos="0x00" prec="0x00" ttl="52" srcport="34371" dstport="9897" tcpflags="ACK FIN"

3) Try this: Create a new service definition, called ICMP. Type is IP, protocol =1. Then, use that in your pf rules. Leave all boxes unchecked in Packet Filter > ICMP, except for Ping from Firewall, and Traceroute from Firewall. Double checked here, and that lets me use the Support > Tools, and also control who can ping to or through the firewall perfectly. 

That directly contradicts what the 'help' file as well as the text displayed on that page is saying, i.e. (see my initial post)

Allowing any ICMP traffic on this tab will override ICMP settings being made in the packet filter.

So, by that token if I do what you are suggesting then all hell breaks loose and my icmp settings for various hosts/networks are going to be ignored - that is my understanding...unless, of course, I am missing something.

4) If you have a support contract, and you plan on calling support, then don't do this: Try editing the sshd_config-default file instead, then restart the SSH service. See if that survives a reboot.

My thoughts exactly (sort of suspected that would work, but didn't want to go that route as I was hoping to find a more 'civilised' way of dealing with this issue).

If you think it should be different, you'll need to put in a feature request, or contact support.

It is getting a long list this...[;)]

As far as what services are listening, on what interfaces, what does 'iptables -nvL' show? If there are no iptables rules allowing access to the ports listed in netstat, then there is no problem. Can you actually connect to any of the listed ports from outside the firewall? 

What iptables do/show is entirely irrelevant! 

What do you think is the safest option - not having (unnecessary) connection on 0.0.0.0 and iptables or having such a connection and relying solely on iptables to do its job properly and not getting bypassed (or, to put it another way - do you think iptables is 100% secure all the time in any circumstances and cannot be broken into?!). I think that is a no-brainer myself! 

SMTP is always listening, because it's use by ASG for notifications. Access is restricted by iptables. From the netstat snip you pasted, I don't see pop3, or imap as mentioned. Astaro doesn't have an IMAP proxy. Not a bad point though about postgres. Though it would take a user created Any >Any> External(Address) pf rule to be dangerous.

I have all notifications turned off, so by that token smtp should not be running, let alone listening on 0.0.0.0 (if it is used solely by Astaro - smart people invented 127.0.0.1 for that). As for relying on iptables (again) - see my previous paragraph. 

Also, what about DNS and NTP - any need for listening on 0.0.0.0, given the restrictions I mentioned in my previous post. Add to that SSH as well - it should not, under any circumstances, be listening on 0.0.0.0 - it should have separate instances listening depending on the settings on which networks are allowed to use SSH. That is my view.

As for my imap example was mistakenly identified - it is smtp-secure what I was meant to type (port 465), but my original point still stands.

You should be able to drop the unwanted packets with a pf rule that matches that traffic. so:
Src: Any
Svc: Port 9897, or Any if there are other ports.
Dst: 
Action: Drop 
Leave logging off, and it should clean up your logs.

When I read:

Allowing any ICMP traffic on this tab will override ICMP settings being made in the packet filter.

I don't see the same contradiction that you do. Override does not mean it will disable all my existing settings, just those that overlap. By allowing ICMP TO the firewall, that will obviously override rules that allow only specific IPs to send ICMP to the firewall. Allow ICMP FROM the firewall won't override settings controlling ICMP TO the firewall. The use of the word any does add ambiguity, but my view is tainted by having tested and see how it actually works. What I posted earlier works exactly as you want, regardless of how we think the word any affects the meaning of that statement.

I have to disagree strongly with you regarding some of what you said regarding iptables.  But first, I DO agree that it is an additional restriction to bind processes to loopback, and I DO agree with you fully that the postgres process SHOULD be bound to the loopback. 

but when you say:

 do you think iptables is 100% secure all the time in any circumstances and cannot be broken into?!

If you believe this to be true, then why would you even think of using an iptables firewall?? If your firewall will not stop all packets that you have told it to, then it is no longer acting as a firewall. 

But taking that one step further, we'll assume for a second that iptables is weak. What happens if the DNS service, or the SMTP service, or the NTP service IS prematurely exposed to the internet? These are production ready services that are exposed to the internet daily on thousands of firewalls, without being compromised, so the answer is: nothing. 
 
This leaves only the postgres process, which as far as I know, Astaro does not intend for this to directly face the internet. But for any of this to be a problem STILL requires a problem with iptables, or a deliberately created pf rule. The typical Any > Any > Any > Allow mistake won't even do it.

You should be able to drop the unwanted packets with a pf rule that matches that traffic. so:
Src: Any
Svc: Port 9897, or Any if there are other ports.
Dst: 
Action: Drop 
Leave logging off, and it should clean up your logs.

Unfortunately this won't work because I need port 9897 to be open (see this post) as I have DNAT running on that port. Astaro allows 'normal' packets to go through (as it should), but clogs my log with blocked packets destined to the same port, but having the above tcp flags set in addition. 

In other words, it is letting any:any-max -> astaro:9897 (to be redirected to dmz:9897 via dnat), but if a packet has any:any-max -> astaro:9897 with tcpflags ack+fin (sometimes ack+fin+rsh, I think, not sure) it blocks them. As I pointed out, these clog my logs and currently account for about 80% of blocked traffic!

What I need, again, is two things - 1) this was already dealt with - it was established that astaro rightly blocks these packets (fair enough); 2) a way to prevent astaro from logging these as I do not want to scroll through thousand of lines of logs every single day, thanks.

On the ICMP issue - yes, 'any' means any (the whole bloody lot). If you have defined any ICMP rules, it overrides them. Perhaps the wording should be changed to reflect that because, as you said, it is misleading. 

I take your word for it that I can use it the way you describe, so will give it a go (it will be easy to test the validity of what you say as I have disabled ICMP protocols of any kind on my networks, allowing only two machines to use it and now will enable astaro as well).

I have to disagree strongly with you regarding some of what you said regarding iptables.

NO software ever invented (and that includes iptables) is invincible - if you believe that you are either arrogant, misguided or both! 

But first, I DO agree that it is an additional restriction to bind processes to loopback, and I DO agree with you fully that the postgres process SHOULD be bound to the loopback. 

This is how it should be - if there is no need, it should not be there. End of.

but when you say:

If you believe this to be true, then why would you even think of using an iptables firewall?? If your firewall will not stop all packets that you have told it to, then it is no longer acting as a firewall. 

I did not say it won't stop any packets, just that it may be vulnerable as it is a software invented by a human (see the above paragraph).

But taking that one step further, we'll assume for a second that iptables is weak. What happens if the DNS service, or the SMTP service, or the NTP service IS prematurely exposed to the internet? These are production ready services that are exposed to the internet daily on thousands of firewalls, without being compromised, so the answer is: nothing. 

[:O] You can't be serious! 

What you are suggesting is that even if these services are exposed 'there is nothing to worry about as there are thousands of services like that out there in the open/unprotected Internet who run perfectly well'. 

I hope I am wrong in this, but if this is your line of thinking and if this is the typical frame of mind/attitude of astaro developers, I have to conclude that you are not only arrogant, but start believing your own hype, my friend. 

By exposing these services unnecessarily in the open you invite abuse...and as they say...you will get it!

I am repeating myself here, but If there is no need for a service to be connected at this address (and the potential of this service being exploited from outside is there) then this connection should not exist. Simple as.

DNAT rules will be processed before firewall rules. Creating the pf rule described will only get rid of the expired session packets. Natted packets will not match the above pf rule, and still pass successfully.


To be clear, I'm not an Astaro developer. I am a customer, and partner who is very familiar with the system. I've been using it for years. My only input into the products design is the same as yours - through feature requests. 

My point about dns, smtp, ntp being exposed to the internet was that there are thousands of Astaro customers with these features turned on and receiving packets from the internet.  My point was that there would have to be both a problem with iptables, and a vulnerability in one of these services for a problem to occur. These services are pounded on daily for many customers without protection from iptables, and  without compromise. If there is a problem with one of these services it will not be found or experienced by someone whose firewall has an iptables rule blocking packets from arriving at it. That's all. I don't disagree with your ideas from a general design stance, but just because those services are running, does not mean that a failure of iptables would constitute a vulnerability in the underlying services. This isn't MS SQL server running on windows. This is a hardened linux OS, with critical services running under reduced privileges in isolated chroot environments. 

I think we've both stated our opinions clearly. You make valid points, and as I said I agree in principal, but I think you strongly overstate any potential risk.

DNAT rules will be processed before firewall rules. Creating the pf rule described will only get rid of the expired session packets. Natted packets will not match the above pf rule, and still pass successfully.

I have to try that one out - good point.

My point about dns, smtp, ntp being exposed to the internet was that there are thousands of Astaro customers with these features turned on and receiving packets from the internet.  My point was that there would have to be both a problem with iptables, and a vulnerability in one of these services for a problem to occur. These services are pounded on daily for many customers without protection from iptables, and  without compromise.

Try telling that to a person, whos machine is compromised (even if it is just one). This is a silly argument, for arguments' sake. It is immaterial whether these services have actually been compromised (or not) in 'thousands of machines running out there'. Discovering a vulnerability (or possibility of a compromise) is more than enough. 

As I said in my previous post - with leaving these services running on 0.0.0.0 you are inviting abuse - and you will get it sooner rather than later! What is the point? No need for it whatsoever.

By the same token, why not create all sort of services and make them listen on 0.0.0.0 and rely on iptables alone to protect you. Would you do that?

I don't disagree with your ideas from a general design stance, but just because those services are running, does not mean that a failure of iptables would constitute a vulnerability in the underlying services.

It will constitute such vulnerability. The attacker will know what you are running. Also, following your logic above, why have a firewall at all - just leave the attackers to scan for the services you are running and pick them up one by one. The mere information alone gathered by the attacker that you are running these will constitute a compromise. Any security expert worth his salt will tell you that!

I think we've both stated our opinions clearly. You make valid points, and as I said I agree in principal, but I think you strongly overstate any potential risk.

It is a matter of principle for me - better safe than sorry. I stated many times on this thread - it is much safer option to not have an open port accessible by an attacker from outside, then relying solely on iptables to protect you. It is lazy programming at the very least, blatant ignorrance (or arrogance) at its worst. 

Either way, using Astaro won't inspire me with confidence at all. I did try v4.0 a couple of years ago, but ditched it then. Last week I decided to give it another chance, but I see nothing has changed - pretty interface, shit implementation. Sadly, I am back with my other tried and tested firewall for the time being...