Did not it occur to you that the problem may not be SUSE at all?
As you see in the log, a file with the name “dd.rar” existed. My server sent a lot of sessions and used all bandwidth. It was like a DDoS attack. Why? Any wrong configuration?
What’s happened?
Is it not SUSE problem? OK, tell me what is wrong?
Is it not SUSE problem? OK, tell me what is wrong.
Consider installing SELinux: <https://doc.opensuse.org/documentation/leap/security/html/book.security/part.selinux.html>.
Consider implementing all the recommendations in the openSUSE Security Guide: <https://doc.opensuse.org/documentation/leap/security/html/book.security/index.html>.
Consider purchasing the following Linux Security and System Administration handbooks – all O’Reilly:
- Linux Security Cookbook – Barret, Silverman and Byrnes – ISBN: 0-596-00391-9
- Linux System Administration – Adelstein and Lubanovic – ISBN: 0-596-00952-6
- Linux Networking Cookbook – Schroder – ISBN: 0-596-10248-8
- Linux Cookbook – Schroder – ISBN: 0-596-00640-3
Consider taking a Linux Networking and/or System Administration certification course: <https://training.linuxfoundation.org/training/> – either online self paced or, instructor lead.
No,
your log says that the remote User **tried **to download a “dd.rar” file but the file doesn’t exist on your system which is why the action resulted in a failure…
Which is good for you!
TSU
Then why OpenSUSE used all bandwidth and made a lot of sessions?
- How did you monitor the bandwidth being used?
- How did you trace the HTTP Server sessions being setup?
By FortiGate device. OpenSUSE made a lot of sessions and used all the internet bandwidth.
Other Distros like CentOS with disabled SELinux never had the same problem.
On Fri, 14 Jun 2019 09:26:04 +0000, hack3rcon wrote:
> Other Distros like CentOS with disabled SELinux never had the same
> problem.
You got lucky, or the default logging on those platforms doesn’t provide
the same level of detail in the logs.
A server cannot control who attempts to connect to it. Script kiddies
run scripts that probe entire IP address ranges or random addresses in an
attempt to find vulnerable systems - they typically scan for web servers
and other well-known ports as a starting point to attempt to hack into
the systems.
That is normal and part of “life on the Internet”. Companies that have
entire teams devoted to hardening and securing their systems constantly
monitor that traffic to determine the threat risk level and to ensure
that appropriate measures are taken in place.
But a request to a web server on port 80/443 in and of itself is not a
“hack” attempt.
It’s a combination of behaviors.
If your router is set to forward ports 80 and 443 to your openSUSE box,
then you are going to have attempts to access the system. Attempts to
hack a box don’t translate to success.
Being diligent is of course appropriate. But don’t misinterpret what
you’re seeing and make assumptions based on not understanding what you’re
seeing.
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
Unless the remote User is intentionally trying to download a file that doesn’t exist on your system in machine gun fashion, it’s not a malicious DDOS attack and unless your webserver is running on a tiny device like a RPi, you should have plenty of excess hardware capability for even weak attacks if that is what is what is happening.
Short of using your Fortigate to block the IP address of the remote User(Yes, you should be able to do that),
You can also re-tune your web server for more capacity, so for instance this might be more necessary for a web server like Apache but less necessary for an nginx webserver because of how they serve files and manage network connections.
TSU
I captured the traffics and if you like I can share.
OK – I suspect that, we can begin to understand you concerns.
Given that, the Fortinet Fortigate product seems to be a dedicated device which offers Unified Threat Management, please explain why that dedicated protection device is allowing unwanted access to a particular server located within your protected network?
- Is the link between the dedicated device providing Threat Management and the Internet symmetrical or asymmetrical? – Are the downlink and uplink bit-rates identical or, is the downlink faster than the uplink?
- What happens if the information being offered by the openSUSE server is moved off to another server? – Does the other server (preferably with an OS from another distro) also suffer from the effects that the openSUSE server seems to be suffering?
- Assuming an asymmetric bit rate between the dedicated Threat Management device and the Internet, can the dedicated Threat Management device throttle the downlink bit-rate to the openSUSE server to be the same as the uplink bit-rate?
- Assuming that, the information being offered by the openSUSE server is “interesting” for whoever it is, can the dedicated Threat Management device delay the uplink packets containing the acknowledgements being sent by the openSUSE server in response to the downlink session requests being received from the Internet?
- Assuming that, the session request flood can be narrowed to a specific IP address range, can the dedicated Threat Management device be configured to drop a percentage (per minute or per second) of the downlink session requests being received from that IP address range for the openSUSE server?
- Is the hardware of the openSUSE server the same as the hardware of the other server systems connected to the dedicated Threat Management device?
The Wireshark capture traffic is:
https://paste.opensuse.org/view//3101802
Looking at the trace and using <https://www.iplocation.net/> to work out where on the Planet Earth the packets are coming from, the following may be concluded:
- “fe80::c965:cfcf:d265:fdb9” is a private IPv6 address.
- “172.20.2.3?” are private IPV4 addresses.
- “224.0.0.252” is not locatable.
- “8.8.4.4” is Google …
- “5.39.28.137” is located either in France or, the Czech Republic.
- “216.108.251.184” is located in Hong Kong.
And yes, there are TCP packets being processed every few milliseconds.
- Meaning, the server is busy and, processing the traffic at a respectable rate.
But, I can’t see anything which is hinting at an attack – it seems to be perfectly normal high volume TCP traffic being processed by a system which can happily handle the traffic rate …
In your opinion, this amount of traffic for a linux server that just connected to the internet and not provide any services is normal?