1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

IP Blocking in More Detail

Discussion in 'Tomato Firmware' started by Sean Rhodes, Nov 3, 2012.

  1. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Hi guys,

    I was wondering if someone could help me as to the best way to block external connections without blocking myself when I'm on the road?

    I'm using Tomato Firmware 1.28.0000 MIPSR2-101 K26 USB Big-VPN firmware with a Cisco (Linksys) E4200 v1 router and here's my scenario:

    I'm using Remote desktop on a macbook to connect over 5900 and 3823, back to my home PC, which I have no issues with, BUT... I was noticing that there had been repeated attempts to log on to my machine, a typical IP being 62.149.7.244, which is Kiev in Russia according to Whois.

    Right now, I have it configured to only allow access via known IP's which means when I'm on the road, I can't access it myself so it defeats the purpose.

    To get around that, I have been logging in using realvnc over a non standard port, enabling the current IP i'm using in my firewall and then re-logging in using Remote Desktop.

    Can anyone suggest a better way to protect myself?

    Is blocking all IPS from that country via an ip tables script then only way, or can someone suggest other alternatives that I haven't thought of?

    Thanks in advance.
     
  2. phuque99

    phuque99 LI Guru Member

  3. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Thanks Phuque99,

    I saw that thread, but I have a USB drive hooked up on the router and was hoping to avoid removing it. If that's my only option then I may have to go that route
     
  4. phuque99

    phuque99 LI Guru Member

    Try the quick and dirty method with multiple iptables
     
  5. phuque99

    phuque99 LI Guru Member

    I missed the fact that you can also host the database in JFFS, so you can try that.
     
  6. koitsu

    koitsu Network Guru Member

    Sean, I understand your predicament quite well, as it's something I've had to deal with regarding previous customers of mine (I did server hosting for 18 years) -- specifically how we had a very strict set of ingress (inbound) firewall rules for services like SSH which were a problem when the customers would roam (travel to New York, Nevada, etc. and use public wifi access points there). In other words: the customers wanted security but also wanted a "way in" when they were trying to connect from some random IP somewhere. So I understand your situation.

    The solutions I recommend for this are the following:

    1. Run the service you need on a non-standard port. You talk about TCP ports 5900 and 3823. TCP port 5900 is for VNC, not Remote Desktop, and 5900 is the "base port", meaning VNC display 0 = port 5900, VNC display 1 = port 5901, etc.. TCP port 3823 is not registered with IANA so I have absolutely no idea what that port is for. Possibly you mean port 3389, which is what Remote Desktop (Microsoft Terminal Services) uses?

    Either way, run the service on a non-standard port, or if you can't change the port number in the software (VNC server, RD server), then forward a different port on the WAN side to the correct port on the LAN. I.e. forward TCP port 12345 (on the WAN) to port 5900 (on the LAN). Tomato lets you do this via the GUI quite easily. Please pick a port number that is in the 5-digit range.

    For VNC, you'd want to connect to {wanipaddress}:6445. Where did I get 6445 from? Simple: 12345-5900 = 6445. Like I said: VNC uses a "base port" mentality, hence the needed math. Otherwise you can change your VNC client configuration and tell it the base port is at 12345 after which you can just connect to {wanipaddress}.

    For Remote Desktop, you simply connect to {wanipaddress}:12345.

    This will cut down greatly on the number of attack attempts you see. I would say it'll remove probably 95% of them.

    2. Use an SSH, then tunnel your VNC/RD over that. This sounds scary at first but it's really not. The two most important parts to this are: 1) run the SSH server on a port different than TCP port 22 (same reasoning as #1 above), and 2) use key-based authentication ONLY (this means that even if someone find your SSH server running on a non-standard port, they can't brute-force their way in by guessing passwords because passwords are disabled entirely. Note theses are SSH passwords, not the same thing as VNC/RD passwords). You will need an SSH client that supports forwarding, and one that will let you generate public keys -- best one I can recommend, hands down, is PuTTY. I can describe all the steps you need to go through to do this, if you want. It's not hard, it just takes a little time and will always work for you, but the aforementioned item is easier/quicker.

    These solutions require the least amount of work and "scale well" compared to doing something like blocking an entire country. I have no problem with someone blocking an entire netblock/country (really I don't!), just that it's not reliable -- because of the shortage of IPv4 space, ARIN is moving around netblocks somewhat often. Korea might get a new /22 tomorrow, for example, because someone in the US relinquished their /22 and Korea needs it. Blocking things per country is a constant administrative mess and adds unnecessary complexity for something which you don't need. Apply KISS principle as much as possible!
     
  7. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Thanks for all your help guys. I think mapping to non standard ports on the wan would be the quickest way to go for me right now, but ultimately ssh with my current key pair, or would you recommend a completely different key pair? I actually use ssh over a non standard port to login to my router itself and have my own key pair, so I will experiment with that and try to setup RDP and VNC through that also.

    Thanks again, this has been a great resource.
     
  8. koitsu

    koitsu Network Guru Member

    You can use your existing key pair -- there's no sense in using another pair (IMO, that just adds more annoyance/complexity to the situation).

    Speaking strictly about the SSH tunnelling method:

    In your SSH client, set up what's called a "local forward", where the local port (source port) is 12345, and the destination is {lanipofwindowsbox}:3389 (for RDP) or {lanipofwindowsbox}:5900 (for VNC, then refer to the above advice about the "base port" ordeal). Then in your RDP or VNC client, the host you connect to is localhost:12345 (for RDP) or localhost:6445 (for VNC, re: "base port" ordeal).

    Make sense? If not I can explain it in more detail.

    And in case it's not obvious: for this to function you need to keep the SSH session open to the router. The instant you close the SSH session, the tunnel gets closed. I state that only because in my experience (previous day job, etc.) people would often bitch/cry that their tunnels went down when they closed/exited PuTTY. I was like, "really? seriously? this is what you make a ticket for?" :p
     
  9. USNetboy

    USNetboy Networkin' Nut Member

    Isn't this what VPN is for? Setup an OpenVPN server on your router (there are many guides out there on how to do it). Use the TAP interface and your remote PC will become literally part of your home network once VPN'd in. This has many advantages over any of the above solutions. With this in place, you don't need to punch multiple holes in your firewall or use non-standard ports. All your traffic to all your home systems (including router management) will be accessed over a single UDP port (which is less noticeable in port scans than TCP). If you are willing to make yourself a bit more discoverable and do not serve HTTPS on your WAN side router interface, you can setup your OpenVPN to listen to TCP/443. This will let you VPN in from ultra restrictive remote locations (some hotels are known to block almost anything other than HTTP/HTTPS) as most firewalls will see this as HTTPS traffic.
     

Share This Page