http://www.perlmonks.org?node_id=931752


in reply to Why socket not responding in webserver

Probably a firewall issue: Client  --(SYN)--> Firewall( TCP 12000 blocked )  --X--> Webhost.
Contact admin.

Take care not to introduce security risks. Maybe you can realise your service by means of an existing webserver and e.g. CGI?

Replies are listed 'Best First'.
Re^2: Why socket not responding in webserver
by romy_mathew (Beadle) on Oct 16, 2011 at 21:57 UTC
    Would like to know adding socket communication like the similar one I posted above is a real security issue...?, I had this feeling{socket communication is high risk} from many online posts and documents but still don't understand why this is highly prone for attack.

      Depends. You didn't gave much information about the environment your script is used in (exposition to threats) and what it is supposed to do (extend of damage in case of successful attack). The measures you have to take might be simple (e.g. when operating in a somewhat closed environment: intranet, VPN) or more complex (Internet).

      E.g., your current implementation is accessible for everybody who can connect to port 12000 of the webhost. If your're not talking about an intranet webhost, the script is in principle globally accessible! There is no password protection. If you had one, it could be snooped since there is no encryption in place. I guess, you will replace the interact() sub with something more powerful. It could be something innocent as

      # simple time service sub interact { ... print $sock "It's: " . localtime . "\n"; ... }
      or something like
      # poor man's telnet sub interact { ... while ( <$sock> ) { chomp; print $sock `$_ 2>&1`; } ... }

      Read perlsec as an introduction. Minimum security measures to take:

      • use taint-mode / sanitize all input
      • execute with minimum privileges
      • chroot if possible
      • provide password protection
      • restrict access to given IPs (ideally localhost, maybe you can use an SSH-tunnel?)
      • restrict local resource usage (e.g. kill script if interact() runs too long) / ulimit
      • use a daemon package
      • don't forget logging
      • keep your environment patched
      • update: add - SIGPIPE handler (see what I mean with next item?)
      • etc. ... it's the game to forget something that can be used to compromise your site.
      It is not impossible to create a reasonable safe socket based server, but it is hard work and little mistakes have potential for great harm (or I am just too paranoid ;-).