How to close nc port in Debian 9?











up vote
0
down vote

favorite












I am struggling to close these ports which seem to be backdoors -- or at least I have never opened and used them. How can I close or shutdown nc and close these ports?



netstat -lntup | grep nc


netstat output



ps-ef


ps -ef output






linux services netstat port







share|improve this question









New contributor




ARH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • You may able to use the PPID of the nc processes to identify where the processes are coming from. Perhaps a runaway script?
    – Haxiel
    Nov 23 at 11:28










  • thanks, I am new linux OS, should I check process id?
    – ARH
    Nov 23 at 11:35










  • Yes, you can run ps -ef|grep nc and add the output to the question.
    – Haxiel
    Nov 23 at 11:38












  • Thanks @Haxiel, I haved added the output for ps
    – ARH
    Nov 23 at 12:09










  • I can see the update, but please don't post images of text. The third column in that output is the parent PID of a process. You can examine parent process using ps -p PID. For example, the first nc process (925) has process 922 as its parent, which again has 921 as its parent. Keep tracing the process parent and see if you can get any useful information.
    – Haxiel
    Nov 23 at 12:35

















up vote
0
down vote

favorite












I am struggling to close these ports which seem to be backdoors -- or at least I have never opened and used them. How can I close or shutdown nc and close these ports?



netstat -lntup | grep nc


netstat output



ps-ef


ps -ef output






linux services netstat port







share|improve this question









New contributor




ARH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • You may able to use the PPID of the nc processes to identify where the processes are coming from. Perhaps a runaway script?
    – Haxiel
    Nov 23 at 11:28










  • thanks, I am new linux OS, should I check process id?
    – ARH
    Nov 23 at 11:35










  • Yes, you can run ps -ef|grep nc and add the output to the question.
    – Haxiel
    Nov 23 at 11:38












  • Thanks @Haxiel, I haved added the output for ps
    – ARH
    Nov 23 at 12:09










  • I can see the update, but please don't post images of text. The third column in that output is the parent PID of a process. You can examine parent process using ps -p PID. For example, the first nc process (925) has process 922 as its parent, which again has 921 as its parent. Keep tracing the process parent and see if you can get any useful information.
    – Haxiel
    Nov 23 at 12:35















up vote
0
down vote

favorite









up vote
0
down vote

favorite











I am struggling to close these ports which seem to be backdoors -- or at least I have never opened and used them. How can I close or shutdown nc and close these ports?



netstat -lntup | grep nc


netstat output



ps-ef


ps -ef output






linux services netstat port







share|improve this question









New contributor




ARH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I am struggling to close these ports which seem to be backdoors -- or at least I have never opened and used them. How can I close or shutdown nc and close these ports?



netstat -lntup | grep nc


netstat output



ps-ef


ps -ef output






linux services netstat port




linux services netstat port






share|improve this question









New contributor




ARH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




ARH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited Nov 25 at 15:28









Jeff Schaller

36.9k1052121




36.9k1052121






New contributor




ARH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Nov 23 at 10:27









ARH

1092




1092




New contributor




ARH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





ARH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






ARH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • You may able to use the PPID of the nc processes to identify where the processes are coming from. Perhaps a runaway script?
    – Haxiel
    Nov 23 at 11:28










  • thanks, I am new linux OS, should I check process id?
    – ARH
    Nov 23 at 11:35










  • Yes, you can run ps -ef|grep nc and add the output to the question.
    – Haxiel
    Nov 23 at 11:38












  • Thanks @Haxiel, I haved added the output for ps
    – ARH
    Nov 23 at 12:09










  • I can see the update, but please don't post images of text. The third column in that output is the parent PID of a process. You can examine parent process using ps -p PID. For example, the first nc process (925) has process 922 as its parent, which again has 921 as its parent. Keep tracing the process parent and see if you can get any useful information.
    – Haxiel
    Nov 23 at 12:35




















  • You may able to use the PPID of the nc processes to identify where the processes are coming from. Perhaps a runaway script?
    – Haxiel
    Nov 23 at 11:28










  • thanks, I am new linux OS, should I check process id?
    – ARH
    Nov 23 at 11:35










  • Yes, you can run ps -ef|grep nc and add the output to the question.
    – Haxiel
    Nov 23 at 11:38












  • Thanks @Haxiel, I haved added the output for ps
    – ARH
    Nov 23 at 12:09










  • I can see the update, but please don't post images of text. The third column in that output is the parent PID of a process. You can examine parent process using ps -p PID. For example, the first nc process (925) has process 922 as its parent, which again has 921 as its parent. Keep tracing the process parent and see if you can get any useful information.
    – Haxiel
    Nov 23 at 12:35


















