Webserver werkt niet meer na toevoegen 2e NIC in CentOS 7

[Daffie]

Bij een vorige werkgever heb ik met Zabbix gewerkt, een open-source monitoring oplossing. Ik heb me toen alleen over Zabbix an sich hoeven buigen, een collega had toen de onderliggende CentOS machine ingericht.

Inmiddels ben ik ergens anders werkzaam en heb ik mijn collega's ook verteld over Zabbix. Dat was zodanig positief ontvangen dat ik nu een PoCje ga maken hieromheen. Nu moet ik alleen wel zelf de CentOS server inrichten. Ik heb in het verleden hier en daar wel eens wat in CentOS gedaan maar mijn kennis hierin is nou niet bepaald erg groot.

In eerste instantie is het allemaal prima gelukt om een CentOS 7 minimal server te installeren op een ESXi server, statisch IP erin en Zabbix te installeren. Nu is het echter zo dat de management poorten van de fysieke servers (iDRAC en ILO) op een ander subnet zitten; het 'client' lan is 195.193.67.x/24 (ik weet, dat is geen officieel private subnet, maar dit is zo in het verleden ontstaan dus daar moet ik me voorlopig maar even aan houden ), het 'management' lan waar de ILO's en iDRAC's op zitten is 172.16.10.x/24.

Ik moest dus een extra NIC toevoegen aan CentOS. Na erg lang geklungel heb ik dat uiteindelijk voor elkaar gekregen. CentOS gaf de extra interface de naam 'ens192' (de reeds aanwezige interface heet ens160). In eerste instantie had ik het tooltje nmtui gebruikt maar ik kreeg het niet voor elkaar. Uiteindelijk heb ik /etc/sysconfig/network-scripts/ifcfg-ens160 gekopieerd naar /ifcfg-ens192, de gegevens aangepast waar nodig, en het werkte. Tenminste, tot op zekere hoogte. Ik kon nog steeds via het client lan SSH'en naar de CentOS server, en vanaf deze server waren de management poorten in de 172.16.10.x range te pingen. Maar, nu krijg ik de webserver niet meer aan de gang! Er draait op http://[computernaam]/ zo'n default page van Apache, en op http://[computernaam]/zabbix draaide Zabbix. Maar dat kan ik nu allemaal niet meer aan doen. de HTTPD service draait.

Hieronder de relevante (denk ik) configs:

ifcfg-ens160:

code:

TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME="VAA LAN"
UUID=84a1392a-37ea-42c5-9dc9-2dd757d4218c
DEVICE=ens160
ONBOOT=yes
DNS1=195.x.y.z
DNS2=195.x.y.a
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_PRIVACY=no
IPADDR=195.x.y.w
PREFIX=24
GATEWAY=195.x.y.v

ifcfg-ens192:

code:

TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=no
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=no
IPV6_DEFROUTE=no
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME="Management LAN"
UUID=447140a4-a9d8-445d-b888-f85ecf38a15b
DEVICE=ens192
ONBOOT=yes
IPV6_PEERDNS=no
IPV6_PEERROUTES=no
IPV6_PRIVACY=no
IPADDR=172.x.y.x
PREFIX=24

/etc/sysconfig/network:

code:

# Created by anaconda

GATEWAYDEV=ens160

Ik heb het idee dat ik iets over het hoofd zie maar ik krijg niet gevonden wat of waar. Weet iemand wat er mis gaat?

[Hero of Time]

Welke errors krijg je specifiek en kan je nog wel gewoon pingen naar de server? Wat zie je in de apache logs (/var/log/httpd)? Wat is je apache configuratie?

[Daffie]

@Hero of Time : /var/log/httpd is helemaal leeg. Ik kan in /etc/httpd/logs/access_log of /error_log ook niks vreemds vinden. Ik heb geen idee of logging wel aan staat op Apache, deze installatie is ook helemaal default. De config (/etc/httpd/conf/httpd.conf) van Apache is als volgt. Ik heb de commented lines eruit gehaald, werd wel erg lang anders:

code:

