Having had zero interest in hacking since the late nineties, it is facinating to see how “institutionalized” hacking has become. People used to bark at script kiddies, but the slick tools presented here seem way beyond what was available back then.
Very cool.
There is still creativity at the edges (devising new exploits, figuring out how to defeat an input santiser) but day-to-day pentesting work is pretty mundane: you go through all the ports, services, API endpoints looking for standard vulnerablities (CSRF, XSS, SQL injection), look for common login and session issues, if you see XML or file upload you try some standard ways of subverting those, and you test for access control or application logic errors. Proxies like Burp can make it easy to intercept and modify requests or replay them with different sessions.
Even with slick tools, sometimes the crackers do get it wrong. Few days ago I was reading on Check Point a technical analysis of cyber attack on Iranian state television. And the security analysts who were analysing the data were all dealing with debug-mode files left behind after the attack! There was no attempt by the crackers to clean-up the binaries before releasing it on the target.
BTW, there could be a motive behind this as well, to let the victim know deliberately who they were and how they were doing it. But this is very rare, and only useful if it is a one-off attack. But the attack that was analysed by Check Point was that from repeat offenders, so to me it looked like someone who had just taken an online cracking 101 lessons and targeted few state institutions of a country :)
I think these days security testing is just glorified QA. The secret sauce is developing your own methodology, which at the end of the days is a mega comprehensive checklist.
Being a football player is also applying comprehensive checklist, question is who does it faster and is able to execute it.
Like I do understand all the exploits but executing them and executing them quickly or iterating over possible solution space is taking me 4 days on HTB easy boxes.
There are people who break really hard boxes in matter of hours or even minutes.
So for me it is comparison like I am playing soccer with my neighborhood friends and playing premier league. Like I do know the moves that should be done but I do not have reflexes built for that and building those reflexes takes years of focusing on playing football. Having reflexes on which exploit to choose or which tool you should pick up to go through with hack is something like that and you need years to build it up.
I mean… this is an interesting write up, but the “got root” boils down to “someone committed the root private key to git and then left it sitting there”.
To be fair, I bet there are a lot of things like that out there, along with folk using “password1” as their login.
…but it felt like a bit of let down in the story.
1) Get shell access!
2) look for a commit entitled “root key here”
3) profit!
I was a bit disappointed, I was hoping for some exploit… but I guess often this stuff is just mundane human failures.
…also, is it fine to only partially redact a private key in an image?
I mean, tell me I’m wrong here, but isn’t that kinda bad? (Maybe it’s just a mock image for the post, who knows).
I think the “root key here” search was silly but due diligence i suppose. There are a lot more tools than there used to be thats true but its also a much larger attack space than it used to be as well. Scripts and tools make no difference if you don’t know when or how to use them. That’s true overall not just pen testing. But I concur with the sentiment all though I’m also under the impression the purpose of the chosen example was meant in an encouraging way
Nowadays, I tell developers and product owners around me that cybersecurity is basically about 'doing IT well.' There tends to be this attitude at my $BIGCORP that its a box you tick or its something you do to get done - when in actuality its a way of living.
The majority of exploits take advantage of basic mistakes in configuration or code. Most of those issues are well understood, which is why you've seen this rise of detection tools and automation. Big hacks nowadays are necessarily a daisy-chain of exploits, because we're better at security at certain layers.
But overall, we're far from perfection. Solid configuration and code takes thought and planning - two luxuries rarely afforded to product teams when the business is screaming for release.
I think this is a good take, though depending on your domain and the maturity of your security program you eventually reach a point where the blast radius from misconfiguration becomes manageable through mitigations you have in place.
Past that point, it’s daisy chains of exploits as you say. It’s not uncommon for sophisticated attackers to sit on a number of 0-day exploits until they find a venue to deliver them. This is one of the reasons the Log4j announcement was scary—it opened up a venue to a wide variety of applications and infrastructure that were previously protected through other means.
> But overall, we're far from perfection. Solid configuration and code takes thought and planning - two luxuries rarely afforded to product teams when the business is screaming for release.
I’ve found a big part of a good security program is helping an organization calibrate it’s actual risk appetite. If business ending events are known and understood, everyone should know in what cases a security issue becomes a blocker.
> There tends to be this attitude at my $BIGCORP that its a box you tick or its something you do to get done - when in actuality its a way of living.
In many companies, it is just a box to be checked (by a separate Compliance department who does not have access to the codebase only emails to designated contacts in Engineering), and thinking about it beyond that will merely impede one's ability to achieve designated objectives. For anyone actually "making stuff" in this kind of environment, security is (at best) documenting having followed procedure to deflect blame if something bad happens.
Like you note, it’s often mundane exploits that tear the house down. Makes security engineering a challenging job as every secret in an inadvertent commit is a possible way in. Whacking gophers over and over.
Also, why would you put your public key in your own authorized_keys on the same host? (that has the private key)
Is that something people do..?
Edit: typo
The number of times we've had developers commit passwords that they never should have had to Git, and then "revert" it, following which we had to have the passwords changed, is annoyingly high.
I remember in my young and foolish days about 20 years ago getting into a big ecommerce site host (think Shopify) because the site let you upload profile pics and it didn't check the extension. I quickly wrote and uploaded a file explorer as .ASPX and browsed the file system. Found the DB password in the site config file. Used RDP to connect and tried to log in with administrator using the DB password. Worked.
What was the admin password for this huge hosting company?
"internet"
Another anecdote. Worked for a startup 20 years ago. We had millions of users. For some reason we left all the passwords in plaintext in the DB. One day we decide to query the DB for a sorted list of the most common passwords. They were:
password
trustno1
12345
123456
12345678
That 2nd one had to have been due to the X-Files still being shown at that point.
That xxe vulnerability sure was brutal and key to the whole thing. It's quite uncomfortable to be responsible for the security knowing exploits like this exist (of which you aren't aware of)
Yeah, I had never heard of XXE until now. Just looked into if PHP's DOMDocument does this by default and it seems like it's based on a configuration setting for the system (very PHP like...), though it looks like you can always run something like libxml_disable_entity_loader or pass in a flag to the load function to not have it do it.
This begs the questions: why is this the default? If you know you need it, you can be required to pass a flag to explicitly allow instead of having to disallow. I'm going to hope modern XML libraries handle this the opposite way and chalk this up to PHP being on the older side.
There is a YouTuber, STÖK, who makes videos explaining how he discovers some vulnerabilities. He actually has a video where he relied on an xxe vulnerability in an PDF file to snag passwd/shadow.[0]
That is why being responsible for security is such a shitty position in most organizations. You have barely any upside since "we didn't get hacked" is the default, but if you do get hacked it is at least partly on your plate. Most vulnerabilities are things you never have heard of and possibly never will. Finally, you will be hated by every PM/dev trying to get something shipped and will continuously have to defend yourself from executives trying to get their pet project expedited.
Even worse than a full time security person or team is the dev who cares a little more than usually and gets manipulated into doing "security" part time while still being part of a normal team. That is just a fast track to burnout: massive responsibilities with almost no power. I've seen it multiple times now and it never seems to end well.
This is why it’s so important for the organization and C-level to be fully bought in to security. What I’ve seen work in the past is for the devs/PMs to own security for the products they develop, and own the liability for security vulnerabilities. In this model, the security team acts more like an internal consultant that accepts invitations to review products/services.
HackTheBox looks like a neat service to learn some fun skills. I used to love CTFs in college, but haven't done any in quite some time. Anyone have recommendations for any services for this kind of problem/game, or is HTB a solid one to use?
The context of this submission will naturally be lost on many, and the editorialized headline is arguably wildly inappropriate.
This submission is a _single_ write-up of _one_ box on HackTheBox (HTB), which is one of the most popular platforms for redteam-like practice for the price of a common subscription service.
You often see it very directly compared to the hundreds (or thousands) of dollars you would cough up for similar lab material but which also comes with the benefit of OSCP certification (if you pass the exam), thought by some (albeit not all, if you pay attention to this topic on HN) to be one of the more reputable entry-level pentesting credentials.
Just like for CTFs, you can search everywhere in search engines for writeups. (Do note that boxes are split between "Active" and "Retired" machines, and public-facing writeups are only allowed for those that have been retired.)
The most popular (and fantastic, IMO) video walkthroughs are done by the yt channel IppSec
This platform is great fun, and I'll be honest: when I started from zero, I needed to straight-up monkey-see-monkey-do follow-alongs with IppSec videos for most of the boxes that I have done. It is probably also the most hands-on knowledge I have picked up out of anything I've ever done that I have not had to figure out by myself.
I love hackthebox. It is an invaluable resource and great for practice. It is not as comprehensive as the OSCP course material, unfortunately, and even the OSCP material has (or at least had, I know they changed things up recently) its warts.
As someone who abandoned hacking two decades ago, I was really taken aback by that usage of a local web server to transfer shell scripts. What happened to the plain old copy and pasting of scripts through your existing ssh connection, for crying out loud? ;)
Also, you would have been labeled a script kiddie and laughed at for this kind of mostly automated hack in the late 90s.
Gosh, I miss those times when hacking was mostly for fun and challenge. Now it seems to be only for work, money or malice.
I assume it wasn’t your intention, but I read this comment as very harsh on the author. I, too, remember the 90s and I think calling OP a script kiddie was somewhat uncalled for.
I don’t work in security, but I’ve always been very intrigued by it and have enjoyed some success in CTFs. Having said that, is automating stuff not a goal of every software engineer? DevOps has exploded in popularity; terraform didn’t exist in the 90s. Am I a script kiddie for using pre-built (and tested!) terraform modules?
As for the “mostly for fun” quip… OP is literally writing up a HackTheBox challenge, performed purely for fun. If you want something fun and security adjacent to play around with I can’t recommend microcorruption strongly enough; I really really enjoyed that.
You seem to look down on automated actions. But where do you draw the line? So much is already automated by everything you do on the computer.
Do you communicate with web servers using netcat? Do you open raw sockets and forge your own SYN packets? Do you compute cryptographic signatures with you pocket calculator? Do you write programs in Assembler instead of C or Python? No, because in most cases it would be a tremendous waste of time.
Why insist on others going through the same motions you did instead of just publishing your exploit or offensive security tool? Why would you reinvent the wheel if the problem has already been solved by someone else? (Unless for academic purposes.)
There is nothing wrong with tapping into the gigantic hive mind that is modern whitehat hacking. Today, we tend to go for the "standing on the shoulders of giants" approach instead hindering progress by gatekeeping our own achievements.
As someone who abandoned hacking two decades ago, I was really taken aback by that usage of a local web server to transfer shell scripts. What happened to the plain old copy and pasting of scripts through your existing ssh connection, for crying out loud? ;)
While sure, it was probably possible at this point to do that, I can think of a few really good reasons:
- SCP doesn't always work, the SFTP/SCP subsystems can be turned off. This makes it unreliable. In practice, most targets will have it enabled but this could bite you when it doesn't.
- Copy and pasting a 130KB script is not always reliable either, especially if it contains shellcode (you get lovely session- or term-breaking binary data shoved into it). It can work in a pinch but it's less reliable than pretty much all your other options.
- There are categories of attacks that require an out of band connection to exploit, which means you want the server with your tools available somewhere anyways. If it's already set up, why not leverage it?
- You may not have the ability to reliably open a new ssh connection.
Conversely, you have to consider that HTTP traffic may be filtered on egress, monitored, etc.
In my experience, actually getting SSH into the system is typically unnecessary anyways.
Also, you would have been labeled a script kiddie and laughed at for this kind of mostly automated hack in the late 90s.
A script kiddie wasn't a script kiddie because they used scripts sometimes successfully, they were a script kiddie because that's all they could do. Most experienced pentesters I know use linpeas and similar scripts to see if there's any easy low-hanging fruit. It's simpler to do that as a quick check than to run down your own checklist each time. That doesn't mean that's where they stop.
You know, like devs using boilerplate, or people coding using standard libraries, or using a presentation template.
Gosh, I miss those times when hacking was mostly for fun and challenge. Now it seems to be only for work, money or malice.
I'm not sure how you arrived there in this particular thread. Hackthebox and hackthissite and other similar challenge systems, the entire concept of CTFs (check out how many are at ctftime.org) are all for fun challenges to help people learn.
This will never find most UDP services. If you don't send a service-specific probe, the service will most likely simply not answer and the situation will look like there is no service running at all.
Sometimes you get an "ICMP port unreachable" in which case you know there is no service running, but more often than not you won't.
You should at least use `-sV`, so nmap sends service-specific probes. This will increase scan time substantially, so if you have more than one host you might want to limit yourself to the top 100 ports with `-F`.
Also, check out nmap's timing templates (e.g. `-T4`) instead of simply setting the minimum package rate to a ludicrous value. Nmap's man page (which, in my opinion, is the best man page I ever read) says this:
> Specifying a minimum rate should be done with care. Scanning faster than a network can support may lead to a loss of accuracy. In some cases, using a faster rate can make a scan take longer than it would with a slower rate.
A min rate of 10000 may work in a lab environment, but I'd stick to T4 in real environments.
As an experienced software developer I feel like I have decent understanding of how to harden my code both line-by-line and through sound architectural decisions, avoiding mistakes from memory safety to injection to permissions to race conditions to what-have-you. But I will gladly acknowledge that I'm not an expert system administrator and generally need to rely on others who have the necessary skills to set up servers and avoid misconfigurations to the standard I feel like can uphold in my own code.
Seeing a formulaic approach to pen-testing is inspiring. I feel as though if I were to practice, I would eventually be able to develop routines and understanding of how to test for and detect common errors. It would be nice to build additional competence and collaborate more effectively with expert sysadmins, even if I don't plan to masquerade as one.
What sort of basic checks should one perform after provisioning a server or making a service available? (Perform a port scan, validate that an internal server is inaccessible from the wider net, etc.)
> What sort of basic checks should one perform after provisioning a server or making a service available?
Automate everything, as in the provisions. Even if it's a one-shot job. This way if something does go wrong you can go look back at the script and it will give you an idea of where things went wrong (misconfiguration, etc).
I'm accustomed to writing automated unit and integration tests for my code. What sort of tests should I add to the provisioning routine to prove that I got it right?
I appreciate that a skilled pentester would likely uncover service-specific or instance-specific vulnerabilities, but there are surely some testing principles that would make sense for every single server.
Or is it really that at a high level, a port scan suffices and from there everything is service-specific (or at least requires going through a port)? I don't know what I don't know, here. Is there any way that a machine can be vulnerable from a network connection except through a port? (Let's ignore attacks which require physical access for the time being.)
This is a really interesting topic, but as a newbie I would love a little more detail. For example, with the nmap command, why did they use those particular switches?
I understand that nmap is a very versatile port scanning program, and I haven't used it since I was a kid, but I have no idea what about this particular situation calls for -Pn -sT -p- -oN. Is that an ideal configuration to use when you're scanning a target that you know nothing about?
The answer below mentioning explainshell.com doesn't explain the `-Pn` parameter. This one makes nmap skip host discovery and immediately start the port scan. The developer of nmap discourages using this parameter: https://twitter.com/bonsaiviking/status/1286024550241767426
Only if you know the host is alive and at the same time does not want to be seen, then it may make sense to use it, otherwise it messes with nmap's rate calibration.
The website also doesn't really explain why those switches were chosen.
And it's not clear to me either: unless you lack permissions or you find yourself in some other special circumstances, `-sS` is superior over `-sT` (as the man page explains). The latter creates a full TCP connection, while the former sends only a SYN packet and waits for the response: SYN-ACK means port open, RST means port closed. Then it moves on, leaving the half-opened connection dangling.
`--min-rate` was chosen to increase speed, but it comes at the cost of accuracy. `-T4` is the better switch to increase speed. See the man page for details.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
54 comments
[ 0.61 ms ] story [ 40.7 ms ] threadBTW, there could be a motive behind this as well, to let the victim know deliberately who they were and how they were doing it. But this is very rare, and only useful if it is a one-off attack. But the attack that was analysed by Check Point was that from repeat offenders, so to me it looked like someone who had just taken an online cracking 101 lessons and targeted few state institutions of a country :)
Being a football player is also applying comprehensive checklist, question is who does it faster and is able to execute it.
Like I do understand all the exploits but executing them and executing them quickly or iterating over possible solution space is taking me 4 days on HTB easy boxes.
There are people who break really hard boxes in matter of hours or even minutes.
So for me it is comparison like I am playing soccer with my neighborhood friends and playing premier league. Like I do know the moves that should be done but I do not have reflexes built for that and building those reflexes takes years of focusing on playing football. Having reflexes on which exploit to choose or which tool you should pick up to go through with hack is something like that and you need years to build it up.
To be fair, I bet there are a lot of things like that out there, along with folk using “password1” as their login.
…but it felt like a bit of let down in the story.
1) Get shell access!
2) look for a commit entitled “root key here”
3) profit!
I was a bit disappointed, I was hoping for some exploit… but I guess often this stuff is just mundane human failures.
…also, is it fine to only partially redact a private key in an image?
I mean, tell me I’m wrong here, but isn’t that kinda bad? (Maybe it’s just a mock image for the post, who knows).
Regardless of technical details, this is a dummy key for a CTF server - it's not used for anything meaningful.
The majority of exploits take advantage of basic mistakes in configuration or code. Most of those issues are well understood, which is why you've seen this rise of detection tools and automation. Big hacks nowadays are necessarily a daisy-chain of exploits, because we're better at security at certain layers.
But overall, we're far from perfection. Solid configuration and code takes thought and planning - two luxuries rarely afforded to product teams when the business is screaming for release.
Past that point, it’s daisy chains of exploits as you say. It’s not uncommon for sophisticated attackers to sit on a number of 0-day exploits until they find a venue to deliver them. This is one of the reasons the Log4j announcement was scary—it opened up a venue to a wide variety of applications and infrastructure that were previously protected through other means.
> But overall, we're far from perfection. Solid configuration and code takes thought and planning - two luxuries rarely afforded to product teams when the business is screaming for release.
I’ve found a big part of a good security program is helping an organization calibrate it’s actual risk appetite. If business ending events are known and understood, everyone should know in what cases a security issue becomes a blocker.
In many companies, it is just a box to be checked (by a separate Compliance department who does not have access to the codebase only emails to designated contacts in Engineering), and thinking about it beyond that will merely impede one's ability to achieve designated objectives. For anyone actually "making stuff" in this kind of environment, security is (at best) documenting having followed procedure to deflect blame if something bad happens.
It is not: https://blog.cryptohack.org/twitter-secrets
What was the admin password for this huge hosting company?
"internet"
Another anecdote. Worked for a startup 20 years ago. We had millions of users. For some reason we left all the passwords in plaintext in the DB. One day we decide to query the DB for a sorted list of the most common passwords. They were: password trustno1 12345 123456 12345678
That 2nd one had to have been due to the X-Files still being shown at that point.
This begs the questions: why is this the default? If you know you need it, you can be required to pass a flag to explicitly allow instead of having to disallow. I'm going to hope modern XML libraries handle this the opposite way and chalk this up to PHP being on the older side.
I'd be curious to know the history too. Did they really not forsee that external entities are a security hole?
0. https://www.youtube.com/watch?v=aSiIHKeN3ys
Even worse than a full time security person or team is the dev who cares a little more than usually and gets manipulated into doing "security" part time while still being part of a normal team. That is just a fast track to burnout: massive responsibilities with almost no power. I've seen it multiple times now and it never seems to end well.
This submission is a _single_ write-up of _one_ box on HackTheBox (HTB), which is one of the most popular platforms for redteam-like practice for the price of a common subscription service.
You often see it very directly compared to the hundreds (or thousands) of dollars you would cough up for similar lab material but which also comes with the benefit of OSCP certification (if you pass the exam), thought by some (albeit not all, if you pay attention to this topic on HN) to be one of the more reputable entry-level pentesting credentials.
Just like for CTFs, you can search everywhere in search engines for writeups. (Do note that boxes are split between "Active" and "Retired" machines, and public-facing writeups are only allowed for those that have been retired.)
The most popular (and fantastic, IMO) video walkthroughs are done by the yt channel IppSec
This platform is great fun, and I'll be honest: when I started from zero, I needed to straight-up monkey-see-monkey-do follow-alongs with IppSec videos for most of the boxes that I have done. It is probably also the most hands-on knowledge I have picked up out of anything I've ever done that I have not had to figure out by myself.
Also, you would have been labeled a script kiddie and laughed at for this kind of mostly automated hack in the late 90s.
Gosh, I miss those times when hacking was mostly for fun and challenge. Now it seems to be only for work, money or malice.
I don’t work in security, but I’ve always been very intrigued by it and have enjoyed some success in CTFs. Having said that, is automating stuff not a goal of every software engineer? DevOps has exploded in popularity; terraform didn’t exist in the 90s. Am I a script kiddie for using pre-built (and tested!) terraform modules?
As for the “mostly for fun” quip… OP is literally writing up a HackTheBox challenge, performed purely for fun. If you want something fun and security adjacent to play around with I can’t recommend microcorruption strongly enough; I really really enjoyed that.
Do you communicate with web servers using netcat? Do you open raw sockets and forge your own SYN packets? Do you compute cryptographic signatures with you pocket calculator? Do you write programs in Assembler instead of C or Python? No, because in most cases it would be a tremendous waste of time.
Why insist on others going through the same motions you did instead of just publishing your exploit or offensive security tool? Why would you reinvent the wheel if the problem has already been solved by someone else? (Unless for academic purposes.)
There is nothing wrong with tapping into the gigantic hive mind that is modern whitehat hacking. Today, we tend to go for the "standing on the shoulders of giants" approach instead hindering progress by gatekeeping our own achievements.
- SCP doesn't always work, the SFTP/SCP subsystems can be turned off. This makes it unreliable. In practice, most targets will have it enabled but this could bite you when it doesn't.
- Copy and pasting a 130KB script is not always reliable either, especially if it contains shellcode (you get lovely session- or term-breaking binary data shoved into it). It can work in a pinch but it's less reliable than pretty much all your other options.
- There are categories of attacks that require an out of band connection to exploit, which means you want the server with your tools available somewhere anyways. If it's already set up, why not leverage it?
- You may not have the ability to reliably open a new ssh connection.
Conversely, you have to consider that HTTP traffic may be filtered on egress, monitored, etc.
In my experience, actually getting SSH into the system is typically unnecessary anyways.
A script kiddie wasn't a script kiddie because they used scripts sometimes successfully, they were a script kiddie because that's all they could do. Most experienced pentesters I know use linpeas and similar scripts to see if there's any easy low-hanging fruit. It's simpler to do that as a quick check than to run down your own checklist each time. That doesn't mean that's where they stop.You know, like devs using boilerplate, or people coding using standard libraries, or using a presentation template.
I'm not sure how you arrived there in this particular thread. Hackthebox and hackthissite and other similar challenge systems, the entire concept of CTFs (check out how many are at ctftime.org) are all for fun challenges to help people learn.and use tar to stdout, untar from stdin to transfer directories. It can even be compressed while archiving or at ssh level.
or rsync over ssh.
This will never find most UDP services. If you don't send a service-specific probe, the service will most likely simply not answer and the situation will look like there is no service running at all.
Sometimes you get an "ICMP port unreachable" in which case you know there is no service running, but more often than not you won't.
You should at least use `-sV`, so nmap sends service-specific probes. This will increase scan time substantially, so if you have more than one host you might want to limit yourself to the top 100 ports with `-F`.
There are surprisingly many subtleties involved with UDP scans, so I recommend reading this article: https://nmap.org/book/scan-methods-udp-scan.html
Also, check out nmap's timing templates (e.g. `-T4`) instead of simply setting the minimum package rate to a ludicrous value. Nmap's man page (which, in my opinion, is the best man page I ever read) says this:
> Specifying a minimum rate should be done with care. Scanning faster than a network can support may lead to a loss of accuracy. In some cases, using a faster rate can make a scan take longer than it would with a slower rate.
A min rate of 10000 may work in a lab environment, but I'd stick to T4 in real environments.
Seeing a formulaic approach to pen-testing is inspiring. I feel as though if I were to practice, I would eventually be able to develop routines and understanding of how to test for and detect common errors. It would be nice to build additional competence and collaborate more effectively with expert sysadmins, even if I don't plan to masquerade as one.
What sort of basic checks should one perform after provisioning a server or making a service available? (Perform a port scan, validate that an internal server is inaccessible from the wider net, etc.)
Automate everything, as in the provisions. Even if it's a one-shot job. This way if something does go wrong you can go look back at the script and it will give you an idea of where things went wrong (misconfiguration, etc).
I'm accustomed to writing automated unit and integration tests for my code. What sort of tests should I add to the provisioning routine to prove that I got it right?
I appreciate that a skilled pentester would likely uncover service-specific or instance-specific vulnerabilities, but there are surely some testing principles that would make sense for every single server.
Or is it really that at a high level, a port scan suffices and from there everything is service-specific (or at least requires going through a port)? I don't know what I don't know, here. Is there any way that a machine can be vulnerable from a network connection except through a port? (Let's ignore attacks which require physical access for the time being.)
>nmap -Pn -sT -p- --min-rate 10000 \ -oN nmap/tcp_ports_scan
I understand that nmap is a very versatile port scanning program, and I haven't used it since I was a kid, but I have no idea what about this particular situation calls for -Pn -sT -p- -oN. Is that an ideal configuration to use when you're scanning a target that you know nothing about?
This way you can read the full command sort of like a custom pamphlet. To your point, more context beyond the manpage is always helpful.
Only if you know the host is alive and at the same time does not want to be seen, then it may make sense to use it, otherwise it messes with nmap's rate calibration.
The website also doesn't really explain why those switches were chosen.
And it's not clear to me either: unless you lack permissions or you find yourself in some other special circumstances, `-sS` is superior over `-sT` (as the man page explains). The latter creates a full TCP connection, while the former sends only a SYN packet and waits for the response: SYN-ACK means port open, RST means port closed. Then it moves on, leaving the half-opened connection dangling.
`--min-rate` was chosen to increase speed, but it comes at the cost of accuracy. `-T4` is the better switch to increase speed. See the man page for details.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.