You may able to use the PPID of the nc processes to identify where the processes are coming from. Perhaps a runaway script?
– Haxiel
Nov 23 at 11:28




You may able to use the PPID of the nc processes to identify where the processes are coming from. Perhaps a runaway script?
– Haxiel
Nov 23 at 11:28












thanks, I am new linux OS, should I check process id?
– ARH
Nov 23 at 11:35




thanks, I am new linux OS, should I check process id?
– ARH
Nov 23 at 11:35












Yes, you can run ps -ef|grep nc and add the output to the question.
– Haxiel
Nov 23 at 11:38






Yes, you can run ps -ef|grep nc and add the output to the question.
– Haxiel
Nov 23 at 11:38














Thanks @Haxiel, I haved added the output for ps
– ARH
Nov 23 at 12:09




Thanks @Haxiel, I haved added the output for ps
– ARH
Nov 23 at 12:09












I can see the update, but please don't post images of text. The third column in that output is the parent PID of a process. You can examine parent process using ps -p PID. For example, the first nc process (925) has process 922 as its parent, which again has 921 as its parent. Keep tracing the process parent and see if you can get any useful information.
– Haxiel
Nov 23 at 12:35






I can see the update, but please don't post images of text. The third column in that output is the parent PID of a process. You can examine parent process using ps -p PID. For example, the first nc process (925) has process 922 as its parent, which again has 921 as its parent. Keep tracing the process parent and see if you can get any useful information.
– Haxiel
Nov 23 at 12:35












1 Answer
1






active

oldest

votes

















up vote
1
down vote



accepted










After further investigation through chat, the problem was identified with a specific crontab on OP's system. This was identified using the parent PID of the nc process, which showed the following connection:



nc -l -p 45454 -e /usr/sbin/link -> /bin/sh -c nc -l -p 45454 -e /usr/sbin/link -> /usr/sbin/CRON -f



The user account associated with the nc process was named 'link', and had a crontab associated with it. This crontab contained a cron job with the same nc command, scheduled to be run every minute. Since the nc command had been specified to listen indefinitely, new nc processes were being created every minute.



The issue was resolved by commenting out the specific entry in the crontab file.






share|improve this answer

















  • 1




    That chain of processes has some suspicious properties: /usr/sbin/link is not a standard command, although the name closely resembles the standard /usr/bin/link, which would be nonsensical to call from nc like that. Likewise, /usr/sbin/CRON in all-caps is different from the standard /usr/sbin/cron. You should see if /usr/sbin/link and/or /usr/sbin/CRON actually exist, and get them analyzed if they do exist; you may find that they are parts of an intruder's toolkit. There might be an innocent explanation too, but it is possible that someone has (clumsily) hacked this system.
    – telcoM
    Nov 25 at 12:36










  • @telcoM Thanks for the useful info. I'll point OP to your comment from chat.
    – Haxiel
    Nov 25 at 13:13











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});






ARH is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f483646%2fhow-to-close-nc-port-in-debian-9%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote



accepted










After further investigation through chat, the problem was identified with a specific crontab on OP's system. This was identified using the parent PID of the nc process, which showed the following connection:



nc -l -p 45454 -e /usr/sbin/link -> /bin/sh -c nc -l -p 45454 -e /usr/sbin/link -> /usr/sbin/CRON -f



The user account associated with the nc process was named 'link', and had a crontab associated with it. This crontab contained a cron job with the same nc command, scheduled to be run every minute. Since the nc command had been specified to listen indefinitely, new nc processes were being created every minute.



The issue was resolved by commenting out the specific entry in the crontab file.






share|improve this answer

















  • 1




    That chain of processes has some suspicious properties: /usr/sbin/link is not a standard command, although the name closely resembles the standard /usr/bin/link, which would be nonsensical to call from nc like that. Likewise, /usr/sbin/CRON in all-caps is different from the standard /usr/sbin/cron. You should see if /usr/sbin/link and/or /usr/sbin/CRON actually exist, and get them analyzed if they do exist; you may find that they are parts of an intruder's toolkit. There might be an innocent explanation too, but it is possible that someone has (clumsily) hacked this system.
    – telcoM
    Nov 25 at 12:36










  • @telcoM Thanks for the useful info. I'll point OP to your comment from chat.
    – Haxiel
    Nov 25 at 13:13















up vote
1
down vote



accepted










After further investigation through chat, the problem was identified with a specific crontab on OP's system. This was identified using the parent PID of the nc process, which showed the following connection:



nc -l -p 45454 -e /usr/sbin/link -> /bin/sh -c nc -l -p 45454 -e /usr/sbin/link -> /usr/sbin/CRON -f



The user account associated with the nc process was named 'link', and had a crontab associated with it. This crontab contained a cron job with the same nc command, scheduled to be run every minute. Since the nc command had been specified to listen indefinitely, new nc processes were being created every minute.



The issue was resolved by commenting out the specific entry in the crontab file.






share|improve this answer

















  • 1




    That chain of processes has some suspicious properties: /usr/sbin/link is not a standard command, although the name closely resembles the standard /usr/bin/link, which would be nonsensical to call from nc like that. Likewise, /usr/sbin/CRON in all-caps is different from the standard /usr/sbin/cron. You should see if /usr/sbin/link and/or /usr/sbin/CRON actually exist, and get them analyzed if they do exist; you may find that they are parts of an intruder's toolkit. There might be an innocent explanation too, but it is possible that someone has (clumsily) hacked this system.
    – telcoM
    Nov 25 at 12:36










  • @telcoM Thanks for the useful info. I'll point OP to your comment from chat.
    – Haxiel
    Nov 25 at 13:13













up vote
1
down vote



accepted







up vote
1
down vote



accepted






After further investigation through chat, the problem was identified with a specific crontab on OP's system. This was identified using the parent PID of the nc process, which showed the following connection:



nc -l -p 45454 -e /usr/sbin/link -> /bin/sh -c nc -l -p 45454 -e /usr/sbin/link -> /usr/sbin/CRON -f



The user account associated with the nc process was named 'link', and had a crontab associated with it. This crontab contained a cron job with the same nc command, scheduled to be run every minute. Since the nc command had been specified to listen indefinitely, new nc processes were being created every minute.



The issue was resolved by commenting out the specific entry in the crontab file.






share|improve this answer












After further investigation through chat, the problem was identified with a specific crontab on OP's system. This was identified using the parent PID of the nc process, which showed the following connection:



nc -l -p 45454 -e /usr/sbin/link -> /bin/sh -c nc -l -p 45454 -e /usr/sbin/link -> /usr/sbin/CRON -f



The user account associated with the nc process was named 'link', and had a crontab associated with it. This crontab contained a cron job with the same nc command, scheduled to be run every minute. Since the nc command had been specified to listen indefinitely, new nc processes were being created every minute.



The issue was resolved by commenting out the specific entry in the crontab file.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 25 at 11:23









Haxiel

51139




51139








  • 1




    That chain of processes has some suspicious properties: /usr/sbin/link is not a standard command, although the name closely resembles the standard /usr/bin/link, which would be nonsensical to call from nc like that. Likewise, /usr/sbin/CRON in all-caps is different from the standard /usr/sbin/cron. You should see if /usr/sbin/link and/or /usr/sbin/CRON actually exist, and get them analyzed if they do exist; you may find that they are parts of an intruder's toolkit. There might be an innocent explanation too, but it is possible that someone has (clumsily) hacked this system.
    – telcoM
    Nov 25 at 12:36










  • @telcoM Thanks for the useful info. I'll point OP to your comment from chat.
    – Haxiel
    Nov 25 at 13:13














  • 1




    That chain of processes has some suspicious properties: /usr/sbin/link is not a standard command, although the name closely resembles the standard /usr/bin/link, which would be nonsensical to call from nc like that. Likewise, /usr/sbin/CRON in all-caps is different from the standard /usr/sbin/cron. You should see if /usr/sbin/link and/or /usr/sbin/CRON actually exist, and get them analyzed if they do exist; you may find that they are parts of an intruder's toolkit. There might be an innocent explanation too, but it is possible that someone has (clumsily) hacked this system.
    – telcoM
    Nov 25 at 12:36










  • @telcoM Thanks for the useful info. I'll point OP to your comment from chat.
    – Haxiel
    Nov 25 at 13:13








1




1




That chain of processes has some suspicious properties: /usr/sbin/link is not a standard command, although the name closely resembles the standard /usr/bin/link, which would be nonsensical to call from nc like that. Likewise, /usr/sbin/CRON in all-caps is different from the standard /usr/sbin/cron. You should see if /usr/sbin/link and/or /usr/sbin/CRON actually exist, and get them analyzed if they do exist; you may find that they are parts of an intruder's toolkit. There might be an innocent explanation too, but it is possible that someone has (clumsily) hacked this system.
– telcoM
Nov 25 at 12:36