ServerRoot "/etc/httpd"
Listen 80
Include conf.modules.d/*.conf

User apache
Group apache

ServerAdmin [iemand]@[ergens]

<Directory />
    AllowOverride none
    Require all denied
</Directory>

DocumentRoot "/var/www/html"

<Directory "/var/www">
    AllowOverride None
    # Allow open access:
    Require all granted
</Directory>

# Further relax access to the default document root:
<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

<IfModule dir_module>
    DirectoryIndex index.html
</IfModule>

<Files ".ht*">
    Require all denied
</Files>

ErrorLog "logs/error_log"

LogLevel warn

<IfModule log_config_module>
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common

    <IfModule logio_module>
      # You need to enable mod_logio.c to use %I and %O
      LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
    </IfModule>

    CustomLog "logs/access_log" combined
</IfModule>

<IfModule alias_module>
    ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
</IfModule>

<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options None
    Require all granted
</Directory>

<IfModule mime_module>
    TypesConfig /etc/mime.types
    AddType application/x-compress .Z
    AddType application/x-gzip .gz .tgz
    AddType text/html .shtml
    AddOutputFilter INCLUDES .shtml
</IfModule>

AddDefaultCharset UTF-8

<IfModule mime_magic_module>
    MIMEMagicFile conf/magic
</IfModule>

EnableSendfile on
IncludeOptional conf.d/*.conf

Vanaf mijn Client PC kan ik de Zabbix/CentOS server pingen. Vanaf de CentOS server kan ik de management poorten van de servers ook pingen.

[Heli0s]

Op welke interface luistert httpd? (wat zegt)

code:

netstat -tunlp

wat is de default route? Heb wel eens gehad dat hij op de verkeerde route antwoorden.

code:

route

[Daffie]

@Heli0s : netstat -tunlp geeft het volgende resultaat:

code:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      976/sshd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1597/master
tcp        0      0 0.0.0.0:10051           0.0.0.0:*               LISTEN      1029/zabbix_server
tcp6       0      0 :::80                   :::*                    LISTEN      2557/httpd
tcp6       0      0 :::22                   :::*                    LISTEN      976/sshd
tcp6       0      0 ::1:25                  :::*                    LISTEN      1597/master
tcp6       0      0 :::10051                :::*                    LISTEN      1029/zabbix_server
tcp6       0      0 :::3306                 :::*                    LISTEN      1059/mysqld

en route geeft:

code:

default         195.x.y.z       0.0.0.0         UG    100    0        0 ens160
172.16.10.0     0.0.0.0         255.255.255.0   U     100    0        0 ens192
195.193.67.0    0.0.0.0         255.255.255.0   U     100    0        0 ens160

EDIT: Wat wellicht goed is om te weten, is dat SELinux helemaal uit staat, omdat het hier om een PoC gaat en deze server in een geisoleerd stukje LAN staat. Aan firewall rules kan het dus mijn inziens niet liggen (?)

[ Voor 8% gewijzigd door Daffie op 22-05-2017 14:45 ]

[Daffie]

Het probleem is opgelost. Toen ik zat te klooien met de extra NIC heb ik de server enkele keren gereboot. Na de reboot stond firewalld blijkbaar weer aan. Toen ik deze uit zette (service firewalld stop) werkte het weer. Ik heb nu (hopelijk) deze daemon persistent uitgezet met het command systemctl disable firewalld

[Hero of Time]

Correct, de firewall is nu uitgeschakeld en zal niet bij het opstarten aan gaan. Maar je kan nog steeds de firewall starten. Dat kan je dan weer voorkomen door systemctl mask firewalld te doen.

[Blokker_1999]

Bad idea. Waarom niet de firewall aan laten staan en deze correct configureren?

[Daffie]

Laat ik je vraag met een andere vraag beantwoorden. Waarom is deze firewall uitzetten een bad idea?

[Basz0r]

Daffie schreef op maandag 22 mei 2017 @ 19:59:
Laat ik je vraag met een andere vraag beantwoorden. Waarom is deze firewall uitzetten een bad idea?

Met een lokale firewall bepaal je welk verkeer je van de buitenwereld wil toestaan. Zo voorkom je dat (onbeveiligde) services, niet zomaar buiten je weten om open staan. Zo kan je bijv ook SSH voor de buitenwereld dicht zetten, maar voor bepaalde IP adressen weer open.

Stel je voor dat je PHP applicatie gehackt wordt, en de hacker weet een shell open te zetten. Dan kan hij bijv een TCP socket open zetten voor de wereld (boven poort 1024, als je apache niet als root draait ), en eventueel commando's daar naartoe spuwen. Als je een lokale firewall hebt, dan is de kans kleiner dat een hacker daar misbruik van kan maken.

[ Voor 29% gewijzigd door Basz0r op 22-05-2017 20:08 ]

[Hero of Time]

Basz0r schreef op maandag 22 mei 2017 @ 20:05:
Met een lokale firewall bepaal je welk verkeer je van de buitenwereld wil toestaan. Zo voorkom je dat (onbeveiligde) services, niet zomaar buiten je weten om open staan. Zo kan je bijv ook SSH voor de buitenwereld dicht zetten, maar voor bepaalde IP adressen weer open.

Standaard staat SSH in firewalld bij elk profiel wagenwijd open. Alleen bij 'block all' wordt port 22 gesloten (net als de rest, gek he? ). Als je echt met een firewall wilt werken, dan stel je die volledig af en weet je wat je doet en zou een probleem zoals de TS had in de eerste plaats niet voorkomen en in de tweede plaats hier niet gevraagd worden omdat het eigenlijk al direct bekend zou moeten zijn dat het in die hoek moet zitten.

Stel je voor dat je PHP applicatie gehackt wordt, en de hacker weet een shell open te zetten. Dan kan hij bijv een TCP socket open zetten voor de wereld (boven poort 1024, als je apache niet als root draait ), en eventueel commando's daar naartoe spuwen. Als je een lokale firewall hebt, dan is de kans kleiner dat een hacker daar misbruik van kan maken.

Daar gaat een firewall echt een klap tegen doen. Lekke PHP is gewoon een lekke PHP. Als er remote code execution mogelijk is, gaat een hacker echt geen lokaal shelletje openen op een poort om bepaalde zaken te doen hoor, dat doet 'ie direct via PHP.

[Basz0r]

Hero of Time schreef op maandag 22 mei 2017 @ 22:07:
[...]

Standaard staat SSH in firewalld bij elk profiel wagenwijd open. Alleen bij 'block all' wordt port 22 gesloten (net als de rest, gek he? ). Als je echt met een firewall wilt werken, dan stel je die volledig af en weet je wat je doet en zou een probleem zoals de TS had in de eerste plaats niet voorkomen en in de tweede plaats hier niet gevraagd worden omdat het eigenlijk al direct bekend zou moeten zijn dat het in die hoek moet zitten.


[...]

Daar gaat een firewall echt een klap tegen doen. Lekke PHP is gewoon een lekke PHP. Als er remote code execution mogelijk is, gaat een hacker echt geen lokaal shelletje openen op een poort om bepaalde zaken te doen hoor, dat doet 'ie direct via PHP.

Een beetje bewustzijn creëren kan geen kwaad. En je kan er niet van uit gaan dat iedereen meteen alle aspecten van zo'n systeem kent. Hij heeft nu in ieder geval wat materiaal om zich er in te verdiepen.

Het remote code execution verhaal was als voorbeeld. Er zijn talloze manieren om het toe te passen. Maar het ging er om dat een lokale firewall bepaalde narigheid kan voorkomen. Ik weet ook wel dat het niet een volledige oplossing is, maar één stap is er al meer als geen.

[Daffie]

Dank voor de antwoorden. Ik ben me terdege bewust van het nut (of de noodzaak, zelfs) van firewalls, en die hebben we ook zeer zeker in gebruik daar waar het 'nodig' is [insert discussie over 'waar is het wel en niet nodig dan' here ] Echter niet op deze CentOS server, omdat dit zoals gezegd sowieso op een geïsoleerd stukje netwerk zit en omdat het een PoC betreft. Als de PoC succesvol is gaan we kijken naar de benodigde kennisinvestering om zoiets ook in productie te kunnen draaien.