Get IP before doing "call [accept]"?

Index > Windows > Get IP before doing "call [accept]"?

Goto page 1, 2 Next

Author

Thread

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 19 Mar 2009, 13:11

How do I get the IP of an incoming connection attempt before accepting it?

And how do I reject an incoming connection, so nothing is sent in reply to it?

I know this can be done at the driver level but is there any way to do it in usermode? Installing drivers is troublesome in Vista and up.

For example this

Code:

push       rAddressSize
push    rAddress
push        [hSock]
call [accept]
cmp dword[rAddress],1234567
je   KillConnection

Gets it but only AFTER replying. How do I get it without first replying to the remote computer? Confused

Here is example scenario to try to explain in case my code example was bad;

Stranger knocks at door
You peek out the window, see he has a gun, and decide to bolt the door shut instead of answering

I want that, instead of

Stranger knocks at door
You open the door and say hello
You look at stranger, stranger looks at you
You say goodbye and close the door (after he knows you are home)

In otherwords
Syn is sent to my computer.. if IP is bad one (in static list of bad IP, or just has made to many requests in short amount of time), then don't even send syn ack back to him.

Please help Confused

19 Mar 2009, 13:11

SFeLi

Joined: 03 Nov 2004
Posts: 138

SFeLi 19 Mar 2009, 13:41

AFAIK, it is not possible without writing a driver. Also WSAAccept could help you, but the second scenario is more polite and portable.

19 Mar 2009, 13:41

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 19 Mar 2009, 15:06

SFeLi wrote:

AFAIK, it is not possible without writing a driver. Also WSAAccept could help you, but the second scenario is more polite and portable.

Thank you..

19 Mar 2009, 15:06

r22

Joined: 27 Dec 2004
Posts: 805

r22 20 Mar 2009, 13:16

You could use UDP instead of TCP. You'd still have to 'recvFrom', but the client won't receive a response unless you give him one.

20 Mar 2009, 13:16

comrade

Joined: 16 Jun 2003
Posts: 1150
Location: Russian Federation

comrade 20 Mar 2009, 17:59

Be aware of all the differences that UDP will bring... no guarantees on delivery, no guarantees on sequence, etc...

20 Mar 2009, 17:59

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 20 Mar 2009, 19:00

r22 wrote:

You could use UDP instead of TCP. You'd still have to 'recvFrom', but the client won't receive a response unless you give him one.

Thanks. I don't know how to make a web server with UDP that will work with most browsers, though. Please advise. Confused

Also how would the necessary reliability be achieved? Will the client send back a packet with checksum of mine whenever he receives one from me (and vice-versa)? Or something else? Confused

20 Mar 2009, 19:00

comrade

Joined: 16 Jun 2003
Posts: 1150
Location: Russian Federation

comrade 20 Mar 2009, 20:07

Browsers expect to use TCP, so I don't think there is anyway to use UDP here.

Reliability in TCP is achieved with a variation on a simple send-and-acknowledge protocol (but modified in such a way to minimize the effects of latency/propagation delay). Sequencing (in-order packet receival) is achieved with something called sliding windows. I don't remember the details, you should pick up a networking book or search for this stuff online Smile

The book we used in college was written Alberto Leon Garcia, but I know there is another popular one used as well...

20 Mar 2009, 20:07

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 20 Mar 2009, 21:29

I have conducted a little experiment, added a MessageBox call under the .accept label of the Quetannon example. The result was that the connection was established even though "invoke accept,[sock],0,0" wasn't executed yet.

Here Wireshark capture with a Quetannon server at port 8080 (shown as "http-alt" on dump), and a Quetannon client on another computer:

Code:

No.     Time        Source                Destination           Protocol Info
     20 1.320171    192.168.1.2           192.168.1.101         TCP      jetformpreview > http-alt [SYN] Seq=0 Win=65535 Len=0 MSS=1460

Frame 20 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a), Dst: Micro-St_d1:69:22 (00:11:09:d1:69:22)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: jetformpreview (2097), Dst Port: http-alt (8080), Seq: 0, Len: 0

