Hi. I am relatively new to the list, and Linux in general. I have tried to find out more about security in man files and a couple of books, trying to make my machines more secure. While i was online yesterday and today I have noticed in my console that I had been portscanned. Sorry for the Spam on this, this is just what they sent. Feb 14 10:57:59 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports 1764, 1765, 1766, 1767, 1768, 1769, 1770, 1771, 1772, ..., flags ??rp?u, TOS 10, TTL 114, started at 10:57:45 Feb 14 11:21:26 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports 1800, 1801, 1802, 1803, 1804, 1805, 1806, 1807, 1808, ..., flags ??rp?u, TOS 10, TTL 114, started at 11:21:12 Feb 14 11:30:56 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports 1819, 1820, 1821, 1822, 1823, 1824, 1825, 1826, 1827, ..., flags ??rp?u, TOS 10, TTL 114, started at 11:30:42 Feb 14 16:28:07 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports 1902, 1903, 1904, 1905, 1906, 1907, 1908, 1909, 1910, ..., flags ??rp?u, TOS 10, TTL 114, started at 16:27:55 Feb 14 16:50:44 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports 1925, 1926, 1927, 1928, 1929, 1930, 1931, 1932, 1933, ..., flags ??rp?u, TOS 10, TTL 114, started at 16:50:29 Feb 14 17:02:38 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports 1976, 1977, 1978, 1979, 1980, 1981, 1982, 1983, 1984, ..., flags ??rp?u, TOS 10, TTL 114, started at 17:02:23 Feb 14 17:33:54 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, ..., flags ??rp?u, TOS 10, TTL 114, started at 17:33:40 Feb 14 21:03:23 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports 2052, 2053, 2054, 2055, 2056, 2057, 2058, 2059, 2060, ..., flags ??rp?u, TOS 10, TTL 114, started at 21:03:11 Feb 15 13:42:21 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports 2120, 2121, 2122, 2123, 2124, 2125, 2126, 2127, 2128, ... Now i have a small linux machine used to masquerade for the machines in our local setup so we can use the internet together. This is my ipchains setup at the moment (I know there is an SuSE packet filter script, I just havent got to grips with it yet :(, but at least im trying to find out the answers) <start of shell script> INTERNAL=192.168.0.0/24 echo -n "Turning on packet filtering:" # Stop all the rules before we set up the new ones echo 0 > /proc/sys/net/ipv4/ip_forward # set the default policy to REJECT /sbin/ipchains -X /sbin/ipchains -F /sbin/ipchains -P input REJECT /sbin/ipchains -P output REJECT /sbin/ipchains -P forward REJECT # Attempt to stop spoofing ipchains -A input -s 192.168.0.0/24 -i ppp0 -j REJECT -l ipchains -A input -s 127.0.0.1 -i ppp0 -j REJECT -l # Set up the input # Allow loopback connections ipchains -A input -s 127.0.0.1 -j ACCEPT # Allow the internal net to the internal net ipchains -A input -s $INTERNAL -d $INTERNAL -j ACCEPT # Allow the internal net to the external net ipchains -A input -s 127.0.0.1 -d ! $INTERNAL -j ACCEPT ipchains -A input -s $INTERNAL -d ! $INTERNAL -j ACCEPT # Allow the external net to the internal net # the active FTP stuff here. ipchains -A input -p tcp -s ! $INTERNAL 20 -j ACCEPT ipchains -A input -p tcp -s ! $INTERNAL 21 -j ACCEPT # Deny all incoming SYN requests on TCP ipchains -A input -p tcp -s ! $INTERNAL ! -y -j ACCEPT ipchains -A input -p udp -s ! $INTERNAL -d ! $INTERNAL -j ACCEPT ipchains -A input -s ! $INTERNAL -d ! $INTERNAL -j REJECT # Set up the forwarding chain # Allow forwarding in the internal net ipchains -A forward -s $INTERNAL -d $INTERNAL -j ACCEPT # Masqurade the internal to the external net ipchains -A forward -s $INTERNAL -d ! $INTERNAL -j MASQ # Masqurade should take care of external to internal # this should stop non masquraded forwarding ipchains -A forward -s ! $INTERNAL -d $INTERNAL -j REJECT # Set up the output rules ipchains -A output -j ACCEPT ipchains -P input REJECT ipchains -P output REJECT ipchains -P forward REJECT echo 1 > /proc/sys/net/ipv4/ip_forward <end of script> All I want the external network to do is send ICQ packets inside. Otherwise stop anything not a reply to a masqed packet. My questions are as follows (and i know they may be foolish): How did the person doing the portscan mannage to send thier packets to my internal machine 192.168.0.51 directly ? (I have noticed a lack of the same activity on the router which is 192.168.0.50 and i thought all my packets would look like they came from there) How can I get more information about the scanner on that host. I have tried to do the usual of host 216.77.42.93 and got no host, I've done a traceroute so I know what machines it goes through. I've tried to telnet to a few ports to see if they have any open to get the name of the place. I just want more information so I can keep tabs on it and mail the admin about the activities. Can anyone give me a few links to places to find out mroe about security in general. Thank you for your patience with this newbie. Stephen Thompson
HiHO...
Feb 14 10:57:59 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports ^^ # Allow the external net to the internal net # the active FTP stuff here. ipchains -A input -p tcp -s ! $INTERNAL 20 -j ACCEPT
this is, how the packages came in...
ipchains -A input -p udp -s ! $INTERNAL -d ! $INTERNAL -j ACCEPT
what is the sense of this rule ?? not FROM internal and not TO internal ??? only packets from external to your world decices will match this rule...
ipchains -A input -s ! $INTERNAL -d ! $INTERNAL -j REJECT
# Set up the forwarding chain # Allow forwarding in the internal net ipchains -A forward -s $INTERNAL -d $INTERNAL -j ACCEPT
i don't think, you really need this rule- forwarding is between two interfaces, e.g. eth0 <-> ppp0 and your internal net is connected to one interface, and the machines communicate directly, without the router...
# Masqurade should take care of external to internal # this should stop non masquraded forwarding ipchains -A forward -s ! $INTERNAL -d $INTERNAL -j REJECT
i think, masquerading won't work at all with this rule- no packet will be forwarded back to internal ?
All I want the external network to do is send ICQ packets inside. Otherwise stop anything not a reply to a masqed packet.
hmmm, i could't find any rules for icq (but i don't know, which ports are used)
How did the person doing the portscan mannage to send thier packets to my internal machine 192.168.0.51 directly ?
i think it was an active ftp-request, (20 -> 1023:), i don't really understand, which way the packets took back to you, as the masquerading should not work in my eyes. maybe the module ip_masq_ftp does it ?? any hints please)
and i thought all my packets would look like they came from there)
no, the packets come from there, but tey look, like they come from where they come...
How can I get more information about the scanner on that host. I have tried to do the usual of host 216.77.42.93 and got no host, I've done a traceroute so I know what machines it goes through. I've tried to telnet to a few ports to see if they have any open to get the name of the place. I just want more information so I can keep tabs on it and mail the admin about the activities.
i think you were on the right way- the only service provided by this machine is ftp. but i don't think, it was really a scan. it won't be possible to adress a package to an adress with 192.168.x.x - it never would find the way to you. it would be only possible to scan that host from within your net and for this your router must be hacked and the sender adress would not be from outside your network. i didn't check everything in your setup, but it looks quite broken to me. maybe you should try to update the suse-firewall to 1.4 and try a configuration like this: FW_DEV_WORLD="ppp0" FW_DEV_INT="eth0" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_LOCALNETS="192.168.0.0/24" FW_MASQ_DEV="$FW_DEV_WORLD" FW_KERNEL_SECURITY="yes" FW_AUTOPROTECT_GLOBAL_SERVICES="yes" FW_PROTECT_FROM_INTERNAL="no" FW_TCP_SERVICES_EXTERNAL="" FW_UDP_SERVICES_EXTERNAL="" FW_TRUSTED_HOSTS="" FW_TCP_SERVICES_TRUSTED="" FW_UDP_SERVICES_TRUSTED="" FW_TCP_SERVICES_INTERNAL="" FW_UDP_SERVICES_INTERNAL="" FW_TCP_ALLOW_INCOMING_HIGHPORTS="" FW_UDP_ALLOW_INCOMING_HIGHPORTS="dns" FW_SERVICE_DNS="no" FW_FORWARD_TCP="" FW_FORWARD_UDP="" FW_REDIRECT_TCP="" FW_REDIRECT_UDP="" FW_LOG_DENY_CRIT="yes" FW_LOG_DENY_ALL="no" FW_LOG_ACCEPT_CRIT="yes" FW_LOG_ACCEPT_ALL="no" FW_ALLOW_FW_PING="no" FW_ALLOW_FW_TRACEROUTE="no" FW_ALLOW_FW_SOURCEQUENCH="yes" FW_MASQ_MODULES="ftp " with this configuration everything will be masqueraded, only passive ftp is possible and i don't know, if icq will work. you will find information on this in /etc/rc.firewall and in /usr/doc/packages/firewals so far... ____________________________________________________________ | .~. s.martin@odn.de | | /V\ fon +49(0)911.2256 03 | | /( )\ fax +49(0)911.2256 06 | | ^`~'^ mobile +49(0)173.380 43 12 | | pgp: http://www.xhponozon.com/keys/stephan.asc | |___________________________________________________________|
Hy, Stephan Martin wrote:
HiHO...
Feb 14 10:57:59 reaper scanlogd: From 216.77.42.93:20 to 192.168.0.51 ports ^^
If it realy was an aktive ftp connection, the dest. port should be 20 and not the source port, like here. IMHO it was a portscan, no ftp.
# Allow the external net to the internal net # the active FTP stuff here. ipchains -A input -p tcp -s ! $INTERNAL 20 -j ACCEPT
this is, how the packages came in...
yes ! But why this rule ? You have to open the dest. Port, not the source Port: ipchains -A input -p tcp -s ! $INTERNAL --dport 20 -j ACCEPT or better: ipchains -A input -p tcp -s ! $INTERNAL -d $INTERNAL 20 -j ACCEPT
# Set up the forwarding chain # Allow forwarding in the internal net ipchains -A forward -s $INTERNAL -d $INTERNAL -j ACCEPT
i don't think, you really need this rule- forwarding is between two interfaces, e.g. eth0 <-> ppp0 and your internal net is connected to one interface, and the machines communicate directly, without the router...
ACK
# Masqurade should take care of external to internal # this should stop non masquraded forwarding ipchains -A forward -s ! $INTERNAL -d $INTERNAL -j REJECT
i think, masquerading won't work at all with this rule- no packet will be forwarded back to internal ?
I think it works ! The packets are demasqueraded automaticaly by the kernel.
All I want the external network to do is send ICQ packets inside. Otherwise stop anything not a reply to a masqed packet.
hmmm, i could't find any rules for icq (but i don't know, which ports are used)
Also don`t know.
How did the person doing the portscan mannage to send thier packets to my internal machine 192.168.0.51 directly ?
i think it was an active ftp-request, (20 -> 1023:), i don't really understand, which way the packets took back to you, as the masquerading should not work in my eyes. maybe the module ip_masq_ftp does it ?? any hints please)
an aktive ftp-request uses the oposite ports: 1023: -> 20 not 20 -> 1023:
and i thought all my packets would look like they came from there)
no, the packets come from there, but tey look, like they come from where they come...
?
How can I get more information about the scanner on that host. I have tried to do the usual of host 216.77.42.93 and got no host, I've done a traceroute so I know what machines it goes through. I've tried to telnet to a few ports to see if they have any open to get the name of the place. I just want more information so I can keep tabs on it and mail the admin about the activities.
i think you were on the right way- the only service provided by this machine is ftp. but i don't think, it was really a scan. it won't be possible to adress a package to an adress with 192.168.x.x - it never would find the way to you. it would be only possible to scan that host from within your net and for this your router must be hacked and the sender adress would not be from outside your network.
ip-spoofing ? source-routing ?
i didn't check everything in your setup, but it looks quite broken to me.
To me too :-( Did you copy it from somewhere, or wrote it yourselfe ?
maybe you should try to update the suse-firewall to 1.4 and try a configuration like this: [suse-firewall-script-options dumped]
I don`t know the suse-firewall-script, but IMHO it is no good idea to use a firewall script which you don`t fully understand. cu, Ray -- __ _ Raymond Häb, ray.haeb@gmx.net, cologne, germany / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . .
HiHO...
If it realy was an aktive ftp connection, the dest. port should be 20 and not the source port, like here. IMHO it was a portscan, no ftp.
yes ! But why this rule ? You have to open the dest. Port, not the source Port:
ipchains -A input -p tcp -s ! $INTERNAL --dport 20 -j ACCEPT
or better:
ipchains -A input -p tcp -s ! $INTERNAL -d $INTERNAL 20 -j ACCEPT
that's wrong. an *active* ftp-session works like that: -> the client opens command channel to server port 21: client 1023: --> server 21 -> and then the server opens the data channel from port 20 to the client: client 1023: <-- server 20 that's the reason, why it's quite ugly to use active ftp through a packet filter. you have to allow incoming packages without ack-bit (initializing a connection) from every host in the internet to every port above 1023. and because it's not difficult to start a connection from port 20 when you've got root permissions, an attacker can open connections through your filter to every port above 1023.
I think it works ! The packets are demasqueraded automaticaly by the kernel.
that was, what i didn't know for sure. if the kernel does it, is it possible to avoid it with unloading ip_masq_ftp ??
an aktive ftp-request uses the oposite ports: 1023: -> 20 not 20 -> 1023:
see above...
ftp. but i don't think, it was really a scan. it won't be possible to adress a package to an adress with 192.168.x.x - it never would find the way to you. it would be only possible to scan that host from within your net and for this your router must be hacked and the sender adress would not be from outside your network.
ip-spoofing ?
in that case i think the sender-adress should be something within the inetrnal net and no ip-adress from anywhere else ??
source-routing ?
i think the standard kernels should be compiled with "drop source routed packages" ???
I don`t know the suse-firewall-script, but IMHO it is no good idea to use a firewall script which you don`t fully understand.
it's a script, which allows very much configuration with variables, and due to this it's creating a lot of rules, which are quite complicated to understand in short time. that's the reason, why i don't use it. but i think, it's better to use this package in a wuite good configuration, than using something selfmade, which looks more strange... stephan ____________________________________________________________ | .~. s.martin@odn.de | | /V\ fon +49(0)911.2256 03 | | /( )\ fax +49(0)911.2256 06 | | ^`~'^ mobile +49(0)173.380 43 12 | | pgp: http://www.xhponozon.com/keys/stephan.asc | |___________________________________________________________|
participants (3)
-
Raymond Haeb -
Stephan Martin -
Stephen Thompson