Should I enable port forwarding

I recently wanted to test a weboage that I'm currently hosting on Apache by enabling port forwarding so I could view it from the outside. However, when I looked at my router logs, I saw that someone was scanning my IP address from many different IP addresses (most probably using Tor). Now I'm unsure about whether I should enable port forwarding in case I get pwned.

Qubyte wrote: I recently wanted to test a weboage that I'm currently hosting on Apache by enabling port forwarding so I could view it from the outside. However, when I looked at my router logs, I saw that someone was scanning my IP address from many different IP addresses (most probably using Tor). Now I'm unsure about whether I should enable port forwarding in case I get pwned. Interesting question. The answer is an easy-peasy NO, but let's dissect it a bit to figure out why, and then turn it into a big bad MAYBE because I hate making life easy for other people.

In security, the answer to any question about allowing anything new is always no. You want your walls to be high, your moat to be deep, your rooms to have locks, and your peasants to starve. Nothing in, nothing out. Ever. But this isn't a useful life (ask Rapunzel, I guess). We live in an age where, for better or for worse, everything is connected and talking to one another. Is my computer "less secure" because it's on the internet? You better bet your sweet buns it is! But am I willing to give up all those adorable puppy videos because of that? C'mon, man, have you seen a puppy of course I'm not! Everything is about risk management. So what are your risks?

weboage> hosting on Apache> scanning my IP address So by enabling port forwarding, you'd be allowing an attacker, perhaps someone who has already expressed an interest in you (we'll get to that in a second), access to your personal webpage by connecting to and speaking with your instantiation of Apache. They'd also likely be able to interact with any backend databases and the software to manage/run them as well. What are the risks here?

1. Well, if you're running an old out-of-date version of Apache, they could potentially interact with it in such a way as to gain a foothold in or even control of your computer. If it's the newest version of Apache and you work to ensure it stays up-to-date, then this risk is, in my opinion, mitigated.
2. What about Apache settings? If you manually installed and configured the server software, an attacker would be able to gain access to and maybe control what is being served. Default passwords, accidentally-included-directories, etc. could all be taken advantage of.
3. What about your webpage? An outsider would now potentially have access to any of its outward-facing APIs. SQL requests, JS functions, comments, the like. Are you okay with an arbitrary person on the internet seeing and interacting with your work-in-progress website?

In my eyes, these are probably reasonable risks. If my gain from accessing my site from outside my WAN was even moderate, I'd go ahead and punch that hole in my firewall. But let's take it a step further and mitigate a bit harder.

• Risk (1) can be mitigated with some good, old-fashioned virtual machining (or containering if you're looking for something lighter-weight and lighter-security-guarantee-y). Putting your entire setup in a VM and properly isolating your host from it ensures that even if you're the target of an active well-provisioned campaign and your server gets popped in such a way as to allow arbitrary code execution, then the attacker still wouldn't have access to your main system (barring vulns in VirtualBox or VMWare or Docker or whatever, of course).
• Risk (2) can be mitigated by fully understanding how the software you're allowing outsiders to touch works. Where are the settings saved, how are they interacted with, which parts have to run as root, how does it determine what to serve, etc, etc, etc. Copy/pasting from StackOverflow without understanding is a recipe for disaster (see: this pdf for an interesting study).
• Risk (3) can be mitigated through good-old access control. Lock your entire site behind a password-or-rsa-key-wall and go at it.

So there you have it. A series of off-the-top-of-my-head risks, their possible mitigations, and all the muddy logic in-between. I can't tell you that you won't get pwned and I can't tell you whether the risk you're accepting is worth it, but I can say that if I were in your shoes I'd probably just do it and see what happens. Also, this is all my opinion based on a short introduction of the situation. Please feel free to disagree and start a discussion.

TL;DR: Go with what you feel.

Sidenote:

(most probably using Tor) Tor IPs are [s]all[/s] mostly publicly-available. If you think a scan is coming through Tor, just search the listing of Tor IPs and be sure. If you don't access your site or your server through Tor, then you might as well block all IPs on that list and be done with it.

• futility

Thanks Futility, I wasn't expecting such an answer! I thought it was going to be a simple "g00gl3 it n00b" haha

Risk (1) can be mitigated with some good, old-fashioned virtual machining I was thinking of running it in a VM with its own USB wifi adapter.

Well, if you're running an old out-of-date version of Apache, they could potentially interact with it in such a way as to gain a foothold in or even control of your computer. I like to keep my programs up-to-date because I'm quite paranoid about these things as it is, since my ex helped the guy she was cheating on me with hack me with a rubber ducky. This is also part of the reason I want to get into cyber security - those people need to be stopped and locked up :)

I've seen a few threads on reddit by people who have had similar scans on their IPs, with everyone telling them not to forward any ports or they'll get pwned. There are also lots of comments by other people going "Help me! This is what the logs show: …" and they copy-paste the log that has "source address: (attacker's IP), destination address: (their own IP, completely unedited)". I think it's safe to assume they've had much, much more such log entries since posting those haha

Blocking Tor exit node IPs seems like something I should definitely do, I'll have a look at the list after my cup of tea :P

As a side note, would running a meterpreter reverse tcp listener through a forwarded port pose a threat? I've gained access to metasploitable on my local network a few times, but I'd like to have a go at going through the outside network. I've been working through my "Metasploit for Beginners" book which is good for explaining how to use auxiliary modules, payloads and exploits, but not how they actually work which is a bit shit :P