----------

No.     Time        Source                Destination           Protocol Info
     21 1.320197    192.168.1.101         192.168.1.2           TCP      http-alt > jetformpreview [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460

Frame 21 (58 bytes on wire, 58 bytes captured)
Ethernet II, Src: Micro-St_d1:69:22 (00:11:09:d1:69:22), Dst: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: jetformpreview (2097), Seq: 0, Ack: 1, Len: 0

----------

No.     Time        Source                Destination           Protocol Info
     22 1.320644    192.168.1.2           192.168.1.101         TCP      jetformpreview > http-alt [ACK] Seq=1 Ack=1 Win=65535 Len=0

Frame 22 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a), Dst: Micro-St_d1:69:22 (00:11:09:d1:69:22)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: jetformpreview (2097), Dst Port: http-alt (8080), Seq: 1, Ack: 1, Len: 0

So unless you have some special setting on the socket the hand-shake will take place even if you don't accept it.

20 Mar 2009, 21:29

SFeLi

Joined: 03 Nov 2004
Posts: 138

SFeLi 20 Mar 2009, 21:37

LocoDelAssembly, could you please test WSAAccept on socket with SO_CONDITIONAL_ACCEPT set? I believe Windows would not answer to the connection request till the filter function return something and if you return CF_REJECT from it Windows would send RST. Right?

20 Mar 2009, 21:37

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 20 Mar 2009, 21:50

Sorry, I completely overlooked your post.

Do you mean this? What I have to do to make it work in user-mode?

[edit]I think I have found it: http://msdn.microsoft.com/en-us/library/dd264794(VS.85).aspx . I'll try that later (but the thread's starter can start testing it before me of course Wink

)

20 Mar 2009, 21:50

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 21 Mar 2009, 06:21

SFeLi wrote:

LocoDelAssembly, could you please test WSAAccept on socket with SO_CONDITIONAL_ACCEPT set? I believe Windows would not answer to the connection request till the filter function return something and if you return CF_REJECT from it Windows would send RST. Right?

Sending RST is as bad as sending SYN ACK.. it still lets them know that I am there, and still wastes bandwidth.. or am I missing something here? Confused

I'm still pretty newb in this area. I just want to learn from the ground up how to make a network app as securely as possible, without relying on kernel mode drivers.

21 Mar 2009, 06:21

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 21 Mar 2009, 07:29

OK, this is the server:

Code:

format pe console
include 'win32ax.inc'

BANNED_IP = $0201A8C0 ; 192.168.1.2 in big endian (this is valid for my own testing, you may use a different IP address here)
BIND_PORT = $901F     ; 8080 in big endian

;;;;;; Stuff not available in standard package
SOCKET_ERROR          = -1
WSAECONNREFUSED       = 10061

SOL_SOCKET            = $FFFF
SO_CONDITIONAL_ACCEPT = $3002

CF_ACCEPT             = $0000
CF_REJECT             = $0001
CF_DEFER              = $0003

struct WSABUF
  len dd ?
  buf dd ?
ends
;;;;;;

      cinvoke printf, <"Calling WSAStartup", 10>
      invoke  WSAStartup, $0202, wsadata

      test    eax, eax
      jnz     error

      cinvoke printf, <"Calling socket", 10>
      invoke  socket, AF_INET, SOCK_STREAM, 0

      mov     ebx, eax
      cmp     eax, SOCKET_ERROR
      je      error

      cinvoke printf, <"Calling setsockopt (to set SO_CONDITIONAL_ACCEPT option)", 10>
      invoke  setsockopt, ebx, SOL_SOCKET, SO_CONDITIONAL_ACCEPT, optvalBuff, optlenBuff

      test    eax, eax
      jnz     error

      cinvoke printf, <"Calling bind", 10>
      invoke  bind, ebx, saddr, sizeof.sockaddr_in

      test    eax, eax
      jnz     error

      cinvoke printf, <"Calling listen", 10>
      invoke  listen, ebx, 1

      test    eax, eax
      jnz     error

      invoke  printf, <"Calling WSAAccept (execution will stop here until a connection request is made)", 10>
      invoke  WSAAccept, ebx, NULL, NULL, ConditionFunc, NULL

      mov     edi, eax
      cmp     eax, SOCKET_ERROR
      je      errorAccept

      cinvoke printf, <"Calling closesocket (for listening socket)", 10>
      invoke  closesocket, ebx

      test    eax, eax
      jnz     error

      cinvoke printf, <"Calling send... ">
      invoke  send, edi, welcomeMessage, sizeof.welcomeMessage, 0

      cmp     eax, SOCKET_ERROR
      je      error

      cinvoke printf, <"%u bytes has been sent (buffer size is %u)", 10>, eax, sizeof.welcomeMessage

      cinvoke printf, <"Calling closesocket (for accepted socket)", 10>
      invoke  closesocket, edi ; This is indeed very important since without it nothing is recieved by the remote host when I tested it

      test    eax, eax
      jnz     error

