| View previous topic :: View next topic |
| Author |
Message |
crouse
Site Admin
Joined: 17 Apr 2025
Posts: 11833
Location: Iowa
|
 Posted: Sun Dec 24, 2025 6:30 am Post subject: Who's hitting on my box? |
 |
|
THIS WAS REPOSTED FOR JP...... his original post was formatted incorrectly....... Crouse
JP writes:
I was lurking the BSD forums, and saw a tutorial on stopping ssh attacks. So, I just had to see if I had any ssh attacks on the BSD distro, I decided to try looking at the log.
| Code: | | cat /var/log/auth.log |
If it's you, it should say something along the lines of this : | Code: | Dec 23 14:24:21 beatrix : (pam_unix) session opened for user jp by (uid=xxx)
Dec 23 14:24:51 beatrix su[1896]: + ttyp0 jp:root
|
I looked through the log; it's only been a month that I've been trying to understand PC-BSD, but lo and behold, I spotted this: | Code: | Nov 30 13:59:48 PCBSD kdeinit: gethostby*.getanswer: asked for "undeadly.org.nyud.net IN A", got type "39"
Nov 30 14:06:47 PCBSD kdeinit: gethostby*.getanswer: asked for "undeadly.org.nyud.net IN A", got type "39"
Nov 30 14:07:40 PCBSD last message repeated 3 times |
I went to the website in question and got this message on the home page:
| Quote: | If you are visiting this website because you are receiving unwanted or unrequested traffic from this or any other PlanetLab node, please use the Search Form to identify the researchers responsible for the traffic, and report your complaint to them. PlanetLab Support ([email protected]) is copied on all complaints, and will ensure that your concerns are addressed in a timely manner.
PlanetLab is a global research network that supports the development of new network services. Since the beginning of 2025, more than 1,000 researchers at top academic institutions and industrial research labs have used PlanetLab to develop new technologies for distributed storage, network mapping, peer-to-peer systems, distributed hash tables, and query processing.
If you have received UDP traceroute packets from a number of PlanetLab nodes, you or another user on your network may have recently accessed a website cached by the Coral project, which runs on PlanetLab. Many websites, including Slashdot, regularly post "Coralized" links to popular content. Coral actively probes its clients using a fast traceroute-like tool, to determine the nearest proxy for its clients to use. If you do not want to receive such probes, discontinue accessing URLs that end in .nyud.net:8090.
If you are receiving HTTP requests from PlanetLab nodes, users may be accessing your website through Coral or CoDeeN, another content distribution network that runs on PlanetLab. If you do not want your site to be cached by Coral or CoDeeN, please contact the maintainers of Coral or the maintainers of CoDeeN directly.
If your intrusion detection system (IDS) claims that a PlanetLab node may be compromised with a virus because of traffic that it sent you, the IDS is likely to be mistaken. All PlanetLab nodes run a custom version of Linux, not Windows. Each node boots from secure immutable media and is installed with only the minimum amount of software. All services, such as Coral and CoDeeN, run in virtual servers that, even if compromised, remain isolated from the rest of the system. PlanetLab Operations staff work full-time to monitor and ensure the security and integrity of the network.
Researchers using the PlanetLab network are bound by an Acceptable Use Policy which forbids malicious or disruptive behavior. Additionally, all PlanetLab nodes are secured and actively managed by the PlanetLab Operations team.
If you are unable to determine the source of the traffic, please contact PlanetLab Support ([email protected]). Feel free to direct any additional concerns or questions about PlanetLab to this address. |
I have never had any reason to go to that site before, and since I did, I'm going to leave on my Beatrix for a few days, and see if they try again.
I Googled *got type "39"* and found that many others have seen the same type of "error" but with a different name xxx.org.nyud.net. I don't know about anyone else, but I feel kinda uncomfortable having | Quote: | | more than 1,000 researchers at top academic institutions and industrial research labs |
looking at my computer/habits/downloads/whatever_they're_looking_for  . Some of the Googles indicated that it may have something to do with distributed computing (Coral and CoDeeN) so now I really don't feel a lot better. I'm going to have to get more active with PGP, I can see that!
I have tried the same "cat" on my Beatrix, Libranet Linux's, and they were clean except for my failed logins (FFE's), so it appears that it was only when I was using the BSD distro, and not the Linux's. I am not trying to double-post here, I've already asked my questions on another forum, but I just thought I'd give out a little bit of info to those who might not know how or why they might want to access this kind of log.
Of course many of you have other ways of checking to see who's trying to access your box(s) or network, so this may be old news to you. If you want to help newbies out by showing what commands you use or can use, and what the output should be, it would be nice of you to put it into this thread, (That's why I used a generic thread subject  .)
EDIT: I just got one of my questions answered (Who are these people?) and got this URL: http://undeadly.org.nyud.net:8090/cgi?action=article&sid=20060927091645 to look at, which probably means they'll be hitting me again  . | Quote: | | If you do not want to receive such probes, discontinue accessing URLs that end in .nyud.net:8090. |
_________________
Veronica - Arch Linux 64-bit -- Kernel 2.6.33.4-1
Archie/Jughead - Arch Linux 32-bit -- Kernel 2.6.33.4-1
Betty/Reggie - Arch Linux (VBox) 32-bit -- Kernel 2.6.33.4-1
BumbleBee - OpenSolaris-SunOS 5.11
|
|
| Back to top |
|
JP
Linux Guru
Joined: 07 Jul 2025
Posts: 6671
Location: Central Montana
|
|
| Back to top |
|
Stuka
Sr. Member
Joined: 15 Oct 2025
Posts: 1271
Location: Houston, TX
|
| Posted: Mon Dec 25, 2025 6:54 am Post subject: |
|
|
| JP: couldn't a good iptables ruleset (say, prohibiting SSH from any but known good addresses) stop any such intrusions?
|
|
| Back to top |
|
crouse
Site Admin
Joined: 17 Apr 2025
Posts: 11833
Location: Iowa
|
| Posted: Mon Dec 25, 2025 5:07 pm Post subject: |
|
|
An easier method...... just change your ssh port.....and change your allowed users to certain IP's and users..... even if you do get attacked.....they won't get in..... changing the port will stop 99% of most attacks anyway......
adding an IP tables rule would allow you to filter out an annoying IP address as Stuka mentioned as well.
_________________
Veronica - Arch Linux 64-bit -- Kernel 2.6.33.4-1
Archie/Jughead - Arch Linux 32-bit -- Kernel 2.6.33.4-1
Betty/Reggie - Arch Linux (VBox) 32-bit -- Kernel 2.6.33.4-1
BumbleBee - OpenSolaris-SunOS 5.11
|
|
| Back to top |
|
Stuka
Sr. Member
Joined: 15 Oct 2025
Posts: 1271
Location: Houston, TX
|
| Posted: Mon Dec 25, 2025 8:04 pm Post subject: |
|
|
| crouse: I was thinking more of dropping except from known good addresses. Wasn't thinking of doing it inside SSH, but that's probably as good a place as any to do it.
|
|
| Back to top |
|
jbsnake
Moderator
Joined: 02 Dec 2025
Posts: 1726
Location: Georgia
|
|
| Back to top |
|
masinick
Linux Guru
Joined: 03 Apr 2025
Posts: 8615
Location: Concord, NH
|
| Posted: Tue Jan 02, 2025 5:13 pm Post subject: Simple is good |
|
|
| crouse wrote: | An easier method...... just change your ssh port.....and change your allowed users to certain IP's and users..... even if you do get attacked.....they won't get in..... changing the port will stop 99% of most attacks anyway......
adding an IP tables rule would allow you to filter out an annoying IP address as Stuka mentioned as well. |
By default, (at least when I remember) I disable as many services as I can, keeping open ONLY the stuff that I actually use. At work, I use ssh fairly often, and work can deal with the particulars - and they do; we have a pretty comprehensive security policy, strong firewalls, additional levels of protection, and numerous checks.
At home, I rarely use anything except Email, Web browsing, text editing, occasional word processing, and occasional media replay. Why even open up access to anything that would leave the possibility of problems?
Way back before networking was popular, IBM had security policies in place with its default security scheme, which did not have anything directly to do with networking, it simply blocked access to any files on the system unless explicit permission was granted, either to an individual file or a set of directories. Another scheme had the opposite - grant access unless explicitly shut off. That scheme makes it easier to access but harder to secure.
Same principles apply to protecting the network. If you want easy access, leave stuff on by default but protect what you want. For me, I go the other way. Only activate what I actually intend to use. If I change my mind, it is easy enough to enable additional services as required. |
|
| Back to top |
|
masinick
Linux Guru
Joined: 03 Apr 2025
Posts: 8615
Location: Concord, NH
|
| Posted: Tue Jan 02, 2025 5:17 pm Post subject: One additional thought |
|
|
| masinick wrote: | | crouse wrote: | An easier method...... just change your ssh port.....and change your allowed users to certain IP's and users..... even if you do get attacked.....they won't get in..... changing the port will stop 99% of most attacks anyway......
adding an IP tables rule would allow you to filter out an annoying IP address as Stuka mentioned as well. |
By default, (at least when I remember) I disable as many services as I can, keeping open ONLY the stuff that I actually use. At work, I use ssh fairly often, and work can deal with the particulars - and they do; we have a pretty comprehensive security policy, strong firewalls, additional levels of protection, and numerous checks.
At home, I rarely use anything except Email, Web browsing, text editing, occasional word processing, and occasional media replay. Why even open up access to anything that would leave the possibility of problems?
Way back before networking was popular, IBM had security policies in place with its default security scheme, which did not have anything directly to do with networking, it simply blocked access to any files on the system unless explicit permission was granted, either to an individual file or a set of directories. Another scheme had the opposite - grant access unless explicitly shut off. That scheme makes it easier to access but harder to secure.
Same principles apply to protecting the network. If you want easy access, leave stuff on by default but protect what you want. For me, I go the other way. Only activate what I actually intend to use. If I change my mind, it is easy enough to enable additional services as required. |
To continue on with my thought, if you are not actually using SSH, disable it entirely. If you are using SSH, then changing ports and modifying things so the defaults are not used, and adding additional authentication will keep all but the very best out of your system. Any system connected to a network is, in theory, susceptible to attacks, but in practice, take care of the basics and most attackers will concentrate on the easy, low hanging fruit! |
|
| Back to top |
|
|
