Deny SSH connection, but can still connect ? [Archive]

malexe

December 3rd, 2009, 20:23

I have this rule
10200 allow tcp from any to any dst-port 22 in via bge0 setup keep-state

and I can connect via ssh to the server.

So why do I have such thing in my log:
Dec 3 19:19:56 hostname kernel: ipfw: 50000 Deny TCP source_ip:63209 my_server_ip:22 in via bge0

I use FreeBSD 8.0 with IPFW.

graudeejs

December 3rd, 2009, 20:30

perhaps you have deny quick few lines higher...

Or deny .... few lines lower... for this statement

malexe

December 3rd, 2009, 20:48

here is my complete list of ipfw rules:

00300 allow ip from any to any via lo0
00301 allow ip from any to any via tap0
00500 check-state
01000 allow ip from any to any out via bge0 keep-state
10050 allow tcp from any to any dst-port 80 in via bge0 setup keep-state
10080 allow tcp from any to any dst-port 888 in via bge0 setup keep-state
10100 allow tcp from any to any dst-port 9418 in via bge0 setup keep-state
10199 allow tcp from any to any dst-port 22 in setup keep-state
10200 allow tcp from any to any dst-port 22 in via bge0 setup keep-state
10300 allow udp from any to any dst-port 1194 in via bge0 keep-state
50000 deny log ip from any to any in via bge0
51000 deny log ip from any to any
65535 deny ip from any to any

even If have I have a deny rule after, the packet should be allowed from a rule before it. (And it is allowed, because I can SSH successfully)

graudeejs

December 3rd, 2009, 22:12

UPS... I mistaken it for pf... sorry.... I'm not familiar with ipfw

idle

December 4th, 2009, 13:19

There is always some packets that will not match any rule, and reach the last one.
Even if you have only two:
allow ip from any to any
deny ip from any to any
I don't know why, perhaps some buffer overflow.
It's a rarity, no reason to worry

malexe

December 4th, 2009, 16:12

Really ?! This is the first time I see such behavior. :\

idle

December 4th, 2009, 16:19

Check your counter for rule 65535.
This is mine from one server:
60000 112350152 76310585995 allow ip from any to any
....
65535 249 16583 deny ip from any to any

DutchDaemon

December 4th, 2009, 21:26

I could imagine that IPFW, even in its 'openest' configuration, would still not accept certain out-of-state packets, weird tcp flags combinations, or orphaned/malformed fragments.

anomie

December 4th, 2009, 22:48

@malexe: What ssh client are you using?

It's likely that if you were also logging allowed ssh packets, you'd first see logged accepted packets, followed by one or two logged denied packets.

See DutchDaemon's post above -- your client may just be sending some strange or otherwise unexpected packets during an ssh session.

hedwards

December 6th, 2009, 05:33

I'm not really an expert, but do you really want to have both of these written like that? Looking at the handbook, it appears that setup starts the session, and then you require that the packets come through a specific interface. EDIT: What I mean is that there might be a conflict between these two. I'd consider dropping one temporarily and seeing if that fixes things.

I'm not that familiar with IPFW, but I'd assume that you're starting a session and that the 10200 rule is not matching 10199 because it's not recording the state information as being via the bge0. Which should be the case since you don't want an authenticated session moving between interfaces under normal conditions.
10199 allow tcp from any to any dst-port 22 in setup keep-state
10200 allow tcp from any to any dst-port 22 in via bge0 setup keep-state

malexe

December 8th, 2009, 17:36

@malexe: What ssh client are you using?

It's likely that if you were also logging allowed ssh packets, you'd first see logged accepted packets, followed by one or two logged denied packets.

See DutchDaemon's post above -- your client may just be sending some strange or otherwise unexpected packets during an ssh session.

I am using Putty. Anyone had issue with putty on windows ?o_O

malexe

December 8th, 2009, 17:37

I'm not really an expert, but do you really want to have both of these written like that? Looking at the handbook, it appears that setup starts the session, and then you require that the packets come through a specific interface. EDIT: What I mean is that there might be a conflict between these two. I'd consider dropping one temporarily and seeing if that fixes things.

I'm not that familiar with IPFW, but I'd assume that you're starting a session and that the 10200 rule is not matching 10199 because it's not recording the state information as being via the bge0. Which should be the case since you don't want an authenticated session moving between interfaces under normal conditions.
10199 allow tcp from any to any dst-port 22 in setup keep-state
10200 allow tcp from any to any dst-port 22 in via bge0 setup keep-state

Thanks for noticing that, I will remove one. But I doubt it really has any bad effect.

hedwards

December 11th, 2009, 05:33

Thanks for noticing that, I will remove one. But I doubt it really has any bad effect.
I wouldn't expect it to be causing the problem, but then again I'm not fully familiar with how exactly the states are saved.

And from further review of the error message, it looks like you may have gotten the set up wrong.

50000 deny log ip from any to any in via bge0

^^ Matches.
10200 allow tcp from any to any dst-port 22 in via bge0 setup keep-state
^^ Doesn't match currently. I'd try removing 50000 for the time being and see if that fixes things. I forget if IPFW is a last rule wins system or not.

malexe

December 13th, 2009, 23:43

it is a first rule wins.

Lowell

December 15th, 2009, 17:48

Have you ever noticed a legitimate ssh connection fail? If you can't connect the message to the packet that produced it, there's no way to be sure that you have a real problem.

For example, somebody outside may be trying to sneak a packet through your firewall by sending a TCP packet to port 22 without a SYN but without having an established session. In that case, your firewall is correctly blocking the attack.

It's also possible that the firewall is losing track of the state somehow, but in that case you would notice your established ssh session dropping.

malexe

December 17th, 2009, 20:10

Ok thanks for the information ! I will investigate keeping that in mind.