exit:
      cinvoke printf, <"Shutting down...", 10>
      invoke  WSACleanup
      invoke  ExitProcess, 0

error:
      push    eax ; This push is parameter for printf
      invoke  WSAGetLastError
.show:
      cinvoke printf, <"Error condition detected, program aborted", 10, "WSAGetLastError = %X", 10, "EAX = %X", 10>, eax
      jmp     exit

errorAccept:
      push    eax ; This push is parameter for printf
      invoke  WSAGetLastError

      cmp     eax, WSAECONNREFUSED
      jne     error.show

      cinvoke printf, <"Connection rejected by the condition function", 10>
      jmp     exit

proc ConditionFunc, lpCallerId, lpCallerData, lpSQOS, lpGQOS, lpCalleeId, lpCalleeData, g, dwCallbackData

      mov     eax, [lpCalleeData]
      mov     [eax+WSABUF.len], 0

      mov     eax, [lpCallerId]
      test    eax, eax
      jz      .reject

      mov     eax, [eax+WSABUF.buf]
      cmp     dword [eax+sockaddr_in.sin_addr], BANNED_IP
      je      .reject

.accept:
      mov     eax, CF_ACCEPT

.exit:
      ret

.reject:
      mov     eax, CF_REJECT
      jmp     .exit
endp


align 4 ; Just to be safe
data import 
  library kernel32, 'kernel32.dll',\
          msvcrt,'msvcrt.dll',\
          winsock,'ws2_32.DLL'

  import kernel32,\
         ExitProcess, 'ExitProcess'

  import msvcrt,\
         printf, 'printf'

  import winsock,\
         WSAStartup, 'WSAStartup',\
         WSACleanup, 'WSACleanup',\
         WSAAccept, 'WSAAccept',\
         WSAGetLastError, 'WSAGetLastError',\
         socket, 'socket',\
         bind, 'bind',\
         listen, 'listen',\
         WSAaccept, 'WSAaccept',\
         recv, 'recv',\
         send, 'send',\
         closesocket, 'closesocket',\
         setsockopt, 'setsockopt'
end data

optvalBuff dd TRUE
optlenBuff dd 4

welcomeMessage db "Greetings curious visitor, I'm going to kill this connection right now.", 10,\
                  "Have a nice day (I don't really care, I'm just a computer anyway)",10
sizeof.welcomeMessage = $ - welcomeMessage

saddr sockaddr_in AF_INET,\   ; sin_family
                  BIND_PORT,\ ; sin_port
                  0,          ; sin_addr
store byte 0 at $-1           ; To ensure sin_zero[8] array will be filled with zeros

wsadata WSADATA

And this is the capture using a banned remote host with Quetannon:

Code:

No.     Time        Source                Destination           Protocol Info
      1 0.000000    192.168.1.2           192.168.1.101         TCP      sabams > http-alt [SYN] Seq=0 Win=65535 Len=0 MSS=1460

Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a), Dst: Micro-St_d1:69:22 (00:11:09:d1:69:22)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: sabams (2760), Dst Port: http-alt (8080), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
      2 0.000068    192.168.1.101         192.168.1.2           TCP      http-alt > sabams [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

Frame 2 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: Micro-St_d1:69:22 (00:11:09:d1:69:22), Dst: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: sabams (2760), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
      3 0.435566    192.168.1.2           192.168.1.101         TCP      sabams > http-alt [SYN] Seq=0 Win=65535 Len=0 MSS=1460

Frame 3 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a), Dst: Micro-St_d1:69:22 (00:11:09:d1:69:22)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: sabams (2760), Dst Port: http-alt (8080), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
      4 0.435595    192.168.1.101         192.168.1.2           TCP      http-alt > sabams [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

Frame 4 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: Micro-St_d1:69:22 (00:11:09:d1:69:22), Dst: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: sabams (2760), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
      5 0.936264    192.168.1.2           192.168.1.101         TCP      sabams > http-alt [SYN] Seq=0 Win=65535 Len=0 MSS=1460

Frame 5 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a), Dst: Micro-St_d1:69:22 (00:11:09:d1:69:22)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: sabams (2760), Dst Port: http-alt (8080), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
      6 0.936284    192.168.1.101         192.168.1.2           TCP      http-alt > sabams [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

Frame 6 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: Micro-St_d1:69:22 (00:11:09:d1:69:22), Dst: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: sabams (2760), Seq: 1, Ack: 1, Len: 0

BTW, there is a bug in the server which makes the server unresponsive to remote hosts at times by an unknown reason (the connection is refused as shown in the dump above but WSAAccept never returns).

21 Mar 2009, 07:29

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 21 Mar 2009, 07:33

LocoDelAssembly wrote:

OK, this is the server:

Code:

format pe console
include 'win32ax.inc'

BANNED_IP = $0201A8C0 ; 192.168.1.2 in big endian (this is valid for my own testing, you may use a different IP address here)
BIND_PORT = $901F     ; 8080 in big endian

;;;;;; Stuff not available in standard package
SOCKET_ERROR          = -1
WSAECONNREFUSED       = 10061

SOL_SOCKET            = $FFFF
SO_CONDITIONAL_ACCEPT = $3002

CF_ACCEPT             = $0000
CF_REJECT             = $0001
CF_DEFER              = $0003

struct WSABUF
  len dd ?
  buf dd ?
ends
;;;;;;

      cinvoke printf, <"Calling WSAStartup", 10>
      invoke  WSAStartup, $0202, wsadata

      test    eax, eax
      jnz     error

      cinvoke printf, <"Calling socket", 10>
      invoke  socket, AF_INET, SOCK_STREAM, 0

      mov     ebx, eax
      cmp     eax, SOCKET_ERROR
      je      error

      cinvoke printf, <"Calling setsockopt (to set SO_CONDITIONAL_ACCEPT option)", 10>
      invoke  setsockopt, ebx, SOL_SOCKET, SO_CONDITIONAL_ACCEPT, optvalBuff, optlenBuff

      test    eax, eax
      jnz     error

      cinvoke printf, <"Calling bind", 10>
      invoke  bind, ebx, saddr, sizeof.sockaddr_in

      test    eax, eax
      jnz     error

      cinvoke printf, <"Calling listen", 10>
      invoke  listen, ebx, 1

      test    eax, eax
      jnz     error

      invoke  printf, <"Calling WSAAccept (execution will stop here until a connection request is made)", 10>
      invoke  WSAAccept, ebx, NULL, NULL, ConditionFunc, NULL

      mov     edi, eax
      cmp     eax, SOCKET_ERROR
      je      errorAccept

      cinvoke printf, <"Calling closesocket (for listening socket)", 10>
      invoke  closesocket, ebx

      test    eax, eax
      jnz     error

      cinvoke printf, <"Calling send... ">
      invoke  send, edi, welcomeMessage, sizeof.welcomeMessage, 0

      cmp     eax, SOCKET_ERROR
      je      error

      cinvoke printf, <"%u bytes has been sent (buffer size is %u)", 10>, eax, sizeof.welcomeMessage

      cinvoke printf, <"Calling closesocket (for accepted socket)", 10>
      invoke  closesocket, edi ; This is indeed very important since without it nothing is recieved by the remote host when I tested it

      test    eax, eax
      jnz     error

exit:
      cinvoke printf, <"Shutting down...", 10>
      invoke  WSACleanup
      invoke  ExitProcess, 0

error:
      push    eax ; This push is parameter for printf
      invoke  WSAGetLastError
.show:
      cinvoke printf, <"Error condition detected, program aborted", 10, "WSAGetLastError = %X", 10, "EAX = %X", 10>, eax
      jmp     exit

errorAccept:
      push    eax ; This push is parameter for printf
      invoke  WSAGetLastError

      cmp     eax, WSAECONNREFUSED
      jne     error.show

      cinvoke printf, <"Connection rejected by the condition function", 10>
      jmp     exit

proc ConditionFunc, lpCallerId, lpCallerData, lpSQOS, lpGQOS, lpCalleeId, lpCalleeData, g, dwCallbackData

      mov     eax, [lpCalleeData]
      mov     [eax+WSABUF.len], 0

      mov     eax, [lpCallerId]
      test    eax, eax
      jz      .reject

      mov     eax, [eax+WSABUF.buf]
      cmp     dword [eax+sockaddr_in.sin_addr], BANNED_IP
      je      .reject

.accept:
      mov     eax, CF_ACCEPT

.exit:
      ret

.reject:
      mov     eax, CF_REJECT
      jmp     .exit
endp


align 4 ; Just to be safe
data import 
  library kernel32, 'kernel32.dll',\
          msvcrt,'msvcrt.dll',\
          winsock,'ws2_32.DLL'

  import kernel32,\
         ExitProcess, 'ExitProcess'

  import msvcrt,\
         printf, 'printf'

  import winsock,\
         WSAStartup, 'WSAStartup',\
         WSACleanup, 'WSACleanup',\
         WSAAccept, 'WSAAccept',\
         WSAGetLastError, 'WSAGetLastError',\
         socket, 'socket',\
         bind, 'bind',\
         listen, 'listen',\
         WSAaccept, 'WSAaccept',\
         recv, 'recv',\
         send, 'send',\
         closesocket, 'closesocket',\
         setsockopt, 'setsockopt'
end data

optvalBuff dd TRUE
optlenBuff dd 4

welcomeMessage db "Greetings curious visitor, I'm going to kill this connection right now.", 10,\
                  "Have a nice day (I don't really care, I'm just a computer anyway)",10
sizeof.welcomeMessage = $ - welcomeMessage

saddr sockaddr_in AF_INET,\   ; sin_family
                  BIND_PORT,\ ; sin_port
                  0,          ; sin_addr
store byte 0 at $-1           ; To ensure sin_zero[8] array will be filled with zeros

wsadata WSADATA

And this is the capture using a banned remote host with Quetannon:

Code:

No.     Time        Source                Destination           Protocol Info
      1 0.000000    192.168.1.2           192.168.1.101         TCP      sabams > http-alt [SYN] Seq=0 Win=65535 Len=0 MSS=1460

Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a), Dst: Micro-St_d1:69:22 (00:11:09:d1:69:22)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: sabams (2760), Dst Port: http-alt (8080), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
      2 0.000068    192.168.1.101         192.168.1.2           TCP      http-alt > sabams [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

Frame 2 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: Micro-St_d1:69:22 (00:11:09:d1:69:22), Dst: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: sabams (2760), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
      3 0.435566    192.168.1.2           192.168.1.101         TCP      sabams > http-alt [SYN] Seq=0 Win=65535 Len=0 MSS=1460

Frame 3 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a), Dst: Micro-St_d1:69:22 (00:11:09:d1:69:22)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: sabams (2760), Dst Port: http-alt (8080), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
      4 0.435595    192.168.1.101         192.168.1.2           TCP      http-alt > sabams [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

Frame 4 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: Micro-St_d1:69:22 (00:11:09:d1:69:22), Dst: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: sabams (2760), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
      5 0.936264    192.168.1.2           192.168.1.101         TCP      sabams > http-alt [SYN] Seq=0 Win=65535 Len=0 MSS=1460

Frame 5 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a), Dst: Micro-St_d1:69:22 (00:11:09:d1:69:22)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: sabams (2760), Dst Port: http-alt (8080), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
      6 0.936284    192.168.1.101         192.168.1.2           TCP      http-alt > sabams [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

Frame 6 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: Micro-St_d1:69:22 (00:11:09:d1:69:22), Dst: Pro-Nets_55:cc:9a (00:06:4f:55:cc:9a)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: sabams (2760), Seq: 1, Ack: 1, Len: 0

BTW, there is a bug in the server which makes the server unresponsive to remote hosts at times by an unknown reason (the connection is refused as shown in the dump above but WSAAccept never returns).

Is there a way to get rid of this part?? "http-alt > sabams [RST, ACK]"

Then it would be perfect..

21 Mar 2009, 07:33

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 21 Mar 2009, 07:49

If there is one I'm unaware of it. I have just posted that to confirm to SFeLi the TCP/IP behavior when the SO_CONDITIONAL_ACCEPT is set.

The people from outside will probably see it as a computer without firewall, but if they can detect that something is servicing at 8080 port because of a difference (if any) between a SO_CONDITIONAL_ACCEPT port and a real closed port I don't know.

Anyway, Microsoft discourages the use of this because besides it reduces networking performance, it also disables the built-it SYN attack protection.

Have you investigated about the availability of APIs that can configure the installed firewall? There are many programs that are able to communicate with the Windows firewall (eMule for example), but I don't know if them work when a third party firewall is installed.

BTW, almost 5:00 AM here, I'll go to sleep now if you don't mind Smile

21 Mar 2009, 07:49

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 21 Mar 2009, 07:57

LocoDelAssembly wrote:

If there is one I'm unaware of it. I have just posted that to confirm to SFeLi the TCP/IP behavior when the SO_CONDITIONAL_ACCEPT is set.

The people from outside will probably see it as a computer without firewall, but if they can detect that something is servicing at 8080 port because of a difference (if any) between a SO_CONDITIONAL_ACCEPT port and a real closed port I don't know.

Anyway, Microsoft discourages the use of this because besides it reduces networking performance, it also disables the built-it SYN attack protection.

Have you investigated about the availability of APIs that can configure the installed firewall? There are many programs that are able to communicate with the Windows firewall (eMule for example), but I don't know if them work when a third party firewall is installed.

BTW, almost 5:00 AM here, I'll go to sleep now if you don't mind

Thanks, I guess I'll just try to interface with the Windows firewall then.

I hate the idea of running two software firewalls at the same time, though.. Crying or Very sad

And I'd really prefer for the block just to be with my process, instead of everything on the computer (last time I checked Windows firewall has no way to block an IP on certain ports, only the whole computer).

Can you please tell me why it would reduce performance to do it at process level? It seems like it would be faster since the processing would only be done on traffic to that port instead of everything..

21 Mar 2009, 07:57

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 21 Mar 2009, 17:44

Well it is not specified by I believe the problem is due to the extra kernel-mode to user-mode transitions caused by your program asking more participation on the handshake processing. I suppose that the performance reduction is only seen on the port you bind with the conditional option, the rest of the traffic is not affected by this probably.

About the Windows' firewall, in the part of port blocking you have the option to specify what IP or IP blocks you want to be blocked (the option is called scope or so, don't remember and my WinXP doesn't have firewall at all because it was nLite'd).

