Vraag Hoe kun je zien wat een server doet? [Gesloten]


Ik heb 3 Linux-boxen overhandigd, 1 voorkant met apache erop en nog een 2 die, voor zover ik weet, niet veel doen. Alles draait op Redhat.

De vraag is simpel: hoe weet ik wat de server aan het doen is? Er is geen documentatie beschikbaar van de maker.


42
2018-06-09 13:23


oorsprong


De processlist, netwerklisteners (misschien zou vergelijken moeten zijn uitgevoerd op basis van init-scripts) ... - HBruijn
verdomme! weet iemand toch waar ze voor zijn? dus ze willen dat je hen steunt, maar weet je niet wat ze doen ?! - Digital Lightcraft
Zet ze uit. Iemand zal het je laten weten, bijna onmiddelijk, wat werkt niet. - jscott
ZET HET NIET UIT. Koppel de Ethernet-kabel los als u wilt scream-testen. Als je nog nooit een box met een uptime van twee jaar hebt gehad die niet opnieuw kan worden opgestart, zul je dit op een gegeven moment doen. Dit is niet het moment om die frustratie aan de mix toe te voegen. - Aaron Copley
Wat iedereen zei, maar ook: voer nmap tegen hen uit. - Katherine Villyard


antwoorden:


Koppel de Ethernet-kabel los en zie wie er overstuur raakt.

Serieus is dat dergelijke mysteriemachines veel mentale overhead creëren voor een team en vaak absoluut geen bedrijfswaarde bieden. Praat met je baas, als niemand weet wat het doet, kan het niemand iets schelen wat het doet.


42
2018-06-09 17:49



ZET HET NIET UIT. Koppel de Ethernet-kabel los als u wilt scream-testen. Als je nog nooit een box met een uptime van twee jaar hebt gehad die niet opnieuw kan worden opgestart, zul je dit op een gegeven moment doen. Dit is niet het moment om die frustratie aan de mix toe te voegen. (Dit hier kopiëren omdat het moet worden gelezen.) - Aaron Copley
Je hebt 100% gelijk, ik heb het bericht bewerkt om dat weer te geven. Ik was een beetje grappig, maar ik kan nog steeds grappig zijn zonder een ramp te veroorzaken. - Josh Rumbut
Voordat het netwerk wordt losgekoppeld, is het een goed idee om een ​​lijst met actieve processen op te slaan en sockets op elke server te openen - voor het geval dat iets vertrouwt op een TCP-verbinding tussen de servers die toevallig vele maanden lang GEVESTIGD zijn gebleven zonder dat iemand erover nadacht het automatiseren van alle stappen die nodig waren om het in het eerste geval te openen. (Bijvoorbeeld als iemand tijdelijk een ssh-port forwarding nodig had en het vervolgens vergeten was.) - kasperd
Doe dit niet. Wat een belachelijk advies. Domme, gedachteloze IT-mensen die dit deden, kostten me zoveel tijd en werk. EERST VRAGEN. Als je niet weet wie je moet vragen, VRAAG IEDEREEN. - Lightness Races in Orbit
Zorg ervoor dat je genoeg tijd laat voor iemand om te gillen - de enige keer dat ik dit deed met een stoffige of desktop-machine die op een serverruimte-rek zat - niemand wist wat het deed, het duurde een volledige maand voordat iemand het merkte toen we het loskoppelden . Blijkt dat het deel uitmaakte van het salarissysteem, zonder die server kon de boekhouding geen maandelijkse loonlijst genereren. Het had minimaal drie jaar zonder toezicht gelopen - dus de "scream-test" was een succes, als we het niet hadden gedaan, zou de server uiteindelijk op zichzelf zijn overleden. We eindigden het in onze VMware-cluster. - Johnny


Dit is een vrij brede vraag voor het Serverfault-formaat, maar hier is een goed begin:

  • Controleer op lopende processen en processen die gepland zijn om te worden uitgevoerd bij het opstarten van het systeem.
    • Bekijk de lopende configuratie van elk.
    • Zoek naar gedefinieerde gegevensmappen. (Misschien heeft iemand MySQL geïnstalleerd en ingeschakeld, maar er zijn geen databases.)
  • Controleer op geplande taken.
  • Controleer de logboeken om te zien;
    • wie is er recent ingelogd (en vraagt ​​ze)
    • en om een ​​idee te krijgen van wat er is uitgevoerd.

Je hebt de versie niet genoemd, dus ik heb de details weggelaten.


30
2018-06-09 14:02



