Strange snmpd traffic
up vote
0
down vote
favorite
my snmp server is using 3% of CPU and about 600 kbit/s of bandwidth.
Using "iftop" my server is sending data to an unknown IP, in HTTP port, but the destination IP does not ping and has no HTTP port open.
myhostname.com.br:snmp => 144.168.68.43:http 520Kb 487Kb 487Kb
<= 40.2Kb 37.6Kb 37.6Kb
All defaults (snmpd.conf), I just use it to local MRTG.
It's a CentOS 7 under OpenVZ. Any ideas?
centos7 snmp snmpd
asked Nov 19 at 11:40
Arvy
4321921
add a comment |
up vote
0
down vote
favorite
my snmp server is using 3% of CPU and about 600 kbit/s of bandwidth.
Using "iftop" my server is sending data to an unknown IP, in HTTP port, but the destination IP does not ping and has no HTTP port open.
myhostname.com.br:snmp => 144.168.68.43:http 520Kb 487Kb 487Kb
<= 40.2Kb 37.6Kb 37.6Kb
All defaults (snmpd.conf), I just use it to local MRTG.
It's a CentOS 7 under OpenVZ. Any ideas?
centos7 snmp snmpd
asked Nov 19 at 11:40
Arvy
4321921
Well, first of all never expose snmp publicly, get some firewall rules in place.
– nos
Nov 19 at 11:45
Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in). This is outgoing connection, from my server to this IP.
– Arvy
Nov 19 at 11:50
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
my snmp server is using 3% of CPU and about 600 kbit/s of bandwidth.
Using "iftop" my server is sending data to an unknown IP, in HTTP port, but the destination IP does not ping and has no HTTP port open.
myhostname.com.br:snmp => 144.168.68.43:http 520Kb 487Kb 487Kb
<= 40.2Kb 37.6Kb 37.6Kb
All defaults (snmpd.conf), I just use it to local MRTG.
It's a CentOS 7 under OpenVZ. Any ideas?
centos7 snmp snmpd
asked Nov 19 at 11:40
Arvy
4321921
my snmp server is using 3% of CPU and about 600 kbit/s of bandwidth.
Using "iftop" my server is sending data to an unknown IP, in HTTP port, but the destination IP does not ping and has no HTTP port open.
myhostname.com.br:snmp => 144.168.68.43:http 520Kb 487Kb 487Kb
<= 40.2Kb 37.6Kb 37.6Kb
All defaults (snmpd.conf), I just use it to local MRTG.
It's a CentOS 7 under OpenVZ. Any ideas?
centos7 snmp snmpd
centos7 snmp snmpd
asked Nov 19 at 11:40
Arvy
4321921
asked Nov 19 at 11:40
Arvy
4321921
edited Nov 19 at 11:52
asked Nov 19 at 11:40
Arvy
4321921
asked Nov 19 at 11:40
Arvy
4321921
asked Nov 19 at 11:40
Arvy
4321921
4321921
Well, first of all never expose snmp publicly, get some firewall rules in place.
– nos
Nov 19 at 11:45
Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in). This is outgoing connection, from my server to this IP.
– Arvy
Nov 19 at 11:50
add a comment |
Well, first of all never expose snmp publicly, get some firewall rules in place.
– nos
Nov 19 at 11:45
Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in). This is outgoing connection, from my server to this IP.
– Arvy
Nov 19 at 11:50
Well, first of all never expose snmp publicly, get some firewall rules in place.
– nos
Nov 19 at 11:45
Well, first of all never expose snmp publicly, get some firewall rules in place.
– nos
Nov 19 at 11:45
Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in). This is outgoing connection, from my server to this IP.
– Arvy
Nov 19 at 11:50
Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in). This is outgoing connection, from my server to this IP.
– Arvy
Nov 19 at 11:50
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
Are these notifications/traps, or responses to Get requests?
Responses
Someone is polling your SNMP service, it's as simple as that.
If you don't want them to do that, firewall them (or it) off.
It's common for public services to be polled by random strangers, sometimes as a result of an automated probe but sometimes for explicitly malicious purposes. That's why we have firewalls.
Neither ICMP ping nor HTTP has anything to do with it; SNMP responses go to the same address (IP & port) that the requests came from — the choice of port is effectively arbitrary, but it would seem that the originator has specifically decided to use port 80 because this is commonly an open port, and does not draw much attention. This in itself is frankly suspicious because, unless there are strange technical constraints, an authentic and authorised SNMP manager would be using a port more conventionally allocated to SNMP traffic (like UDP 162).
Traps (notifications)
If there is no evidence of incoming requests triggering this traffic, then your SNMP Agent is doing this on its own. Did you configure it to do so? If not, you may have been hacked and somebody else has configured it this way instead.
You can still firewall it off (the firewall goes both ways!) though you really should be checking into what happened.
Otherwise
If there are no requests incoming, and your SNMP manager is not configured to send notifications to 144.168.68.43, then do you have another SNMP manager you're not aware of? Some piece of software you installed that has SNMP support? Otherwise you're really in trouble.
answered Nov 19 at 12:40
Lightness Races in Orbit
278k51445763
No, firewall is closed. The traffic is from my server (outgoing).
– Arvy
Nov 19 at 12:42
@Arvy If it were closed, the requests would not be getting through. If you're saying that your agent is dispatching SNMP notifications (as opposed to responses to a Get request) then either your config is wrong or you have been hacked.
– Lightness Races in Orbit
Nov 19 at 12:43
I found, it's something related to MIB, reading something. I really don't understand snmp well, I don't know what the server is trying to read from internet.
– Arvy
Nov 19 at 12:50
1
MIB definitions don't autonomously trigger SNMP requests. If you can provide a packet capture we'll at least know what the traffic is, though that likely won't tell us why.
– Lightness Races in Orbit
Nov 19 at 13:10
After a reboot, the problem is fixed. I'll monitor. Thanks.
– Arvy
Nov 19 at 15:22
|
show 1 more comment
up vote
0
down vote
I think I found the problem. This IP is related to MIB, reading something from an unreachable IP.
If I block it (iptables), "journal" starts to log every 2-3 seconds:
Nov 19 10:33:44 loki snmpd[18942]: send response: Failure in sendto
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysDescr.0
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.1
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysObjectID.0
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.2
Nov 19 10:33:44 loki snmpd[18942]: -- DISMAN-EVENT-MIB::sysUpTimeInstance
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.3
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysContact.0
(....)
I just don't know how to fix... at least, server is not compromissed.
answered Nov 19 at 12:49
Arvy
4321921
The log seems clear: someone is polling your snmpd. Your server IS likely compromised. You have not proven your assertion "Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in)" with netstat -an or iptables.
– Gambit Support
Nov 19 at 13:52
tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN 427/snmpd udp 0 0 127.0.0.1:161 0.0.0.0:* 427/snmpd
– Arvy
Nov 19 at 15:21
1
At least these are responses, not notifications
– Lightness Races in Orbit
Nov 19 at 15:32
1
Arvy, showing that it listens on 127.0.0.1 DOES NOT prove that it does not listen on other ports. What does this say "netstat -an | grep :161"?
– Gambit Support
Nov 19 at 17:07
Only udp 0 0 127.0.0.1:161 0.0.0.0:* - anyway, after the reboot, no more strange traffic detected.
– Arvy
Nov 19 at 18:51
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Are these notifications/traps, or responses to Get requests?
Responses
Someone is polling your SNMP service, it's as simple as that.
If you don't want them to do that, firewall them (or it) off.
It's common for public services to be polled by random strangers, sometimes as a result of an automated probe but sometimes for explicitly malicious purposes. That's why we have firewalls.
Neither ICMP ping nor HTTP has anything to do with it; SNMP responses go to the same address (IP & port) that the requests came from — the choice of port is effectively arbitrary, but it would seem that the originator has specifically decided to use port 80 because this is commonly an open port, and does not draw much attention. This in itself is frankly suspicious because, unless there are strange technical constraints, an authentic and authorised SNMP manager would be using a port more conventionally allocated to SNMP traffic (like UDP 162).
Traps (notifications)
If there is no evidence of incoming requests triggering this traffic, then your SNMP Agent is doing this on its own. Did you configure it to do so? If not, you may have been hacked and somebody else has configured it this way instead.
You can still firewall it off (the firewall goes both ways!) though you really should be checking into what happened.
Otherwise
If there are no requests incoming, and your SNMP manager is not configured to send notifications to 144.168.68.43, then do you have another SNMP manager you're not aware of? Some piece of software you installed that has SNMP support? Otherwise you're really in trouble.
answered Nov 19 at 12:40
Lightness Races in Orbit
278k51445763
No, firewall is closed. The traffic is from my server (outgoing).
– Arvy
Nov 19 at 12:42
@Arvy If it were closed, the requests would not be getting through. If you're saying that your agent is dispatching SNMP notifications (as opposed to responses to a Get request) then either your config is wrong or you have been hacked.
– Lightness Races in Orbit
Nov 19 at 12:43
I found, it's something related to MIB, reading something. I really don't understand snmp well, I don't know what the server is trying to read from internet.
– Arvy
Nov 19 at 12:50
1
MIB definitions don't autonomously trigger SNMP requests. If you can provide a packet capture we'll at least know what the traffic is, though that likely won't tell us why.
– Lightness Races in Orbit
Nov 19 at 13:10
After a reboot, the problem is fixed. I'll monitor. Thanks.
– Arvy
Nov 19 at 15:22
|
show 1 more comment
up vote
1
down vote
accepted
Are these notifications/traps, or responses to Get requests?
Responses
Someone is polling your SNMP service, it's as simple as that.
If you don't want them to do that, firewall them (or it) off.
It's common for public services to be polled by random strangers, sometimes as a result of an automated probe but sometimes for explicitly malicious purposes. That's why we have firewalls.
Neither ICMP ping nor HTTP has anything to do with it; SNMP responses go to the same address (IP & port) that the requests came from — the choice of port is effectively arbitrary, but it would seem that the originator has specifically decided to use port 80 because this is commonly an open port, and does not draw much attention. This in itself is frankly suspicious because, unless there are strange technical constraints, an authentic and authorised SNMP manager would be using a port more conventionally allocated to SNMP traffic (like UDP 162).
Traps (notifications)
If there is no evidence of incoming requests triggering this traffic, then your SNMP Agent is doing this on its own. Did you configure it to do so? If not, you may have been hacked and somebody else has configured it this way instead.
You can still firewall it off (the firewall goes both ways!) though you really should be checking into what happened.
Otherwise
If there are no requests incoming, and your SNMP manager is not configured to send notifications to 144.168.68.43, then do you have another SNMP manager you're not aware of? Some piece of software you installed that has SNMP support? Otherwise you're really in trouble.
answered Nov 19 at 12:40
Lightness Races in Orbit
278k51445763
No, firewall is closed. The traffic is from my server (outgoing).
– Arvy
Nov 19 at 12:42
@Arvy If it were closed, the requests would not be getting through. If you're saying that your agent is dispatching SNMP notifications (as opposed to responses to a Get request) then either your config is wrong or you have been hacked.
– Lightness Races in Orbit
Nov 19 at 12:43
I found, it's something related to MIB, reading something. I really don't understand snmp well, I don't know what the server is trying to read from internet.
– Arvy
Nov 19 at 12:50
1
MIB definitions don't autonomously trigger SNMP requests. If you can provide a packet capture we'll at least know what the traffic is, though that likely won't tell us why.
– Lightness Races in Orbit
Nov 19 at 13:10
After a reboot, the problem is fixed. I'll monitor. Thanks.
– Arvy
Nov 19 at 15:22
|
show 1 more comment
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Are these notifications/traps, or responses to Get requests?
Responses
Someone is polling your SNMP service, it's as simple as that.
If you don't want them to do that, firewall them (or it) off.
It's common for public services to be polled by random strangers, sometimes as a result of an automated probe but sometimes for explicitly malicious purposes. That's why we have firewalls.
Neither ICMP ping nor HTTP has anything to do with it; SNMP responses go to the same address (IP & port) that the requests came from — the choice of port is effectively arbitrary, but it would seem that the originator has specifically decided to use port 80 because this is commonly an open port, and does not draw much attention. This in itself is frankly suspicious because, unless there are strange technical constraints, an authentic and authorised SNMP manager would be using a port more conventionally allocated to SNMP traffic (like UDP 162).
Traps (notifications)
If there is no evidence of incoming requests triggering this traffic, then your SNMP Agent is doing this on its own. Did you configure it to do so? If not, you may have been hacked and somebody else has configured it this way instead.
You can still firewall it off (the firewall goes both ways!) though you really should be checking into what happened.
Otherwise
If there are no requests incoming, and your SNMP manager is not configured to send notifications to 144.168.68.43, then do you have another SNMP manager you're not aware of? Some piece of software you installed that has SNMP support? Otherwise you're really in trouble.
answered Nov 19 at 12:40
Lightness Races in Orbit
278k51445763
Are these notifications/traps, or responses to Get requests?
Responses
Someone is polling your SNMP service, it's as simple as that.
If you don't want them to do that, firewall them (or it) off.
It's common for public services to be polled by random strangers, sometimes as a result of an automated probe but sometimes for explicitly malicious purposes. That's why we have firewalls.
Neither ICMP ping nor HTTP has anything to do with it; SNMP responses go to the same address (IP & port) that the requests came from — the choice of port is effectively arbitrary, but it would seem that the originator has specifically decided to use port 80 because this is commonly an open port, and does not draw much attention. This in itself is frankly suspicious because, unless there are strange technical constraints, an authentic and authorised SNMP manager would be using a port more conventionally allocated to SNMP traffic (like UDP 162).
Traps (notifications)
If there is no evidence of incoming requests triggering this traffic, then your SNMP Agent is doing this on its own. Did you configure it to do so? If not, you may have been hacked and somebody else has configured it this way instead.
You can still firewall it off (the firewall goes both ways!) though you really should be checking into what happened.
Otherwise
If there are no requests incoming, and your SNMP manager is not configured to send notifications to 144.168.68.43, then do you have another SNMP manager you're not aware of? Some piece of software you installed that has SNMP support? Otherwise you're really in trouble.
answered Nov 19 at 12:40
Lightness Races in Orbit
278k51445763
edited Nov 19 at 12:42
answered Nov 19 at 12:40
Lightness Races in Orbit
278k51445763
answered Nov 19 at 12:40
Lightness Races in Orbit
278k51445763
answered Nov 19 at 12:40
Lightness Races in Orbit
278k51445763
278k51445763
No, firewall is closed. The traffic is from my server (outgoing).
– Arvy
Nov 19 at 12:42
@Arvy If it were closed, the requests would not be getting through. If you're saying that your agent is dispatching SNMP notifications (as opposed to responses to a Get request) then either your config is wrong or you have been hacked.
– Lightness Races in Orbit
Nov 19 at 12:43
I found, it's something related to MIB, reading something. I really don't understand snmp well, I don't know what the server is trying to read from internet.
– Arvy
Nov 19 at 12:50
1
MIB definitions don't autonomously trigger SNMP requests. If you can provide a packet capture we'll at least know what the traffic is, though that likely won't tell us why.
– Lightness Races in Orbit
Nov 19 at 13:10
After a reboot, the problem is fixed. I'll monitor. Thanks.
– Arvy
Nov 19 at 15:22
|
show 1 more comment
No, firewall is closed. The traffic is from my server (outgoing).
– Arvy
Nov 19 at 12:42
@Arvy If it were closed, the requests would not be getting through. If you're saying that your agent is dispatching SNMP notifications (as opposed to responses to a Get request) then either your config is wrong or you have been hacked.
– Lightness Races in Orbit
Nov 19 at 12:43
I found, it's something related to MIB, reading something. I really don't understand snmp well, I don't know what the server is trying to read from internet.
– Arvy
Nov 19 at 12:50
1
MIB definitions don't autonomously trigger SNMP requests. If you can provide a packet capture we'll at least know what the traffic is, though that likely won't tell us why.
– Lightness Races in Orbit
Nov 19 at 13:10
After a reboot, the problem is fixed. I'll monitor. Thanks.
– Arvy
Nov 19 at 15:22
No, firewall is closed. The traffic is from my server (outgoing).
– Arvy
Nov 19 at 12:42
No, firewall is closed. The traffic is from my server (outgoing).
– Arvy
Nov 19 at 12:42
@Arvy If it were closed, the requests would not be getting through. If you're saying that your agent is dispatching SNMP notifications (as opposed to responses to a Get request) then either your config is wrong or you have been hacked.
– Lightness Races in Orbit
Nov 19 at 12:43
@Arvy If it were closed, the requests would not be getting through. If you're saying that your agent is dispatching SNMP notifications (as opposed to responses to a Get request) then either your config is wrong or you have been hacked.
– Lightness Races in Orbit
Nov 19 at 12:43
I found, it's something related to MIB, reading something. I really don't understand snmp well, I don't know what the server is trying to read from internet.
– Arvy
Nov 19 at 12:50
I found, it's something related to MIB, reading something. I really don't understand snmp well, I don't know what the server is trying to read from internet.
– Arvy
Nov 19 at 12:50
1
1
MIB definitions don't autonomously trigger SNMP requests. If you can provide a packet capture we'll at least know what the traffic is, though that likely won't tell us why.
– Lightness Races in Orbit
Nov 19 at 13:10
MIB definitions don't autonomously trigger SNMP requests. If you can provide a packet capture we'll at least know what the traffic is, though that likely won't tell us why.
– Lightness Races in Orbit
Nov 19 at 13:10
After a reboot, the problem is fixed. I'll monitor. Thanks.
– Arvy
Nov 19 at 15:22
After a reboot, the problem is fixed. I'll monitor. Thanks.
– Arvy
Nov 19 at 15:22
|
show 1 more comment
up vote
0
down vote
I think I found the problem. This IP is related to MIB, reading something from an unreachable IP.
If I block it (iptables), "journal" starts to log every 2-3 seconds:
Nov 19 10:33:44 loki snmpd[18942]: send response: Failure in sendto
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysDescr.0
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.1
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysObjectID.0
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.2
Nov 19 10:33:44 loki snmpd[18942]: -- DISMAN-EVENT-MIB::sysUpTimeInstance
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.3
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysContact.0
(....)
I just don't know how to fix... at least, server is not compromissed.
answered Nov 19 at 12:49
Arvy
4321921
The log seems clear: someone is polling your snmpd. Your server IS likely compromised. You have not proven your assertion "Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in)" with netstat -an or iptables.
– Gambit Support
Nov 19 at 13:52
tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN 427/snmpd udp 0 0 127.0.0.1:161 0.0.0.0:* 427/snmpd
– Arvy
Nov 19 at 15:21
1
At least these are responses, not notifications
– Lightness Races in Orbit
Nov 19 at 15:32
1
Arvy, showing that it listens on 127.0.0.1 DOES NOT prove that it does not listen on other ports. What does this say "netstat -an | grep :161"?
– Gambit Support
Nov 19 at 17:07
Only udp 0 0 127.0.0.1:161 0.0.0.0:* - anyway, after the reboot, no more strange traffic detected.
– Arvy
Nov 19 at 18:51
add a comment |
up vote
0
down vote
I think I found the problem. This IP is related to MIB, reading something from an unreachable IP.
If I block it (iptables), "journal" starts to log every 2-3 seconds:
Nov 19 10:33:44 loki snmpd[18942]: send response: Failure in sendto
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysDescr.0
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.1
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysObjectID.0
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.2
Nov 19 10:33:44 loki snmpd[18942]: -- DISMAN-EVENT-MIB::sysUpTimeInstance
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.3
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysContact.0
(....)
I just don't know how to fix... at least, server is not compromissed.
answered Nov 19 at 12:49
Arvy
4321921
The log seems clear: someone is polling your snmpd. Your server IS likely compromised. You have not proven your assertion "Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in)" with netstat -an or iptables.
– Gambit Support
Nov 19 at 13:52
tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN 427/snmpd udp 0 0 127.0.0.1:161 0.0.0.0:* 427/snmpd
– Arvy
Nov 19 at 15:21
1
At least these are responses, not notifications
– Lightness Races in Orbit
Nov 19 at 15:32
1
Arvy, showing that it listens on 127.0.0.1 DOES NOT prove that it does not listen on other ports. What does this say "netstat -an | grep :161"?
– Gambit Support
Nov 19 at 17:07
Only udp 0 0 127.0.0.1:161 0.0.0.0:* - anyway, after the reboot, no more strange traffic detected.
– Arvy
Nov 19 at 18:51
add a comment |
up vote
0
down vote
up vote
0
down vote
I think I found the problem. This IP is related to MIB, reading something from an unreachable IP.
If I block it (iptables), "journal" starts to log every 2-3 seconds:
Nov 19 10:33:44 loki snmpd[18942]: send response: Failure in sendto
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysDescr.0
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.1
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysObjectID.0
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.2
Nov 19 10:33:44 loki snmpd[18942]: -- DISMAN-EVENT-MIB::sysUpTimeInstance
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.3
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysContact.0
(....)
I just don't know how to fix... at least, server is not compromissed.
answered Nov 19 at 12:49
Arvy
4321921
I think I found the problem. This IP is related to MIB, reading something from an unreachable IP.
If I block it (iptables), "journal" starts to log every 2-3 seconds:
Nov 19 10:33:44 loki snmpd[18942]: send response: Failure in sendto
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysDescr.0
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.1
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysObjectID.0
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.2
Nov 19 10:33:44 loki snmpd[18942]: -- DISMAN-EVENT-MIB::sysUpTimeInstance
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysORDescr.3
Nov 19 10:33:44 loki snmpd[18942]: -- SNMPv2-MIB::sysContact.0
(....)
I just don't know how to fix... at least, server is not compromissed.
answered Nov 19 at 12:49
Arvy
4321921
answered Nov 19 at 12:49
Arvy
4321921
answered Nov 19 at 12:49
Arvy
4321921
answered Nov 19 at 12:49
Arvy
4321921
4321921
The log seems clear: someone is polling your snmpd. Your server IS likely compromised. You have not proven your assertion "Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in)" with netstat -an or iptables.
– Gambit Support
Nov 19 at 13:52
tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN 427/snmpd udp 0 0 127.0.0.1:161 0.0.0.0:* 427/snmpd
– Arvy
Nov 19 at 15:21
1
At least these are responses, not notifications
– Lightness Races in Orbit
Nov 19 at 15:32
1
Arvy, showing that it listens on 127.0.0.1 DOES NOT prove that it does not listen on other ports. What does this say "netstat -an | grep :161"?
– Gambit Support
Nov 19 at 17:07
Only udp 0 0 127.0.0.1:161 0.0.0.0:* - anyway, after the reboot, no more strange traffic detected.
– Arvy
Nov 19 at 18:51
add a comment |
The log seems clear: someone is polling your snmpd. Your server IS likely compromised. You have not proven your assertion "Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in)" with netstat -an or iptables.
– Gambit Support
Nov 19 at 13:52
tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN 427/snmpd udp 0 0 127.0.0.1:161 0.0.0.0:* 427/snmpd
– Arvy
Nov 19 at 15:21
1
At least these are responses, not notifications
– Lightness Races in Orbit
Nov 19 at 15:32
1
Arvy, showing that it listens on 127.0.0.1 DOES NOT prove that it does not listen on other ports. What does this say "netstat -an | grep :161"?
– Gambit Support
Nov 19 at 17:07
Only udp 0 0 127.0.0.1:161 0.0.0.0:* - anyway, after the reboot, no more strange traffic detected.
– Arvy
Nov 19 at 18:51
The log seems clear: someone is polling your snmpd. Your server IS likely compromised. You have not proven your assertion "Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in)" with netstat -an or iptables.
– Gambit Support
Nov 19 at 13:52
The log seems clear: someone is polling your snmpd. Your server IS likely compromised. You have not proven your assertion "Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in)" with netstat -an or iptables.
– Gambit Support
Nov 19 at 13:52
tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN 427/snmpd udp 0 0 127.0.0.1:161 0.0.0.0:* 427/snmpd
– Arvy
Nov 19 at 15:21
tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN 427/snmpd udp 0 0 127.0.0.1:161 0.0.0.0:* 427/snmpd
– Arvy
Nov 19 at 15:21
1
1
At least these are responses, not notifications
– Lightness Races in Orbit
Nov 19 at 15:32
At least these are responses, not notifications
– Lightness Races in Orbit
Nov 19 at 15:32
1
1
Arvy, showing that it listens on 127.0.0.1 DOES NOT prove that it does not listen on other ports. What does this say "netstat -an | grep :161"?
– Gambit Support
Nov 19 at 17:07
Arvy, showing that it listens on 127.0.0.1 DOES NOT prove that it does not listen on other ports. What does this say "netstat -an | grep :161"?
– Gambit Support
Nov 19 at 17:07
Only udp 0 0 127.0.0.1:161 0.0.0.0:* - anyway, after the reboot, no more strange traffic detected.
– Arvy
Nov 19 at 18:51
Only udp 0 0 127.0.0.1:161 0.0.0.0:* - anyway, after the reboot, no more strange traffic detected.
– Arvy
Nov 19 at 18:51
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53373870%2fstrange-snmpd-traffic%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Well, first of all never expose snmp publicly, get some firewall rules in place.
– nos
Nov 19 at 11:45
Snmpd is bind to 127.0.0.1 and blocked using iptables (udp in). This is outgoing connection, from my server to this IP.
– Arvy
Nov 19 at 11:50