Anyway, perhaps you don't need to have two firewalls, maybe the API allows you to control a third party firewall that supports the firewall API. Check with eMule to see if it is able to open the ports on firewalls other than the one that comes with Windows.

21 Mar 2009, 17:44

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 21 Mar 2009, 17:52

LocoDelAssembly wrote:

Well it is not specified by I believe the problem is due to the extra kernel-mode to user-mode transitions caused by your program asking more participation on the handshake processing. I suppose that the performance reduction is only seen on the port you bind with the conditional option, the rest of the traffic is not affected by this probably.

Wouldn't it only be slower if my handshake processing routines were less efficient then the Windows ones? It has to transition anyways, to send the data to my process. Why would handling the handshake there be slower?

LocoDelAssembly wrote:

About the Windows' firewall, in the part of port blocking you have the option to specify what IP or IP blocks you want to be blocked (the option is called scope or so, don't remember and my WinXP doesn't have firewall at all because it was nLite'd).

Yes I know it has some kind of rudimentary IP blocking, or it wouldn't even count as a firewall at all. I was asking if it's possible to specify a port as part of the IP block (block meaning to block, not meaning a range of IPs). I just want this to be for my process not the whole machine..

LocoDelAssembly wrote:

Anyway, perhaps you don't need to have two firewalls, maybe the API allows you to control a third party firewall that supports the firewall API. Check with eMule to see if it is able to open the ports on firewalls other than the one that comes with Windows.

I doubt there are any remotely decent firewalls or antiviruses that would allow user mode programs to tamper with them.
They would be functionally useless if they allowed that.
Please correct me if I'm wrong and there is a way to mess with the ESET firewall from a user mode process.
Although I'd dump it in favor of something else if there was, so I guess that's rather academic.

21 Mar 2009, 17:52

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 21 Mar 2009, 18:27

Quote:

Yes I know it has some kind of rudimentary IP blocking, or it wouldn't even count as a firewall at all. I was asking if it's possible to specify a port as part of the IP block (block meaning to block, not meaning a range of IPs). I just want this to be for my process not the whole machine..

Yes, you block the port but additionally you specify the scope of blocking and on this scope you set the banned IP addresses.

Quote:

I doubt there are any remotely decent firewalls or antiviruses that would allow user mode programs to tamper with them.
They would be functionally useless if they allowed that.

Firewalls are supposed to protect you from outside attacks, if you execute malware on your computer then the AV is responsible for blocking it or you by using a Windows account with low enough privileges to prevent firewall settings changes (then your server would run under a separate user with enough privileges to make changes).

Seems to be a firewall API after all, check.

But before doing anything just try eMule to see if it is able to set up your third party firewall.

[edit] Check this link, maybe there is something useful on the posted links: http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/e0c85889-7427-4c19-b771-589b47251fc9/ [/edit]

