Have a question or want to start a discussion? Post it! No Registration Necessary. 
Now with pictures!
Threaded View
Subject
- Posted on
- Santa Claus
May 10, 2008, 11:07 pm
Reply
Save
Print
Dear NG,
Subject: Newbie with ssh-server running... Hacking attempts against
me... I hope this question is appropriate - My log says:
----
May 10 22:21:20 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:20 Apple sshd[1112]: Failed password for invalid user root
from 140.134.28.184 port 56234 ssh2
May 10 22:21:23 Apple sshd[1122]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:23 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:23 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:24 Apple sshd[1122]: Failed password for invalid user root
from 140.134.28.184 port 56582 ssh2
May 10 22:21:27 Apple sshd[1128]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:27 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:27 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:27 Apple sshd[1128]: Failed password for invalid user root
from 140.134.28.184 port 56729 ssh2
May 10 22:21:30 Apple sshd[1131]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:33 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:33 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:33 Apple sshd[1131]: Failed password for invalid user root
from 140.134.28.184 port 56853 ssh2
May 10 22:21:36 Apple sshd[1134]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:44 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:44 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:44 Apple sshd[1134]: Failed password for invalid user root
from 140.134.28.184 port 57155 ssh2
----
I have a perl-program called "grok" which I use to run a little
python-script, everytime anyone tries to login with a wrong password (it
keeps looking in the log-file for a pattern saying invalid password)...
I find it very entertaining to be able to watch when somebody tries to
hack me. This guy: 140.134.28.184 seem to be very aggressive. I guess it
must be some brute-force thing he's using because now I just saw a lot
of warning-dialogue-boxes popup.
Newbie question: Any chance I can see which passwords he's trying to use?
Newbie question: Why is the hacking attempts originating from different
ports? Starting from 56234 and ending around 56853 according to the log...
I already disabled root login.
Newbie question: Are all hackers so stupid they always try to login my
root account so they never try to guess a username?
Once I'm done entertaining myself, I'm going to make it more secure by
using a non-standard ssh-port.
I think I have something called PAM running.
Newbie question: Is that the thing that makes it slower and slower to
login with wrong passwords with ssh?
Anything else a newbie server admin should be aware of? I believe trying
to hack me is a crime, but I guess nobody tries to report such things to
the local police?
** Posted from http://www.teranews.com **
Subject: Newbie with ssh-server running... Hacking attempts against
me... I hope this question is appropriate - My log says:
----
May 10 22:21:20 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:20 Apple sshd[1112]: Failed password for invalid user root
from 140.134.28.184 port 56234 ssh2
May 10 22:21:23 Apple sshd[1122]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:23 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:23 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:24 Apple sshd[1122]: Failed password for invalid user root
from 140.134.28.184 port 56582 ssh2
May 10 22:21:27 Apple sshd[1128]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:27 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:27 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:27 Apple sshd[1128]: Failed password for invalid user root
from 140.134.28.184 port 56729 ssh2
May 10 22:21:30 Apple sshd[1131]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:33 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:33 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:33 Apple sshd[1131]: Failed password for invalid user root
from 140.134.28.184 port 56853 ssh2
May 10 22:21:36 Apple sshd[1134]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:44 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:44 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:44 Apple sshd[1134]: Failed password for invalid user root
from 140.134.28.184 port 57155 ssh2
----
I have a perl-program called "grok" which I use to run a little
python-script, everytime anyone tries to login with a wrong password (it
keeps looking in the log-file for a pattern saying invalid password)...
I find it very entertaining to be able to watch when somebody tries to
hack me. This guy: 140.134.28.184 seem to be very aggressive. I guess it
must be some brute-force thing he's using because now I just saw a lot
of warning-dialogue-boxes popup.
Newbie question: Any chance I can see which passwords he's trying to use?
Newbie question: Why is the hacking attempts originating from different
ports? Starting from 56234 and ending around 56853 according to the log...
I already disabled root login.
Newbie question: Are all hackers so stupid they always try to login my
root account so they never try to guess a username?
Once I'm done entertaining myself, I'm going to make it more secure by
using a non-standard ssh-port.
I think I have something called PAM running.
Newbie question: Is that the thing that makes it slower and slower to
login with wrong passwords with ssh?
Anything else a newbie server admin should be aware of? I believe trying
to hack me is a crime, but I guess nobody tries to report such things to
the local police?
** Posted from http://www.teranews.com **
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
Look at it from the other side of the fence. The cracker wants to gain
root as quickly as possible so that he can clear his tracks before anyone
notices his intrusion.
If he goes after a user account first, unless the admin was careless, the
user accounts will be restricted. The cracker still has to find an exploit
to escalate his privileges from there. More time spent, and more chance of
being discovered.
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
JD wrote:
It's just impossible for him to login with root here, so I'm laughing a
bit over it...
Let's say he got in: How would he clear his tracks?
1) Delete the log file?
2) Edit the log file manually?
3) Something else clever?
He'll get nowhere with my server, trying to hack root...
** Posted from http://www.teranews.com **
It's just impossible for him to login with root here, so I'm laughing a
bit over it...
Let's say he got in: How would he clear his tracks?
1) Delete the log file?
2) Edit the log file manually?
3) Something else clever?
He'll get nowhere with my server, trying to hack root...
** Posted from http://www.teranews.com **
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
Even if he's not completely successful, the time wasted tracking him back and
time offline while you repair what he damaged can be extremely expensive.
dd if=/dev/zero of=/dev/hda &
dd if=/dev/zero of=/dev/sda &
find /var -type f -exec dd if=/dev/zero of=$name &
Etc.
Can you log in as root, remotely? Can he steal your passwords or passkeys? Are
you *SURE* your sshd or httpd or SNMP are all really securfe?
Have you ever read up on 'zero-day' exploits, and cracking kits?
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
Nico Kadel-Garcia wrote:
-snip-
It's just a home computer server. I don't have company secrets or so on
it, so I'm just "practicing" and listening to advice from experts...
I think the last line would be the best. I would reinstall my OS on the
computer, if anyone did something like this. But I thought a hacker
would be more clever than you propose:
I would definately figure out that somebody had been on my system if all
files in /var were missing suddenly. And then the hacker couldn't come
back - I thought he would clear his tracks and keep a backdoor open -
how could/would he do something like that?
Thank you.
1) Root login is impossible because I disabled it in sshd_config. But I
guess people can login with user accounts and sudo (they would have to
guess two passwords). Only 1 user account is allowed to login
(AllowedUsers) - and this is myself. Everytime my username logs in, a
python-script is ran that popups a warning on my desktop. So when I'm
sitting in front of my pc I can see hacking attempts in real-time.
When I'm away, I don't see them before I get home (I'm home every
evening at least).
2) I don't know if he can steal my passwords/passkeys. Even if he looked
in my garbage he wouldn't see such things. I don't know if he could
sniff it somehow...
3) I don't have httpd running - only have 1 ssh-server running now (to
practice, and learning how to protect myself - once I'm good at that, I
could perhaps run something more)... I disabled X11-forwarding.
4) SNMP? Never heard of it. Do I have to worry?
Not really. I'm using:
# telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.7
^C^C
Connection closed by foreign host.
So its: OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
Do I have to worry or upgrade? I just saw on openssh.com that there's a
new version: OpenSSH 5.0/5.0p1 released Apr 3, 2008.
I believe(d) that SSH even though it is from 2006, should be pretty
secure? Else I can upgrade in the coming days...
** Posted from http://www.teranews.com **
-snip-
It's just a home computer server. I don't have company secrets or so on
it, so I'm just "practicing" and listening to advice from experts...
I think the last line would be the best. I would reinstall my OS on the
computer, if anyone did something like this. But I thought a hacker
would be more clever than you propose:
I would definately figure out that somebody had been on my system if all
files in /var were missing suddenly. And then the hacker couldn't come
back - I thought he would clear his tracks and keep a backdoor open -
how could/would he do something like that?
Thank you.
1) Root login is impossible because I disabled it in sshd_config. But I
guess people can login with user accounts and sudo (they would have to
guess two passwords). Only 1 user account is allowed to login
(AllowedUsers) - and this is myself. Everytime my username logs in, a
python-script is ran that popups a warning on my desktop. So when I'm
sitting in front of my pc I can see hacking attempts in real-time.
When I'm away, I don't see them before I get home (I'm home every
evening at least).
2) I don't know if he can steal my passwords/passkeys. Even if he looked
in my garbage he wouldn't see such things. I don't know if he could
sniff it somehow...
3) I don't have httpd running - only have 1 ssh-server running now (to
practice, and learning how to protect myself - once I'm good at that, I
could perhaps run something more)... I disabled X11-forwarding.
4) SNMP? Never heard of it. Do I have to worry?
Not really. I'm using:
# telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.7
^C^C
Connection closed by foreign host.
So its: OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
Do I have to worry or upgrade? I just saw on openssh.com that there's a
new version: OpenSSH 5.0/5.0p1 released Apr 3, 2008.
I believe(d) that SSH even though it is from 2006, should be pretty
secure? Else I can upgrade in the coming days...
** Posted from http://www.teranews.com **
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
Santa Claus wrote:
Oh, one could look in /etc/mtab for the list of mounted partitions, and do
'fdisk -l' to look for ones that aren't mounted. But you get the hint. Not all
crackers want to be pleasant and graceful, some of them are quite destructive.
Take a look at the histories of Kevin Mitnick and Robert Morris for the kinds
of damage they did, incidentally, to systems they hacked.
Then you can log in as root, remotely. A cracker might steal or crack user
access, gain local account access this way, and run a local crack. I'm not
saying this is likely against you, you might be cautious: but simply blocking
root in sshd_config isn't enough.
OpenSSH has also had a number of remote exploits over the years: it's a vast
improvement over rsh or telnet, but that doesn't make it complete.
By which point, your disk might be zeroed.
This is where experience and security training helps. Default command-line
Subversion tools, for example, keep passwords in clear-text. So do Japper
servers, and if you're using standard FTP or unencrypted HTTP to provide
account access, well, they can be sniffed.
If you want to learn additional protection techniques, take a look at port
knocking running on a non-standard port, the use of various RSA based security
keys, and other more robust techniques.
Probably not: SNMP is primarily a monitoring technology, used to monitor
network and disk and other system characteristics. Some people use "SNMP
traps" to trigger actions on a server, and that can be fun to configure properly.
You need to stay up to date with patches, not necessarily the primary version.
They started adding the capability for a chroot cage at about 4.7, after years
of people like me lobbying and publishing patches to provide one.
Well, it depends on what you want to do. If you've got people accessing your
site versus 'sftp', or scp with tools like 'WinSCP', you might want to update
to version 5.0 and set up a real chroot cage to keep them away from the rest
of your system.
Oh, one could look in /etc/mtab for the list of mounted partitions, and do
'fdisk -l' to look for ones that aren't mounted. But you get the hint. Not all
crackers want to be pleasant and graceful, some of them are quite destructive.
Take a look at the histories of Kevin Mitnick and Robert Morris for the kinds
of damage they did, incidentally, to systems they hacked.
Then you can log in as root, remotely. A cracker might steal or crack user
access, gain local account access this way, and run a local crack. I'm not
saying this is likely against you, you might be cautious: but simply blocking
root in sshd_config isn't enough.
OpenSSH has also had a number of remote exploits over the years: it's a vast
improvement over rsh or telnet, but that doesn't make it complete.
By which point, your disk might be zeroed.
This is where experience and security training helps. Default command-line
Subversion tools, for example, keep passwords in clear-text. So do Japper
servers, and if you're using standard FTP or unencrypted HTTP to provide
account access, well, they can be sniffed.
If you want to learn additional protection techniques, take a look at port
knocking running on a non-standard port, the use of various RSA based security
keys, and other more robust techniques.
Probably not: SNMP is primarily a monitoring technology, used to monitor
network and disk and other system characteristics. Some people use "SNMP
traps" to trigger actions on a server, and that can be fun to configure properly.
You need to stay up to date with patches, not necessarily the primary version.
They started adding the capability for a chroot cage at about 4.7, after years
of people like me lobbying and publishing patches to provide one.
Well, it depends on what you want to do. If you've got people accessing your
site versus 'sftp', or scp with tools like 'WinSCP', you might want to update
to version 5.0 and set up a real chroot cage to keep them away from the rest
of your system.
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
Santa Claus wrote:
No sweat. If you need to give user file-access and want an easier, more
managable 'chroot' configuration, seriously consider WebDAV over HTTPS. It
handles symlinks, which SCP and sftp do not, and has much better resolution
over upload, download, and filesystem access.
No sweat. If you need to give user file-access and want an easier, more
managable 'chroot' configuration, seriously consider WebDAV over HTTPS. It
handles symlinks, which SCP and sftp do not, and has much better resolution
over upload, download, and filesystem access.
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
On Sun, 11 May 2008 13:40:50 +0200, Santa Claus wrote:
One should not be overconfident. 100% security and usable machine is a bit
of an oxymoron. Nothing is impossible. A better description would be "it
is extremely difficult for him to login in as root". Even an idiot
scriptkiddie may find a crack in your armor if he runs enough scripts for
a long enough time. The weakness he finds may not be your password. It
could be a zero-day exploit in some other program that gives him root.
Any or all of the above. Once he gains root, *nothing* on your server can
be trusted. At that point, if you suspected the intrusion, you can't use
any tools on that machine to verify that an intrusion happened. Any or all
executables may have been altered or replaced with his own modified and
backdoored copies.
See above note about overconfidence. :)
One should not be overconfident. 100% security and usable machine is a bit
of an oxymoron. Nothing is impossible. A better description would be "it
is extremely difficult for him to login in as root". Even an idiot
scriptkiddie may find a crack in your armor if he runs enough scripts for
a long enough time. The weakness he finds may not be your password. It
could be a zero-day exploit in some other program that gives him root.
Any or all of the above. Once he gains root, *nothing* on your server can
be trusted. At that point, if you suspected the intrusion, you can't use
any tools on that machine to verify that an intrusion happened. Any or all
executables may have been altered or replaced with his own modified and
backdoored copies.
See above note about overconfidence. :)
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
It actually isn't, since both can work hand-in-hand.
Unlike in the real work, computers do have strict notions of decisions.
There is no way to bypass an
if (entered_password equals system_password)
return AUTHENTICATION_SUCCESSFUL
else
return ACCESS_DENIED
by pushing it with hammer, while the possibility of resorting to throwing a
nuclear bomb at it. There is no equivalent of "if brute force doesn't solve
to problem, use more brute force", and the space of possible inputs,
outputs, functions and states is enumerable - I gave you a very trivial
example above.
Modern operating system or modern hardware can strictly and fully enforce
every possible policy you implement against programs.
> Even an idiot
Assuming that there is a crack (not so likely for a relative small SSH
server), that the exploit is applicable (if he'd be required to get an
unprivileged logon first and can't get it, the attacks stops instantly),
that unknown parameters can be guessed with sufficient accuracy...
And how should he get the exploit executed on the machine in first place, if
no logon is ever granted to him? This would at least require user
interaction and totally unrelated internet-facing application.
Not true, please take a look on OpenBSD's global security levels. Once
raised, global restrictions apply even to root, and can't be lowered any
more in any way (albeit an attack by the user based upon physical access,
like booting a Live CD to bypass the security restrictions). Most likely
such a configuration could be applied to Windows Vista as well (which makes
great preservations on locking out even the administrator from doing
legitimate things), though this OS has its very own implementation problems
that already make it unsuitable in any security context.
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
On Sun, 11 May 2008 17:14:45 +0200, Sebastian G. wrote:
I was looking at it in terms of MS and the NT C2 security certification.
If no one can access the server, then it is 100% secured. The more ways
there are to access it, the greater the potential for unauthorised access.
Higher security usually translates to less user friendly.
Correct, which is why I stated /may/ find a crack in the armor.
How do exploits get executed then? Otherwise they wouldn't be exploits.
You trust things more than I would if I suspected a successful compromise.
I was looking at it in terms of MS and the NT C2 security certification.
If no one can access the server, then it is 100% secured. The more ways
there are to access it, the greater the potential for unauthorised access.
Higher security usually translates to less user friendly.
Correct, which is why I stated /may/ find a crack in the armor.
How do exploits get executed then? Otherwise they wouldn't be exploits.
You trust things more than I would if I suspected a successful compromise.
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
JD wrote:
Higher security in terms of discretionary access control only translates to
higher isolation of user contexts. Within a user context, any application is
free to do whatever unprivileged action it requires to do its job.
This would limit the attack vector to all protocol action performed before
login. Unless you're too stupid to implement CRC32 correctly, I'd say this
is a non-issue.
The kernel is always the ultimate authority in the system. If it decides
that root isn't the ueber-privileged user any more, it can enforce various
limitations. One is that the kernel's logging facility is completely
isolated, and all privileges that root could use to get access to kernel
memory or compromising the kernel are removed. That is, root might still
overwrite the privileges of any user, can change the system time, can debug
other processes, can read disks in raw mode etc. but he can't load any
drivers, do any kernel debugging, change the RTC time, write to the disk in
raw mode, or bypass access checks on the kernel's files and objects.
Higher security in terms of discretionary access control only translates to
higher isolation of user contexts. Within a user context, any application is
free to do whatever unprivileged action it requires to do its job.
This would limit the attack vector to all protocol action performed before
login. Unless you're too stupid to implement CRC32 correctly, I'd say this
is a non-issue.
The kernel is always the ultimate authority in the system. If it decides
that root isn't the ueber-privileged user any more, it can enforce various
limitations. One is that the kernel's logging facility is completely
isolated, and all privileges that root could use to get access to kernel
memory or compromising the kernel are removed. That is, root might still
overwrite the privileges of any user, can change the system time, can debug
other processes, can read disks in raw mode etc. but he can't load any
drivers, do any kernel debugging, change the RTC time, write to the disk in
raw mode, or bypass access checks on the kernel's files and objects.
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
JD wrote:
I didn't claim that this model or approach is perfect or even a good idea.
But it's a non-theoretical productive OS where in a certain configuration
there simply is no ultimately powerful principal, and root is merely a
normal user with some privileges to manage non-system stuff.
I didn't claim that this model or approach is perfect or even a good idea.
But it's a non-theoretical productive OS where in a certain configuration
there simply is no ultimately powerful principal, and root is merely a
normal user with some privileges to manage non-system stuff.
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
Sebastian G. wrote:
>
Oh. Oh, my. You don't get out much, do you?
As shown above. Given the complexity of many contemporary services, and the
ease of making a security mistake in supporting complex new services, such a
claim is not founded on experience or in fact.
Well, a small and lightly used SSH server, sure. But what about your
passwords? What about remote keystroke loggers on whatever machine you connect
from? What about the rare, but historically problematic, exploits of unpatched
OpenSSH?
See above.
Similar levels of control are possible with SELinux. But have you actually
carefully gone through and done this?
If he has root, he can usually write directly to disk. This is difficult to
prevent. OpenBSD's history of high levels of internal security are good, but
their history of accepting community submitted patches is not, nor is Theo de
Raadt known to play that well with others. It leads to potential weaknesses:
if you need to run a service that is not integral to OpenBSD (such as
Subversion), you're at the mercy of the other, less security minded developers.
>
Oh. Oh, my. You don't get out much, do you?
As shown above. Given the complexity of many contemporary services, and the
ease of making a security mistake in supporting complex new services, such a
claim is not founded on experience or in fact.
Well, a small and lightly used SSH server, sure. But what about your
passwords? What about remote keystroke loggers on whatever machine you connect
from? What about the rare, but historically problematic, exploits of unpatched
OpenSSH?
See above.
Similar levels of control are possible with SELinux. But have you actually
carefully gone through and done this?
If he has root, he can usually write directly to disk. This is difficult to
prevent. OpenBSD's history of high levels of internal security are good, but
their history of accepting community submitted patches is not, nor is Theo de
Raadt known to play that well with others. It leads to potential weaknesses:
if you need to run a service that is not integral to OpenBSD (such as
Subversion), you're at the mercy of the other, less security minded developers.
Re: Subject: Newbie with ssh-server running... Hacking attempts against me...
Without intending to be rude, the answer is because "that's how TCP/IP
works" -- I'll try to explain, although I may glaze over a few technical
details to make the explanation more understandable.
Every TCP connection needs a unique combination of
srcIP&dstIP&srcPORT&dstPORT, otherwise it's not possible to determine
which packet is associated with a given connection.
With most OSes, srcPORTs are not reused at all until a previous
connection has ended (plus a wait period)
In this particular case, since the srcIP&dstIP&dstPORT are fixed,
srcPORT must be rotated.
This all happens behind the scenes -- Try opening two SSH connections
from another machine into the server and take a look at the source
ports.
Virtually all *nix boxes have a "root" account, and it also happens to
have the permissions that the attacker wants. In other words, they're
picking low hanging fruit.
Security by obscurity. Fun.
That isn't to say that changing the port is a bad idea, but it just
makes you marginally less likely to get hit by a script kiddy.
You could report it. On a good day, you won't even get laughed at,
although filing the report will be the extent of the activity launched.
In other words, don't bother.
Site Timeline
- » Defense against nmap tcp synchronise scans
- — Next thread in » Networking Firewalls
-
- » Multiple Subnets with Sonicwall
- — Previous thread in » Networking Firewalls
-
- » coronavirus COVID-19
- — Newest thread in » Networking Firewalls
-
- » The Man From A.S.S.
- — The site's Newest Thread. Posted in » CCTV, Alarms and other Physical Security
-
XML Sitemap