Friday, October 6, 2017

Hi all, quick and dirt post. So you're upgrading to R80.x and you've got none ascii stuff in the database(s).

Here is a quick and dirt way to see what matches for Objects_5_0.c and rulebases_5_0.fws. This will be shown as network_objects and rulebases in the pre upgrade report.

works for object_5_0.C hits

grep --color='auto' -P '^\t\t:|[^\x00-\x7F]' objects_5_0.C | grep -B1 -P '^\t\t\t'

This works for rulebases_5_0.fws hits

grep --color='auto' -P 'rule-base|[^\x00-\x7F]' rulebases_5_0.fws | grep -P -B 1 '^\t\t\t'

You should get a very clear listing of the offending objects/rules. Let me know if you see a better way to do this. Now you can find out what to clean up via dashboard.


Monday, January 23, 2017

Installing and Using Google Authenticator for Two Factor Auth on a Checkpoint 750

Hi all, in Installing Kali Linux on a Checkpoint 750 SMB Gaia Emebedded Firewall I dropped a hint about a reason to do this. Well here is an interesting use case. We can create a free stand alone 2 factor authentication system for VPN users using Google Authenticator. BTW I updated the Kali install. I forgot about mounting proc and sys. Head over there and check the update if you've not already.

For example say you didn't have a external radius sever and/or user directory (ldap, MS DC etc). Using this method you can have a working two factor authentication system that doesn't require connectivity to an external radius server. Granted you can always just pull the radius config out of this write up as well. By the end of this the goal is to show how to put all this together.

Here is a list of the moving part we'll be using.
The way this will be tied together is the following.

Request comes into the firewall in the following form

unix passwd password + OTP

  1. Firewall forwards request to Free Radius (which is installed on the 750 in this case).
  2. Free Radius passes the username and password to via the Radius PAM module.
  3. PAM passes the username and password to the Google LibPAM module. 
  4. Google's libpam module strips the OTP off the password string and verifies the OTP with google. If the authentication is good Google's libpam sends the password (without the OTP) string back to pam.
  5. Pam then checks the password using the normal unix checks.

If everything is good the FreeRadius sends an accept message back to the firewall and then you're golden!

Now before we get too much further into this let me give you a little warning. This will require some hacking. Why is that you ask? Well.. Kali (guessing most if not all Debian based OSes) assumes the Linux kernel has audit support enabled but the kernel on the 750 does not as seen by

[Expert@FW750]# gzip -dc /proc/config.gz | egrep -i audit
# CONFIG_AUDIT is not set

This causes Google's pam module to fail when creating a network connection. Found this with strace. Basically you'll see socket(bla NETLINK_ADUIT) error =PROTOUNSUPPORTED or something like that.

There might be a better way of dealing with this, but the current work around is to recompile the pam package. What is kind of a pain is if there is an update to pam and you update the chroot with say apt-get upgrade or something then you'll need to recompile the package with the new pam module. You can always make more then one chroot also so you could make one just for Free Radius and a different one for all the things Kali can do.

Right so anyway... Let configure some stuff. I'm going to assume you already have the chroot setup so i'll be going right into that, but first add a loop interface. This will be a private interface we'll be telling freeraidus to use. You should also create 2 firewall rules for this under the "Incoming, Internal and VPN traffic" section. One to allow radius from loop00 to loop00 and a second rule to deny all other radius. BTW radius object has a timeout of 3600 seconds (seems high for udp) so if you've already passed traffic the deny rule won't take effect until radius falls out of the connections table. I lowered radius timeout to 30 seconds. ok ok ok.. configure stuff.

From clish run the following to create a loop interface for radius.

FW750> add interface-loopback ipv4-address

Next we'll login to the chroot and update the apt-get system then install some packages (FreeRadius, Google libpam). BTW make sure proc and sys are mounted inside the chroot. I updated the kali write up about that.

[Expert@FW750]# chroot /mnt/sd/kali-chroot bash -l
root@FW750:/# apt-get update
!stuff happens
root@FW750:/# apt-get install libpam-google-authenticator freeradius
! lots of output
!don't worry about java errors. freeradius must have javasupport enable by default.
Do you want to continue? [Y/n] y

A lot of things will start download. Lets queue up some Music while we wait.

After a few minutes you'll have almost everything you need. 

