| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| Redhat_VSFTPD_Server---CP_FW---Gentoo_Linux_Client The checkpoint firewall is running IPSO 4.1 build 33 with NGx R61 with HFA_02. It is being managed by a Provider-1 (SPLAT) NGx R61 with HFA_02. There is no NAT on the firewall, just routing. I enable SmartDefense on the CMA to block all known ports for FTP. I have a very simple rule: Any Any FTP accept log On the FTP Server, I modified the vsftpd.conf file to allow passive mode and specify the passive range between 1520 and 1800. After that, I restarted the vsftpd daemon (service vsftpd restart). Now from the gentoo linux client, I perform ftp connection (ftp 192.168.15.10) to the ftp server with a valid account on the ftp server: Gen2Linux ~ # cd /tmp Gen2Linux tmp # ftp 192.168.15.10 Connected to 192.168.15.10 (192.168.15.10). 220 (vsFTPd 1.2.0) Name (192.168.15.10:root): admin 530 Please login with USER and PASS. SSL not available 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> bin 200 Switching to Binary mode. ftp> prompt Interactive mode off. ftp> hash Hash mark printing on (1024 bytes/hash mark). ftp> passive Passive mode on. ftp> ls 227 Entering Passive Mode (192,168,15,10,6,16) 150 Here comes the directory listing. drwxr-xr-x 8 501 501 4096 Jul 04 04:23 Service -rw-r--r-- 1 501 501 37918648 Jul 03 21:34 ipso371build020.tgz drwxr-xr-x 4 501 501 4096 Jul 04 03:53 replica_package 226 Directory send OK. ftp> On the FTP Server, this is what I am seeing: [root@dca2-LinuxES root]# tcpdump -i eth0 -n host 198.147.14.60 tcpdump: listening on eth0 09:52:05.917006 198.147.14.60.50586 > 192.168.15.10.h323gatedisc: S 3181618356:3181618356(0) win 5840 <mss 1460,sackOK,timestamp 14945005 0,nop,wscale 2> (DF) 09:52:05.917058 192.168.15.10.h323gatedisc > 198.147.14.60.50586: S 1475061600:1475061600(0) ack 3181618357 win 5792 <mss 1460,sackOK,timestamp 12209006 14945005,nop,wscale 0> (DF) 09:52:05.917998 198.147.14.60.50586 > 192.168.15.10.h323gatedisc: . ack 1 win 1460 <nop,nop,timestamp 14945005 12209006> (DF) 09:52:05.918140 198.147.14.60.56826 > 192.168.15.10.ftp: P 42:48( 09:52:13.172622 198.147.14.60.55101 > 192.168.15.10.gdp-port: . ack 1 win 1460 <nop,nop,timestamp 14945730 12209731> (DF) 09:52:13.172843 198.147.14.60.56826 > 192.168.15.10.ftp: P 150:156(6) ack 1386 win 1460 <nop,nop,timestamp 14945730 12209731> (DF) [tos 0x10] 09:52:13.173021 192.168.15.10.ftp > 198.147.14.60.56826: P 1386:1425(39) ack 156 win 5792 <nop,nop,timestamp 12209731 14945730> (DF) 09:52:13.173284 192.168.15.10.gdp-port > 198.147.14.60.55101: P 1:302(301) ack 1 win 5792 <nop,nop,timestamp 12209731 14945730> (DF) [tos 0x8] 09:52:13.173322 192.168.15.10.ftp > 198.147.14.60.56826: P 1425:1449(24) ack 156 win 5792 <nop,nop,timestamp 12209731 14945730> (DF) 09:52:13.173359 192.168.15.10.gdp-port > 198.147.14.60.55101: F 302:302(0) ack 1 win 5792 <nop,nop,timestamp 12209731 14945730> (DF) [tos 0x8] 09:52:13.174689 198.147.14.60.55101 > 192.168.15.10.gdp-port: . ack 302 win 1728 <nop,nop,timestamp 14945730 12209731> (DF) [tos 0x8] 09:52:13.175077 198.147.14.60.55101 > 192.168.15.10.gdp-port: F 1:1(0) ac 09:54:39.799188 198.147.14.60.59197 > 192.168.15.10.sa-msg-port: S 3337646170:3337646170(0) win 5840 <mss 1460,sackOK,timestamp 14960393 0,nop,wscale 2> (DF) 09:54:39.799262 192.168.15.10.sa-msg-port > 198.147.14.60.59197: S 1620672975:1620672975(0) ack 3337646171 win 5792 <mss 1460,sackOK,timestamp 12224394 14960393,nop,wscale 0> (DF) 09:54:39.800184 198.147.14.60.59197 > 192.168.15.10.sa-msg-port: . ack 1 win 1460 <nop,nop,timestamp 14960393 12224394> (DF) 09:54:39.800330 198.147.14.60.45607 > 192.168.15.10.ftp: P 293:299(6) ack 2417 win 1460 <nop,nop,timestamp 14960393 12224394> (DF) [tos 0x10] 09:55:01.059062 198.147.14.60.39612 > 192.168.15.10.tftp-mcast: S 3363041828:3363041828(0) win 5840 <mss 1460,sackOK,timestamp 14962519 0,nop,wscale 2> (DF) 09:55:01.059142 192.168.15.10.tftp-mcast > 198.147.14.60.39612: S 1651134495:1651134495(0) ack 3363041829 win 5792 <mss 1460,sackOK,timestamp 12226520 14962519,nop,wscale 0> (DF) 09:55:01.060111 198.147.14.60.39612 > 192.168.15.10.tftp-mcast: . ack 1 win 1460 <nop,nop,timestamp 14962519 12226520> (DF) 09:55:01.060259 198.147.14.60.45607 > 192.168.15.10.ftp: P 341:347(6) ack 2865 win 1460 <nop,nop,timestamp 14962519 12226520> (DF) [tos 0x10] 09:55:01.060471 192.168.15.10.ftp > 198.147.14.60.45607: P 2865:2904(39) ack 347 win 5792 <nop,nop,timestamp 12226520 14962519> (DF) 09:55:01.060761 192.168.15.10.tftp-mcast > 198.147.14.60.39612: P 1:302(301) ack 1 win 5792 <nop,nop,timestamp 12226520 14962519> (DF) [tos 0x8] 09:55:01.060801 192.168.15.10.ftp > 198.147.14.60.45607: P 2904:2928(24) ack 347 win 5792 <nop,nop,timestamp 12226520 14962519> (DF) 09:55:01.060843 192.168.15.10.tftp-mcast > 198.147.14.60.39612: F 302:302(0) ack 1 win 5792 <nop,nop,timestamp 12226520 14962519> (DF) [tos 0x8] 09:55:01.062162 198.147.14.60.39612 > 192.168.15.10.tftp-mcast: . ack 302 win 17 Why is SmartDefense NOT blocking "KNOWN PORTS"? So much for being "Smart"? Can someone explain this? Thanks. |
![]() |
| Thread Tools | |
| Display Modes | |
| |