Find the answer to your Linux question:
Results 1 to 8 of 8
I have a question about security, I'm wondering if anyone here knows. Recently I was experimenting with OpenVNP, and was running a VPN server off of port 1194. My cable ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2012
    Posts
    11

    OpenVPN makes other ports visible?


    I have a question about security, I'm wondering if anyone here knows.

    Recently I was experimenting with OpenVNP, and was running a VPN server off of port 1194. My cable modem/router was configured to do port forwarding from external port 1194 to my server's port 1194, so this service was exposed to the internet.

    After leaving this service running for the weekend, I was surprised to find today (Monday) that my server had been hacked, due to a brute force attack on the ssh service running on port 22. This was surprising to me because I did not believe that port 22 was exposed to the internet.

    My question is, does anybody know how this could have happened? Does OpenVPN somehow make other ports visible? The server was configured to do ethernet bridging (i.e. "tap" not "tun").

    Also, because in the past I've occasionally recieved off point responses to posts, the question I'm interested in is how port 22 could have been exposed to the internet given the above configuration (i.e., port forwarding to OpenVPN on 1194 only), so if the response isn't an attempt to answer this, please do not respond. For example, if your response is "regardless of your configuration, you should always secure ssh services etc. etc." please do not respond.

    Thanks so much in advance.

  2. #2
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,387
    In theory yes, but it wouldnt be my first thought.
    The attacker would first have to connect to/break in your vpn.

    Can you first check,
    1) if port 22 is portforwarded to that server
    2) if that brute force attack maybe happened from the internal network.
    You must always face the curtain with a bow.

  3. #3
    Just Joined!
    Join Date
    May 2012
    Posts
    11
    Thanks for the reply.

    Port 22 is definitely not port forwarded to that server. There are only 2 port forward rules, one to the VPN on port 1194 (which I've since removed), and a second to an Apache server on a different host in my LAN (which doesn't show any sign of tampering).

    I can pretty much guarantee it wasn't internal for a large number of reasons:
    1. Pretty much everyone who has access to the internal network has access to that machine anyways, so no one has any motivation (nor would they, I think, it's a very small company)
    2. The IP address used to hack it was logged and is clearly external to the LAN.

  4. #4
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,387
    So the next step would be to correlate vpn logins with the ssh logs of the server.
    Maybe one of the vpn accounts/logins is compromised.

    The second -but imho less probable- option is: the host for the vpn server is also hacked.
    You must always face the curtain with a bow.

  5. #5
    Just Joined!
    Join Date
    May 2012
    Posts
    11
    Thanks for the reply.

    I thought of trying to check the VPN logs, but I wasn't able to figure out where to look. I'll follow any suggestions, though.

    Thanks

  6. #6
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,387
    OpenVPN 2.3
    In the --daemon case, the actual logfile would then depend on the syslog config.

    --daemon [progname]
    Become a daemon after all initialization functions are com-
    pleted. This option will cause all message and error output to
    be sent to the syslog file (such as /var/log/messages), except
    for the output of shell scripts and ifconfig commands, which
    will go to /dev/null unless otherwise redirected. The syslog
    redirection occurs immediately at the point that --daemon is
    parsed on the command line even though the daemonization point
    occurs later. If one of the --log options is present, it will
    supercede syslog redirection.

    --log file
    Output logging messages to file, including output to std-
    out/stderr which is generated by called scripts. If file
    already exists it will be truncated. This option takes effect
    immediately when it is parsed in the command line and will
    supercede syslog output if --daemon or --inetd is also speci-
    fied. This option is persistent over the entire course of an
    OpenVPN instantiation and will not be reset by SIGHUP, SIGUSR1,
    or --ping-restart.
    You must always face the curtain with a bow.

  7. #7
    Just Joined!
    Join Date
    May 2012
    Posts
    11
    Okay--I finally figured out the problem. It had nothing to do with VPN, but a mistake in the router settings. I had "DMZ Host" selected, which forwards to all ports on the target host, not just the ones with explicit forwarding rules.

    My mistake--thanks for the help!

  8. #8
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,387
    yw.
    Glad you found the cause.
    You must always face the curtain with a bow.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •