Domanda:
Se un server apre solo le porte 22 e 80, abbiamo solo questi due modi per hackerarlo?
244boy
2020-04-18 20:31:16 UTC
view on stackexchange narkive permalink

Se un server Linux apre solo la porta SSH 22 e la porta HTTP 80, dobbiamo passare attraverso una di queste due porte per hackerare il server da Internet?

Se hai solo queste due porte aperte, puoi comunicare solo con quelle due, sì.
Dipende da come definisci "aperto" - forse come "risposte con SYN / ACK o RST a un SYN"?In tal caso, potrebbe reagire ad altre porte (o al traffico non TCP) in modi vulnerabili, anche se forse non tramite risposte di per sé.
Stai parlando di quali porte sono aperte sul server stesso?O stai parlando di quali porte inoltra il router?O cosa esattamente?
Per quanto riguarda gli attacchi remoti, allora certo.Il fatto che tu sia o meno al sicuro dipende in gran parte da quali programmi sono in ascolto su quelle porte e se sono adeguatamente protetti.
Probabilmente vuoi anche 443.
Cinque risposte:
reed
2020-04-18 21:46:30 UTC
view on stackexchange narkive permalink

Non proprio. Direi che dipende dal tuo modello di minaccia. Potrebbero esserci altre minacce che non hanno bisogno di utilizzare quelle porte per compromettere il tuo server. Il primo esempio a cui riesco a pensare in questo momento è un attacco alla catena di approvvigionamento. Quando aggiorni un software sul tuo server, se il software aggiornato è stato compromesso da un attacco alla catena di approvvigionamento, il tuo server verrà infettato. Oppure, se installi programma-esempio per errore invece di programma_esempio (nota il trattino invece del trattino basso) e programma-esempio era dannoso e era stato dato quel nome apposta per confonderti, quindi il tuo server sarà compromesso. Penso che qualcosa di simile sia successo di recente ... oh, ieri ( Bitcoin che ruba app nel repository Ruby). Altri esempi? Forse un po 'di MITM nelle connessioni in uscita dal tuo server. Quindi non dimentichiamoci del phishing o di qualsiasi cosa che coinvolga l'ingegnere sociale.

Quindi, per essere precisi, se mi chiedessi "in generale, posso essere hackerato da una minaccia remota solo attraverso porte aperte?", La mia risposta sarebbe no. La probabilità o meno di alcune minacce dipende dal tuo modello di minaccia, che a sua volta dipende da ciò che fa il tuo server, da come lo gestisci, da chi sei, ecc.