# Start hacking

# This part is only needed for installing on the 750. If you're by chance running through this for an external radius server you can skip this.

So now we have all our apps installed. Lets rebuild pam! 

First you'll need to tell apt you'll be downloading source. If your not sure how to change /etc/apt/source.list basically just copy whats there and change the starting 'deb' to 'deb-src'. This will do that for you if you super lazy. We'll also be installing everything needed to build pam.

root@FW750:/# egrep -q '^deb-src' /etc/apt/sources.list || sed 's/^deb /deb-src /' /etc/apt/sources.list >> /etc/apt/sources.list
root@FW750:/# mkdir pam ; cd pam
root@FW750:/pam# apt-get update    
more stuff
Reading package lists... Done
root@FW750:/pam# apt-get build-dep pam
!more output stuff
root@FW750:/# export CONFIGURE_OPTS="--disable-audit" ; apt-get source --compile pam
root@FW750:/pam# dpkg -i libpam-modules_1.1.8-3.5_armhf.deb libpam-modules-bin_1.1.8-3.5_armhf.deb libpam-runtime_1.1.8-3.5_all.deb libpam0g_1.1.8-3.5_armhf.deb

ok all done /pam you can delete this entire dir if you want.

# End hacking

Ok right.. so lets configure everything!

# Start Radius config!

Edit /etc/pam.d/radiusd. This is what we want it to look like. This is so the user FreeRadius runs as can read the users Google authenticator configuration file.

auth       required forward_pass
auth   required use_first_pass
#@include common-auth
@include common-account
@include common-password
@include common-session

Now edit


Add this to the top of it.This basically says if the unix user is a member of /etc/group "disabled" then reject the radius request. Next part says pass the user login to the pam backend.

DEFAULT Group == "disabled", Auth-Type := Reject
Reply-Message = "Your account has been disabled."
DEFAULT Auth-Type := PAM

run the following to enable the pam module

ln -s /etc/freeradius/3.0/mods-available/pam /etc/freeradius/3.0/mods-available/pam

setup the client IP and Password for radius packets from the firewall.



