Fork a Process Attached to my Terminal

So I was dinkering around in my terminal one day and thought I had one program running in the background, when really it was gedit. The first instance of gedit will of course, block my terminal, and I won't be able to use the terminal because it's attached to the GUI.

If I wanted my terminal back, I could always Ctrl+Z and go on about my day - but wait, gedit is frozen and I can't use it unless I return my terminal to it by running "fg". Ok, I can close gedit and lose all my tabs, or save my state in a session, and proceed to "gedit &" to run a fork in the background. That's annoying though.

So, I saw this and it dawned on me what's going on in the details:

root@localhost:/srv/salt#fg
gedit top.sls 2> /dev/null > /dev/null
^Z
[1]+  Stopped                 gedit top.sls 2> /dev/null > /dev/null

Wait, so the process is "Stopped" ??!? >_>
....
...
..
!!!

root@localhost:/srv/salt#ps faux|grep gedit
root     29482  0.8  0.5 359648 40576 pts/0    Tl   13:30   0:16                          |           \_ gedit top.sls

root@zynx:/srv/salt#kill -SIGCONT 29482

And voila!!!
Gedit was back in focus and ready to go!!!
That's the key - if you accidentally fg your apps in your terminal, you can always Ctrl+Z; kill -SIGCONT to return them as they were.

Cheers!

Firewall Check

I'm sure there are plenty of tools out there that do better than I, but this was my hack and I'm going to put it out there...

So, on the server, I setup its own user account. Its shell was set to something I could control, and it did exactly what I was looking for in a couple of commands:

# Add a temp user to the system so we can tinker around with this...
adduser --home=/tmp/netcat --shell=/tmp/netcat/nc --ingroup=nogroup --disabled-password --system tmpnetcat

# Setup the home so I can login using SSH keys since passwords are disabled anyways...
install -d -otmpnetcat -gnogroup -m0700 /tmp/netcat/.ssh
install -otmpnetcat -gnogroup -m640 ~/.ssh/id_rsa.pub /tmp/netcat/.ssh/authorized_keys

# Enable this user for accesing /bin/nc without a password as root so they can bind to any address for testing.
echo -e '\n\ntmpnetcat ALL=NOPASSWD: /bin/nc' >> /etc/sudoers

# Insert the script we'll execute when this user logs in.
cat <<NCEXEC > /tmp/netcat/nc
#!/bin/bash

PORT=$2
if [ -z "$PORT" ]; then
        echo -e "\n\n\033[31mI require a port to listen\033[0m. Use ssh $USER@$HOSTNAME [port]\n\n" >/dev/stderr
        exit 1
fi

echo "Listening on port $PORT."
for i in 1 2 3; do
cat <<EOF | /usr/bin/sudo /bin/nc -l -s 192.168.0.1 -p $PORT
HTTP/1.1 200 OK
Date: $(date '+a, %m %b %Y %R:%S GMT %z')
Server: Port Testing
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/plain; charset=UTF-8

EOF
done
NCEXEC

The server is basically just a shell account that opens a netcat on a port for listening and echos a passing response message for 3 client connections.

The client is simple. This script should get us going:

#!/bin/bash

exec 3>status.log

export interrupted=false

# Bash for() loops have a way with Ctrl+C/SIGINT interrupts. This ensures we'll get our shell back when we INT everything.
is_interrupt () { interrupted=true; }
trap is_interrupt 2

# Grep -v out the ports we use so we don't cause a conflict.
for port in $(seq 1 65535|egrep -v '22|53|80|443|953|3306|6010'); do
 if [ "$interrupted" = "true" ]; then
  exec 3>&-
  exit 2
 fi

 ssh -q tmpnetcat@kizmedia $port 2>ssh.err >ssh.out &
 sshpid=$!

 # Wait for the nc to be up and listening.
 while [ -z ssh.out ]; do
  sleep 0.1s
 done

 if httping -t2 -c3 -p$port markizano.net; then
  echo "$port passed." | tee -a /proc/$$/fd/3
 else
  echo "$port failed." | tee -a /proc/$$/fd/3
 fi

 sleep 0.5s
 if [ -d /proc/$sshpid ]; then
  killz=0
  while [ -d /proc/$sshpid ]; do
   echo "Killing ssh pid $pid";
   kill -15 $sshpid
   sleep 1s
   killz=$(($killz+1))
   if [ $killz -ge 6 ]; then
    echo -e "Murdering SSH Pid $sshpid!!!"
    kill -9 $sshpid
   fi
  done
 fi
done

exec 3>&-

When it's all said and done, you should have a file called status.log that contains a list of pass or fail messages per port that was attempted. Save this log - it takes a long time to generate. This allows for just a little bit of tolerance. I've yet to make it into anything packageable or fancy. It's a hack at best. I guess I know why I didn't find this easily on searching.

Complaints and Achievements

If there's one thing I notice about people in my day to day interactions, it's that people do a lot of complaining. No, this is nothing recent, but a collection of things I've seen over time in my years talking to people...