That chain of processes has some suspicious properties: /usr/sbin/link is not a standard command, although the name closely resembles the standard /usr/bin/link, which would be nonsensical to call from nc like that. Likewise, /usr/sbin/CRON in all-caps is different from the standard /usr/sbin/cron. You should see if /usr/sbin/link and/or /usr/sbin/CRON actually exist, and get them analyzed if they do exist; you may find that they are parts of an intruder's toolkit. There might be an innocent explanation too, but it is possible that someone has (clumsily) hacked this system.
– telcoM
Nov 25 at 12:36












@telcoM Thanks for the useful info. I'll point OP to your comment from chat.
– Haxiel
Nov 25 at 13:13




@telcoM Thanks for the useful info. I'll point OP to your comment from chat.
– Haxiel
Nov 25 at 13:13










ARH is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















ARH is a new contributor. Be nice, and check out our Code of Conduct.













ARH is a new contributor. Be nice, and check out our Code of Conduct.












ARH is a new contributor. Be nice, and check out our Code of Conduct.
















Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f483646%2fhow-to-close-nc-port-in-debian-9%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

Morgemoulin

Image
Morgemoulin — miejscowość i gmina — Państwo   Francja Region Grand Est Departament Moza Okręg Verdun Kod INSEE 55357 Powierzchnia 6,82 km² Populacja  (1990) • liczba ludności 75 • gęstość 11 os./km² Kod pocztowy 55400 Położenie na mapie Francji Morgemoulin 49°14′N   5°35′E / 49,233333   5,583333 Portal Francja Morgemoulin – miejscowość i gmina we Francji, w regionie Grand Est, w departamencie Moza. Według danych na rok 1990 gminę zamieszkiwało 75 osób, a gęstość zaludnienia wynosiła 11 osób/km² (wśród 2335 gmin Lotaryngii Morgemoulin plasuje się na 970. miejscu pod względem liczby ludności, natomiast pod względem powierzchni na miejscu 848.). Bibliografia | Francuski urząd statystyczny ( fr. ) . p   •   d   •   e Gminy okręgu Verdun Abaucourt-Hautecourt • Aincreville • Ambly-sur-Meuse • Amel-sur-l'Étang • Ancemont • Arrancy-sur-Crusne • Aubréville • Autré...
Read more

Scott Moir

Image
Scott Moir Tessa Virtue i Scott Moir w 2016 r. Reprezentacja   Kanada Data i miejsce urodzenia 2 września 1987 London Wzrost 180 cm Konkurencja Pary taneczne Partner sportowy Tessa Virtue Trener Marie-France Dubreuil, Patrice Lauzon, Romain Haguenauer Poprzednio: Marina Zujewa, Oleg Epstein, Igor Szpilband, Johnny Johns, Carol Moir, Paul MacIntosh, Suzanne Killing Klub Montreal International School of Skating Poprzednio: Arctic Edge FSC Ilderton Skating Club Lokalizacja treningowa Montreal Poprzednio: Canton Kitchener Rekordy życiowe ISU przed sezonem 2018/2019 Nota łączna 206,07 Igrzyska Olimpijskie 2018 Taniec krótki 83,67 Igrzyska Olimpijskie 2018 Taniec dowolny 122,40 Igrzyska Olimpijskie 2018 Dorobek medalowy Reprezentacja   Kanada Igrzyska olimpijskie Złoto Vancouver 2010 pary taneczne Złoto Pjongczang 2018 pary taneczne Złoto Pjongczang 2018 drużynowo Srebro S...
Read more

Souastre

Image
Souastre — miejscowość i gmina — Herb Państwo   Francja Region Hauts-de-France Departament Pas-de-Calais Okręg Arras Kod INSEE 62800 Powierzchnia 7,18 km² Populacja  (1990) • liczba ludności 352 • gęstość 49 os./km² Kod pocztowy 62111 Położenie na mapie Francji Souastre 50°09′N   2°34′E / 50,150000   2,566667 Portal Francja Souastre – miejscowość i gmina we Francji, w regionie Hauts-de-France, w departamencie Pas-de-Calais. Według danych na rok 1990 gminę zamieszkiwały 352 osoby, a gęstość zaludnienia wynosiła 49 osób/km² (wśród 1549 gmin regionu Nord-Pas-de-Calais Souastre plasuje się na 887. miejscu pod względem liczby ludności, natomiast pod względem powierzchni na miejscu 507.). Bibliografia | Francuski urząd statystyczny ( fr. ) . p   •   d   •   e Gminy okręgu Arras Ablain-Saint-Nazaire Ablainzevelle Acheville Achicourt Achiet-le-Grand Achiet-le-Pe...
Read more