Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #205567 > unrolled thread

Strange attacks in my log

Back to article view | Back to linux.debian.user

Contents

  Strange attacks in my log Hans <hans.ullrich@loop.de> - 2019-02-21 10:40 +0100
    Re: Strange attacks in my log Reco <recoverym4n@enotuniq.net> - 2019-02-21 11:20 +0100
      Re: Strange attacks in my log Hans <hans.ullrich@loop.de> - 2019-02-21 11:50 +0100
        Re: Strange attacks in my log Reco <recoverym4n@enotuniq.net> - 2019-02-21 13:10 +0100
      Re: Strange attacks in my log Hans <hans.ullrich@loop.de> - 2019-02-21 16:30 +0100
        Re: Strange attacks in my log Reco <recoverym4n@enotuniq.net> - 2019-02-21 16:50 +0100
          Re: Strange attacks in my log Hans <hans.ullrich@loop.de> - 2019-02-21 17:40 +0100
            Re: Strange attacks in my log Reco <recoverym4n@enotuniq.net> - 2019-02-21 18:30 +0100
    Re: Strange attacks in my log Dan Purgert <dan@djph.net> - 2019-02-21 11:30 +0100

#205567 — Strange attacks in my log

[Multipart message — attachments visible in raw view] — view raw

Hi folks,

I discovered some strange log entries, which are created by "portsentry" (a tool for 
wathing port accesses).

It looks like whenever I insert an USB-drive or a SD-Card, the own system wants to 
access on an UDP-Port (69 or 161). It tries also to access all other computers in the 
network. 

This looks strange for me, because I can not reproduce, why inserting a memeory 
device, network activies are started. 

With wireshark I could see, this is "BJNP" (whatever this means)

Same happens, when pulling the USB-stick or the sd-card out.

This is, what is in the log:

---------------- snip ----------

Feb 21 10:14:39 localhost udisksd[13607]: g_object_unref: assertion'G_IS_OBJECT 
(object)' failed Feb 21 10:14:44 localhost scanbd: /usr/sbin/scanbd: no devices, not 
starting any polling thread Feb 21 10:14:47 localhost portsentry[6172]: attackalert: 
Connect from host: 192.168.2.117/192.168.2.117 to UDP port: 161 Feb 21 10:14:47 
localhost portsentry[6172]: attackalert: Host: 192.168.2.117 is already blocked. 
Ignoring Feb 21 10:14:48 localhost portsentry[6172]: attackalert: Connect from host: 
192.168.2.117/192.168.2.117 to UDP port: 161 Feb 21 10:14:48 localhost 
portsentry[6172]: attackalert: Host: 192.168.2.117 is already blocked. Ignoring Feb 
21 10:14:53 localhost scanbd: /usr/sbin/scanbd: no devices, not starting any polling 
thread Feb 21 10:15:01 localhost CRON[27395]: (root) CMD (if [ -x /usr/bin/
gsmsmsrequeue ]; then /us


---------- snap -----------------

Same log appeares on the other computers (with the same source). I inserted the 
card in the computer with the ip "192.168.2.117".

Can anybody confirm this, or does know some background?

Thanks for enlightening me.

Best regards

Hans

[toc] | [next] | [standalone]

#205569

	Hi.

On Thu, Feb 21, 2019 at 10:29:49AM +0100, Hans wrote:
> Hi folks,
> 
> I discovered some strange log entries, which are created by "portsentry" (a tool for 
> wathing port accesses).
> 
> It looks like whenever I insert an USB-drive or a SD-Card, the own system wants to 
> access on an UDP-Port (69 or 161).
udp:69 is TFTP.
udp:161 is SNMP.

I can understand udp:161. One of the functions of snmpd is filesystem
monitoring, and you have this scanbd thing that implies SANE that
implies snmpd.
But establishing TFTP session 'just because' is weird.


> It tries also to access all other computers in the network. 

Broadcast, unicast, or ...?


> This looks strange for me, because I can not reproduce, why inserting a memeory 
> device, network activies are started. 
> 
> With wireshark I could see, this is "BJNP" (whatever this means)

Curious. Can you share a this network dump in pcap format?
As in,

tcpdump -s0 -w /tmp/69_161.pcap -ni any udp port 69 or udp port 161


> Same happens, when pulling the USB-stick or the sd-card out.
> 
> This is, what is in the log:
> 
> ---------------- snip ----------
> 
> Feb 21 10:14:39 localhost udisksd[13607]: g_object_unref: assertion'G_IS_OBJECT 
> (object)' failed Feb 21 10:14:44 localhost scanbd: /usr/sbin/scanbd: no devices, not 
> starting any polling thread

Useless


> Feb 21 10:14:47 localhost portsentry[6172]: attackalert: 
> Connect from host: 192.168.2.117/192.168.2.117 to UDP port: 161

So it's a local SNMP connection, if I get it right?

Reco

[toc] | [prev] | [next] | [standalone]

#205571

[Multipart message — attachments visible in raw view] — view raw

Am Donnerstag, 21. Februar 2019, 11:19:08 CET schrieb Reco:
Hi Reco (and all others),

sure, I attached the wireshark pcap. Thre is nothing secret in it.

However, I know, what the ports are for, but it is not understandable for me, 
why there are networking protocols are started, when I just put a stick into 
the required slot. And these devices are still not mounted! There is no sense 
IMO, why the computer is scanning the network at all.

This is really weired. I wouldn't have noticed it, when I wouldn't have 
installed several alerting tools. 

Notice: You just put an usb-stick into the slot - and the system is starting 
network protocols and begin scanning the network. WTF???

My systems are all debian/testing (32-bit and 64-bit), all have the same 
configurations and package versions.

Hope this helps.

Best regards

Hans 



> 	Hi.
> 
> On Thu, Feb 21, 2019 at 10:29:49AM +0100, Hans wrote:
> > Hi folks,
> > 
> > I discovered some strange log entries, which are created by "portsentry"
> > (a tool for wathing port accesses).
> > 
> > It looks like whenever I insert an USB-drive or a SD-Card, the own system
> > wants to access on an UDP-Port (69 or 161).
> 
> udp:69 is TFTP.
> udp:161 is SNMP.
> 
> I can understand udp:161. One of the functions of snmpd is filesystem
> monitoring, and you have this scanbd thing that implies SANE that
> implies snmpd.
> But establishing TFTP session 'just because' is weird.
> 
> > It tries also to access all other computers in the network.
> 
> Broadcast, unicast, or ...?
> 
> > This looks strange for me, because I can not reproduce, why inserting a
> > memeory device, network activies are started.
> > 
> > With wireshark I could see, this is "BJNP" (whatever this means)
> 
> Curious. Can you share a this network dump in pcap format?
> As in,
> 
> tcpdump -s0 -w /tmp/69_161.pcap -ni any udp port 69 or udp port 161
> 
> > Same happens, when pulling the USB-stick or the sd-card out.
> > 
> > This is, what is in the log:
> > 
> > ---------------- snip ----------
> > 
> > Feb 21 10:14:39 localhost udisksd[13607]: g_object_unref:
> > assertion'G_IS_OBJECT (object)' failed Feb 21 10:14:44 localhost scanbd:
> > /usr/sbin/scanbd: no devices, not starting any polling thread
> 
> Useless
> 
> > Feb 21 10:14:47 localhost portsentry[6172]: attackalert:
> > Connect from host: 192.168.2.117/192.168.2.117 to UDP port: 161
> 
> So it's a local SNMP connection, if I get it right?
> 
> Reco

[toc] | [prev] | [next] | [standalone]

#205572

	Hi.

On Thu, Feb 21, 2019 at 11:42:58AM +0100, Hans wrote:
> Am Donnerstag, 21. Februar 2019, 11:19:08 CET schrieb Reco:
> Hi Reco (and all others),
> 
> sure, I attached the wireshark pcap. Thre is nothing secret in it.

That's interesting. Aforementioned pcap does not contain udp:69, but it
does contain broadcast udp:161 (src: 192.168.2.117 dst:
255.255.255.255), requesting three OIDs via SNMP v2c:

$ snmptranslate -mALL .1.3.6.1.2.1.1.1.0
RFC1213-MIB::sysDescr.0
$ snmptranslate -mALL .1.3.6.1.2.1.1.2.0
RFC1213-MIB::sysObjectID.0
$ snmptranslate -mALL .1.3.6.1.2.1.2.2.1.6.1
RFC1213-MIB::ifPhysAddress.1


A hint. One should not (ab)use SNMP this way. Even if you're doing
device discovery - you're doing it wrong by sending SNMP to broadcast.
Explains why your other hosts see this though.


> However, I know, what the ports are for, but it is not understandable for me, 
> why there are networking protocols are started, when I just put a stick into 
> the required slot. And these devices are still not mounted! There is no sense 
> IMO, why the computer is scanning the network at all.

There can be an explanation, though, but Wireshark/tcpdump in not
suitable to get it.

Install auditd.
Invoke "auditctl -a always,exit -S connect".
Insert any usb stick
Invoke "auditctl -D" to clear the rules.

All the answers should wait one at /var/log/audit/audit.log

Reco

[toc] | [prev] | [next] | [standalone]

#205589

[Multipart message — attachments visible in raw view] — view raw

Hmm, tried "auditctl -a always,exit -S connect -F arch=b64


Tha manual told nothing about a logfile. 

What do I do wrong?

Hans

[toc] | [prev] | [next] | [standalone]

#205590

	Hi.

On Thu, Feb 21, 2019 at 04:29:11PM +0100, Hans wrote:
> Hmm, tried "auditctl -a always,exit -S connect -F arch=b64

auditctl -a always,exit -S connect

Ignore 'syscall mismatch' warning, it will work anyway.

> Tha manual told nothing about a logfile. 

It's /var/log/audit/audit.log.
Red Hat documentation at it's finest.

Reco

[toc] | [prev] | [next] | [standalone]

#205595

[Multipart message — attachments visible in raw view] — view raw

Am Donnerstag, 21. Februar 2019, 16:46:42 CET schrieb Reco:
Yes, worked. However, I did not find any unusual, however, putting a stick in 
is starting "colord-sane", which will explain the UDP request.

This does not explain, why a sd-card or usb-stick is calling this.

The only explanation I have, is that the kernel starts some module, which acts 
as watched. 

I wonder, why no one else noticed this behaviour, as this looks a "normal" 
behaviour on all systems.

Very strange.....

Best 

Hans
> 	Hi.
> 
> On Thu, Feb 21, 2019 at 04:29:11PM +0100, Hans wrote:
> > Hmm, tried "auditctl -a always,exit -S connect -F arch=b64
> 
> auditctl -a always,exit -S connect
> 
> Ignore 'syscall mismatch' warning, it will work anyway.
> 
> > Tha manual told nothing about a logfile.
> 
> It's /var/log/audit/audit.log.
> Red Hat documentation at it's finest.
> 
> Reco

[toc] | [prev] | [next] | [standalone]

#205601

	Hi.

On Thu, Feb 21, 2019 at 05:29:56PM +0100, Hans wrote:
> Am Donnerstag, 21. Februar 2019, 16:46:42 CET schrieb Reco:
> Yes, worked. However, I did not find any unusual, however, putting a stick in 
> is starting "colord-sane", which will explain the UDP request.

Judging from the whopping 151 lines of the source of this colord-sane -
it cannot explain UDP.
Just a wild guess, though. Do you have HPLIP installed?

Oh, can I see the audit please? Unless it's private and all that.


> This does not explain, why a sd-card or usb-stick is calling this.

True.


> The only explanation I have, is that the kernel starts some module, which acts 
> as watched. 

Nope. See, nor kernel itself nor its modules do not have SNMP
implementation. Kernel can send broadcasts if told to. Kernel can
receive an answer to these broadcasts.
But nothing in the kernel can talk or understand SNMP.
It definitely was some userspace program.


> I wonder, why no one else noticed this behaviour, as this looks a "normal" 
> behaviour on all systems.

How many people run portsentry?
How many actually watch for the packets that are outgoing from the host?

Reco

[toc] | [prev] | [next] | [standalone]

#205570

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hans wrote:
> Hi folks,
>
> I discovered some strange log entries, which are created by
> "portsentry" (a tool for wathing port accesses).
>
> It looks like whenever I insert an USB-drive or a SD-Card, the own
> system wants to access on an UDP-Port (69 or 161). It tries also to
> access all other computers in the network. 

UDP 161 is used for SNMP (Simple Network Management Protocol) -- well,
it's "assigned" to that protocol, but like TCP port 53 (DNS over TCP),
it may not be used all that much.

UDP 69 is TFTP.

>
> This looks strange for me, because I can not reproduce, why inserting
> a memeory device, network activies are started. [...]

Could be triggering some service on the machine in question. What OS is
the host you're plugging this card into running?


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlxuepwACgkQjhHd8xJ5
ooHnQwf/TrmqKAeLc1zkKWfs1Oykk2t+HvD8DixH6380c3HHLIL0Wxp1IsxMEV7N
AsdFmYygp2KFzo+CqzhIdYQkN2mV2DikkQEeMsgoJCTSCEGk5c9shSnSjjErH3J0
+y8xMfGD8edRD/rLfbmoqWsHjzthEfhPDLQNvi7YtVlssfL6/MR9F8sv6mYUiTQR
HE8YN276x47ytVBDIsfX1yvaxpxt51Zg3bdVPNWBfO2r79DuHJaaSykv8lB/VT3F
3Aj/+u78ZkhSlhJvN3JajZIbvOg9nXGSpNZRa4KFKCrKVXvJw6+zT4vaa3/B4Bvx
TTGV94s/vF4OKPtUpK3piEDEejTroQ==
=or9p
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web