Do we have to talk about how much we hate our jobs?
Do we need to discuss the reasons why we're so tired all the time?
Do we HAVE to point out just how much of a drag it is to work?


Look people... If you feel so bad about life and what it is today, then why not go ahead and shove off and move on to the next thing in your spiritual adventure. In the meantime, those of us that actually want to achieve something will continue to get the fsck off this rock.

I want to talk about our achievements. I want to talk about our goals. I want to talk about our success.
Instead of talking about how tired you are - talk about what you're going to do throughout the day. Focus less on your fatigue and it will seem less apparent to you. "Out of sight, out of mind." Though, for that 14:00 crash in the day, I find a quick 15 minute nap is a much more effective way of fighting it than a 2-4 hour boxing match with your yawns...

Special Characters In Passwords

In this day and age of technology, we all need access to our protected data. In order to do that, you need a good password. What if you're not allowed to create a good password?

Too often, I see web forms that try to be clever in that they require you to have a uppercase, lowercase and a number in order to make your password stronger and harder to guess. Then they turn around and deny you the use of special characters. That's like walking into a bar, and the minimum is 3 drinks and you think you're going to have a good time, until you find out they watered the beer down to >1.5% - Good job!

Other instances, I see web forms that totally DENY you the use of anything except alphanumeric characters. I've never seen an instance of a web form that does this legitimately. The only excuse for this is because the developer who created the form didn't properly escape the data before printing it to the next stream.

This is ridiculous! The best thing you can do for your users is to validate on input - escape on output!!!

Let's break this down for those who need more explaining:

Validate On Input

If you are expecting an eMail address, validate the string as an eMail address using regular expressions or some type of string matching pattern. If you are expecting a phone number, then you can expect to receive only digits, dots and slashes and maybe an X to note the extension. If you want to be uniform with your data, break the components into multiple inputs and validate each input. Same rules apply for IP addresses, MAC addresses, name, address, and any other type of data you may accept.

Escape On Output

Before printing any user input to any stream, you have to properly escape that data. The art of escaping comes with the driver you're using to print to the stream.

    SQL

For example, when printing to a SQL query - you'll want to use your programming language's database driver's function to escape the data for the SQL stream. Alternatively, you can use prepared statements to create queries, and use placeholders for the data. The DB driver will replace the placeholder with the appropriate escaped data before executing the query.

    FILE

When printing to a file path, you want to ensure you're taking the basename() of the user input to prevent directory traversal. DO NOT simply remove dots and slashes as you could wind up mangling the resulting file name. Limit user input to a specific directory. If you must have organization and folders with the user data, then store the metadata in a data store of sorts. Do not allow users to create their own directory trees as it could allow for injection.

    JAVASCRIPT

Let's assume you have some data that came from the end-user and you want to put it into a javascript function somewhere in the response. Don't just strip the quotes, use JSON encoding to properly encode the data as a JSON object and return that to the client.

    XML/HTML

When printing to the browser, most times, you can get away with the 5 main characters that define XML ( < > & " ' ), however all web-based languages should have an HTML escaping function. Additionally, you need to consider the character set a client is using. If not, all languages have access to libxml, which is a core library dealing with XML. When printing to an HTML stream, if you don't know an HTML escaping function, use XML escaping (since HTML essentially is XML). Create a DOM document element, set the value of the element to your user data, then retrieve the escaped string from the element. I know it sounds like a PITA, but I guarantee you it will CYA!



It doesn't matter which stream you're using, you must find the proper driver and function to escape the data for that stream. Most languages have these functions built right into the framework, so you don't have to cook up your own function escape(){}

Do NOT put restrictions on what the user can use for their password field. Do NOT limit the length, do NOT limit the characters (except for what is reasonable for your data store). Sure - there should be a minimum number of characters, and if you want to require the user have 1 upper, lower and number in their password - fine. It ensures there is more entropy and makes the password that much more complex and difficult to bruteforce.
That's the whole point of a password! It's a secret token that's supposed to be difficult to guess. When you limit that range from the whole alphabet at 65535 characters to just alphanumeric at 36, you increase the chances of an easy bruteforce. This is simply NOT the function of a password. Even then - we should be using "passphrases" - or a collection of words or a phrase that grants us access.
http://xkcd.com/936/

You people need to get out of the 1900s and the year 2000 and upgrade to 2013. We are the Gods of our virtual environment. To assume that it's impossible to accept a user's password as they submit it without opening a vulnerability is a testament to your incompetence to building secure web applications.

apt-get update markizano

Hey all,
So you might have noticed that there suddenly is a page going on at the big www :)
Just a heads up: It's up and running: http://www.markizano.net/.

I want this to be a place where I can say I designed something from scratch. I know that doesn't sound like me - and for the record: I'm still no designer and most will probably laugh at my choice of color scheme. Hey - you can't say I didn't warn you! Though, all work here is my own, or I contributed a decent chunk to its production.

Take caution and tread lightly - the site is still in development, but is at least presentable. I have further plans for the layout so don't count on the theme staying the same for long =)

Cheers!