Ma, per essere chiari, anche se il server fosse stato compromesso da un simile attacco, la comunicazione in entrata / uscita tra il server e l'attaccante sarebbe avvenuta tramite la porta 22 o la porta 80, giusto?
@onurcanbektas No, porte aperte generalmente significano porte in ascolto, quindi solo le connessioni in entrata le usano.Le connessioni in uscita generalmente utilizzano una porta casuale (con alcune limitazioni).A meno che con "porte aperte" non si intenda che tutto il resto è bloccato da un firewall.Ma in tal caso il server probabilmente non sarebbe in grado di effettuare connessioni in uscita, come quella necessaria per scaricare l'aggiornamento menzionato in questa risposta.
@Tomeamis Quindi, a meno che non sia bloccata da un firewall, un'applicazione può utilizzare qualsiasi porta casuale per le connessioni in uscita?
@onurcanbektas Sì.Puoi controllare tu stesso (puoi eseguire `netstat -a` per vedere le connessioni attive, e la maggior parte avrà un numero di porta alto con l'indirizzo locale).La porta 80 assegnata a HTTP è per la destinazione.Quindi, quando vuoi connetterti al server example.com su HTTP, ti connetti a example.com alla porta 80, ma la connessione può provenire da qualsiasi porta.E dato che i numeri di porta bassi vengono generalmente assegnati, le porte alte vengono solitamente utilizzate per le connessioni in uscita.
@Tomeamis oh capisco;Grazie per la risposta.
@onurcanbektas solo per completezza, non * qualsiasi * porta casuale.Non puoi usare le porte già in uso (ad esempio la porta 80 in questo caso) e di solito i sistemi operativi ti limitano a porte superiori a 1024 o superiori a un numero maggiore (il numero esatto dipende dal sistema operativo e probabilmente puoi cambiarlo con un po 'di sforzo).
Moo
2020-04-19 07:05:16 UTC
view on stackexchange narkive permalink

No.

Ci sono molte cose che possono essere attaccate su un computer di destinazione e un'applicazione di servizio (httpd o sshd per esempio) è solo una di quelle cose.

Ricorda, c'è un intero stack di rete tra la porta di rete fisica sulla scheda di rete e l'applicazione che gestisce il traffico effettivo (cioè sshd) - in questo stack ci sono cose come funzionalità del kernel come firewall, driver di rete ecc. attaccato separatamente all'applicazione di gestione.

Vedi il numero di vulnerabilità di esecuzione remota del kernel Linux evidenziate qui che non richiedono alcuna applicazione di gestione per essere sfruttate, e invece consentono un utente malintenzionato deve eseguire codice semplicemente creando un pacchetto di rete non valido.

Ovviamente, è più facile attaccare l'applicazione piuttosto che il kernel, perché il kernel tende ad essere ispezionato molto più pesantemente.

fraxinus
2020-04-19 17:50:04 UTC
view on stackexchange narkive permalink

Un tentativo di elencare alcuni modi per hackerare un server senza utilizzare http o ssh:

  1. Utilizzo di una vulnerabilità in Management Engine
  2. Utilizzo di un bug in una scheda di rete firmware o driver
  3. Usare qualcosa di non molto sicuro nella piattaforma di virtualizzazione, avere un accesso legittimo a (o hackerare) una macchina virtuale vicina
  4. Sfruttare qualche bug nel driver IP o TCP nel sistema operativo
  5. Utilizzo di alcune interazioni di rete in cui il server funge da client (query DNS, aggiornamenti automatici, accesso al database), spoofing o hacking nel server legittimo di questi servizi.

    6. Esempio per 4.: molto tempo fa, c'è stato un attacco ping of death che sfruttava un bug nel driver del livello IP, nessuna porta aperta necessaria.

haha sì, quando ero uno scr1pt k1d una volta ho ucciso un client win95 in giappone .. scusa
gnasher729
2020-04-18 23:56:36 UTC
view on stackexchange narkive permalink

La chiusura dei port è una delle prime linee di difesa.

Quando una porta è aperta, ci sarà un software in esecuzione che ha gestito i dati in entrata su quella porta. Quel software può contenere bug che consentono il successo di un attacco. Se apri 100 porte, ci sono 100 software potenzialmente insicuri. Con solo due porte aperte, ci sono solo due parti di software potenzialmente vulnerabili. Ovviamente assicurarsi che 100 pezzi non siano vulnerabili è molto più difficile di due pezzi.

Ma un utente malintenzionato può tentare di entrare attraverso un altro percorso. Il tuo server dovrebbe ricevere blocchi di dati contenenti un numero di porta e il tuo software dovrebbe indirizzare il blocco alla porta giusta o buttarlo via, possibilmente registrarlo. Se il software che invia i blocchi in entrata alle porte ha dei bug, un utente malintenzionato potrebbe sfruttare questi bug e un tale exploit potrebbe essere indipendente dalle porte aperte.

Questo è impreciso.Le porte che non sono chiuse non sono aperte: https://security.stackexchange.com/questions/96568/open-ports-with-no-services-bound-to-them
"Se apri 100 porte, ci sono 100 parti di software potenzialmente non sicure." <- Perché presumi una mappatura 1-a-1 tra porte e "parti di software"?Un singolo programma può facilmente ascoltare su un centinaio di porte diverse.Certo, sarebbe una cosa strana da fare, ma ci sono molti programmi che ascoltano almeno su più di una porta.(Ed è vero anche il contrario, è possibile condividere una singola porta di ascolto tra più processi.)
@PeterW.Cosa stai cercando di dire?Nessuno ha mai fatto alcun reclamo per quanto riguarda le porte filtrate e non filtrate.Una porta aperta non è semplicemente una porta non filtrata, è una porta a cui puoi connetterti con successo ().
PaHa
2020-04-18 20:55:03 UTC
view on stackexchange narkive permalink

Se il server ha solo servizi ssh e http aperti, dovrai sfruttare le possibili vulnerabilità relative a uno o entrambi i servizi, per hackerare il server.

Un altro modo sarebbe l'accesso fisico alla tastiera del server, ma penso che intendevi solo attaccare attraverso la rete. (ricorda di scansionare tutte le porte 1-65535)

Ricorda che c'è un intero stack di rete tra la porta di rete fisica e l'applicazione ricevente, comprese le funzionalità del kernel e i driver che possono essere attaccati.Questo può essere fatto anche su porte chiuse - solo perché nulla è in ascolto su quelle porte non significa che il sistema non le stia gestendo, ad esempio nel sistema di regole del firewall, ecc. Ampie opportunità per un vettore di attacco.
-1.OP, sei incoraggiato ad aspettare almeno un giorno o due prima di accettare una risposta, per dare alla community ea te stesso la possibilità di giudicare la qualità di una selezione di risposte prima di sceglierne una (se ce ne sono!).
L'unica risposta finora per menzionare l'attacco fisico.
@mckenzm Vero, ma la domanda dice da Internet che sembra escludere attacchi fisici.
Lo pago io, preclude anche dispositivi compromessi sulla rete locale.(Colleghi).


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...