# Add the Use the loop address we created earlier.
client  firewall {
ipaddr =
secret = somepw

Now lets edit the main site radius server config.


replace all
ipaddr = *

ipaddr =

Comment out ALL the IPv6 sections (the entire section)

uncomment the pam section (around line 489)
        #  Pluggable Authentication Modules.



uncomment src_ip and set it to the loop00 interface IP as well.

src_ipaddr =

Geez.. are we done yet? As it turns out.. almost! We're now going to make the FreeRadius server run as root. This is needed because the google pam module will switch to the user's uid before reading the config file. I did try the pam option to allow perms 0660 but because of the uid switch I couldn't get it to work.



and change user and group to root.

        user = root
        group = root

# End Radius config!

# Start of google authenticator config.

First add a unix user. This will be the user account you configure for the VPN. I'll make a testuser account. Afterwards log as test user and setup google-authenticator. BTW you might want to full size your ssh session so you can see the full QRcode on the console (yes that work.. amamzing).

root@FW750:/pam# adduser testuser
Adding user `testuser' ...
Adding new group `testuser' (1000) ...
Adding new user `testuser' (1000) with group `testuser' ...
Creating home directory `/home/testuser' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for testuser
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
root@FW750:/pam# su - testuser
testuser@FW750:~$ google-authenticator

Answer yes to all questions, open the app and take a pic of the QRcode with the app (i used iOS version). This will fully configure the OTP app. Side note.. that is so cool..

# End of google config

OK, lets fire it up!

logout of the chroot jail and start the radius server.

root@FW750:/# exit
[Expert@FW750]# chroot /mnt/sd/test/kali-chroot freeradius
[Expert@FW750]# ps axuw | egrep '[U]SER|[f]reeradius'
root     24025  0.5  0.8  55624  8332 ?        Ssl  06:27   0:00 freeradius

# Firewall config (ok well I created the loop00 interface way above but firewall config!)

Now to wrap everything up, make your firewall rules look like this.

Then go to VPN -> Authinication Servers -> Primary Raidius -> Configure ( here the is. My doesn't say configure because I already configured it). Also make sure you're using the same secret key from the radius config.

Lastly hit the "permissions for RADIUS users" and fill everything out. Make sure the check mark is enabled. Send all users. I'm not sure that the role matters. I think its just adding an extra A/V pair that the radius server is ignoring, but i went with network admin.

And then to wrap up the config. Setup freeradius to start on startup.

Here is my startup script.

[Expert@FW750]# cat /pfrm2.0/etc/userScript
mount /dev/sda1 /mnt/sd
mount -t proc proc /mnt/sd/kali-chroot/proc
mount -t sysfs sysfs /mnt/sd/kali-chroot/sys
ln -s /bin/busybox /bin/crond
mkdir -p /mnt/sd/backups
mkdir -p /var/spool/cron/crontabs/
cp /storage/*.zip /mnt/sd/backups
echo '1 1 * * *  cp /storage/*.zip /mnt/sd/backups' >> /var/spool/cron/crontabs/root
chmod 600 /var/spool/cron/crontabs/root
chroot /mnt/sd/kali-chroot freeradius

# If something goes wrong!

Most the the problems I were with the radius configs. If you want to debug radius run it with the -XXX arguments and you'll get a decent amount of debug output. It can also be useful to start rsyslog inside the chroot for more log. Also the google pam module has a debug option. Follow the link at the top for more info. In addition you can add the word "debug" to the line in /etc/pam.d/radiusd file. This will spit out helpful into on what Google Authenticator is doing. Make sure NTP is enabled and that the clock is synced. If not you'll have to sync the clock and possibly recreate the token.

# I want more users!
So login to the chroot and add them! Just run through the google authenticator config section for every user.

That's all for now!

Tuesday, January 17, 2017

Installing Kali Linux on a Checkpoint 750 SMB Gaia Emebedded Firewall

Hi all! Its been a little while since I posted something. I've had a little side project I've been working and I just got everything setup. I have a different write up describing how to install a Debian (ehem stable) chroot on a SD card in a Checkpoint SMB 750 running Gaia Emebedded. Well, I found an easier way to do this. Basically install your favorite Debian based OS (Debian or. um.. how about Kali Rolling!? ok ok I'm pretty sure Ubuntu would work also) on a VM and install the debootstrap package (apt-get install debootstrap).

BTW i'm assuming you have a SD card and that its formatted for a Linux file system on in. Oh right...sorry I forgot the 750 doesn't have a file system util; we'll cover how to address that also.

First lets assume you've installed Kali somewhere.. maybe a VM, booted up and logged in. Take a look at /etc/apt-sources.list. I see this.

deb kali-rolling main non-free contrib

The important part is the URL and the kali-rolling. This is where to get the files and which version.

The following command will grab everything and put it in ~/kail-chroot, extract it, but not complete the install (--foreign). Also note its downloading the arm binaries.

debootstrap --arch armhf --foreign kali-rolling kali-chroot

After a few mins and a lot of stuff on the screen about packages you'll have a folder called ~/kail-chroot.

# formating SD card. Skip to #finish installing kali if you already have a linux file system on the sd card.

Now.. first thing we need to do is reformat that pesky sd car if you haven't already.

Grab, hopefully, all the files needed to run mke2fs from kali-choot

tar -zcvf mke2fs.tgz kali-chroot/sbin/ kali-chroot/bin/ kali-chroot/lib/ kali-chroot/etc/ kali-chroot/root/

copy mke2fs.tgz to your firewall and put it in /storage using scp or whatever. We're just using this as a temp holding area so that we can run mke2fs

On the firewall run the following.

cd /storage
tar -zxvf mke2fs.tgz
mkdir storage/kali-chroot/dev
cp /dev/sda* /storage/kali-chroot/dev/
umount /dev/sda1
chroot /storage/kali-chroot

At this point you should see

I have no name!@FW750:/#

Thats ok, fdisk -l /dev/sda should show some info about the sd card most likely a msdos filesystem. If the umount give filesystem busy or something like that open the webui on your firewall and "Logs and Monitoring" -> Options -> "Eject SD card safely" and the umount should work.. or it will already be unmounted.

Now you can format the sd card with ext3 or ext4. I went with ext3 for basically no good reason (or because i thought this was an 1100 that doesn't support ext4 take, take your pick).

Assuming everything is umounted run the following to format with ext3 (or change to ext4).

mke2fs -t ext3 /dev/sda1
mount /dev/sda1 /mnt/sd

lots of stuff later and you have a ext3 (or 4) filesystem! This is good because it can repair itself (angy look for no fsck) and its a real linux filesystem.

You can now delete /storage/kali-chroot if you want.

# finish installing kali!

ok back on your kali install VM or where ever you installed it.

Make a new tar file that will include the full kali we downloaded earlier.

tar -zcvf kali-choot.tgz kali-chroot/

upload kali-chroot.tgz to /mnt/sd/

Back to the firewall.. and uncompress everything.

cd /mnt/sd
tar -zxvf kali-choot.tgz

Login to the chroot

chroot /mnt/sd/kali-chroot bash -l

if you see something like this.. its game on!

[Expert@FW]# chroot /mnt/sd/kali-chroot bash -l

Now finish the installer!

[Expert@FW]# ./debootstrap/debootstrap --second-stage

lots of stuff will fly by.. unpacking, installing, etc.

That,s basically it! Now you have a kali install on your firewall. I should point out its a very minimal install. Also there maybe utilities that come with kali that won't work for a lot of reasons (no memory being a big one). 
I left out a final step. You need to mount proc and sysfs!
If you're inside the jail run this.
mount -t proc proc /proc
mount -t sysfs sysfs /sys
If you outside of the jail
mount -t proc proc /mnt/sd/kali-chroot/proc
mount -t sysfs sysfs /mnt/sd/kali-chroot/sys
Also be sure to add the following to the startup script. This way this gets mounted on start of the firewall (assuming you want to, which i do)

# mount sda1 because mounting happens after startup script.
mount /dev/sda1 /mnt/sd
mount -t proc proc /mnt/sd/kali-chroot/proc
mount -t sysfs sysfs /mnt/sd/kali-chroot/sys

Now i'm sure you're thinking.. what is this point of this? I'll get to that real soon My G^2.  

Saturday, September 10, 2016

How to install Debian on Gaia Embedded - 700/1400 (not 1200R (ok and not 600/1100*))

UPDATE: Turns out this doesn't work on the 600/1100 (wah waaaah). Need some more testing (Yeah, I totally tested this on a 600/1100 before posting) to see if i can work around libc issue.

I recently... well maybe not that recently.. spent a few months working on building cross compilers that matched up %100 to a given Checkpoint Gaia Embedded system. Meaning, same libc (glibc 2.5, what a pain!), compiler version (based on glibc output) and kernel heads version.

I thought this was needed so that everything would be compatible. Well, turns out I made things way harder then it should have been. I recently found out that glibc is basically backwards compatible. There may be edge cases where things don't end up right, but for the most part, it seems pretty darn backwards compatible.

So that got me thinking. I started downloading .deb files and extracting them on my 750 and pretty much everything worked. Granted there was a lot of tracing library dependencies. So knowing that all worked I switched gears. I bought a 32 gig microsd card and installed it. I did format it to ext4 since vfat isn't a linux friendly file system. Side note: of course 7xx doesn't have the mkfs.ext4. Sigh... I'll have to map out all the needed libraries for that and point out the download links.

So the next idea was, can we just install debian on the 750 in a chroot environment? It turns out, yeah. I used the Debootstrap to create the chroot. It took a little while as it needs perl and wget and a few other things. The default wget on Gaia Embedded doesn't support https so just to be safe I pulled wget down also.

Before continuing, this is not supported by anyone. I would only do this on a test box, and not on a production firewall.

Basically I downloaded all these utilities on a spare Linux box in our Miami office:


I put them on a linux box and extracted them using this... somewhat nasty process:

for x in `ls *.deb` ; do ar xv $x ; tar -zxvf data.tar.gz ; tar -Jxvf data.tar.xz ; done

What I'm doing is expanding the .deb archive, which contains 3 or more files. The binaries are in a file called data.tar.gz (gziped) or data.tar.xz (lzma). I would have done this on Checkpoint Gaia Embedded but it doesn't include anything uncompress lzma. Kind of a brute force method to extract everything, but it worked. After that the raw files are ready to install on your Checkpoint firewall.

Next I just moved the files over to the Maimi Checkpoint firewall, so now I have this:

[Expert@FWCKP750]# ls -l
drwxr-xr-x 2 root root 4096 Sep 10 10:49 bin
drwxr-xr-x 5 root root 4096 Sep 10 10:13 etc
drwxr-xr-x 3 root root 4096 Sep 10 09:40 lib
drwxr-xr-x 2 root root 4096 Sep 10 09:33 sbin
drwxr-xr-x 7 root root 4096 Sep 10 09:47 usr
drwxr-xr-x 3 root root 4096 Sep 10 09:33 var
[Expert@FWCKP750]# pwd

Debootstrap is really just a shell script so once you have everything you can just run it. You also don't have to run it in Miami, I won't tell anyone if you do.

I did make a small script to setup library and path so the debootstrap files are used first. The last item was to tell debootstrap where its shell include files were.

I put this in

[Expert@FWCKP750]# pwd

[Expert@FWCKP750]# cat
declare -x DEBOOTSTRAP_DIR="/mnt/sd/debian/cnf/bootstrap/usr/share/debootstrap/"
declare -x LD_LIBRARY_PATH="/mnt/sd/debian/cnf/bootstrap/usr/lib/arm-linux-gnueabihf:/mnt/sd/debian/bootstrap/usr/lib:/mnt/sd/debian/bootstrap/lib/arm-linux-gnueabihf:/mnt/sd/debian/bootstrap/lib:.:/pfrm2.0/lib:/pfrm2.0/lib/iptables:"
declare -x PATH="/mnt/sd/cnf/debian/bootstrap/usr/bin:/mnt/sd/debian/bootstrap/usr/sbin:/mnt/sd/debian/bootstrap/sbin:/usr/local/bin:/usr/bin:/bin:/pfrm2.0/bin:/pfrm2.0/bin/cli:/pfrm2.0/bin/cli/provisioning:.:/usr/local/sbin:/usr/sbin:/sbin:/opt/fw1/bin"

This will suck in those settings for this login session on the Miami Checkpoint firewall.


That should be about all that is needed to run debootstrap. Next, just make the dir you want to install the OS into and run debootstrap.

mkdir /mnt/sd/stable-chroot

Then fire off debootstrap.

debootstrap --arch arghf stable /mnt/sd/stable-chroot

With luck and about 15 min you'll have a fully installed OS. We'll need a few little tweaks to wrap this up.

We need to mount proc and sysfs inside the chroot.

I added these statements to my userScript to handle this at bootup (yes the Miami Checkpoint firewall):

[Expert@FWCKP750]# ls -l userScript
-rwxr-xr-x 1 root root 120 Sep 10 12:01 userScript
[Expert@FWCKP750]# cat userScript
mount /dev/mmcblk1 /mnt/sd
mount proc /mnt/sd/stable-chroot/proc -t proc
mount sysfs /mnt/sd/stable-chroot/sys -t sysfs

You can just run those mount commands by hand also if you want. The mount /mnt/sd isn't
needed if the system is already up and running as it should auto mount. However,
the auto mount happens after userScript. Adding the mount to userScript is the workaround.

Now you're ready to jump in. Here I login to the chroot and then show python version
and perl version install.

[Expert@FWCKP750]# chroot /mnt/sd/stable-chroot bash -l
root@FWCKP750:/# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin root@FWCKP750:/# cat /etc/debian_version 8.5
root@FWCKP750:/# python3 -V Python 3.4.2
root@FWCKP750:/# perl -v This is perl 5, version 20, subversion 2 (v5.20.2) built for arm-linux-gnueabihf-thread-multi-64int (with 81 registered patches, see perl -V for more detail) Copyright 1987-2015, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at, the Perl Home Page. root@FWCKP750:/#

The install is about 500meg. Fits just great on a 32gig sd card, but is way too big without it.

I should point out things will work just fine inside the chroot. Once you logout, some things
will work outside of the chroot (/mnt/sd/stable-chroot/usr/bin/lsof for example), others you
may need to create a shell script to add library search and path statements, or in the case of
perl and python, do something to tell it where the modules are located.

I hope I didn't loose you at inside the chroot and outside the chroot. Chroot is a linux command that CHanges the ROOT dir.

So outside the chroot means the dir structure would look like this for example:

inside the chroot it would look like this.

Here is an example:
First I login to the chroot (now I'm inside)
[Expert@FWCKP750]# chroot /mnt/sd/stable-chroot bash -l
I create a file called TestFile
root@FWCKP750:/# touch TestFile
Notice how i'm in /
root@FWCKP750:/# pwd
And we see the TestFile
root@FWCKP750:/# ls
TestFile boot etc lib mnt proc run srv tmp var
bin dev home media opt root sbin sys usr
root@FWCKP750:/# exit
Now I logout. Notice out the directory changes? I'm now outside the chroot.
[Expert@FWCKP750]# pwd
[Expert@FWCKP750]# ls
TestFile dev lib opt run sys var
bin etc media proc sbin tmp
boot home mnt root srv usr
Hope that clears things up!

One interesting thing I noticed was the default ip utilties package on gaia embedded says
it doesn't support netns (Network Name Space (think VSX)), but using the Debian ip utility I was able to create a netns name. I haven't looked into this any further.

I'll have to run through the whole process again to make sure I documented it correctly.

Wait what? You would like a tar file of the debootstrap dir?

ok ok ok. Here you go.

debootstrap - 600 / 1100 / 700 / 1400

Thursday, September 8, 2016

Meetup group created!

Hi everyone, if you live in south Florida (or close enough) you should join the Meetup! The South Florida Checkpoint Zdebug Group - SFCZG for short! We're just getting started with the meetup. We're researching a location somewhere in Miami. Might expand to Fort Lauderdale at some point, but for now we'll be sticking to Miami for the Checkpoint meetup.

Join and drop a line!

Wednesday, July 13, 2016

Enhanced TCP logging options.

There is an interesting post on cpug about tcp logging options. You can get a lot more details on what happened to a tcp connection, such as when it expired, why it closed etc. Take a look!

TCP State Logging sk101221

Monday, July 4, 2016

4th of July Sheboygan Beer Brats

We're taking a moment away from Check Point firewall posts in Miami to describe how to make your very own firewalls... I mean Sheboygan Bier Brats. For those who don't know, my wife is from the German province of Wisconsin and this will cover how to make a proper brat!


Here are pics of everything.

Brats - out of package (yes warrenty voided)

This is really only 2... and it might have been white. The first one was yellow for sure!

Yes, the whole thing! Pretend you're German!

MUSTARD BEER MUG POWER!!! It's only 8 ounces btw.

BTW Bubbie's pickles are amazing. We're using Bubbie's Sauerkraut since we don't have a German Grandmother handy to make it for us. Heat and serve either on the side, or on the brat.

ok how to do this..

Hurl brats in a pot of ice water. This will help prevent bursting on the grill is what legends of old tell us. Do this for about 10 mins.

Important! The next 2 steps are done at the same time. Cook brats and heat up the da bier unions and butta.

Step 1 - cooking brats

Put your electric grill on medium low. You want to make sure the grill doesn't get too hot or the brats will burst. However, this should still be enough power to flip the breaker and kill power to the flat. 

This way, your Mobile Access Blade demo you're working on can go down hard and your wife can bring up (again!) how she has been saying for 3 weeks you need to get a UPS for your lab gear. You'll of course want to admit she is right, as always. Don't turn the servers back on, but reset the breaker.

If you can, don't use an electric grill! Charcoal is best.

Grill the brats for about 30 mins then turn them over and cook for another 30 min. This isn't a hard rule. The key is cook slow and make sure they're cooked. When you poke them, they should be firm and look like this just after turning.

Cooked, and ready to simmer in the butta and da bier!

While the brats are cooking put the da biers in the a pot with unions and da butta.

Step 2 Cooking the brine.

Put 9 x 12 oz of da biers, unions, butta in a pot on low. You don't want anything above a simmer.

Ok so let's assume steps 1 and 2 are complete. 

Ask the dog if she has found a job yet.

The lack of eye contact is not a good sign.

Patio lizard is not amused.

Use ray gun to increase dog's head to show your displeasure.

Now, take your brats and put them in the brine and let simmer for about an hour if you can stand it.

Now we didn't do this last step, but its pretty darn good. Do this if you have access to hard rolls (yes again they are soft and don't ask). Cut open the bun and only dip the open part of the bun in the brine, just enough to toast. Then grill the bun brine side down. This will take it to another level. We didn't do that this time.

Finished product. Yes, I know that's wine, we only had 3 da biers. We had no choice!