SSH subject question on packet monitoring

nomb · 04-24-2007, 09:36 AM

Hey guys,

I work for a fairly large corporation and set up my personal server's ssh to go through port 443 hoping that I would be able to reach it from work.

Well, I can't.

Firstly, I'm not looking for help on getting that to work. The net admin obviously doesn't want it working so thats good enough for me, plus I have a vpn connection anyway. My question is more because I'm confused on how they could be filtering it. Even tho I went through cisco and thought myself pretty knowledgeable.

If 443 is used for the correct purpose it works great so I know the port is open. Also if you point at my
domain:443 you get the standard ssh banner displaying the version and everything. I was always under the impression if for example you could go to a wab page through port 80 it was open and could be used. How else can traffic be filtered because I think I would like to imploy it onto my own server.

Do you think the firewall is comparing the size of the transmission on port 443 to what it should be? seeing its to big and saying no? Or could it maybe be looking at the structure of the packet and realizing it to be ssh?

Anyway thanks for your input.

nomb

mastrboy · 04-25-2007, 03:57 AM

they could have some kind of packet inspection, 1 string in the ssh server is sent in clear text, and they could block if this string is found, try telnet to your ssh server and see.

Output of telnet to my ssh server: SSH-2.0-OpenSSH_4.3p2 Debian-9

So if they look for the string SSH and then block the connection by inspecting the packages.
(even snort can do this)

and checkpoint fw-1 has something thats called smartdefense which does the same thing.

edit: stupid typos

jschiwal · 04-25-2007, 04:13 AM

You may be going through a man-in-the-middle proxy server for https. If you are on the web on a secure site, you might want to look at the certificate. It it belongs to your company, then that is the case. Your browser may be issued the company-wide proxy certificate instead. Then the traffic is unencrypted, examined or stored and re-encrypted with the target website's certificates.

Quote:

The net admin obviously doesn't want it working

He doesn't want users connecting to their home machines and possibly infecting the work computers with malware. However, if some users have laptops that they take home, that is the most likely way a virus can get inside the network.

nomb · 04-25-2007, 09:43 AM

Well telnet is blocked. Any other ideas?
Also another big reason is because I do web development for a major insurance company and they don't want info leaked out.

win32sux · 04-29-2007, 05:25 AM

Quote:

Originally Posted by nomb

How else can traffic be filtered because I think I would like to imploy it onto my own server.

you could do it with iptables, by using the u32 and string matches...

Quote:

Checking for values in the TCP payload

As with the udp payload example above, this approach is only useful if we're absolutely certain of where our data of interest can be found. In this example, I want to find ssh sessions, even if they're on a port _other_ than 22. But wait - ssh connections are encrypted! Sounds hopeless? Actually, it isn't.

The first thing to happen in an ssh connection is that the server sends a protocol string back to the client. The protocol looks like: SSH-protoversion-softwareversion comments

The protoversion is generally 1.99, 2.0, or 1.5 . The entire line, including a possible trailing carriage return and linefeed, needs to be smaller than 255 bytes. This line _may_ have another line before it, but this would break compatibility with ssh 1.0 clients, so I'm guessing this is uncommon. The above information comes from draft-ietf-secsh-transport-17.txt , if you want to see more details.

The interesting piece, as far as we're concerned, is that "SSH-" string. It lands in the first 4 bytes of the connection. Bingo! We can use the u32 module to look at only those bytes in the early part of a connection; this is a much less intensive check than checking with the string module, and makes it feasible to look for ssh connections on any port without undue load on the firewall.

Lets get the easy stuff out of the way. I want to check tcp packets, unfragmented ones, I'm only interested in packets in the first 255 bytes of a connection, and established ones, obviously, and the entire packet length needs to be between 45 and 375 bytes (think about the minimums and maximums for IP and tcp headers and ssh protocol string):
iptables -p tcp \! -f -m connbytes --connbytes 0:255 -m state --state ESTABLISHED -m length --length 46:375

With these restrictions, we should be inspecting very few packets; this allows us to look at the first few packets of every connection for legitimate or rogue ssh connections.

Now u32 does its magic. We'll build it up from scratch. Because we've already checked for protocol TCP, we'll skip 6&0xFF=0x6. We skip over the IP header with 0>>22&0x3C@:
0>>22&0x3C@

We now need to skip over the tcp header; we pull the TCP header length from the first half of byte 12. Although we'd need to right shift it 28 bits to get it into the last 4 bits of our 32 bit buffer, we have to multiply this by 4, too, to get the number of 4-byte words this number expresses; this is why we right shift by 26 and mask again with 0x3C:
0>>22&0x3C@ 12>>26&0x3C@

This slides us into the tcp payload portion of the packet. As the bytes we want to test should generally be in the first 4 bytes of the packet, we just grab 4 bytes starting at 0 and compare them to 0x5353482D (the hex equivalent of "SSH-"):
0>>22&0x3C@ 12>>26&0x3C@ 0=0x5353482D

Here's the entire test, line wrapped to save screen space:
iptables -p tcp \! -f -m connbytes --connbytes 0:255 -m state --state ESTABLISHED -m length --length 46:375 -m u32 --u32 "0>>22&0x3C@ 12>>26&0x3C@ 0=0x5353482D"

Once I've done this, I can even check for specific SSH protocol versions with -m string --string "SSH-1.99" or even as specific as -m string --string "SSH-1.99-OpenSSH_3.7.1p2" . This string match - normally very expensive in terms of processor time per packet - isn't bad at all if we've already figured out with the previous iptables command that this is almost certainly an ssh protocol string. By essentially requiring "SSH-" in the first 4 bytes of the connection, we avoid the problem of the string match incorrectly matching "SSH-" when someone downloads this article over port 80.

Taken from: http://www.stearns.org/doc/iptables-u32.current.html

nomb · 04-30-2007, 01:22 AM

Very cool. That must be how they are doing it and I think I should add that into my firewall.