Er is iets belangrijker dan welke services worden geconfigureerd om te starten wanneer het systeem opstart. Welke services worden momenteel uitgevoerd? Het starten van een service en het vergeten om het te configureren om te starten bij het opstarten is geen moeilijke fout om te maken. In een verwante notitie is het een goed idee om naar de andere systeemstatus te kijken, zoals: koppelpunten, routeringstabel, iptables-regels. Dit zijn allemaal dingen die gemakkelijk kunnen worden gewijzigd terwijl het systeem draait zonder te onthouden de configuratiebestanden bij te werken die tijdens het opstarten werden gebruikt. - kasperd
Daarnaast zou ik een poortscanner gebruiken om te zien welke poorten open zijn en vervolgens proberen om verbinding te maken met de gebruikelijke hulpmiddelen. Voor (een eenvoudig) voorbeeld, als poort 443 open is, kunt u proberen een webbrowser te gebruiken om er verbinding mee te maken. Ik heb deze schijnbaar in de steek gelaten servers regelmatig moeten verkennen en een van mijn favoriete tools om snel door de configuratiebestanden in / etc en andere plaatsen te bladeren, is door "lynx" of "links" te gebruiken als je dat wilt. Dit zijn op karakters gebaseerde webbrowsers die ook goed genoeg werken als bestandsbrowser, met handige cursortoetsennavigatie. - aseq
@kasperd Eerlijk spelen op hardloop- en permanente services. Maar ik dacht aan firewallregels, koppelpunten, enz. Die leek me als nevencomponenten die al aan een van de bestaande opsommingspunten zijn gekoppeld. YMMV. - Aaron Copley
Voeg toe - Controleer op actieve netwerkverbindingen en noteer de namen van de services en poortnummers. De beste methode om dit te doen, verschilt per besturingssysteem. BIJVOORBEELD netto stat. Plaats ook een soort tracering op de computer, zodat u kunt zien wat het doet gedurende de dag. Misschien wilt u ook rekening houden met scenario's wanneer dingen die op de servers worden uitgevoerd, schadelijk kunnen zijn. - IceMage


Er zijn een paar dingen die u zou kunnen doen om te proberen en na te gaan wat er op uw systeem draait.

U kunt controleren op welke poorten uw server luistert om een ​​idee te krijgen van wat er op die server staat. Een goede opdracht om te gebruiken zou zijn:

 [root@server ~]# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             Stat    e       PID/Program name
tcp        0      0 0.0.0.0:139                 0.0.0.0:*                   LIST    EN      1880/smbd
tcp        0      0 0.0.0.0:5666                0.0.0.0:*                   LIST    EN      1911/nrpe
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LIST    EN      1759/sshd

Zoals u kunt zien aan de hand van de bovenstaande voorbeelduitvoer, presenteert deze u de protocolversie (tcp of udp), het adres waarnaar wordt geluisterd, de poort die geopend is en het programma dat luistert.

In het bovenstaande afgekapte voorbeeld (een servermachine) kunt u zien dat tcp-poorten 139, 5666 en 22 luisteren. Deze lossen op naar respectievelijk samba, nrpe (Nagios-agent) en ssh en worden bevestigd wanneer je het programma controleert dat op die poort luistert.

Bovendien kunt u de lijst met daemons controleren die zijn geconfigureerd om te starten bij het opstarten, om dit te doen, voert u het volgende uit: chkconfig --list | grep "3:on"

Voorbeeld:

[root@server ~]# chkconfig --list | grep "3:on"
NetworkManager  0:off   1:off   2:on    3:on    4:on    5:on    6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
sysstat         0:off   1:on    2:on    3:on    4:on    5:on    6:off
udev-post       0:off   1:on    2:on    3:on    4:on    5:on    6:off
vncserver       0:off   1:off   2:on    3:on    4:on    5:on    6:off
webmin          0:off   1:off   2:on    3:on    4:off   5:on    6:off
x2gocleansessions       0:off   1:off   2:on    3:on    4:on    5:on    6:off
.
.
.

of:

service --status-all


19
2018-06-09 14:48



ik vind netstat -plunt makkelijker te onthouden. - abligh
Ook, tcpdump kan handig zijn om te bepalen wie daadwerkelijk elke service gebruikt. - abligh


Een andere methode omvat het controleren van de /etc directory en kijk naar de wijzigingsdatums. Na een nieuwe installatie moeten alle bestanden in deze map ongeveer dezelfde datum / tijd hebben. En omdat een installatie meestal veel dingen installeert die mensen meestal niet gebruiken, alleen de bestanden met een latere wijzigingsdatum geven het werkelijke doel van de server weer. Als dit ext4 is, zou u ook de geboortedatum van directory's moeten kunnen extraheren, zodat de taak vrij eenvoudig zou kunnen zijn.

Nog een andere methode zou het controleren van de .bash_history bestanden om te zien wat de admins van plan waren. Dit bestand kan een schat aan kennis bieden.


18
2018-06-09 15:22





Controleer de firewallregels. Met een beetje geluk is het geconfigureerd voor default-deny. Dat betekent dat er een expliciete regel is voor elke toegestane service.

Dit is beter dan netstat omdat het ook poorten kan weergeven die geopend zijn voor bijvoorbeeld nachtelijke back-ups.


7
2018-06-09 20:41





Eén antwoord dat ik nog niet heb gezien: controleer de meest recentelijk gewijzigde bestanden. Logs, databasebestanden, andere uitvoerbestanden enz. Worden mogelijk nog steeds geschreven en kunnen aanwijzingen bevatten:

find . -mtime -3 

Dat zou gewijzigde bestanden in de huidige map vinden en dieper, veranderd in de laatste 3 dagen. Verhoog het getal 3 tot een weloverwogen gok totdat u enige output krijgt die u kunt onderzoeken.

Niet onfeilbaar, omdat de boxen mogelijk enkele webservice-oproepen verwerken en sommige gegevens retourneren zonder ooit iets te schrijven. Maar toegevoegd aan de geweldige mix hierboven vermeld, kan het slechts enkele aanwijzingen opleveren.


6
2018-06-11 12:39