21 Mar 2009, 18:27

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 21 Mar 2009, 18:33

LocoDelAssembly wrote:

Quote:

Yes I know it has some kind of rudimentary IP blocking, or it wouldn't even count as a firewall at all. I was asking if it's possible to specify a port as part of the IP block (block meaning to block, not meaning a range of IPs). I just want this to be for my process not the whole machine..

Yes, you block the port but additionally you specify the scope of blocking and on this scope you set the banned IP addresses.

How? I only see an option to block an IP from everything, or to block a port from all IPs. I see no option to block an IP from a port.

LocoDelAssembly wrote:

Quote:

I doubt there are any remotely decent firewalls or antiviruses that would allow user mode programs to tamper with them.
They would be functionally useless if they allowed that.

Firewalls are supposed to protect you from outside attacks, if you execute malware on your computer then the AV is responsible for blocking it

I can't rely on a firewall that isn't even leak proof, and don't want to have two firewalls active at the same time..

LocoDelAssembly wrote:

or you by using a Windows account with low enough privileges to prevent firewall settings changes (then your server would run under a separate user with enough privileges to make changes).

Seems to be a firewall API after all, check.

But before doing anything just try eMule to see if it is able to set up your third party firewall.

Sorry, I should have clarified; I don't want kernel mode privileges on this. I'm looking for a user mode solution.

21 Mar 2009, 18:33

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 21 Mar 2009, 18:49

Where do you see kernel-mode privileges? It is administrator privileges what is required at most but always in user-mode.

The scope thing here: http://www.minasi.com/sp1r2book/ch8.pdf (page 91 [17th])

21 Mar 2009, 18:49

Goto page 1, 2 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum