Malicious network traffic originating from a Linux machine

[John Friday]

A friend of mine has a Linux laptop that he occasionally brings into university.

After experiencing some network issues (lost packets, slow internet) he contacted his university's IT department, who then asked him for his computers host name, MAC address, IP address when connected and ethernet port socket number in the building.

He provided all of this, and apparently a computer matching the details he provided was blacklisted on the university network for unusual network traffic and attempting to hack* another user's computer. *Defined as "malicious network traffic" from his computer to another user.

The problem was resolved with my friend being told not to plug his Linux laptop into the university network again, and instead use a Windows machine supplied by and administered by the IT department.

For my friend, the problem is not over because he wants to know if his laptop really is compromised. The IT department are not interested in forensically checking it (too much effort, it's a Linux machine, etc.) so the post-mortem would mostly be left to my friend.

Moving forward, we have a few questions on how this could have happened, and how to conduct the post-mortem analysis.

How it happened:
1. Presumably if someone wanted to spoof the MAC address of a computer on a local network, the best MAC address to spoof would be occasional laptop users who bring their laptop into work.

How sure can my friend be that his computer really is infected, if the IT department say that the attacker's computer matches his MAC address, IP address, host name and ethernet socket in the building?

2. Is there a way for network sysadmins to locate which is the ethernet socket that is physically responsible for the attack?

3. If you put yourself in my friend's shoes, and you wanted to forensically inspect your laptop for any signs of tampering, how would you start? Take the SSD out, make an image of that, work on the image (Assuming the infection is not at BIOS level)? What commands will you do to look for anything suspicious?

[Marc Haber]

John Friday <john.2...@gmail.com> wrote:
>He provided all of this, and apparently a computer matching the details he provided was blacklisted on the university network for unusual network traffic and attempting to hack* another user's computer. *Defined as "malicious network traffic" from his computer to another user.

Would they be cooperative enough to tell _what_ the unusual network
traffic is and what kind of hacking attempts were seen ("pcap or it
didn't happen" will probably make a clueful admin more cooperative).

In this unspecific form, I suspect that the IT department is building
a strawman to ease their work load.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marco Moock]

Am Dienstag, 30. August 2022, um 05:10:37 Uhr schrieb John Friday:

> The problem was resolved with my friend being told not to plug his
> Linux laptop into the university network again, and instead use a
> Windows machine supplied by and administered by the IT department.

Why don't reinstall the Linux operating system on the laptop?
Maybe it has been hacked.

> How it happened:
> 1. Presumably if someone wanted to spoof the MAC address of a
> computer on a local network, the best MAC address to spoof would be
> occasional laptop users who bring their laptop into work.

Hard to say, but you need to tell us what the machine did and what was
running on the machine.

> How sure can my friend be that his computer really is infected, if
> the IT department say that the attacker's computer matches his MAC
> address, IP address, host name and ethernet socket in the building?

There may be a switch where anybody else might spoof the MAC address,
but it is mostly secure that the laptop did nasty things.

> 2. Is there a way for network sysadmins to locate which is the
> ethernet socket that is physically responsible for the attack?

It is. Managed switches (e.g. Cisco Catalyst) support MAC/switchport
tables. They can also save that information in a database for years.
On a switch every MAC address that occurred is assigned to a switchport.
Now they have a second table with the switchports and the sockets in
the building. With that they can find out which MAC is using which
socket in which building.
They can also monitor ARR/NDP traffic to have a IP/MAC relation.

> 3. If you put yourself in my friend's shoes, and you wanted to
> forensically inspect your laptop for any signs of tampering, how
> would you start? Take the SSD out, make an image of that, work on the
> image (Assuming the infection is not at BIOS level)? What commands
> will you do to look for anything suspicious?

I would look which server services ran, e.g. someone break in via ssh
or telnet.

Additionally, it is possible that he ran malicious software/scrips.

The only solution is to reinstall the operating system in the machine.

[John Friday]

On Tuesday, August 30, 2022 at 4:01:17 PM UTC+3, Marco Moock wrote:
> Am Dienstag, 30. August 2022, um 05:10:37 Uhr schrieb John Friday:
>
> > The problem was resolved with my friend being told not to plug his
> > Linux laptop into the university network again, and instead use a
> > Windows machine supplied by and administered by the IT department.
> Why don't reinstall the Linux operating system on the laptop?
> Maybe it has been hacked.

Re-installing the Linux operating system is indeed the end step. For now, we are trying to understand what happened and how it happened.

If his Linux computer was compromised then all of us (except maybe the Windows admins) would want to know how to prevent recurrences in the future.

Also, if his computer really was compromised then it means a ton of legwork for him - credit card, bank, email, crypto accounts all need to be secured. He must further assume all personal data on the laptop is now in the possession of third parties. Therefore he wants to make certain if is laptop has indeed been compromised.

> > How it happened:
> > 1. Presumably if someone wanted to spoof the MAC address of a
> > computer on a local network, the best MAC address to spoof would be
> > occasional laptop users who bring their laptop into work.
> Hard to say, but you need to tell us what the machine did and what was
> running on the machine.

The machine won't be powered on for the time being. We are making an image of the hard drive housing his root and home directories. His laptop had a separate hard drive for VMs - I presume imaging that one would not be necessary? Anything malicious would probably reside in the root and home folders?

> > How sure can my friend be that his computer really is infected, if
> > the IT department say that the attacker's computer matches his MAC
> > address, IP address, host name and ethernet socket in the building?
> There may be a switch where anybody else might spoof the MAC address,
> but it is mostly secure that the laptop did nasty things.
> > 2. Is there a way for network sysadmins to locate which is the
> > ethernet socket that is physically responsible for the attack?
> It is. Managed switches (e.g. Cisco Catalyst) support MAC/switchport
> tables. They can also save that information in a database for years.
> On a switch every MAC address that occurred is assigned to a switchport.
> Now they have a second table with the switchports and the sockets in
> the building. With that they can find out which MAC is using which
> socket in which building.

OK. I do not know if the university network uses these switches or if they bothered to look through the logs. I only know the meeting with the head of IT security happened after he had network issues and was asked to submit his computer name, IP address when plugged in, MAC address and ethernet socket number to the IT department.

Presumably if they knew which was the offending ethernet port, especially if the attacks were happening over a course of time as I understand they were, they could have come there and taken a look at what/who was plugged in.

> They can also monitor ARR/NDP traffic to have a IP/MAC relation.
> > 3. If you put yourself in my friend's shoes, and you wanted to
> > forensically inspect your laptop for any signs of tampering, how
> > would you start? Take the SSD out, make an image of that, work on the
> > image (Assuming the infection is not at BIOS level)? What commands
> > will you do to look for anything suspicious?
> I would look which server services ran, e.g. someone break in via ssh
> or telnet.

How do you check this on an offline Linux image?

>
> Additionally, it is possible that he ran malicious software/scrips.

Possible. His laptop had a graphics card with proprietary drivers which he needed to get working for CAD software.

>
> The only solution is to reinstall the operating system in the machine.

Agreed, but we would like to understand more before we wipe it and start anew.

[John Friday]

We are checking but I believe the IT people consider the matter closed with the user's agreement to not connect his laptop to the university network and instead use the Windows machines administered by the IT staff.

[Robert Heller]

Step one would be to get chrootkit and run that to see if the laptop has been
rooted.

http://www.chkrootkit.org/

Note: the usual way a Linux machine would get rooted would be a *server*
machine with a service deamon that is mis-configured or contains a known
security problem (eg a server that is not up-to-date). A desktop or laptop
would normally not get rooted that way, *unless* there were service deamons
running -- eg a web developer with a desktop or laptop *could* install
MySql-server, Apache, and PHP and run as a "local" LAMP to locally test things
like webservices he/she is developing. Ideally, not doing this with a public
facing IP or restricting Apache to listening only on 127.0.0.1, etc. Someone
might also run the OpenSSH server on their desktop or laptop to allow
connections from other machines on their (home) LAN. In any case if this is
going on, one must be careful to keep this software up-to-date and/or
properly sandboxed. It is rather hard to hack a Linux machine, esp. if it is
kept up-to-date.

Then install Nmap and do a full port scan on the laptop. (This might not
really show anything meaningful, but is a useful step, esp. to see if there
are things like botnet client servers running or "forgotten" service deamons
running, possibly improperly.)

If he is running a Debian variant, he can also do:

sudo dpkg -V

If he is running a RedHat-flavored system, he can do:

sudo rpm -Va

These latter two will tell him if any of the install packages have been messed
with somehow (it is *normal* for config files to deviate from the package, but
should be looked at anyway to be sure).

Otherwise, he should check to see if there are any files in his $HOME
directory that should not be there (partitularly look into filenames starting
with a dot (.)) -- either he ran something that dropped something where he had
write access (eg under $HOME) that is malicious OR someone accessed his
machine while is was away from it or he lent it someone -- eg a family
member, etc. and that person installed something malicious.

Unless this "friend" (or other party) knows (or guessed) he password (OR he
has configured sudo to work withOUT a password!) the worst is this "friend"
(or other party) put the malware somewhere under $HOME.

>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Robert Heller]

At Tue, 30 Aug 2022 06:17:05 -0700 (PDT) John Friday <john.2...@gmail.com> wrote:

>
> On Tuesday, August 30, 2022 at 4:01:17 PM UTC+3, Marco Moock wrote:
> > Am Dienstag, 30. August 2022, um 05:10:37 Uhr schrieb John Friday:
> >
> > > The problem was resolved with my friend being told not to plug his
> > > Linux laptop into the university network again, and instead use a
> > > Windows machine supplied by and administered by the IT department.
> > Why don't reinstall the Linux operating system on the laptop?
> > Maybe it has been hacked.
>
> Re-installing the Linux operating system is indeed the end step. For now, we are trying to understand what happened and how it happened.
>
> If his Linux computer was compromised then all of us (except maybe the Windows admins) would want to know how to prevent recurrences in the future.
>
> Also, if his computer really was compromised then it means a ton of legwork for him - credit card, bank, email, crypto accounts all need to be secured. He must further assume all personal data on the laptop is now in the possession of third parties. Therefore he wants to make certain if is laptop has indeed been compromised.
>
> > > How it happened:
> > > 1. Presumably if someone wanted to spoof the MAC address of a
> > > computer on a local network, the best MAC address to spoof would be
> > > occasional laptop users who bring their laptop into work.
> > Hard to say, but you need to tell us what the machine did and what was
> > running on the machine.
>
> The machine won't be powered on for the time being. We are making an image
> of the hard drive housing his root and home directories. His laptop had a
> separate hard drive for VMs - I presume imaging that one would not be
> necessary? Anything malicious would probably reside in the root and home
> folders?

It would depend on how the VMs are configured. If the VMs are totally
sandboxed and "off" the network, they are effectively harmless. If not, then
they are suspect too.

>
> > > How sure can my friend be that his computer really is infected, if
> > > the IT department say that the attacker's computer matches his MAC
> > > address, IP address, host name and ethernet socket in the building?
> > There may be a switch where anybody else might spoof the MAC address,
> > but it is mostly secure that the laptop did nasty things.
> > > 2. Is there a way for network sysadmins to locate which is the
> > > ethernet socket that is physically responsible for the attack?
> > It is. Managed switches (e.g. Cisco Catalyst) support MAC/switchport
> > tables. They can also save that information in a database for years.
> > On a switch every MAC address that occurred is assigned to a switchport.
> > Now they have a second table with the switchports and the sockets in
> > the building. With that they can find out which MAC is using which
> > socket in which building.
>
> OK. I do not know if the university network uses these switches or if they
> bothered to look through the logs. I only know the meeting with the head of
> IT security happened after he had network issues and was asked to submit his
> computer name, IP address when plugged in, MAC address and ethernet socket
> number to the IT department.
>
> Presumably if they knew which was the offending ethernet port, especially if
> the attacks were happening over a course of time as I understand they were,
> they could have come there and taken a look at what/who was plugged in.

Yep. Again it depends on the specific switch tech in use and to what extent
the IT security people bothered to configured things. However, with budget
limitations, it is quite possible that the university might not be using tech.
that would give them that level of information or bothered to configure things
to do that. A *university* is not likely to be as "paranoid" as all that.

>
>
> > They can also monitor ARR/NDP traffic to have a IP/MAC relation.
> > > 3. If you put yourself in my friend's shoes, and you wanted to
> > > forensically inspect your laptop for any signs of tampering, how
> > > would you start? Take the SSD out, make an image of that, work on the
> > > image (Assuming the infection is not at BIOS level)? What commands
> > > will you do to look for anything suspicious?
> > I would look which server services ran, e.g. someone break in via ssh
> > or telnet.
>
> How do you check this on an offline Linux image?

You could use this image in a sandboxed VM. Or you could power up the machine
in a controlled sandboxed enironment (out of range of any WiFi, or
disable/remove the WiFi card, etc.). Or just see what is installed (eg is
openssh-server installed? And configured to run?)

>
> >
> > Additionally, it is possible that he ran malicious software/scrips.
>
> Possible. His laptop had a graphics card with proprietary drivers which he
> needed to get working for CAD software.

Possible, but unlikely.

>
> >
> > The only solution is to reinstall the operating system in the machine.
>
> Agreed, but we would like to understand more before we wipe it and start
> anew.

Yes, understanding what happened will help you prevent it from happening
again.

[Marco Moock]

Am Dienstag, 30. August 2022, um 06:18:24 Uhr schrieb John Friday:

> We are checking but I believe the IT people consider the matter
> closed with the user's agreement to not connect his laptop to the
> university network and instead use the Windows machines administered
> by the IT staff.

This case isn't closed, he needs to find out what happens on the laptop.

[The Natural Philosopher]

On 30/08/2022 13:30, Marc Haber wrote:
> John Friday <john.2...@gmail.com> wrote:
>> He provided all of this, and apparently a computer matching the details he provided was blacklisted on the university network for unusual network traffic and attempting to hack* another user's computer. *Defined as "malicious network traffic" from his computer to another user.
>
> Would they be cooperative enough to tell _what_ the unusual network
> traffic is and what kind of hacking attempts were seen ("pcap or it
> didn't happen" will probably make a clueful admin more cooperative).
>
> In this unspecific form, I suspect that the IT department is building
> a strawman to ease their work load.
>
> Greetings
> Marc

Its probably something utterly trivial lie someone once did a broadcast
ping from it or something

Also, be aware that spoofing a different MAC address on Linux is utterly
trivial so he could take it in and simply change the MAC address

https://linuxhint.com/find_mac_address_change_mac_address_linux/

--
If I had all the money I've spent on drink...
..I'd spend it on drink.

Sir Henry (at Rawlinson's End)

[The Natural Philosopher]

Aha. This smacks of 'we only allow our windows laptops that we maintain
to work here, and all other MAC addresses are disabled, so there but we
dont admit it'

Shades of the BOFH...


--
Those who want slavery should have the grace to name it by its proper
name. They must face the full meaning of that which they are advocating
or condoning; the full, exact, specific meaning of collectivism, of its
logical implications, of the principles upon which it is based, and of
the ultimate consequences to which these principles will lead. They must
face it, then decide whether this is what they want or not.

Ayn Rand.

[The Natural Philosopher]

I suspect the answer will be 'not a damned thing' and anyway netstat is
your friend here.

At least I had the decency to own up when a guy got his email to me
bounced. Sick of spam coming from .info sites I had blacklisted that
whole top level domain. I blacklisted the whole of India, too. For a
while until I needed to get mail from there.

From the info to date plus a bit of experience of IT techs, I suspect
the true answer is,"if we didn't supply it, its blacklisted by default'

Being able to plug anything into a university network is an invitation
to abuse.

[Andreas Kohlbach]

On Tue, 30 Aug 2022 16:43:36 +0100, The Natural Philosopher wrote:
>
> On 30/08/2022 15:32, Marco Moock wrote:
>> Am Dienstag, 30. August 2022, um 06:18:24 Uhr schrieb John Friday:
>>
>>> We are checking but I believe the IT people consider the matter
>>> closed with the user's agreement to not connect his laptop to the
>>> university network and instead use the Windows machines administered
>>> by the IT staff.
>> This case isn't closed, he needs to find out what happens on the
>> laptop.
>>
> I suspect the answer will be 'not a damned thing' and anyway netstat
> is your friend here.
>
> At least I had the decency to own up when a guy got his email to me
> bounced. Sick of spam coming from .info sites I had blacklisted that
> whole top level domain.

That's way over top in my opinion. At least I know (and have accounts) on
a bunch of .info sites.

> I blacklisted the whole of India, too. For a while until I needed to
> get mail from there.

That is a good idea. Unless you have business with India.
--
Andreas

[John Friday]

He did have an openssh server running to transfer files between his laptop and his home Windows desktop. As the sole user of the laptop, his account was also a sudoer, so anyone who compromised his account password or used a privilege escalation could get root.

A Linux laptop makes an undesirable target to attack on a university network. One of the advantages of a university network is the institutional subscription to many journals. A laptop that is sometimes taken into/out of the campus would have spotty access for a would-be attacker, at best.

> Then install Nmap and do a full port scan on the laptop. (This might not
> really show anything meaningful, but is a useful step, esp. to see if there
> are things like botnet client servers running or "forgotten" service deamons
> running, possibly improperly.)
>
> If he is running a Debian variant, he can also do:
>
> sudo dpkg -V
>
> If he is running a RedHat-flavored system, he can do:
>
> sudo rpm -Va

He was using Debian 11.3

> These latter two will tell him if any of the install packages have been messed
> with somehow (it is *normal* for config files to deviate from the package, but
> should be looked at anyway to be sure).
>
> Otherwise, he should check to see if there are any files in his $HOME
> directory that should not be there (partitularly look into filenames starting
> with a dot (.)) -- either he ran something that dropped something where he had
> write access (eg under $HOME) that is malicious OR someone accessed his
> machine while is was away from it or he lent it someone -- eg a family
> member, etc. and that person installed something malicious.
>
> Unless this "friend" (or other party) knows (or guessed) he password (OR he
> has configured sudo to work withOUT a password!) the worst is this "friend"
> (or other party) put the malware somewhere under $HOME.

I'll do this once we finish making an image of his root and home hard drive. Given the history I don't want to connect his NVMe SSD to any of my computers so for now I am making the image over ssh with dd, with the SSD mounted on a SSD hat for a Raspberry Pi. It is taking a while - 512GB SSD and so far only 45GB downloaded. I believe it should be ready by a few hours, then I will be able to do the tests you all have suggested so far.

[John Friday]

Agreed spoofing the MAC address is trivial but if he is caught using the laptop on campus, and even more so with a spoofed MAC, it would reflect very poorly on him and the previous (closed) case, where his culpability I understand was ruled out eventually.

[Rich]

John Friday <john.2...@gmail.com> wrote:
> if the IT department say that the attacker's computer matches his MAC
> address, IP address, host name and ethernet socket in the building?

Most network hardware allows for runtime changing of the MAC address
(there is a hard coded default in ROM, with the ability to set any MAC
address via software).

So, it is possible for someone else to use his system's MAC address
(provided that someone else obtained the MAC address -- it is unlikely
they randomly selected it).

The IP address is likely assigned by the uni via DHCP, so IP address is
not very useful as an "ID" of "this hardware was responsible".

So it is also possible that someone else did plug into that same port
with a machine where they used your friends MAC address. Do note that
"possible" is not synonymous with "probable". You have not indicated
where the wall jack is located. If the wall jack is inside his dorm
room, then that limits the number of individuals who could possibly do
so. If the wall jack is in the cafeteria then the field of possible
individuals opens up considerably.

Is it likely someone cloned his MAC address? It is unlikely someone
did so by randomly picking a MAC. So if someone did clone his MAC,
they were targeting him (or more likely they were targeting a MAC
address they obtained via some arp level network scanning).

> 2. Is there a way for network sysadmins to locate which is the
> ethernet socket that is physically responsible for the attack?

Yes, non-home level network switches allow identification of which MAC
is connected to which switch port. Most commercial installations then
track which physical wall jack is connected to which switch port to
then track an issue to an exact wall jack.

> 3. If you put yourself in my friend's shoes, and you wanted to
> forensically inspect your laptop for any signs of tampering, how
> would you start? Take the SSD out, make an image of that, work on
> the image (Assuming the infection is not at BIOS level)? What
> commands will you do to look for anything suspicious?

Working from an image would help, because some malware does try to hide
its presence when it is running. But do keep in mind that from the
uni. perspective "malicious activity" is a rather broad term. If the
uni. won't tell specifically what they saw, then it is going to be
difficult to narrow things down (unless inspecting the image
immediately reveals a culprit).

And, also, if he allows javascript to run by default in his
web-browser, it is very possible that there is nothing at all present
on the laptop, and all of the malicious activity was generated because
he had an exploited ad network deliver a bit of port scanning
javascript or a shady web page attempt to do a network scan simply
because he browsed to the web page (either by accident or on purpose).

[John Friday]

On Tuesday, August 30, 2022 at 7:01:12 PM UTC+3, Rich wrote:
> John Friday <john.2...@gmail.com> wrote:
> > if the IT department say that the attacker's computer matches his MAC
> > address, IP address, host name and ethernet socket in the building?
> Most network hardware allows for runtime changing of the MAC address
> (there is a hard coded default in ROM, with the ability to set any MAC
> address via software).
>
> So, it is possible for someone else to use his system's MAC address
> (provided that someone else obtained the MAC address -- it is unlikely
> they randomly selected it).
>
> The IP address is likely assigned by the uni via DHCP, so IP address is
> not very useful as an "ID" of "this hardware was responsible".
>
> So it is also possible that someone else did plug into that same port
> with a machine where they used your friends MAC address. Do note that
> "possible" is not synonymous with "probable". You have not indicated
> where the wall jack is located. If the wall jack is inside his dorm
> room, then that limits the number of individuals who could possibly do
> so. If the wall jack is in the cafeteria then the field of possible
> individuals opens up considerably.

The wall jack was in his graduate student office to which a few people have keys to. The laptop when at home was in shared accommodation and not always screen locked.

He didn't bring his laptop into university all the time, and being a part time graduate student furthermore didn't come into university all the time either.

The IT people were not so forthcoming with information, but from what we can deduce:
1. The hostile action done by the offending computer was "sending malicious traffic to another user on the network" and also allegedly connecting to hundreds of IP addresses in Europe simultaneously. My friend explained the latter as due to P2P downloads of Raspberry Pi and Linux ISOs, both of which are free to distribute and not copyrighted material. So the only remaining question mark is what the traffic to the other user in the university was. My friend said he doesn't know the guy.

2. The fact that the IT people did not immediately come to the offending wall jack, but took action only after he reported severe packet losses (of the order of 60%) to the IT staff, who then asked for his computer name/DHCP IP address/MAC address/wall jack number, suggests they did not or could not find out which computer was responsible until they received all the information from the "offender". Put another way, if you were in charge of cybersecurity at a university, became aware of one computer "sending malicious traffic" to another and were doing your job, if you couldn't log in remotely to the offender as a sysadmin, you'd go visit the wall socket as the attack was unfolding to see what computer was attached to it and maybe who was doing it.

3. He has asked the IT department for exact times when the attacks from his computer allegedly occurred, but hasn't received anything yet. If the attacks happened when he wasn't physically present in the university, then it clearly shows the attacks used his MAC address. At which point the IT security manager asked him, "Do you have VPN into campus set up?" He answered no - he doesn't even have the 2FA app for the VPN installed on his phone. It seems to suggest that the IT security people don't know/can't know/can't be bothered to check if he did use VPN in the past or has it set up,

For computers which connect from his building via wall jack, they all have public network IP addresses with the last two octets being assigned to the (building).(user). If someone connected from outside using VPN, would the IP address clearly be different as a VPN user or would the university's DHCP always try to give the user the same IP address regardless if the connection was made via VPN or by ethernet port?

Will have more information soon. Currently 380/512 GB copied out.

[Rich]

John Friday <john.2...@gmail.com> wrote:
> ...

> and apparently a computer matching the details he provided was
> blacklisted on the university network for unusual network traffic and
> attempting to hack* another user's computer. *Defined as "malicious
> network traffic" from his computer to another user.

Another line of thought: Are you sure your friend is being totally
honest with you?

Linux already includes many tools that if used as intended would make
"unusual network traffic" (ping) and/or be defined as "attempting to hack
another user's computer" (nmap).

It is very possible he tried an nmap scan example he found online
somewhere one time, and the uni. noticed the scan and blacklisted the
MAC. Note that this "noticed the scan" is likely an automated system.

So have you enquired as to whether he was "experimenting" with anything
such that the uni. network scanner might have labeled it a "hack
attempt"? Because if he did, then that would mean the laptop is not
actually 'infected' with anything and the problem resolves to a PEBCAK
issue (which if so would save you any additional time investment).

[John Friday]

Here are the results of some tests and commands on the "infected" system:

1. chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `crontab'... not infected
Checking `date'... not infected
Checking `du'... not infected
Checking `dirname'... not infected
Checking `echo'... not infected
Checking `egrep'... not infected
Checking `env'... not infected
Checking `find'... not infected
Checking `fingerd'... not found
Checking `gpm'... not found
Checking `grep'... not infected
Checking `hdparm'... not found
Checking `su'... not infected
Checking `ifconfig'... not infected
Checking `inetd'... not infected
Checking `inetdconf'... not found
Checking `identd'... not found
Checking `init'... not infected
Checking `killall'... not infected
Checking `ldsopreload'... not infected
Checking `login'... not infected
Checking `ls'... not infected
Checking `lsof'... not infected
Checking `mail'... not found
Checking `mingetty'... not found
Checking `netstat'... not infected
Checking `named'... not found
Checking `passwd'... not infected
Checking `pidof'... not infected
Checking `pop2'... not found
Checking `pop3'... not found
Checking `ps'... not infected
Checking `pstree'... not infected
Checking `rpcinfo'... not found
Checking `rlogind'... not found
Checking `rshd'... not found
Checking `slogin'... not infected
Checking `sendmail'... not found
Checking `sshd'... not infected
Checking `syslogd'... not tested
Checking `tar'... not infected
Checking `tcpd'... not found
Checking `tcpdump'... not infected
Checking `top'... not infected
Checking `telnetd'... not found
Checking `timed'... not found
Checking `traceroute'... not found
Checking `vdir'... not infected
Checking `w'... not infected
Checking `write'... not infected
Checking `aliens'... no suspect files
Searching for sniffer's logs, it may take a while... nothing found
Searching for rootkit HiDrootkit's default files... nothing found
Searching for rootkit t0rn's default files... nothing found
Searching for t0rn's v8 defaults... nothing found
Searching for rootkit Lion's default files... nothing found
Searching for rootkit RSHA's default files... nothing found
Searching for rootkit RH-Sharpe's default files... nothing found
Searching for Ambient's rootkit (ark) default files and dirs... nothing found
Searching for suspicious files and dirs, it may take a while... Searching for LPD Worm files and dirs... nothing found
Searching for Ramen Worm files and dirs... nothing found
Searching for Maniac files and dirs... nothing found
Searching for RK17 files and dirs... nothing found
Searching for Ducoci rootkit... nothing found
Searching for Adore Worm... nothing found
Searching for ShitC Worm... nothing found
Searching for Omega Worm... nothing found
Searching for Sadmind/IIS Worm... nothing found
Searching for MonKit... nothing found
Searching for Showtee... nothing found
Searching for OpticKit... nothing found
Searching for T.R.K... nothing found
Searching for Mithra... nothing found
Searching for LOC rootkit... nothing found
Searching for Romanian rootkit... nothing found
Searching for Suckit rootkit... nothing found
Searching for Volc rootkit... nothing found
Searching for Gold2 rootkit... nothing found
Searching for TC2 Worm default files and dirs... nothing found
Searching for Anonoying rootkit default files and dirs... nothing found
Searching for ZK rootkit default files and dirs... nothing found
Searching for ShKit rootkit default files and dirs... nothing found
Searching for AjaKit rootkit default files and dirs... nothing found
Searching for zaRwT rootkit default files and dirs... nothing found
Searching for Madalin rootkit default files... nothing found
Searching for Fu rootkit default files... nothing found
Searching for ESRK rootkit default files... nothing found
Searching for rootedoor... nothing found
Searching for ENYELKM rootkit default files... nothing found
Searching for common ssh-scanners default files... nothing found
Searching for Linux/Ebury - Operation Windigo ssh... nothing found
Searching for 64-bit Linux Rootkit ... nothing found
Searching for 64-bit Linux Rootkit modules... nothing found
Searching for Mumblehard Linux ... nothing found
Searching for Backdoor.Linux.Mokes.a ... nothing found
Searching for Malicious TinyDNS ... nothing found
Searching for Linux.Xor.DDoS ... nothing found
Searching for Linux.Proxy.1.0 ... nothing found
Searching for CrossRAT ... nothing found
Searching for Hidden Cobra ... nothing found
Searching for Rocke Miner ... nothing found
Searching for PWNLNX4 lkm... nothing found
Searching for PWNLNX6 lkm... nothing found
Searching for suspect PHP files... nothing found
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... chkproc: nothing detected
chkdirs: nothing detected
Checking `rexedcs'... not found
Checking `sniffer'... lo: not promisc and no packet sniffer sockets wlp4s0: PACKET SNIFFER(/usr/sbin/NetworkManager[1031], /usr/sbin/wpa_supplicant[1041], /usr/sbin/wpa_supplicant[1041])
Checking `w55808'... not infected
Checking `wted'... chkwtmp: nothing deleted
Checking `scalper'... not infected
Checking `slapper'... not infected
Checking `z2'... user anonymous deleted or never logged from lastlog!
Checking `chkutmp'... The tty of the following user process(es) were not found
in /var/run/utmp !
! RUID PID TTY CMD
! anonymous 1621 pts/0 bash
! anonymous 3470 pts/0 sudo chkrootkit
! root 3471 pts/0 /bin/sh /usr/sbin/chkrootkit
! root 4230 pts/0 ./chkutmp
! root 4232 pts/0 ps axk tty,ruser,args -o tty,pid,ruser,args
! root 4231 pts/0 sh -c ps axk "tty,ruser,args" -o "tty,pid,ruser,args"
! anonymous 1641 pts/1 bash
! anonymous 2671 pts/1 sudo synaptic-pkexec
! root 2673 pts/1 /usr/sbin/synaptic
! root 2672 pts/1 /bin/sh /usr/bin/synaptic-pkexec
chkutmp: nothing deleted
Checking `OSX_RSPLUG'... not tested




2. service --status-all
[ - ] alsa-utils
[ - ] anacron
[ + ] apparmor
[ + ] avahi-daemon
[ + ] bluetooth
[ - ] console-setup.sh
[ + ] cron
[ - ] cryptdisks
[ - ] cryptdisks-early
[ + ] cups
[ + ] cups-browsed
[ + ] dbus
[ + ] hddtemp
[ - ] hwclock.sh
[ - ] keyboard-setup.sh
[ + ] kmod
[ + ] lightdm
[ + ] lm-sensors
[ + ] networking
[ + ] openvpn
[ - ] pcscd
[ - ] plymouth
[ + ] plymouth-log
[ + ] procps
[ - ] pulseaudio-enable-autospawn
[ - ] rsync
[ + ] rsyslog
[ - ] saned
[ - ] speech-dispatcher
[ - ] ssh
[ - ] ssh.disabled
[ - ] sudo
[ + ] udev
[ - ] x11-common


3. sudo dpkg -V
??5?????? /boot/System.map-5.10.0-14-amd64
??5?????? /boot/config-5.10.0-14-amd64
??5?????? /boot/vmlinuz-5.10.0-14-amd64
??5?????? /boot/System.map-5.10.0-9-amd64
??5?????? /boot/config-5.10.0-9-amd64
??5?????? /boot/vmlinuz-5.10.0-9-amd64


4. iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
DROP tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state NEW
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere



5. netstat -aN (university's IP address removed for anonymity, this was just before the laptop was disconnected from the university network)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:ipp 0.0.0.0:* LISTEN
tcp6 0 0 localhost:ipp [::]:* LISTEN
udp 0 0 192.168.51.20:bootpc public.IPaddress.7.9:bootps ESTABLISHED
udp 0 0 0.0.0.0:631 0.0.0.0:*
udp 0 0 0.0.0.0:59619 0.0.0.0:*
udp 0 0 0.0.0.0:mdns 0.0.0.0:*
udp 0 0 0.0.0.0:40083 0.0.0.0:*
udp6 0 0 [::]:59022 [::]:*
udp6 0 0 [::]:mdns [::]:*
raw6 0 0 [::]:ipv6-icmp [::]:* 7
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 22812 /tmp/ssh-k3iGGXRU3E2R/agent.1550
unix 2 [ ACC ] STREAM LISTENING 22842 @/tmp/dbus-f348apcZwQ
unix 2 [ ACC ] STREAM LISTENING 22615 /tmp/.X11-unix/X0
unix 2 [ ACC ] STREAM LISTENING 15050 /tmp/.ICE-unix/1550
unix 2 [ ACC ] STREAM LISTENING 10456 /run/avahi-daemon/socket
unix 2 [ ACC ] STREAM LISTENING 10458 /run/cups/cups.sock
unix 2 [ ACC ] STREAM LISTENING 15049 @/tmp/.ICE-unix/1550
unix 2 [ ACC ] STREAM LISTENING 10460 /run/dbus/system_bus_socket
unix 2 [ ACC ] STREAM LISTENING 72822 /tmp/.vbox-anonymous-ipc/ipcd
unix 2 [ ] DGRAM 21810 /run/user/1000/systemd/notify
unix 2 [ ACC ] STREAM LISTENING 10462 /run/pcscd/pcscd.comm
unix 2 [ ACC ] STREAM LISTENING 21813 /run/user/1000/systemd/private
unix 2 [ ACC ] STREAM LISTENING 21819 /run/user/1000/bus
unix 2 [ ACC ] STREAM LISTENING 22614 @/tmp/.X11-unix/X0
unix 2 [ ACC ] STREAM LISTENING 21821 /run/user/1000/gnupg/S.dirmngr
unix 2 [ ACC ] STREAM LISTENING 21823 /run/user/1000/gnupg/S.gpg-agent.browser
unix 2 [ ACC ] STREAM LISTENING 21825 /run/user/1000/gnupg/S.gpg-agent.extra
unix 2 [ ACC ] STREAM LISTENING 21827 /run/user/1000/gnupg/S.gpg-agent.ssh
unix 2 [ ACC ] STREAM LISTENING 21829 /run/user/1000/gnupg/S.gpg-agent
unix 2 [ ACC ] STREAM LISTENING 21831 /run/user/1000/pipewire-0
unix 2 [ ACC ] STREAM LISTENING 21833 /run/user/1000/pk-debconf-socket
unix 2 [ ACC ] STREAM LISTENING 21835 /run/user/1000/pulse/native
unix 2 [ ACC ] STREAM LISTENING 34170 /run/user/1000/keyring/control
unix 4 [ ] DGRAM 1436 /run/systemd/notify
unix 2 [ ACC ] STREAM LISTENING 1439 /run/systemd/private
unix 2 [ ACC ] STREAM LISTENING 1441 /run/systemd/userdb/io.systemd.DynamicUser
unix 2 [ ACC ] STREAM LISTENING 1442 /run/systemd/io.system.ManagedOOM
unix 2 [ ] DGRAM 1451 /run/systemd/journal/syslog
unix 2 [ ACC ] STREAM LISTENING 1453 /run/systemd/fsck.progress
unix 17 [ ] DGRAM 1457 /run/systemd/journal/dev-log
unix 8 [ ] DGRAM 1459 /run/systemd/journal/socket
unix 2 [ ACC ] STREAM LISTENING 1461 /run/systemd/journal/stdout
unix 2 [ ACC ] SEQPACKET LISTENING 1463 /run/udev/control
unix 2 [ ACC ] STREAM LISTENING 14431 /run/systemd/journal/io.systemd.journal
unix 2 [ ] DGRAM 21664 /run/wpa_supplicant/wlp4s0
unix 2 [ ] DGRAM 21668 /run/wpa_supplicant/p2p-dev-wlp4s0
unix 3 [ ] STREAM CONNECTED 55069 @/tmp/.ICE-unix/1550
unix 3 [ ] STREAM CONNECTED 23018
unix 3 [ ] STREAM CONNECTED 2019 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 72823 /tmp/.vbox-anonymous-ipc/ipcd
unix 3 [ ] STREAM CONNECTED 22846 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 67941
unix 3 [ ] STREAM CONNECTED 18180 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 17982 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 18050
unix 3 [ ] STREAM CONNECTED 14763
unix 3 [ ] STREAM CONNECTED 21003 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 77188
unix 3 [ ] STREAM CONNECTED 11058
unix 3 [ ] STREAM CONNECTED 23755
unix 3 [ ] STREAM CONNECTED 11012 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 68484 /run/cups/cups.sock
unix 3 [ ] DGRAM 71346
unix 3 [ ] STREAM CONNECTED 18022
unix 3 [ ] STREAM CONNECTED 31147 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 956
unix 3 [ ] STREAM CONNECTED 24631 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 21014 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 24714
unix 3 [ ] STREAM CONNECTED 74149 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 15072
unix 3 [ ] STREAM CONNECTED 17899
unix 3 [ ] STREAM CONNECTED 15130 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 21103 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 24715
unix 3 [ ] STREAM CONNECTED 21951 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 15068
unix 3 [ ] STREAM CONNECTED 73541
unix 3 [ ] STREAM CONNECTED 23024
unix 3 [ ] STREAM CONNECTED 21108
unix 3 [ ] STREAM CONNECTED 22972 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 21881
unix 3 [ ] STREAM CONNECTED 72824 /tmp/.vbox-anonymous-ipc/ipcd
unix 3 [ ] STREAM CONNECTED 23702 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 22907
unix 3 [ ] STREAM CONNECTED 18110
unix 2 [ ] DGRAM 14433
unix 3 [ ] STREAM CONNECTED 77190 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 24841 /run/user/1000/pulse/native
unix 3 [ ] STREAM CONNECTED 23052
unix 3 [ ] STREAM CONNECTED 21114
unix 3 [ ] STREAM CONNECTED 21884
unix 3 [ ] STREAM CONNECTED 24697 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 24624
unix 3 [ ] STREAM CONNECTED 15071
unix 3 [ ] STREAM CONNECTED 71340 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 23014 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 19343 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 11005 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 24629
unix 2 [ ] DGRAM 744
unix 3 [ ] STREAM CONNECTED 18109 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 1662 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 24809 @/tmp/.ICE-unix/1550
unix 3 [ ] STREAM CONNECTED 21109
unix 3 [ ] STREAM CONNECTED 20344 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 11048
unix 3 [ ] STREAM CONNECTED 11006 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 15062 @/tmp/.ICE-unix/1550
unix 3 [ ] STREAM CONNECTED 22979 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 1797 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 23728 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 74154
unix 3 [ ] STREAM CONNECTED 11059 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 17949 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 10995 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 21887 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 21851 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 970 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 23013
unix 3 [ ] STREAM CONNECTED 21953
unix 3 [ ] STREAM CONNECTED 21929 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 22906
unix 3 [ ] STREAM CONNECTED 18095
unix 3 [ ] STREAM CONNECTED 17948 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 15162 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 22974
unix 3 [ ] STREAM CONNECTED 80902 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 22893
unix 2 [ ] DGRAM 24579
unix 3 [ ] STREAM CONNECTED 19304 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 21779
unix 3 [ ] STREAM CONNECTED 21893 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 21878
unix 3 [ ] STREAM CONNECTED 24717
unix 3 [ ] DGRAM 926
unix 3 [ ] STREAM CONNECTED 11014 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 23684 @/tmp/.ICE-unix/1550
unix 3 [ ] STREAM CONNECTED 22000 @/tmp/.ICE-unix/1550
unix 3 [ ] STREAM CONNECTED 961
unix 3 [ ] STREAM CONNECTED 21921
unix 3 [ ] STREAM CONNECTED 24656
unix 3 [ ] DGRAM 747
unix 3 [ ] STREAM CONNECTED 18111 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 15065
unix 3 [ ] STREAM CONNECTED 66947
unix 3 [ ] STREAM CONNECTED 24808
unix 3 [ ] DGRAM 21812
unix 3 [ ] STREAM CONNECTED 21926
unix 3 [ ] STREAM CONNECTED 10923
unix 3 [ ] STREAM CONNECTED 22889
unix 3 [ ] STREAM CONNECTED 10955 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 11050 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 14903
unix 3 [ ] STREAM CONNECTED 66948
unix 3 [ ] STREAM CONNECTED 11044
unix 3 [ ] STREAM CONNECTED 23682 @/tmp/.ICE-unix/1550
unix 3 [ ] STREAM CONNECTED 17981 @/dbus-vfs-daemon/socket-ee0hkXrH
unix 3 [ ] STREAM CONNECTED 14730
unix 3 [ ] STREAM CONNECTED 24842
unix 3 [ ] STREAM CONNECTED 23053 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 21132
unix 2 [ ] DGRAM 21780
unix 3 [ ] STREAM CONNECTED 15164 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 21915
unix 3 [ ] STREAM CONNECTED 20351 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 21882 /run/user/1000/bus
unix 3 [ ] DGRAM 925
unix 3 [ ] STREAM CONNECTED 71343
unix 3 [ ] STREAM CONNECTED 18106 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 11000 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 19317 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 24813 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 21954
unix 3 [ ] STREAM CONNECTED 24625
unix 3 [ ] STREAM CONNECTED 735
unix 3 [ ] STREAM CONNECTED 72382
unix 3 [ ] STREAM CONNECTED 24721 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 20356 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 67942 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 30100
unix 3 [ ] STREAM CONNECTED 22785 /run/user/1000/pipewire-0
unix 3 [ ] STREAM CONNECTED 19344 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 22858 @/tmp/.X11-unix/X0
unix 3 [ ] DGRAM 748
unix 3 [ ] STREAM CONNECTED 17974 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 23057 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 23049
unix 3 [ ] STREAM CONNECTED 17977 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 21903
unix 3 [ ] STREAM CONNECTED 67948
unix 3 [ ] STREAM CONNECTED 11008 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 24653
unix 3 [ ] STREAM CONNECTED 17979
unix 3 [ ] STREAM CONNECTED 71342 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 22054 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 21815
unix 3 [ ] STREAM CONNECTED 77189
unix 3 [ ] STREAM CONNECTED 21880
unix 3 [ ] STREAM CONNECTED 23703 @/tmp/dbus-f348apcZwQ
unix 2 [ ] DGRAM 920
unix 3 [ ] STREAM CONNECTED 14718
unix 2 [ ] DGRAM 17604
unix 3 [ ] STREAM CONNECTED 66945
unix 3 [ ] STREAM CONNECTED 22917
unix 3 [ ] STREAM CONNECTED 21545
unix 2 [ ] DGRAM 21877
unix 3 [ ] STREAM CONNECTED 24712
unix 3 [ ] DGRAM 927
unix 3 [ ] STREAM CONNECTED 10999 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 18161 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 22983 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 22847 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 22888
unix 3 [ ] STREAM CONNECTED 10956 /run/systemd/journal/stdout
unix 3 [ ] DGRAM 71345
unix 3 [ ] STREAM CONNECTED 23017 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 18184 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 23054 /run/user/1000/bus
unix 2 [ ] DGRAM 21774
unix 3 [ ] STREAM CONNECTED 11062
unix 3 [ ] STREAM CONNECTED 10997 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 71338 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 22855
unix 3 [ ] STREAM CONNECTED 24592
unix 3 [ ] STREAM CONNECTED 17978
unix 3 [ ] STREAM CONNECTED 14696
unix 3 [ ] STREAM CONNECTED 24838
unix 3 [ ] STREAM CONNECTED 24811 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 21546 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 10983
unix 3 [ ] STREAM CONNECTED 22820 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 22886
unix 3 [ ] STREAM CONNECTED 24634
unix 3 [ ] STREAM CONNECTED 18079
unix 3 [ ] STREAM CONNECTED 10626 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 24843
unix 3 [ ] STREAM CONNECTED 15174 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 11007
unix 3 [ ] STREAM CONNECTED 10996 /run/systemd/journal/stdout
unix 2 [ ] DGRAM 10623
unix 3 [ ] STREAM CONNECTED 24706
unix 3 [ ] STREAM CONNECTED 15048 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 23686 @/tmp/.ICE-unix/1550
unix 3 [ ] STREAM CONNECTED 24840
unix 3 [ ] STREAM CONNECTED 15196 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 10619 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 80901 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 11011
unix 3 [ ] STREAM CONNECTED 22845
unix 3 [ ] STREAM CONNECTED 11009 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 24662
unix 3 [ ] STREAM CONNECTED 18105
unix 3 [ ] STREAM CONNECTED 14704
unix 3 [ ] STREAM CONNECTED 24807
unix 3 [ ] STREAM CONNECTED 17983 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 985
unix 3 [ ] STREAM CONNECTED 23689 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 23701 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 14467 /run/systemd/journal/stdout
unix 2 [ ] DGRAM 72614
unix 3 [ ] STREAM CONNECTED 18112
unix 3 [ ] STREAM CONNECTED 15067
unix 3 [ ] STREAM CONNECTED 24781
unix 3 [ ] STREAM CONNECTED 15129 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 21994
unix 2 [ ] DGRAM 21544
unix 3 [ ] STREAM CONNECTED 21857
unix 3 [ ] STREAM CONNECTED 24655
unix 3 [ ] STREAM CONNECTED 22856
unix 3 [ ] STREAM CONNECTED 15079
unix 3 [ ] STREAM CONNECTED 21137
unix 3 [ ] STREAM CONNECTED 22020 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 11046
unix 3 [ ] STREAM CONNECTED 10554
unix 3 [ ] STREAM CONNECTED 21013 /run/user/1000/bus
unix 3 [ ] DGRAM 924
unix 3 [ ] STREAM CONNECTED 14871
unix 2 [ ] DGRAM 17771
unix 3 [ ] STREAM CONNECTED 66949
unix 3 [ ] STREAM CONNECTED 22026
unix 3 [ ] STREAM CONNECTED 11052 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 21596
unix 3 [ ] STREAM CONNECTED 22786 /run/user/1000/pipewire-0
unix 3 [ ] STREAM CONNECTED 23695 @/tmp/.ICE-unix/1550
unix 3 [ ] STREAM CONNECTED 22857 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 23690 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 20341 /run/dbus/system_bus_socket
unix 2 [ ] DGRAM 24916
unix 3 [ ] DGRAM 21811
unix 3 [ ] STREAM CONNECTED 24718
unix 3 [ ] STREAM CONNECTED 24705 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 21858
unix 3 [ ] STREAM CONNECTED 22895
unix 3 [ ] STREAM CONNECTED 21911 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 21125
unix 3 [ ] STREAM CONNECTED 11049 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 21904
unix 3 [ ] STREAM CONNECTED 10477
unix 3 [ ] STREAM CONNECTED 10994 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 18108
unix 3 [ ] STREAM CONNECTED 15075
unix 3 [ ] STREAM CONNECTED 36255
unix 3 [ ] STREAM CONNECTED 22980 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 21557 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 18121 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 22775
unix 3 [ ] STREAM CONNECTED 21017 /run/user/1000/bus
unix 3 [ ] DGRAM 1437
unix 3 [ ] STREAM CONNECTED 59099 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 23688 /run/user/1000/bus
unix 2 [ ] STREAM CONNECTED 20447
unix 3 [ ] STREAM CONNECTED 24720
unix 3 [ ] STREAM CONNECTED 23055 /run/user/1000/bus
unix 2 [ ] DGRAM 20340
unix 3 [ ] STREAM CONNECTED 21852 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 1633
unix 3 [ ] STREAM CONNECTED 15195 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 19359
unix 3 [ ] STREAM CONNECTED 23019 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 19346 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 53517
unix 3 [ ] STREAM CONNECTED 15083
unix 3 [ ] DGRAM 23606
unix 3 [ ] STREAM CONNECTED 21892 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 10747 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 18115
unix 3 [ ] STREAM CONNECTED 19342
unix 2 [ ] DGRAM 36259
unix 3 [ ] STREAM CONNECTED 23012 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 10599 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 15095 @/tmp/.ICE-unix/1550
unix 3 [ ] STREAM CONNECTED 21035
unix 3 [ ] STREAM CONNECTED 14735 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 23020 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 18096 /run/dbus/system_bus_socket
unix 2 [ ] DGRAM 20689
unix 2 [ ] DGRAM 1679
unix 3 [ ] STREAM CONNECTED 18162
unix 3 [ ] STREAM CONNECTED 22570
unix 3 [ ] STREAM CONNECTED 15082
unix 3 [ ] STREAM CONNECTED 23704 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 972 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 72816
unix 3 [ ] STREAM CONNECTED 20322
unix 3 [ ] STREAM CONNECTED 20659 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 20658
unix 3 [ ] STREAM CONNECTED 18120
unix 3 [ ] STREAM CONNECTED 35384 /run/systemd/journal/stdout
unix 2 [ ] DGRAM 20346
unix 3 [ ] STREAM CONNECTED 23022 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 15172
unix 3 [ ] STREAM CONNECTED 23754
unix 3 [ ] STREAM CONNECTED 34171
unix 3 [ ] STREAM CONNECTED 23694 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 14703 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 21100
unix 3 [ ] STREAM CONNECTED 22844
unix 3 [ ] STREAM CONNECTED 15178
unix 3 [ ] STREAM CONNECTED 15198 @/dbus-vfs-daemon/socket-vU98pGwl
unix 2 [ ] DGRAM 1782
unix 3 [ ] STREAM CONNECTED 21850 /run/systemd/journal/stdout
unix 2 [ ] DGRAM 36260
unix 3 [ ] STREAM CONNECTED 15179
unix 3 [ ] STREAM CONNECTED 20333
unix 3 [ ] STREAM CONNECTED 21879 /run/user/1000/bus
unix 2 [ ] DGRAM 1634
unix 2 [ ] DGRAM 22784
unix 3 [ ] STREAM CONNECTED 15227
unix 3 [ ] STREAM CONNECTED 20250
unix 3 [ ] STREAM CONNECTED 20674
unix 2 [ ] DGRAM 18114
unix 3 [ ] STREAM CONNECTED 19341
unix 3 [ ] STREAM CONNECTED 15200
unix 3 [ ] DGRAM 23607
unix 3 [ ] STREAM CONNECTED 24608 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 18107 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 23673
unix 3 [ ] STREAM CONNECTED 14695 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 59483
unix 3 [ ] STREAM CONNECTED 19345 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 21012
unix 3 [ ] STREAM CONNECTED 22755
unix 3 [ ] STREAM CONNECTED 23011 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 20249
unix 3 [ ] STREAM CONNECTED 10450 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 21876 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 15121
unix 3 [ ] STREAM CONNECTED 23591
unix 3 [ ] STREAM CONNECTED 21011
unix 3 [ ] STREAM CONNECTED 1590
unix 3 [ ] STREAM CONNECTED 18163 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 67943 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 15122 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 20360
unix 3 [ ] STREAM CONNECTED 21004
unix 3 [ ] STREAM CONNECTED 19362
unix 2 [ ] DGRAM 20332
unix 3 [ ] STREAM CONNECTED 21104 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 40133 /run/dbus/system_bus_socket
unix 2 [ ] DGRAM 22764
unix 3 [ ] STREAM CONNECTED 20359
unix 3 [ ] STREAM CONNECTED 1780
unix 3 [ ] STREAM CONNECTED 23021 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 22819
unix 3 [ ] STREAM CONNECTED 72833
unix 3 [ ] STREAM CONNECTED 11010 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 20254
unix 3 [ ] STREAM CONNECTED 20679
unix 3 [ ] STREAM CONNECTED 21788 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 74156 /run/dbus/system_bus_socket
unix 2 [ ] DGRAM 20248
unix 3 [ ] STREAM CONNECTED 21098
unix 3 [ ] STREAM CONNECTED 22817
unix 2 [ ] DGRAM 59481
unix 3 [ ] STREAM CONNECTED 20242
unix 3 [ ] STREAM CONNECTED 24723 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 1841
unix 3 [ ] STREAM CONNECTED 40132 /run/user/1000/bus
unix 3 [ ] STREAM CONNECTED 15168
unix 2 [ ] DGRAM 20339
unix 3 [ ] STREAM CONNECTED 21102
unix 3 [ ] STREAM CONNECTED 15157
unix 3 [ ] STREAM CONNECTED 10673 @/tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 51882 /run/systemd/journal/stdout
unix 3 [ ] DGRAM 1438
unix 3 [ ] STREAM CONNECTED 15167
unix 3 [ ] STREAM CONNECTED 19305 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 21034
unix 3 [ ] STREAM CONNECTED 20755 /run/systemd/journal/stdout
unix 3 [ ] STREAM CONNECTED 17789 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 36261
unix 3 [ ] STREAM CONNECTED 15228
unix 3 [ ] STREAM CONNECTED 23724
unix 3 [ ] STREAM CONNECTED 23722 @/tmp/dbus-f348apcZwQ
unix 3 [ ] STREAM CONNECTED 10530 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 15081
unix 2 [ ] DGRAM 20330
unix 3 [ ] STREAM CONNECTED 20343 /run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 18122

[John Friday]

It is possible that my friend may have unknowingly triggered the wrath of the IT security department, perhaps even for being one of the minority Linux users on the campus, but in any case learning how to do a full security audit of a Linux computer (which is the purpose of this thread) is always useful to know.

[Rich]

John Friday <john.2...@gmail.com> wrote:
> On Tuesday, August 30, 2022 at 7:01:12 PM UTC+3, Rich wrote:
>> John Friday <john.2...@gmail.com> wrote:
>> > if the IT department say that the attacker's computer matches his MAC
>> > address, IP address, host name and ethernet socket in the building?
>>

>> So it is also possible that someone else did plug into that same
>> port with a machine where they used your friends MAC address. Do
>> note that "possible" is not synonymous with "probable". You have
>> not indicated where the wall jack is located. If the wall jack is
>> inside his dorm room, then that limits the number of individuals who
>> could possibly do so. If the wall jack is in the cafeteria then the
>> field of possible individuals opens up considerably.
>
> The wall jack was in his graduate student office to which a few
> people have keys to.

This limits the number of possible culprits -- and also reduces the
probability of another computer to a rather small chance.

> The laptop when at home was in shared accommodation and not always
> screen locked.

It is possible someone else added something, but then you point out
something below that probaby shows what they detected.

> 1. The hostile action done by the offending computer was "sending
> malicious traffic to another user on the network" and also allegedly
> connecting to hundreds of IP addresses in Europe simultaneously. My
> friend explained the latter as due to P2P downloads of Raspberry Pi
> and Linux ISOs, both of which are free to distribute and not
> copyrighted material.

This, right here, is likely what the uni. network admins are
complaining about. Most commerical network admins label *all* p2p
traffic as bad, regardless of the actual content being transferred.
The reason why is due to a large majority being either copyright
infringement or sexually explicit material. Rather than trying to
separate the 3% good traffic from the 97% bad, they label it all bad,
ban it all, and move along.

And, all it would have taken was for him to forget bittorrent was
running when he plugged into the uni's network and the result is their
auto-scanner would have sensed the bittorrent traffic and inserted his
MAC onto the ban-list.

> So the only remaining question mark is what the traffic to the other
> user in the university was.

Likely that other user was also using p2p software and his computer was
sending/receiving p2p data from that other user.

> 2. The fact that the IT people did not immediately come to the
> offending wall jack, but took action only after he reported severe
> packet losses (of the order of 60%) to the IT staff, who then asked
> for his computer name/DHCP IP address/MAC address/wall jack number,

Not necessarially. You've got the ordering incorrect here. Action was
taken in the past, they simply did not let him know anything until he
asked "what's going on".

And your statement implies a human watching a network trace log and
deciding to "ban-list" someone. That is not how these occur in uni.
level networks. There are automated traffic monitoring systems that
watch, decide, and act, without human intervention. IT staff likely
knew nothing had occurred until his question to them prompted them to
look up his MAC in the scan-and-ban system, whereupon they found the
scan-and-ban system had banned him.

> Put another way, if you were in charge of cybersecurity at a
> university, became aware of one computer "sending malicious traffic"
> to another and were doing your job, if you couldn't log in remotely
> to the offender as a sysadmin, you'd go visit the wall socket as the
> attack was unfolding to see what computer was attached to it and
> maybe who was doing it.

If you were a network admin, you would not do this after about the
third or fourth time, just today, you've had to go out to do so. It is
all handled by the automated machines. Not by humans watching for
activity and acting upon that activity.

> 3. He has asked the IT department for exact times when the attacks
> from his computer allegedly occurred, but hasn't received anything
> yet. If the attacks happened when he wasn't physically present in
> the university, then it clearly shows the attacks used his MAC
> address.

The result will, likely, be a time when he was at uni.

> At which point the IT security manager asked him, "Do you have VPN
> into campus set up?" He answered no - he doesn't even have the 2FA
> app for the VPN installed on his phone. It seems to suggest that the
> IT security people don't know/can't know/can't be bothered to check
> if he did use VPN in the past or has it set up,

More likely didn't want to bother opening up the app, jumping through
the four-factor-authentication system, waiting 5 minutes while it
slowly loads, only to then check if he has a VPN account.

> For computers which connect from his building via wall jack, they all
> have public network IP addresses with the last two octets being
> assigned to the (building).(user). If someone connected from outside
> using VPN, would the IP address clearly be different as a VPN user or
> would the university's DHCP always try to give the user the same IP
> address regardless if the connection was made via VPN or by ethernet
> port?

Ask the uni. network folks this question. We have no way to know how
they have their VPN setup configured.

[Robert Heller]

(The Raspberry Pi and Linux ISOs ARE copyrighted, just with the GPL license,
which allows free distribution.)

> 2. The fact that the IT people did not immediately come to the offending
> wall jack, but took action only after he reported severe packet losses (of
> the order of 60%) to the IT staff, who then asked for his computer name/DHCP
> IP address/MAC address/wall jack number, suggests they did not or could not
> find out which computer was responsible until they received all the
> information from the "offender". Put another way, if you were in charge of
> cybersecurity at a university, became aware of one computer "sending
> malicious traffic" to another and were doing your job, if you couldn't log
> in remotely to the offender as a sysadmin, you'd go visit the wall socket as
> the attack was unfolding to see what computer was attached to it and maybe
> who was doing it.

This depends on whether the university sprung for the added cost of managed
switches or not or if the IT people had bothered to set up the switches to
store the mapping between mac address and ports. I *suspect* that the
university's budget limitations might mean no to one or both of the above.
Catching the malicious traffic itself is just software (eg wire shark or some
such), so has little or no "cost".

>
> 3. He has asked the IT department for exact times when the attacks from his
> computer allegedly occurred, but hasn't received anything yet. If the
> attacks happened when he wasn't physically present in the university, then
> it clearly shows the attacks used his MAC address. At which point the IT
> security manager asked him, "Do you have VPN into campus set up?" He
> answered no - he doesn't even have the 2FA app for the VPN installed on his
> phone. It seems to suggest that the IT security people don't know/can't
> know/can't be bothered to check if he did use VPN in the past or has it set
> up,
>
> For computers which connect from his building via wall jack, they all have
> public network IP addresses with the last two octets being assigned to the
> (building).(user). If someone connected from outside using VPN, would the IP
> address clearly be different as a VPN user or would the university's DHCP
> always try to give the user the same IP address regardless if the connection
> was made via VPN or by ethernet port?

A VPN would not show up that way. The *VPN* server might have something like a
DHCP server, but that would be something completely different and "local" to
the VPN service. Actually the only way to get on to the university's network
with a VPN would be if the university itself hosted the VPN service.

[John Friday]

It is pretty unfortunate, we hadn't realized that using Bittorrent to download isos of free-to-distribute material can result in a ban and potential disciplinary action. The whole point of downloading Linux/Raspbian ISOs via Bittorrent is to download it faster, share upload capacity with other users and reduce the burden on Debian and the Raspberry Pi foundation servers.

How do these automated traffic monitoring systems work? Based on volume of traffic? He was using a commercial VPN to VPN out of the university network and his DNS servers are 8.8.8.8, so presumably the university's sysadmins can not see his DNS requests?

How are the bans implemented? He said his ethernet connection died gradually at university, at first some days it was OK and other days it was bad, then packet losses started going up until at one stage it reached 80%. Persumably the bans would be no internet access at all rather than slow/sporadic.

[John Friday]

On Tuesday, August 30, 2022 at 8:50:51 PM UTC+3, Robert Heller wrote:

> A VPN would not show up that way. The *VPN* server might have something like a
> DHCP server, but that would be something completely different and "local" to
> the VPN service. Actually the only way to get on to the university's network
> with a VPN would be if the university itself hosted the VPN service.

Yeah I meant this, the university allows staff/students to connect from outside to get a university IP address, so that they can then access journals with the institutional subscription. He hasn't set this up (wouldn't the university sysadmins know this? Or depends how bothered they are to check?) because he lives close to the university.

[The Natural Philosopher]

On 30/08/2022 16:50, Andreas Kohlbach wrote:
> On Tue, 30 Aug 2022 16:43:36 +0100, The Natural Philosopher wrote:
>>
>> On 30/08/2022 15:32, Marco Moock wrote:
>>> Am Dienstag, 30. August 2022, um 06:18:24 Uhr schrieb John Friday:
>>>
>>>> We are checking but I believe the IT people consider the matter
>>>> closed with the user's agreement to not connect his laptop to the
>>>> university network and instead use the Windows machines administered
>>>> by the IT staff.
>>> This case isn't closed, he needs to find out what happens on the
>>> laptop.
>>>
>> I suspect the answer will be 'not a damned thing' and anyway netstat
>> is your friend here.
>>
>> At least I had the decency to own up when a guy got his email to me
>> bounced. Sick of spam coming from .info sites I had blacklisted that
>> whole top level domain.
>
> That's way over top in my opinion. At least I know (and have accounts) on
> a bunch of .info sites.
>

But do you send mail from .info addresses?

>> I blacklisted the whole of India, too. For a while until I needed to
>> get mail from there.
>
> That is a good idea. Unless you have business with India.

:-)


--
"I am inclined to tell the truth and dislike people who lie consistently.
This makes me unfit for the company of people of a Left persuasion, and
all women"

[The Natural Philosopher]

Having read the latest info it is fairly clear that he was blacklisted
for running a torrent client

Which may or may not have had some ratware profile

With a normal http or ftp download able to fully occupy my considerable
bandwidth I dont understand why anyone would use a torrent instead.



--
Truth welcomes investigation because truth knows investigation will lead
to converts. It is deception that uses all the other techniques.

[John Friday]

The torrent client was transmission-gtk which AFAIK does not have any ratware in it.

It also doesn't explain the other issue the network sysadmins raised, which was "malicious traffic" between his computer and another computer on the university network. Although rich suggested that another bittorent client could have been installed on the "victim" computer on the university network.

> Which may or may not have had some ratware profile
>
> With a normal http or ftp download able to fully occupy my considerable
> bandwidth I dont understand why anyone would use a torrent instead.

Torrents can often be faster than http/ftp download because you're downloading from many peers rather than just one server.

[Rich]

John Friday <john.2...@gmail.com> wrote:
> On Tuesday, August 30, 2022 at 8:35:21 PM UTC+3, Rich wrote:
>> And your statement implies a human watching a network trace log and
>> deciding to "ban-list" someone. That is not how these occur in uni.
>> level networks. There are automated traffic monitoring systems that
>> watch, decide, and act, without human intervention. IT staff likely
>> knew nothing had occurred until his question to them prompted them
>> to look up his MAC in the scan-and-ban system, whereupon they found
>> the scan-and-ban system had banned him.
>
> It is pretty unfortunate, we hadn't realized that using Bittorrent to
> download isos of free-to-distribute material can result in a ban and
> potential disciplinary action.

Sadly such is true. Most network admins see bittorrent as all bad
(yes, they are applying the "one rotten apple spoils the whole basket"
analysis, except in this case it is more like 11 out of 12 rotten
apples).

> The whole point of downloading Linux/Raspbian ISOs via Bittorrent is
> to download it faster, share upload capacity with other users and
> reduce the burden on Debian and the Raspberry Pi foundation servers.

Correct. But that does not change the fact that bittorrent traffic is
seen as a "shoot first, ask questions later" protocol.

> How do these automated traffic monitoring systems work?

Look up "Deep Packet Inspection" https://en.wikipedia.org/wiki/Deep_packet_inspection

That will explain better than any summary I might add here.

> He was using a commercial VPN to VPN out of the university network
> and his DNS servers are 8.8.8.8, so presumably the university's
> sysadmins can not see his DNS requests?

Did his laptop do DHCP for the uni. network? One of the items that
returns in the DHCP setup is "name servers" to use for the DHCP IP. If
he did not remember reset his name servers to 8.8.8.8 after obtaining
an IP on the uni network, then he was possibly using the uni's
nameservers (depending on what the VPN does). And, if he did not know
that bittorrent was seen as "bad", he likely also did not know that
DHCP setup would change his nameservers without extra effort by him to
stop such.

As for "commercial VPN" -- depending upon what traffic the "commercial
VPN" captured, the uni might still have seen the name lookups. I.e.,
if the VPN only captured TCP traffic, but left UDP traffic to flow
outside the VPN, his name lookups, even to 8.8.8.8, would still have
been exposed for the uni's scanners to see.

> How are the bans implemented? He said his ethernet connection died
> gradually at university, at first some days it was OK and other days
> it was bad, then packet losses started going up until at one stage it
> reached 80%. Persumably the bans would be no internet access at all
> rather than slow/sporadic.

Another question to ask the uni. In most instances they are "you are
offline now" style bans. That does not mean the uni is not doing
something different.

[The Natural Philosopher]

Well I haven't done a raspian download recently, but all my Mint
downloads come in as fast as my fibre will fetch them


--
A lie can travel halfway around the world while the truth is putting on
its shoes.

[Rich]

John Friday <john.2...@gmail.com> wrote:
> The torrent client was transmission-gtk which AFAIK does not have any
> ratware in it.

Would not make any difference to the uni. admins. If they classify
bittorrent traffic as "malicious" it won't matter which client, nor
what is actually being shared. And, sadly, for many 'corporate'
networks (and a uni network will share more in common with a
'corporate' one than a home network) bittorrent traffic is simply
classified as "malicious".

> It also doesn't explain the other issue the network sysadmins raised,
> which was "malicious traffic" between his computer and another
> computer on the university network. Although rich suggested that
> another bittorent client could have been installed on the "victim"
> computer on the university network.

If he was running a torrent client on the uni network, then it is
very possible this 'traffic' was because the other user was also
running a torrent client. The other user likely also found themselves
in the same tarpit your friend is presently in.

>> Which may or may not have had some ratware profile
>>
>> With a normal http or ftp download able to fully occupy my considerable
>> bandwidth I dont understand why anyone would use a torrent instead.
>
> Torrents can often be faster than http/ftp download because you're
> downloading from many peers rather than just one server.

My experiene has been that they are only faster on the few, very
popular, torrents. Anything outside of the 'popular' is massively
slower. But sometimes a torrent is the only access to some shared
file, so one has to endure the slowness.

[John Friday]

On Tuesday, August 30, 2022 at 9:25:27 PM UTC+3, Rich wrote:
> John Friday <john.2...@gmail.com> wrote:
> > On Tuesday, August 30, 2022 at 8:35:21 PM UTC+3, Rich wrote:
> >> And your statement implies a human watching a network trace log and
> >> deciding to "ban-list" someone. That is not how these occur in uni.
> >> level networks. There are automated traffic monitoring systems that
> >> watch, decide, and act, without human intervention. IT staff likely
> >> knew nothing had occurred until his question to them prompted them
> >> to look up his MAC in the scan-and-ban system, whereupon they found
> >> the scan-and-ban system had banned him.
> >
> > It is pretty unfortunate, we hadn't realized that using Bittorrent to
> > download isos of free-to-distribute material can result in a ban and
> > potential disciplinary action.
> Sadly such is true. Most network admins see bittorrent as all bad
> (yes, they are applying the "one rotten apple spoils the whole basket"
> analysis, except in this case it is more like 11 out of 12 rotten
> apples).
> > The whole point of downloading Linux/Raspbian ISOs via Bittorrent is
> > to download it faster, share upload capacity with other users and
> > reduce the burden on Debian and the Raspberry Pi foundation servers.
> Correct. But that does not change the fact that bittorrent traffic is
> seen as a "shoot first, ask questions later" protocol.

Out of curiosity, can "better security" also be a plus for downloading isos via torrent rather than http/ftp?

The reason being, if a user is redirected to the fake website (complete with fake file checksums) they can download a tainted ISO from the same corrupted source. But it is a bit more troublesome for a malicious actor to set up a fake website with a fake checksum, and then have many different torrent seeds also spreading the same tainted ISO without anyone noticing.

> > How do these automated traffic monitoring systems work?
> Look up "Deep Packet Inspection" https://en.wikipedia.org/wiki/Deep_packet_inspection

I did, thank you. But after reading the article, I understand that encrypted tunnels via VPNs can circumvent DPI. And his transmission-gtk client is set up to require encryption as well, so there are two layers of encryption here.

> That will explain better than any summary I might add here.
> > He was using a commercial VPN to VPN out of the university network
> > and his DNS servers are 8.8.8.8, so presumably the university's
> > sysadmins can not see his DNS requests?
> Did his laptop do DHCP for the uni. network? One of the items that
> returns in the DHCP setup is "name servers" to use for the DHCP IP. If
> he did not remember reset his name servers to 8.8.8.8 after obtaining
> an IP on the uni network, then he was possibly using the uni's
> nameservers (depending on what the VPN does). And, if he did not know
> that bittorrent was seen as "bad", he likely also did not know that
> DHCP setup would change his nameservers without extra effort by him to
> stop such.

He set /etc/resolv.conf to have the immutable attribute. I know because part of the troubleshooting we did on his laptop when it had connectivity problems before IT security came down on him was to try to use the university's DNS servers, and I couldn't delete or edit the file even as root :-)

> As for "commercial VPN" -- depending upon what traffic the "commercial
> VPN" captured, the uni might still have seen the name lookups. I.e.,
> if the VPN only captured TCP traffic, but left UDP traffic to flow
> outside the VPN, his name lookups, even to 8.8.8.8, would still have
> been exposed for the uni's scanners to see.

His setup was openvpn via UDP to a commercial VPN provider.

I understand that TCP traffic is checked for errors while UDP is not. But how does this fit with what you're saying? I don't get it.

How are packet headers encrypted for VPN-based traffic? Would the network sysadmins only see the IP address of the VPN, while the rest of the packet is encrypted?

[Rich]

John Friday <john.2...@gmail.com> wrote:
> On Tuesday, August 30, 2022 at 9:25:27 PM UTC+3, Rich wrote:
>> Correct. But that does not change the fact that bittorrent traffic
>> is seen as a "shoot first, ask questions later" protocol.
>
> Out of curiosity, can "better security" also be a plus for
> downloading isos via torrent rather than http/ftp?

Assuming you obtained the torrent metadata from a reliable source, yes.

From the context of the uni admins, they probably define it as
"malicious" with no way to argue a legimate use.

>> > How do these automated traffic monitoring systems work?
>> Look up "Deep Packet Inspection" https://en.wikipedia.org/wiki/Deep_packet_inspection
>
> I did, thank you. But after reading the article, I understand that
> encrypted tunnels via VPNs can circumvent DPI. And his
> transmission-gtk client is set up to require encryption as well, so
> there are two layers of encryption here.

Which, in theory, should have hid the activity (given the details below
of OpenVPN) such that all the admins saw was a lot of traffic to/from
the VPN host IP address. The fact that the admins know about "lots of
connections to IP's in Europe" you mentioned earlier, it would seem
that his torrent client was not actually getting tunneled over the VPN.

One way that could happen is if he left the torrent client running, put
the laptop to sleep, connected to the uni network, and then restarted
the VPN. During the time between "connected to uni" and "starting up
VPN" all the torrent traffic would have been out in the open. And if
the uni is running scanners, that brief few seconds is all it would
have taken to get 'caught' by the scanners.

>> Did his laptop do DHCP for the uni. network? One of the items that
>> returns in the DHCP setup is "name servers" to use for the DHCP IP. If
>> he did not remember reset his name servers to 8.8.8.8 after obtaining
>> an IP on the uni network, then he was possibly using the uni's
>> nameservers (depending on what the VPN does). And, if he did not know
>> that bittorrent was seen as "bad", he likely also did not know that
>> DHCP setup would change his nameservers without extra effort by him to
>> stop such.
>
> He set /etc/resolv.conf to have the immutable attribute. I know
> because part of the troubleshooting we did on his laptop when it had
> connectivity problems before IT security came down on him was to try
> to use the university's DNS servers, and I couldn't delete or edit
> the file even as root :-)

Hmm, he knew enough to set the immutable attribute on /etc/resolv.conf,
but was unaware that it has been common for years (practically since
the invention of bittorrent) that many "corporate style" network setups
define bittorrent traffic as "malicious" traffic without further
thought.

>> As for "commercial VPN" -- depending upon what traffic the "commercial
>> VPN" captured, the uni might still have seen the name lookups. I.e.,
>> if the VPN only captured TCP traffic, but left UDP traffic to flow
>> outside the VPN, his name lookups, even to 8.8.8.8, would still have
>> been exposed for the uni's scanners to see.
>
> His setup was openvpn via UDP to a commercial VPN provider.
>
> I understand that TCP traffic is checked for errors while UDP is not.
> But how does this fit with what you're saying? I don't get it.

Since I had no knowledge of what VPN he was using I had no way to say
what it was doing. "commerical vpn" can encompass some 'app' that acts
more as a TCP proxy than a true VPN.

> How are packet headers encrypted for VPN-based traffic?

Assuming a usual OpenVPN setup, all network data should be tunnled
through the VPN, so the uni would only see a lot of data to/from the IP
of the VPN host.

As I said above, the fact that the uni made some comment about "lots of
connects to IP's in europe" means that at some point in time, the
torrent traffic was not actually being tunnled through the VPN.

> Would the network sysadmins only see the IP address of the VPN, while
> the rest of the packet is encrypted?

Unless his 'commercial client' setup OpenVPN with a really weak cipher,
the uni admins should not have been able to see anything, other than "a
lot of data to/from IP X". The fact that they made the "lots of IP's
in europe" comment means the torrent traffic did not get tunnled for
some period of time.

[Robert Heller]

Some people *still* have crappy internet service, esp. in the USA (really --
the USA continues to have poor internet service in many places).

[Bobbie Sellers]

And unless you suffer horrible poverty you have to spend a good deal of
money in the USA to have Internet service. People in dire poverty may
be elible for a low speed discounted service. That will not be great
for downloading Linux iso files but may be ok for limited email and
browsing.

bliss in San Francisco, CA. PCLinuxPS, KDE 5, Linux 5.19.4

The rule is perfect: in all matters of opinion our adversaries are
insane. (Mark Twain)

--
bliss dash SF 4 ever at dslextreme dot com

[25B.Z969]

On 8/30/22 8:10 AM, John Friday wrote:
> A friend of mine has a Linux laptop that he occasionally brings into university.
>
> After experiencing some network issues (lost packets, slow internet) he contacted his university's IT department, who then asked him for his computers host name, MAC address, IP address when connected and ethernet port socket number in the building.
>
> He provided all of this, and apparently a computer matching the details he provided was blacklisted on the university network for unusual network traffic and attempting to hack* another user's computer. *Defined as "malicious network traffic" from his computer to another user.
>
> The problem was resolved with my friend being told not to plug his Linux laptop into the university network again, and instead use a Windows machine supplied by and administered by the IT department.

Super-easy to change the broadcast MAC address in Linux.
A little more work and you can have it report that it's
a Win-11 laptop.

He should try that just for fun.

Oh, and M$ probably donates lots of stuff and $$$ to
the university. Apple too abd even though its os is
now BSD-based and BSD is really close to Linux I'll
bet they aren't blocking Apple products.

[John Friday]

On Tuesday, August 30, 2022 at 10:49:40 PM UTC+3, Rich wrote:

> From the context of the uni admins, they probably define it as
> "malicious" with no way to argue a legimate use.

Yeah let's see how things unfold. For now he needs to discuss with his PhD supervisor if he should push back against IT security. The reason being:
1. No actual evidence was presented of what his computer allegedly did to another university member. For all we know both their computers could have been sharing a P2P connection of Debian, for example.
2. No actual evidence of his computer connecting to "hundreds of European IPs" was presented.
3. Checks on his laptop (thanks comp.os.linux.misc) revealed nothing untoward.
4. As we know security people of all types never exaggerate problems.
5. He wants to continue using his own self-administered Linux laptop on the university network, and not some Windows box administered by third parties (plural).

BTW the first question the head of IT security at the university asked him was, is he the administrator of the laptop or is it shared with someone else. Windows sysadmins are mistaken if they think they are the only administrators of a computer when they install commercial antivirus/firewall software - they are shared admins with Microsoft and the antivirus companies.

Incidentally, the head of IT security at the university suggested to my friend to install Microsoft Defender for Linux. Does anyone here think it is a good idea? Ask Microsoft to do a security audit of Linux - because clearly Microsoft has the security nailed down.

> >> > How do these automated traffic monitoring systems work?
> >> Look up "Deep Packet Inspection" https://en.wikipedia.org/wiki/Deep_packet_inspection
> >
> > I did, thank you. But after reading the article, I understand that
> > encrypted tunnels via VPNs can circumvent DPI. And his
> > transmission-gtk client is set up to require encryption as well, so
> > there are two layers of encryption here.
> Which, in theory, should have hid the activity (given the details below
> of OpenVPN) such that all the admins saw was a lot of traffic to/from
> the VPN host IP address. The fact that the admins know about "lots of
> connections to IP's in Europe" you mentioned earlier, it would seem
> that his torrent client was not actually getting tunneled over the VPN.

Or it is possible that the security people were bullshitting to scare a confession out of him.

> One way that could happen is if he left the torrent client running, put
> the laptop to sleep, connected to the uni network, and then restarted
> the VPN. During the time between "connected to uni" and "starting up
> VPN" all the torrent traffic would have been out in the open. And if
> the uni is running scanners, that brief few seconds is all it would
> have taken to get 'caught' by the scanners.

Yeah agreed.

> Hmm, he knew enough to set the immutable attribute on /etc/resolv.conf,
> but was unaware that it has been common for years (practically since
> the invention of bittorrent) that many "corporate style" network setups
> define bittorrent traffic as "malicious" traffic without further
> thought.

The immutable flag on resolv.conf was part of the Debian wiki on resolv.conf
https://wiki.debian.org/resolv.conf

> Since I had no knowledge of what VPN he was using I had no way to say
> what it was doing. "commerical vpn" can encompass some 'app' that acts
> more as a TCP proxy than a true VPN.

His VPN I believe was NordVPN.

> > How are packet headers encrypted for VPN-based traffic?
> Assuming a usual OpenVPN setup, all network data should be tunnled
> through the VPN, so the uni would only see a lot of data to/from the IP
> of the VPN host.
>
> As I said above, the fact that the uni made some comment about "lots of
> connects to IP's in europe" means that at some point in time, the
> torrent traffic was not actually being tunnled through the VPN.

Without seeing the logs, I am more inclined to believe that what triggered the IT security people was the volume of data downloaded, rather than the number of connections. The reason being the volume of data downloaded is a sure thing, while the number of connections is dependent on his VPN connection failing while his torrent client was open. Are network sysadmins able to track the volume of up/down traffic per MAC address and per wall jack?

As mentioned somewhere else, part of his and my hobbies are tinkering around with Single Board Computers (SBCs) for everything from watering the plants in our shared apartment, voice activated door locks, machine vision, etc.

We ordered a bunch of SBCs from China and Korea, they all arrived over the last month and him with his fast university ethernet connection was in charge of downloading all the ISOs for us to try. For example the Armbian downloads have different desktop managers for people to try out so he downloaded most of them via Torrents tunneled through openvpn.

[Tauno Voipio]

The problem with torrents is in the very nature of the torrents. The
user has little, if any control what is sent via the torrent.

I guess that the torrents are the reason for banning his computer. There
is no sense to change to Microsoft and run torrents again.

The simple safety rule here is: DO NOT USE TORRENTS AT ALL.

--

-TV

[Anssi Saari]

John Friday <john.2...@gmail.com> writes:

> His VPN I believe was NordVPN.

I don't know NordVPN but commercial VPNs often have at least dozens of
endpoints in different countries around the world and they have
proprietary clients that have some way of figuring out which is closest
or fastest. Looks like NordVPN advertizes "Choose from NordVPN’s 5536
ultra-fast servers in 59 countries all around the world."

Which could account for lots of connections or at least pings, if done
stupidly. Connecting to European IP addresses only seems suspect whether
this was a VPN client or bittorrent.

But if he uses the bog standard openvpn client then it's more likely
bittorrent didn't use his VPN because it wasn't running at the
time. Which could be easily fixed by configuring the bittorrent client
to use the VPN interface only.

[The Natural Philosopher]

On 30/08/2022 20:49, Rich wrote:
> many "corporate style" network setups
> define bittorrent traffic as "malicious" traffic without further
> thought.

And rightly to. It is the default method of obtaining all manner of
illicit material. As well as viruss and malware

Corporations can be sued and have more cash than individuals.

Allowing users to randomly download anything via known 'grey' protocols
and install software on machines inside your firewall, is probably
something it is just easiest to say 'no' to.



--
When plunder becomes a way of life for a group of men in a society, over
the course of time they create for themselves a legal system that
authorizes it and a moral code that glorifies it.

Frédéric Bastiat

[The Natural Philosopher]

Then they need torrent even less, as they will be able to fully saturate
a dial up link at far far lower bit rates




--
No Apple devices were knowingly used in the preparation of this post.

[Rich]

John Friday <john.2...@gmail.com> wrote:
> On Tuesday, August 30, 2022 at 10:49:40 PM UTC+3, Rich wrote:
>
>> From the context of the uni admins, they probably define it as
>> "malicious" with no way to argue a legimate use.
>
> Yeah let's see how things unfold. For now he needs to discuss with
> his PhD supervisor if he should push back against IT security. The
> reason being:

That will be a decision that we here in the group cannot make for him.

> 1. No actual evidence was presented of what his computer allegedly
> did to another university member. For all we know both their
> computers could have been sharing a P2P connection of Debian, for
> example.
> 2. No actual evidence of his computer connecting to "hundreds of
> European IPs" was presented.

Sadly, this is all too often the case. Network security folks often
operate from a standpoint of judge-jury-executioner with no further
recourse for the accused.

> 4. As we know security people of all types never exaggerate
> problems.

They almost always take a "shoot first -- ask questions later" stance.

> BTW the first question the head of IT security at the university
> asked him was, is he the administrator of the laptop or is it shared
> with someone else. Windows sysadmins are mistaken if they think they
> are the only administrators of a computer when they install
> commercial antivirus/firewall software - they are shared admins with
> Microsoft and the antivirus companies.

Windows users are routinely missinformed or lack understanding. Modern
windows installs are no longer 'their computer' as unless they really
try hard, they allow MS to modify the system at MS's whims.

> Incidentally, the head of IT security at the university suggested to
> my friend to install Microsoft Defender for Linux. Does anyone here
> think it is a good idea? Ask Microsoft to do a security audit of
> Linux - because clearly Microsoft has the security nailed down.

Wolf guarding the sheep house there.

>> > I did, thank you. But after reading the article, I understand that
>> > encrypted tunnels via VPNs can circumvent DPI. And his
>> > transmission-gtk client is set up to require encryption as well, so
>> > there are two layers of encryption here.
>> Which, in theory, should have hid the activity (given the details below
>> of OpenVPN) such that all the admins saw was a lot of traffic to/from
>> the VPN host IP address. The fact that the admins know about "lots of
>> connections to IP's in Europe" you mentioned earlier, it would seem
>> that his torrent client was not actually getting tunneled over the VPN.
>
> Or it is possible that the security people were bullshitting to scare
> a confession out of him.

Just about anything is possible. The real question is how 'probable'
were they to be bullshitting. Most of them have no 'dog in the fight'
and also often operate from a 'what we say goes' (as their managers
often have not the slightest clue). So they usually have no need to
'bullshit' a confession out of anyone. Therefore I'd give a very low
probability score to "they are bullshitting".

>> One way that could happen is if he left the torrent client running, put
>> the laptop to sleep, connected to the uni network, and then restarted
>> the VPN. During the time between "connected to uni" and "starting up
>> VPN" all the torrent traffic would have been out in the open. And if
>> the uni is running scanners, that brief few seconds is all it would
>> have taken to get 'caught' by the scanners.
>
> Yeah agreed.

Also, keep in mind that with something like this, that he has to be
*perfect* in his op-sec, every single time he connects to the uni
network. The uni network, however, only has to capture his system in
one of their automated scans once for something to happen.

Given the senario as we have now been told, the most probable is he
forgot to bring up the VPN one day, or the VPN went down without his
knowledge and all traffic after it went down was "out in the clear".

>> Hmm, he knew enough to set the immutable attribute on
>> /etc/resolv.conf, but was unaware that it has been common for years
>> (practically since the invention of bittorrent) that many "corporate
>> style" network setups define bittorrent traffic as "malicious"
>> traffic without further thought.
>
> The immutable flag on resolv.conf was part of the Debian wiki on
> resolv.conf https://wiki.debian.org/resolv.conf

Ah, slackoverflow style security. On that explains why he was unaware
that the uni admins would likely classify any bittorrent traffic as
bad.

>> > How are packet headers encrypted for VPN-based traffic?
>> Assuming a usual OpenVPN setup, all network data should be tunnled
>> through the VPN, so the uni would only see a lot of data to/from the
>> IP of the VPN host.
>>
>> As I said above, the fact that the uni made some comment about "lots
>> of connects to IP's in europe" means that at some point in time, the
>> torrent traffic was not actually being tunnled through the VPN.
>
> Without seeing the logs, I am more inclined to believe that what
> triggered the IT security people was the volume of data downloaded,
> rather than the number of connections.

I'm inclined to believe that the uni network security admins are simply
reading what they see on the report generated by the scanning system.
As I said above, they have no 'dog in the fight' so it is unlikely
(but, yes, not impossible) for them to be extrapolating.

> The reason being the volume of data downloaded is a sure thing, while
> the number of connections is dependent on his VPN connection failing
> while his torrent client was open.

Yes, but for him to remain safe, he has to be *perfect* in his op-sec,
every single time he connects the laptop. The uni only has to have him
make a mistake once (forget to bring up the vpn -- have the vpn go down
unnoticed) and the scanners have 'caught him in the act'.

> Are network sysadmins able to track the volume of up/down traffic per
> MAC address and per wall jack?

With commerical grade equipment, yes. They can tell you the volume,
type, and with DPI even the TCP port to which each byte was
sent/received (if they decide to turn on logging of such info).

> As mentioned somewhere else, part of his and my hobbies are tinkering
> around with Single Board Computers (SBCs) for everything from
> watering the plants in our shared apartment, voice activated door
> locks, machine vision, etc.

I missed this bit somewhere else in the thread.

> We ordered a bunch of SBCs from China and Korea, they all arrived
> over the last month and him with his fast university ethernet
> connection was in charge of downloading all the ISOs for us to try.
> For example the Armbian downloads have different desktop managers for
> people to try out so he downloaded most of them via Torrents tunneled
> through openvpn.

Ah, so now we know why he was downloading the torrents.

Ok, here's my take, given what has finally been revealed.

1) Your friend at Uni has a Linux laptop, but he is not very well versed
in adversarial op-sec, nor very well versed in Linux admin.

2) He was given the task of downloading some number of torrents of linux
distros for SBC's due to his fast network connection at uni.

3) Because of #1, he made some all too common op-sec mistakes in his
attempts to 'hide' from the uni network scanners while performing #2.

4) As a result of the all too common op-sec mistakes of #3, the uni
scanners caught him torrenting "in the open" and now he has to deal
with cleaning up the resulting mess.


As an example of #1 -- did he setup his linux firewall rules such that
were the VPN to go down while torrenting that the torrent client would
become isolated (i.e., from the torrent clients viewpoint, the whole
network goes down when the VPN goes down)? My guess, given the fact
that he 'stackoverflowed' the immutable /etc/resolv.conf setting is:
no, he did not do so. That is a classic op-sec mistake when torrenting
over a VPN. Forgetting that should the VPN go down, the torrent
traffic will soon start going out 'in the clear'.

[Rich]

The Natural Philosopher <t...@invalid.invalid> wrote:

> On 30/08/2022 20:49, Rich wrote:
>> many "corporate style" network setups define bittorrent traffic as
>> "malicious" traffic without further thought.
>
> And rightly to. It is the default method of obtaining all manner of
> illicit material. As well as viruss and malware
>
> Corporations can be sued and have more cash than individuals.

For what it is worth, I was merely stating a fact. They (corporations)
do often have reasonable reasons for why they setup some of the rules
they setup, once one can see behind the curtain to be aware of the
inputs to the rules making.

> Allowing users to randomly download anything via known 'grey'
> protocols and install software on machines inside your firewall, is
> probably something it is just easiest to say 'no' to.

Agreed. Much easier to just say no than deal with all the messes from
those who did not know what they were doing. And the "did not know
what they were doing" population is about 95+% of the total user
population.

[The Natural Philosopher]

I never found anyone who knew they were installing a virus onto a
network, did you?

If you are piggy backing onto someone else's network, play by their rules.

Having heard more of the story I am 100% with the university. I wouldn't
allow bit torrents on any network I ran either, unless it was my own.,


--
“The fundamental cause of the trouble in the modern world today is that
the stupid are cocksure while the intelligent are full of doubt."

- Bertrand Russell

[John Friday]

Just wanted to update you all about a dramatic turn of events.

Although the IT security people considered the matter closed, as a personal request my friend asked the departmental IT manager for the logs of the event.

After getting it, it turns out that the MAC address of the attacker was completely different to my friend's MAC address. As the first three octets of a MAC address identifies the manufacturer of the computer (different manufacturer to my friend's laptop entirely), a short tour of the building identified the computer responsible for the heavy traffic and attempted attack on another computer in the faculty. It was a *new* Windows 11 PC with Microsoft Defender up to date and the latest scan didn't pick up anything.

It would seem that my friend was accused of being the owner of the infected computer because his IP address matched that of the attacker. The IT security staff didn't scroll down a few lines to check the MAC address matched as well. Apparently the IT security staff had forgotten about DHCP occasionally assigning the same IP address to different MAC addresses if only one computer is connected to the network.

Naturally it is a relief for my friend that his laptop and himself have been cleared of any wrongdoing. He wasn't even 100% sure he downloaded the ISOs as torrents on the university's network anymore, and did not just click on the links to download the ISOs from the official websites. Just confronted by people in authority with evidence he didn't see and they didn't check, accusing him of making so many connections, he naively admitted "It must be torrents"

So the morals of the story here are:
1. Don't assume competence of IT security staff
2. Don't accuse someone until you've checked all the evidence
3. Don't complete and investigation until you've checked the evidence right in front of you
4. An accused person has a right to inspect the evidence
5. If accused, don't be so quick to admit guilt or justify an accusation from people in authority, with a confession
6. Don't be so quick to accuse a foreigner of wrongdoing (my friend is a foreigner)

Too bad I can't change the title of the post to "...from a Windows computer"!

Ironically, an appropriate quote: