I have a server running Suse 11.1 which was recently compromised through the zencart software.
This happened as the hacker was able to get some code onto my server via the web server (via the zencart vulnerability). The code then collected information and sent it on to an external domain.
Fortunately, there was no information on the server so they wasted their time, but my hosting company took the server down whilst I sorted out the issue.
I noticed lots of login attempts via ssh - all failed, but they clog up my log files and I assume they waste resources in general.
So, I would like to achieve 2 things -
SSH needs to remain open to the public (well a very small portion of the public !) - but if anyone keeps failing login or simply makes more than a reasonable number of connection attempts in a small amount of time, then prevent them from further attempts (not permanently - just for an hour or so - so that I do not have to manually un block them)
Most of my server applications never need to connect to the outside world. There are some exceptions such as my external SMTP server, paypals servers and of course the suse repositories etc… I would like to deny access to the internet for all applications apart from certain domains that I allow.
Can anyone steer me in the right direction on how to do this ? I have not had much experience with the suse firewall - I tried to use yast2 to set it up, but found nothing for outgoing connections
On Mon, 26 Oct 2009 21:46:01 +0000, garytaylor wrote:
> 1. SSH needs to remain open to the public (well a very small portion of
> the public !) - but if anyone keeps failing login or simply makes more
> than a reasonable number of connection attempts in a small amount of
> time, then prevent them from further attempts (not permanently - just
> for an hour or so - so that I do not have to manually un block them)
I’ll leave the firewall question for someone else who works with the
firewall more to answer, but from an ssh standpoint, there are two things
you can do:
Change the port to a non-standard port
Disable password authentication and require the use of public key
I used to see the password attempts in my logs as well, and implementing #2 stopped that from happening. It’s generally considered a good
practice, though, to change the port as well. This can be done with a
change to your /etc/sshd_config file.
The special value rpc is recognized as protocol and means that dport is
interpreted as rpc service name. See FW_SERVICES_EXT_RPC for
Note1: keep in mind that FW_SERVICES_EXT_TCP, FW_SERVICES_EXT_UDP
take precedence over FW_SERVICES_ACCEPT_EXT so don’t open the same
port with both options.
Note2: the iptables recent module may not be available for ipv6. To
avoid an error message use 0.0.0.0/0 instead of 0/0. This will
install the rule for ipv4 only.
You can edit FW_SERVICES_ACCEPT_EXT directly with gnomesu/kdesu gedit/kwrite /etc/sysconfig/SuSEfirewall2
or via Yast → system → etc sysconfig editor → network → firewall → susefirewall2 → FW_SERVICES_ACCEPT_EXT (e&oe memory)
On Tue, 27 Oct 2009 03:16:01 +0000, Akoellh wrote:
> garytaylor;2056077 Wrote:
>> This happened as the hacker was able to get some code onto my server
>> via the web server (via the zencart vulnerability).
> And how shall a “firewall” (the “” because SuSEfirewall2 is a packet
> filter) protect you from that?
> It can’t because it is not a firewall’s job to do that.
He doesn’t want the firewall to do this, he wants to use the firewall to
only permit certain applications on the server from connecting to systems
he doesn’t control.
Though of course, apache would need to be able to send data to any client
that connects to it.
That said, I don’t know if openSUSE’s firewall can be configured to do
anything like this.
I’m aware of that, the reason I posted this is actually, that IMHO the OP is missing out the real problem.
How could the system be compromised?
What did I miss to protect those services which should be available over WAN and can not be protected by a firewall? (i.e. applying security patches, insecure configuration of the services, …)
Automated login attempts via SSH on port 22 are annoying but not a security problem if SSH is configured securely, services only available in a LAN should be configured (if possible, most of them can be) only to listen on those addresses or an extra “LAN-only”-interface.
IMHO one can start thinking about further hardening via a “firewall” mechanism AFTER considering the steps mentioned above but not as a starting point.