This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Internal computer was port scanned!

I currently have two Packet Filters defined:

Enabled (Gree) 1. Internal_Network   Any  Any  Allow
Disabled (red)  2. Any  Remote_Desktop  MP2400(single internal computer)  Allow

Here's the kicker though, I was just port scanned by someone on the internet and I got two e-mails.  The first stated my external public IP was portscanned.  Fine, its on the outside, no problem.  The next e-mail a couple seconds later said one of my internal computers named MP2400 (192.168.1.4) was port scanned on 3389 which is the Remote Desktop Protocol.  However, that Packet Rule is RED, meaning its disabled!  How is this possible?  I think there might be an issue as to whether this rule was actually disabled by ASL, even though it was RED and turned off.  Anyone?

My Masq rules are as follows:

Masq_Rule: Internal_Network__ -> All / All MASQ__External None

Remote_Desktop: Any -> External_Interface__ / Remote_Desktop None MP2400 / Remote_Desktop

Now even though the masquerade Remote Desktop Rule is active, shouldn't the packet filter have stopped access to my internal computer?

I have it setup this way so I can remotely activate the RDP packet filter and allow me remote access to my machine.  I shouldn't have to disable the Remote_Desktop Masq rule too should I?

This thread was automatically locked due to age.

Parents

0 cyclops over 21 years ago

Since you have gotten the portscan message your internal host wasn't reached. Due to the linux filtering architecture DNAT happens before filtering, this is why the packet was already translated before the portscan module detected it.

Search for 'picture' in http://docs.astaro.org/older_versions/ASL-V2.0/asl-faq.txt :-)

Greetings
cyclops
Cancel
Vote Up 0 Vote Down

Cancel
0 Jhaislet over 21 years ago in reply to cyclops

I think I understand what you said, but let me clarify if I may.

So the port scan went through the masq table since that was defined for RDP 3389, then the scan worked its way through the various stages of the firewall until it hit the Packet Filter, which is I guess the final door the scan had to pass through before it got to my internal computer. That door was closed, so the scan was dropped (killed).

Am I understanding this correctly?

Hypothetical question here, how would I have known if the port scan had gotten through the Packet Filter zone and actually gotten into my internal network?

Here's the line from the log:

kernel: Portscan detected: IN=eth2 OUT=eth0 SRC=208.180.37.132 DST=192.168.1.4 LEN=40 TOS=0x00 PREC=0x00 TTL=37 ID=38223 PROTO=TCP SPT=65313 DPT=3389 WINDOW=2048 RES=0x00 SYN URGP=0

Thanks for all the help! This is a really friendly board and I can't wait until I learn more about ASL so I can help new comes as well.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 Jhaislet over 21 years ago in reply to cyclops

I think I understand what you said, but let me clarify if I may.

So the port scan went through the masq table since that was defined for RDP 3389, then the scan worked its way through the various stages of the firewall until it hit the Packet Filter, which is I guess the final door the scan had to pass through before it got to my internal computer. That door was closed, so the scan was dropped (killed).

Am I understanding this correctly?

Hypothetical question here, how would I have known if the port scan had gotten through the Packet Filter zone and actually gotten into my internal network?

Here's the line from the log:

kernel: Portscan detected: IN=eth2 OUT=eth0 SRC=208.180.37.132 DST=192.168.1.4 LEN=40 TOS=0x00 PREC=0x00 TTL=37 ID=38223 PROTO=TCP SPT=65313 DPT=3389 WINDOW=2048 RES=0x00 SYN URGP=0

Thanks for all the help! This is a really friendly board and I can't wait until I learn more about ASL so I can help new comes as well.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data