wenn du ernsthaft meinst, dass das ausreicht und ein System damit gut absichert ist… dann hören wir an der Stelle am besten auf.
Ich hab schon infizierte Server gesehen. Also wirklich infiziert von Leuten die (leider )wissen was sie tun. Das ist kein Spaß.
Eine Firewall macht im Prinzip “nur” alle Ports zu, die du nicht brauchst. Das ist grundsätzlich nichts verkehrtes. Da kann schon die erste Hürde sein, zu wissen was macht braucht und was nicht. Allerdings nützt dir eine Firewall gar nichts, wenn die zwar auf Portebene den Traffic filtert, ein Angreifer aber auf Applikationsebene angreift. Dann werden genau die Ports genutzt, die du freihaben musst, weil sonst der Server nicht arbeiten kann.
" Das ist grundsätzlich nichts verkehrtes."
Ich würde mal sagen das ist fundamental wichtig.
Welche Ports man braucht ?
http(s), ssh. Das wars.
Wenn ich sicher wäre unser Provider würde niemals unsere Ip ändern, könnte ich sogar ssh(22) dicht machen. Für den Mailserver (Postix,Dovecot) noch 3,4 Ports das wars.
Ich glaube Angriffe funktionieren, wenn Mitarbeiter sich übers Netzt Trojaner einfangen.
Ansonsten ist das schon sicher.
Mit “grundsätzlich nicht verkehrt” meine ich, dass sollte man machen, aber ist bei weitem nicht alles und vorallem nicht das Entscheidende.
Wie gesagt, erfolgreiche Angriffe laufen eher auf Applikationsebene. Der Datenverkehr wird da zu 99% über http(s) abgewickelt. Da kannst du mit einer Firewall gar nichts machen. Die weiß aufgrund der gesicherten Datenverbindung noch nicht einmal, was für Daten im Einzelnen darüber laufen.
“Ich glaube Angriffe funktionieren, wenn Mitarbeiter sich übers Netzt Trojaner einfangen.
Ansonsten ist das schon sicher.”
Nein. Erfolgreiche Angriffe kommen meist über unzureichend konfigurierte/ ungepatche Software oder schwache Logindaten. Zumindest bei Servern. Du verwechselst das gerade mit Firmen-Netzen. Wir reden hier von Linux-Einzel-Servern.
Mit Einzel-Server ist ein Webserver gemeint, der den gesamten Stack (LAMP z.B. beim OXID Shop) bereitstellt. Im Gegensatz zu Server-Clustern, wo die Dienste auf mehrere Server aufgeteilt sind. Das hat nichts damit zu tun wie viele Leute nicht an dem System über verschiedenste Dienste anmelden dürfen-
An einem Server, worauf Webapplikationen (wie einen Shop) laufen, sollten sich tunlichst nur sehr wenige Mitarbeiter per SSH anmelden dürfen bzw. die Zugangsdaten dazu haben. Ansonsten wäre das bereits die erste Schwachstelle, ohne das der Server etwas dafür kann.
Und solltest du von den Zugangsdaten zur Applikation sprechen, also z.B. der Login zum Adminbereich von Shop oder Wordpress: Ein guter Angreifer, der mehr kann als ein durchschnittliches Scriptkiddie, braucht für einen erfolgreichen Einbruch keine Logindaten, die zuvor z.B. per Trojaner vom Arbeits-PC eines Angestellten entwendet wurden.
Ich kenne einige konkrete Fälle von infizierten Systemen (Linux Webserver), bei denen kein einiziger geklauter/ausgespähter Login/Passwort die Ursache war.
nicht falsch verstehen. Du kannst machen was du willst. Nur soll bitte niemand den Thread hier lesen und danach denken, als Händler wäre es eine gute Idee für 10 EUR einen root-Server zu mieten und den selbst adminstrieren zu wollen bzw. zu können.
Ich war Softwareentwickler. Grundkenntnisse sollte man haben. Aber im Netz gibt´s so viele Infos dazu.
Es passiert aber immer wieder was Neues.
Mails verschicken wir noch über unser altes Paket. Gmail hat die Annahme verweigert, weil im DNS kein SFP1 Record eingetragen war. Offensichtlich prüfen die das mittlerweile.ab.
Gruß
Heinz
550-5.7.26 This message does not pass authentication checks (SPF and DKIM both
550-5.7.26 do not pass). SPF check for …
550-5.7.26 with ip: XXXXXXX].To best protect our users from spam, the
550-5.7.26 message has been blocked. Please visit …
das habe ich versucht bekomme aber weiter die Meldungen:
mmap() failed: [12] Cannot allocate memory
Fatal error: Out of memory (allocated 627056640) (tried to allocate 33554432 bytes) in phar:///homepages/33/dxxxx/htdocs/webshop21/composer.phar/src/Composer/DependencyResolver/Solver.php on line 201
Mittlerweile hatten wir täglich ca. 100 SSH-Login versuche.
Na ja sie kennen noch nicht mal den richtigen Usernamen.
Hat trotzdem genervt.
Habe den Standardport für SSH (22) geändert.
Das ist überaus einfach.
Jetzt ist Ruhe
Du hast wahrscheinlich keine 1024M zur Verfügung. Lass dir mal das aktuelle Limit ausgeben:
Check nochmal mit composer -V ob du wirklich composer 2 hast.
Dann gäbe es noch die Möglichkeit den Shop lokal zu installieren und zu transferieren, hast du ja schon mal gemacht.
Was auch geht ist nur das Composer Update lokal laufen zu lassen, die composer.lock auf den Server zu transferieren und auf dem Server composer install laufen zu lassen. Du musst dabei sicherstellen, dass du lokal die gleiche PHP-Version hast, oder mit
composer config platform.php 8.0.7
Composer anweisen, die PHP-Version für die Abhängigkeiten zu verwenden, die du später im Frontend verwendest.
Wenn der Shop schon installiert ist, und du composer install verwendest, dann musst du noch
composer run-script post-update-cmd
Auf dem Server ausführen, um die neuen Dateien zu kopieren.
Habe composer von 2.0.9 auf 2.2.12 upgedadet (mit dem Befehl /usr/bin/php7.4-cli composer.phar selfupdate 2.2.12)
jetzt kommt beim OXID-Update-Versuch (/usr/bin/php7.4-cli composer.phar update --no-plugins --no-scripts --no-dev) nur:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- OXID-esales/testing-library[v7.1.1, …, v7.3.0] require symfony/filesystem ^3.0 → satisfiable by symfony/filesystem[v3.0.0, …, v3.4.47].
- You can only install one version of a package, so only one of these can be installed: symfony/filesystem[v2.3.0, …, v2.8.52, v3.0.0, …, v3.4.47, v4.0.0, …, v4.4.42, v5.0.0, …, v5.4.19, v6.0.0, …, v6.2.5].
- OXID-esales/oxideshop-metapackage-ce v6.4.3 requires symfony/filesystem v4.4.42 → satisfiable by symfony/filesystem[v4.4.42].
- Root composer.json requires OXID-esales/oxideshop-metapackage-ce v6.4.3 → satisfiable by OXID-esales/oxideshop-metapackage-ce[v6.4.3].
- Root composer.json requires OXID-esales/testing-library ^v7.1.1 → satisfiable by OXID-esales/testing-library[v7.1.1, v7.1.2, v7.2.0, v7.3.0].
Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.
Parse error: syntax error, unexpected T_STRING in /homepages/33/xxxx/htdocs/webshop21/vendor/OXID-esales/oxideshop-doctrine-migration-wrapper/bin/migrate.php on line 11
Fatal error: main() [function.require]: Failed opening required ‘generate_views.php’ (include_path=‘.:/usr/lib/php4.4’) in /homepages/33/xxxx/htdocs/webshop21/vendor/bin/oe-eshop-db_views_generate on line 4
