Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
04-24-2007, 09:36 AM
|
#1
|
Member
Registered: Jan 2006
Distribution: Debian Testing
Posts: 675
Rep:
|
SSH subject question on packet monitoring
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
|
|
|
04-25-2007, 03:57 AM
|
#2
|
Member
Registered: Aug 2005
Distribution: Debian, OpenBSD, PFsense
Posts: 73
Rep:
|
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
Last edited by mastrboy; 04-25-2007 at 03:58 AM.
|
|
|
04-25-2007, 04:13 AM
|
#3
|
LQ Guru
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733
|
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.
Last edited by jschiwal; 04-25-2007 at 04:15 AM.
|
|
|
04-25-2007, 09:43 AM
|
#4
|
Member
Registered: Jan 2006
Distribution: Debian Testing
Posts: 675
Original Poster
Rep:
|
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.
|
|
|
04-29-2007, 05:25 AM
|
#5
|
LQ Guru
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870
|
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
|
|
|
04-30-2007, 01:22 AM
|
#6
|
Member
Registered: Jan 2006
Distribution: Debian Testing
Posts: 675
Original Poster
Rep:
|
Very cool. That must be how they are doing it and I think I should add that into my firewall.
|
|
|
All times are GMT -5. The time now is 05:47 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|