You're missing out on the real fun part man, stick those IP's straight into a web scanner and return the favour. It's amazing how many of these clowns are in such a hurry that they never change the default passwords for any of the shit they use, and how many of them are running old versions of software on their servers with well known vulnerabilities. You already mentioned metasploit so you already have everything you need right at your fingertips so why not go do some fingerprinting of your own ?

Huitzilopochtli wrote: You're missing out on the real fun part man, stick those IP's straight into a web scanner and return the favour. It's amazing how many of these clowns are in such a hurry that they never change the default passwords for any of the shit they use, and how many of them are running old versions of software on their servers with well known vulnerabilities. You already mentioned metasploit so you already have everything you need right at your fingertips so why not go do some fingerprinting of your own ?

Hahaha! If Ido that, I'll be in the same boat as them :P I'm pretty sure they're Tor exit nodes because there's a new scan every 10 minutes or so from a different IP, so maybe the only way would be to scan the new IP as soon as it happened in hopes they haven't disconnected? Doesn't it work with session cookies to keep track of who's connected to what? Or would a scan on that IP just end up scanning the exit node server? Not planning to do it, but I am curious to learn how this stuff works.

gonna grep the shit out of this https://check.torproject.org/exit-addresses haha

Qubyte wrote: Thanks Futility, I wasn't expecting such an answer! I thought it was going to be a simple "g00gl3 it n00b" haha A fair assumption, I suppose. Just doing my part to help pull answers away from that default knee-jerk reaction. Plus it's something of an interesting question/topic- I'm sure my opinion is quite different than others'.

I was thinking of running it in a VM with its own USB wifi adapter. Well then what are we worried about that sounds good as gravy to me. If the VM gets compromised then there's the potential to pivot to the host through a network connection (if it's bridged or shared or whatever) or over shared folders and mounted drives, although I'd say the probability here is relatively slim.

I like to keep my programs up-to-date because I'm quite paranoid about these things as it is, since my ex helped the guy she was cheating on me with hack me with a rubber ducky. This is also part of the reason I want to get into cyber security - those people need to be stopped and locked up :)

I've seen a few threads on reddit by people who have had similar scans on their IPs, with everyone telling them not to forward any ports or they'll get pwned. There are also lots of comments by other people going "Help me! This is what the logs show: …" and they copy-paste the log that has "source address: (attacker's IP), destination address: (their own IP, completely unedited)". I think it's safe to assume they've had much, much more such log entries since posting those haha Shewt man. That's pretty extreme, I'm sorry to hear it. Although I wouldn't exactly call someone plugging a rubber ducky into your computer as "hacking", I see where you're coming from. It's a fun field with loads of interesting opportunities and I hope the positive of learning something new outweigh the losses of the situation that brought you to it. IPs are generally public information and shouldn't be regarded as something to keep private or hidden. That being said, every new connection you allow inside your bordered wall does increase your risk, but if you understand that you can take measures to ensure that bad things don't happen. Knee-jerk don't-do-that-because-it's-bad's bug me.

Blocking Tor exit node IPs seems like something I should definitely do, I'll have a look at the list after my cup of tea :P Definitely a good step, but don't think doing so will necessarily stop anything from happening. Scanning the IPv4 space is super easy to do and not necessarily malicious. Just a thing that happens. And people will always randomly throw metasploit at anything they find. Because they're dumb. Also, it sounds like you've got a bunch of garbage scripts getting thrown your way, so might as well forward through some arbitrary port to help prune the lowest-hanging fruit. A lot of times, these automated scripts will puke if anything out of the ordinary is detected. If rubby duckying is the apex of your aggressor's abilities (AAA!), then this alone should be enough to scare them off. Finally: if you do think you're being personally targeted by someone no longer in your life, why not just try to get a different IP assigned? A lot of times all you need to do for this is usually unplug and replug in your modem (I think?), or just send a quick message to your ISP. Assuming you're not a business or are paying for a static IP for whatever reason, this should be easy peasy. Security through obscurity for the win!

As a side note, would running a meterpreter reverse tcp listener through a forwarded port pose a threat? I've gained access to metasploitable on my local network a few times, but I'd like to have a go at going through the outside network. I've been working through my "Metasploit for Beginners" book which is good for explaining how to use auxiliary modules, payloads and exploits, but not how they actually work which is a bit shit :P Ehhhhh… I… don't think so? Unless netcat (or whatever happens to be on the listening end) has a vuln in it I think you should be fine. Although classic security theory says "of course it's dangerous you dolt you're doing something other than absolutely nothing you stop that right this instance!", so go with what you feel. Although I always suggest keeping metasploit tinkering local just because you're working with vulnerable-by-design applications. Make sure you're not exposing that aperture to the outside.

Huitzilopochtli wrote: stick those IP's straight into a web scanner and return the favour haha I would advise against this too, just 'cause it sounds like too much fun. You know the drill: fun == bad. Stay safe kids.

• Futility

Futility wrote: Definitely a good step, but don't think doing so will necessarily stop anything from happening.

Aye, I get that - it would only stop my router from passing on requests from those IPs, the only way to stop myself from being scanned completely would be to blacklist all IPs except the ones I want to connect to, which wouldn't be practical haha

"of course it's dangerous you dolt you're doing something other than absolutely nothing you stop that right this instance!" Do you know what? I'm going to give it a go! …as soon as I find a tp link driver that works for my wifi adapter and 4.x Linux kernel -.-