Okay, hear is my ipchains script. I do not have pmfirewall installed. I run this script by typing ./chains
#CUSTOM
ipchains -A input -i eth0 --source 207.218.223.135 -j DENY
ipchains -A input -i eth0 --source 195.229.208.146 -j DENY
# TCP
# serve ftp - 20 and 21
ipchains -A input -i eth0 -p tcp --destination-port 20 --syn -j ACCEPT -l
ipchains -A input -i eth0 -p tcp --destination-port 21 --syn -j ACCEPT -l
# serve ssh - 22
ipchains -A input -i eth0 -p tcp --destination-port 22 --syn -j ACCEPT -l
# serve smtp - 25
ipchains -A input -i eth0 -p tcp --destination-port 25 --syn -j ACCEPT
# serve http - 80
ipchains -A input -i eth0 -p tcp --destination-port 80 --syn -j ACCEPT
# serve http admin - 81
ipchains -A input -i eth0 -p tcp --destination-port 81 --syn -j ACCEPT -l
# serve pop3 - 110
ipchains -A input -i eth0 -p tcp --destination-port 110 --syn -j ACCEPT
# server ssl - 443
ipchains -A input -i eth0 -p tcp --destination-port 443 --syn -j ACCEPT -l
# serve ssl admin - 444
ipchains -A input -i eth0 -p tcp --destination-port 444 --syn -j ACCEPT -l
# server dns - 53
ipchains -A input -i eth0 -p tcp --destination-port 53 -j ACCEPT
# disallow SYN on all else
ipchains -A input -i eth0 -p tcp --syn -j DENY -l
# allow existing TCP sessions to continue
ipchains -A input -i eth0 -p tcp -j ACCEPT
# UDP
# DNS response
ipchains -A input -i eth0 -p udp --source 216.88.76.6 53 -j ACCEPT
ipchains -A input -i eth0 -p udp --source 216.88.77.7 53 -j ACCEPT
ipchains -A input -i eth0 -p udp --source 216.12.215.102 53 -j ACCEPT
ipchains -A input -i eth0 -p udp --source 216.12.215.103 53 -j ACCEPT
ipchains -A input -i eth0 -p udp --destination-port 53 -j ACCEPT
# ICMP allowed
ipchains -A input -i eth0 -p icmp -j ACCEPT
# disallow all else
ipchains -A input -i eth0 -j DENY -l
If I run this script, this is what happens. Notice the cpu usage for syslogd. 69.2%. The box becomes nearly inaccessible. What is wrong with my rules that are causing this.
Top output:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
434 root 10 0 476 472 376 S 0 69.2 0.1 91:57 syslogd
1068 root 2 0 884 884 680 R 0 1.1 0.3 0:03 top
443 root 0 0 728 724 304 R 0 0.1 0.2 0:34 klogd
32664 root 0 0 1356 1344 1056 R 0 0.1 0.5 0:00 sshd
1 root 0 0 476 476 404 S 0 0.0 0.1 0:04 init
2 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kflushd
3 root 0 0 0 0 0 SW 0 0.0 0.0 0:06 kupdate
4 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kpiod
I have also noted that my system does not process mail while ipchains is runing. I has ipchains running all night, and logcheck did not send me a single email. I flushed ipchains, and every hourly email suddenly showed up.
Any ideas!!
Full Version: ipchains question - Help!!
Long night and too tired to look really closely.. this is my manual script and all works with it.. (see below) check differences and see whassup maybe??
My guess is something is logging like crazy into /var/log/kernel and messing with klolgd.. do you have a huge amount of traffic??
You might want to remove a couple of the -l modifiers and see if it still happens..
We are talking about a RaQ also.. right??
Outside of my custom additions to keep out bad guys (which I removed for here) this is my rules..
# TCP
# serve ftp for passive clients_ONLY_
ipchains -A input -i eth0 -p tcp --destination-port 21 --syn -j ACCEPT -l
# serve ssh - 22
ipchains -A input -i eth0 -p tcp --destination-port 22 --syn -j ACCEPT -l
# serve smtp - 25
ipchains -A input -i eth0 -p tcp --destination-port 25 --syn -j ACCEPT
# serve http - 80
ipchains -A input -i eth0 -p tcp --destination-port 80 --syn -j ACCEPT
# serve https admin - 81
ipchains -A input -i eth0 -p tcp --destination-port 81 --syn -j ACCEPT -l
# serve pop3 - 110
ipchains -A input -i eth0 -p tcp --destination-port 110 --syn -j ACCEPT
# disallow SYN on all else
ipchains -A input -i eth0 -p tcp --syn -j DENY -l
# allow existing TCP sessions to continue
ipchains -A input -i eth0 -p tcp -j ACCEPT
# UDP
# DNS response
ipchains -A input -i eth0 -p udp --source 216.88.76.6 53 -j ACCEPT
ipchains -A input -i eth0 -p udp --source 216.88.77.7 53 -j ACCEPT
# ICMP allowed
ipchains -A input -i eth0 -p icmp -j ACCEPT
# disallow all else
ipchains -A input -i eth0 -j DENY -l
Man I'm sleepy but they sure look a lot alike... ???? strange?? Hummn.. if you're getting a lot of FTP connections.. that could be it.. every single file is going to make a log entry twice.. once in /var/log/kernel and once in .. again, I'm tired.. but I believe in var/log/secure..
Turn off the -l on your ftp connect and see if that does it??
Shortness
My guess is something is logging like crazy into /var/log/kernel and messing with klolgd.. do you have a huge amount of traffic??
You might want to remove a couple of the -l modifiers and see if it still happens..
We are talking about a RaQ also.. right??
Outside of my custom additions to keep out bad guys (which I removed for here) this is my rules..
# TCP
# serve ftp for passive clients_ONLY_
ipchains -A input -i eth0 -p tcp --destination-port 21 --syn -j ACCEPT -l
# serve ssh - 22
ipchains -A input -i eth0 -p tcp --destination-port 22 --syn -j ACCEPT -l
# serve smtp - 25
ipchains -A input -i eth0 -p tcp --destination-port 25 --syn -j ACCEPT
# serve http - 80
ipchains -A input -i eth0 -p tcp --destination-port 80 --syn -j ACCEPT
# serve https admin - 81
ipchains -A input -i eth0 -p tcp --destination-port 81 --syn -j ACCEPT -l
# serve pop3 - 110
ipchains -A input -i eth0 -p tcp --destination-port 110 --syn -j ACCEPT
# disallow SYN on all else
ipchains -A input -i eth0 -p tcp --syn -j DENY -l
# allow existing TCP sessions to continue
ipchains -A input -i eth0 -p tcp -j ACCEPT
# UDP
# DNS response
ipchains -A input -i eth0 -p udp --source 216.88.76.6 53 -j ACCEPT
ipchains -A input -i eth0 -p udp --source 216.88.77.7 53 -j ACCEPT
# ICMP allowed
ipchains -A input -i eth0 -p icmp -j ACCEPT
# disallow all else
ipchains -A input -i eth0 -j DENY -l
Man I'm sleepy but they sure look a lot alike... ???? strange?? Hummn.. if you're getting a lot of FTP connections.. that could be it.. every single file is going to make a log entry twice.. once in /var/log/kernel and once in .. again, I'm tired.. but I believe in var/log/secure..
Turn off the -l on your ftp connect and see if that does it??
Shortness
I see you are logging syn. Check your logs. Could a syn flood be causing this?
Okay, here is what I have done!
I added the following line:
ipchains -A input -i eth0 -p tcp --destination-port 53 -j ACCEPT
and the cpu usage returned to normal.
Interesting thing is that despite that first line on the script
ipchains -A input -i eth0 --source 207.218.223.135 -j DENY
I am still getting pounded by the service monitoring that is cloggin my logs.
I am quite confused at this point as to what I am doing wrong.
ShortFork,
The scripts look similar, because I found yours posted elsewhere in the forum and modeled mine from it.
And, yes, this is a RaQ4i.
Thanks for the help and any additional insight.
I added the following line:
ipchains -A input -i eth0 -p tcp --destination-port 53 -j ACCEPT
and the cpu usage returned to normal.
Interesting thing is that despite that first line on the script
ipchains -A input -i eth0 --source 207.218.223.135 -j DENY
I am still getting pounded by the service monitoring that is cloggin my logs.
I am quite confused at this point as to what I am doing wrong.
ShortFork,
The scripts look similar, because I found yours posted elsewhere in the forum and modeled mine from it.
And, yes, this is a RaQ4i.
Thanks for the help and any additional insight.
huck,
I really don't think it is a syn flood, although I am not sure I would know what to look for. The traffic on this box is very lite. I am just trying to secure it up a bit and am having problems figuring out why ipchains doesn't block things that I tell it to deny.
I really don't think it is a syn flood, although I am not sure I would know what to look for. The traffic on this box is very lite. I am just trying to secure it up a bit and am having problems figuring out why ipchains doesn't block things that I tell it to deny.
As root do a tail on the kernel log to see whats going on.
Also, do you run your own DNS? Typcially, port 53 is for DNS.
Also, do you run your own DNS? Typcially, port 53 is for DNS.
Yes, I do my own dns. Thanks for the help. I will check those logs and see what I can find.
Here is a sampling of my kernel log. What is going on here?
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=309 S=0x00 I=48497 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=311 S=0x00 I=27969 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=310 S=0x00 I=48498 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=312 S=0x00 I=27970 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=312 S=0x00 I=48499 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=309 S=0x00 I=48501 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=312 S=0x00 I=27973 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=309 S=0x00 I=27975 F=0x0000 T=37 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=309 S=0x00 I=58348 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=309 S=0x00 I=24010 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=312 S=0x00 I=58349 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=312 S=0x00 I=24011 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=311 S=0x00 I=58350 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=309 S=0x00 I=24012 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=287 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=289 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=289 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=312 S=0x00 I=65325 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=310 S=0x00 I=65327 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.33.4.12:53 216.12.215.31:1160 L=288 S=0x00 I=4004 F=0x4000 T=237 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=287 S=0x00 I=40250 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=289 S=0x00 I=65409 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=288 S=0x00 I=19202 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=290 S=0x00 I=65411 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=289 S=0x00 I=40252 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=289 S=0x00 I=30297 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=287 S=0x00 I=65413 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=290 S=0x00 I=19206 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=288 S=0x00 I=40255 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=288 S=0x00 I=30303 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=287 S=0x00 I=65414 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=290 S=0x00 I=19208 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=395 S=0x00 I=40256 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=289 S=0x00 I=30304 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=290 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=289 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=286 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=289 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth last message repeated 6 times
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=309 S=0x00 I=36484 F=0x0000 T=52 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=311 S=0x00 I=50702 F=0x0000 T=52 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=312 S=0x00 I=50704 F=0x0000 T=52 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=310 S=0x00 I=36488 F=0x0000 T=52 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=312 S=0x00 I=36489 F=0x0000 T=52 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=312 S=0x00 I=50705 F=0x0000 T=52 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=309 S=0x00 I=48497 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=311 S=0x00 I=27969 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=310 S=0x00 I=48498 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=312 S=0x00 I=27970 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=312 S=0x00 I=48499 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=309 S=0x00 I=48501 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=312 S=0x00 I=27973 F=0x0000 T=37 (#21)
Dec 13 04:49:19 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 202.153.114.101:53 216.12.215.31:1160 L=309 S=0x00 I=27975 F=0x0000 T=37 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=309 S=0x00 I=58348 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=309 S=0x00 I=24010 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=312 S=0x00 I=58349 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=312 S=0x00 I=24011 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=311 S=0x00 I=58350 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=309 S=0x00 I=24012 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=287 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=289 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=289 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=312 S=0x00 I=65325 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.5.6.30:53 216.12.215.31:1160 L=310 S=0x00 I=65327 F=0x0000 T=47 (#21)
Dec 13 04:49:20 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.33.4.12:53 216.12.215.31:1160 L=288 S=0x00 I=4004 F=0x4000 T=237 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=287 S=0x00 I=40250 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=289 S=0x00 I=65409 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=288 S=0x00 I=19202 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=290 S=0x00 I=65411 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=289 S=0x00 I=40252 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=289 S=0x00 I=30297 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=287 S=0x00 I=65413 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=290 S=0x00 I=19206 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=288 S=0x00 I=40255 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=288 S=0x00 I=30303 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=287 S=0x00 I=65414 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=290 S=0x00 I=19208 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=395 S=0x00 I=40256 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 198.41.0.4:53 216.12.215.31:1160 L=289 S=0x00 I=30304 F=0x0000 T=47 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=290 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=289 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=286 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=289 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth last message repeated 6 times
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 128.63.2.53:53 216.12.215.31:1160 L=288 S=0x00 I=0 F=0x4000 T=49 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=309 S=0x00 I=36484 F=0x0000 T=52 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=311 S=0x00 I=50702 F=0x0000 T=52 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=312 S=0x00 I=50704 F=0x0000 T=52 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=310 S=0x00 I=36488 F=0x0000 T=52 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=312 S=0x00 I=36489 F=0x0000 T=52 (#21)
Dec 13 04:49:21 rehoboth kernel: Packet log: input DENY eth0 PROTO=17 192.12.94.30:53 216.12.215.31:1160 L=312 S=0x00 I=50705 F=0x0000 T=52 (#21)
192.12.94.30 resolves to
Registrant:
Generic Top Level Domain Servers (GTLD-SERVERS-DOM)
VeriSign Global Registry Services
21345 Ridgetop Circle
Dulles, VA 20166
US
Wassup with that... I'm still sleepy... got to bed at 4:40 pacific.. got woken up at 7:30 pacific... zzzz
Since you do your own DNS.. my firewall rules may not be the best for you, since they were written to be used with outside DNS.. but I still have zero idea what's goin on..
Maybe drop the -l modifier one at a time on different rules till you see which one is hosing your system... then figure out why...
Not sure on the rest of the issues..
Too tired to look at all that gibberish and make sense of it.. zzzz
Short-mess
Registrant:
Generic Top Level Domain Servers (GTLD-SERVERS-DOM)
VeriSign Global Registry Services
21345 Ridgetop Circle
Dulles, VA 20166
US
Wassup with that... I'm still sleepy... got to bed at 4:40 pacific.. got woken up at 7:30 pacific... zzzz
Since you do your own DNS.. my firewall rules may not be the best for you, since they were written to be used with outside DNS.. but I still have zero idea what's goin on..
Maybe drop the -l modifier one at a time on different rules till you see which one is hosing your system... then figure out why...
Not sure on the rest of the issues..
Too tired to look at all that gibberish and make sense of it.. zzzz
Short-mess
You should not be logging requests from port 53. This is just a server requesting a DNS lookup.
Basically,
You machine 216.12.215.31 is replying to a DNS request from 202.153.114.101. This is pretty normal. Double check the order and logic of your log files and make sure that you turn off logging for this incoming port. You DNS server will use a range of ports to handle request.
Basically,
You machine 216.12.215.31 is replying to a DNS request from 202.153.114.101. This is pretty normal. Double check the order and logic of your log files and make sure that you turn off logging for this incoming port. You DNS server will use a range of ports to handle request.
huck,
That is the funny thing. This is a stock RaQ4i. I haven't changed the logging at all. That logging stopped with I added an ipchain rule to accept tcp on port 53. Weird.
I have now flushed ipchains altogether. I think I may install pmfirewall again and see if I can make it work. It confused me the first time, but never gave me these problems.
I am just not sure, with pmfirewall, how to add rules to block the bad guys. I guess, I will have to learn.
That is the funny thing. This is a stock RaQ4i. I haven't changed the logging at all. That logging stopped with I added an ipchain rule to accept tcp on port 53. Weird.
I have now flushed ipchains altogether. I think I may install pmfirewall again and see if I can make it work. It confused me the first time, but never gave me these problems.
I am just not sure, with pmfirewall, how to add rules to block the bad guys. I guess, I will have to learn.
Finally got everything working using pmfirewall!!
My logs are cleaner now. I am working to tweak things a bit now.
Thanks for your help guys!!
My logs are cleaner now. I am working to tweak things a bit now.
Thanks for your help guys!!
I have no experience with firewalls nor ipchains and haven't found a good basic (written for us new server admins) tutorial on installing pmfirewall on a server (in fact, most or what I have found starts by saying you need two computers and a network card - I know that can't be right for what I am doing).
We could really use some turtorials like the ones that eva2000 wrote for installing php and the like but about pmfirewall and ipchains. Any volunteers?
But since we don't have that right now, would you mind answering a few questions...?
Are both ipchains and pmfirewall needed, or just one or the other? Looks like pmfirewall is a little simpler.
When I install pmfirewall, if I leave it set at the defaults will it do any good? And will I be able to ssh in from my dialup connection and still be able to use the cp? My main goal is to see if installing this will keep my server from crashing several times a day. It just won't stay up during weekends and holidays, so I am thinking it is some kind of attack, I have eliminated all the other possibilities that I can think of.
If I enter my dialup ip #s as the only allow from numbers, that would mean that only someone from my isp can ssh into the machine... correct? I undertand how that would make security tighter, but how does that protect me from hacker attacks - does pmfirewall track repeated attempts to hack and deny from those, or is that something I need to do manually? See, I really don't know much about this stuff
Chris
We could really use some turtorials like the ones that eva2000 wrote for installing php and the like but about pmfirewall and ipchains. Any volunteers?
But since we don't have that right now, would you mind answering a few questions...?
Are both ipchains and pmfirewall needed, or just one or the other? Looks like pmfirewall is a little simpler.
When I install pmfirewall, if I leave it set at the defaults will it do any good? And will I be able to ssh in from my dialup connection and still be able to use the cp? My main goal is to see if installing this will keep my server from crashing several times a day. It just won't stay up during weekends and holidays, so I am thinking it is some kind of attack, I have eliminated all the other possibilities that I can think of.
If I enter my dialup ip #s as the only allow from numbers, that would mean that only someone from my isp can ssh into the machine... correct? I undertand how that would make security tighter, but how does that protect me from hacker attacks - does pmfirewall track repeated attempts to hack and deny from those, or is that something I need to do manually? See, I really don't know much about this stuff
Chris
Those are pretty good, but the solution not to lock yourself out is a bit odd.
When PMFirewall asks you for unrestricted access from a host, put your IP address or range into the field. If you have a static IP, then you can just put it in:
192.168.1.10
(just an example)
if you need a range
192.168.0.0/255.255.0.0
would allow everything from 192.168.1.1-192.168.255.255
The bit after the / tells you the important parts of the IP address:
255.255.255.255 => match the entire IP exactly
255.255.255.0 => match only the first three parts of the IP
255.255.0.0 => math only the first two parts of the IP
etc.
Never put this
ipchains -A input -s /0/ -j DENY
It will lock everything out. In fact this is the last rule in the ipchains configuration. If something gets all the way down to this rule then it is denied.
A good command to run is:
/sbin/ipchains --list
This will show you the rule list -- just follow it logically to get and idea of how the packets are handled. See th IPChains HOWTO for more info. It is very well written.
IPchains is great. We use it on all of our linux boxes -- mainly to protect the windows boxes behind them.
When PMFirewall asks you for unrestricted access from a host, put your IP address or range into the field. If you have a static IP, then you can just put it in:
192.168.1.10
(just an example)
if you need a range
192.168.0.0/255.255.0.0
would allow everything from 192.168.1.1-192.168.255.255
The bit after the / tells you the important parts of the IP address:
255.255.255.255 => match the entire IP exactly
255.255.255.0 => match only the first three parts of the IP
255.255.0.0 => math only the first two parts of the IP
etc.
Never put this
ipchains -A input -s /0/ -j DENY
It will lock everything out. In fact this is the last rule in the ipchains configuration. If something gets all the way down to this rule then it is denied.
A good command to run is:
/sbin/ipchains --list
This will show you the rule list -- just follow it logically to get and idea of how the packets are handled. See th IPChains HOWTO for more info. It is very well written.
IPchains is great. We use it on all of our linux boxes -- mainly to protect the windows boxes behind them.
well.. now I have gone and done it 
I installed ipchains according to the page Marty pointed out, but as I was installing pmfirewall, my internet connection was interupted. Tried to ssh back in, but after connecting and entering username/password I get no response. Tried ftp and that connects but I don't get a response. Webpages continued to work for about 10 minutes and then they stopped responding also. I have remote reboot but that won't work either - an unrelated problem I believe, which was reported to rs a few days ago when it wouldn't work, and they weren't going to do anything because they were about to move the server to the new data center anyway (don't know if it has been moved yet or not).
Also don't know if this freeze up is caused by the interuption or is caused by whatever else has been causing the repeated freeze ups for the last few days - for which I was hoping putting in the firewall would fix (thinking perhaps the freeze ups are do to some attack).
Would the set up have stopped running when the connection was interupted? Or have I managed to lock me and anyone trying to access my webpages out?
I know it's still there, I can ping it, but that is all.
Yikes.....
I installed ipchains according to the page Marty pointed out, but as I was installing pmfirewall, my internet connection was interupted. Tried to ssh back in, but after connecting and entering username/password I get no response. Tried ftp and that connects but I don't get a response. Webpages continued to work for about 10 minutes and then they stopped responding also. I have remote reboot but that won't work either - an unrelated problem I believe, which was reported to rs a few days ago when it wouldn't work, and they weren't going to do anything because they were about to move the server to the new data center anyway (don't know if it has been moved yet or not).
Also don't know if this freeze up is caused by the interuption or is caused by whatever else has been causing the repeated freeze ups for the last few days - for which I was hoping putting in the firewall would fix (thinking perhaps the freeze ups are do to some attack).
Would the set up have stopped running when the connection was interupted? Or have I managed to lock me and anyone trying to access my webpages out?
I know it's still there, I can ping it, but that is all.
Yikes.....
Which is exactly what I did first time I messed with chains rules... annd..... why I posted my basic script for users to play with..
hopefully you don't have this ruleset in your startup!!
Shortness
hopefully you don't have this ruleset in your startup!!
Shortness
Nope, not in start up, after rs did the physical reboot everything works again - whew -
It's going on 2am soon, I will go to bed and tackle this anew in the morning.
Chris
It's going on 2am soon, I will go to bed and tackle this anew in the morning.
Chris
QUOTE
When PMFirewall asks you for unrestricted access from a host, put your IP address or range into the field. If you have a static IP, then you can just put it in.
This way you don't lock yourself out.
Hi all, I sure appreciate the help I have recieved here.
Ok - I installed ipchains, then pmfirewall, as per the page that Marty mentioned. Thanks Marty, that helped.
Do I understand this correctly - what pmfirewall does is set up the configuration for ipchains? It doesn't actually protect the box itself? Ipchains does that.
Once I go through the basic set up, will that start protecting the server? Or does it not really do anything until I track down the ip's that are attacking me and enter them in as denys?
When I get an IP I want to deny, do I rerun the pmfirewall script again somehow to enter them, or what?
I set pmfirewall not to start on boot up, just in case I lock myself out - with the idea that I can reboot and have access again. After the successfull install (according the the set up script), has it turned itself on? How can I test it? How do I turn it on/off if I need to?
I know, lots of questions, this stuff is way more than I have had to do in the past. The previous server company I had must have had this type stuff upstream from our servers.
Chris
Ok - I installed ipchains, then pmfirewall, as per the page that Marty mentioned. Thanks Marty, that helped.
Do I understand this correctly - what pmfirewall does is set up the configuration for ipchains? It doesn't actually protect the box itself? Ipchains does that.
Once I go through the basic set up, will that start protecting the server? Or does it not really do anything until I track down the ip's that are attacking me and enter them in as denys?
When I get an IP I want to deny, do I rerun the pmfirewall script again somehow to enter them, or what?
I set pmfirewall not to start on boot up, just in case I lock myself out - with the idea that I can reboot and have access again. After the successfull install (according the the set up script), has it turned itself on? How can I test it? How do I turn it on/off if I need to?
I know, lots of questions, this stuff is way more than I have had to do in the past. The previous server company I had must have had this type stuff upstream from our servers.
Chris
Okay, to use pmfirewall to block an annoying ip:
pico -w /usr/local/pmfirewall/pmfirewall.rules.local
find the following:
### AUTOMATICALLY GENERATED BY THE INSTALL SCRIPT ###
Just below that line add a line like this
$IPCHAINS -A input -s ip.to.be.blocked/255.255.255.255 -d $REMOTENET -j DENY
save the files and then do this
/etc/rc.d/init.d/pmfirewall restart
That should do it. If you want to block the whole subnet, just change the last 255 to 0.
pico -w /usr/local/pmfirewall/pmfirewall.rules.local
find the following:
### AUTOMATICALLY GENERATED BY THE INSTALL SCRIPT ###
Just below that line add a line like this
$IPCHAINS -A input -s ip.to.be.blocked/255.255.255.255 -d $REMOTENET -j DENY
save the files and then do this
/etc/rc.d/init.d/pmfirewall restart
That should do it. If you want to block the whole subnet, just change the last 255 to 0.
QUOTE
Originally posted by Marty
http://www.nhhosting.net/NH/pmfirewall.htm
Best install instructions that I can find.
http://www.nhhosting.net/NH/pmfirewall.htm
Best install instructions that I can find.
Thanks Marty, I thought they were pretty good or I wouldn't have put them online
This may sound stupid, but how do you do Passive FTP with the ruleset ShortFork posted? I'm guessing that mine times out while trying to connect to the port, because my FTP client times out on passive and then rolls back to regular FTP (which I do have open).
This is a common problem.
In a Nutshell, here is the common problem:
FTP requires Two ports to run: 20 (commands) and 21 (data). The difference between active and passive FTP is how the ports are opened and the direction of TCP traffic through these ports.
(note: >1024 means a port higher than 1024, -> means direction of traffic)
Note in passive FTP your client tries to make a connection to a high port (>1024), which is most likely blocked by the firewall.
A good technical explanation can be found at:
http://www.slacksite.com/other/ftp.html
This is where the snippets above come from.
In a Nutshell, here is the common problem:
FTP requires Two ports to run: 20 (commands) and 21 (data). The difference between active and passive FTP is how the ports are opened and the direction of TCP traffic through these ports.
(note: >1024 means a port higher than 1024, -> means direction of traffic)
CODE
Active FTP :
command : client >1024 -> server 21
data : client >1024 <- server 20
Passive FTP :
command : client >1024 -> server 21
data : client >1024 -> server >1024
command : client >1024 -> server 21
data : client >1024 <- server 20
Passive FTP :
command : client >1024 -> server 21
data : client >1024 -> server >1024
Note in passive FTP your client tries to make a connection to a high port (>1024), which is most likely blocked by the firewall.
QUOTE
A quick summary of the pros and cons of active vs. passive FTP is also in order:
Active FTP is beneficial to the FTP server admin, but detrimental to the client side admin. The FTP server attempts to make connections to random high ports on the client, which would almost certainly be blocked by a firewall on the client side. Passive FTP is beneficial to the client, but detrimental to the FTP server admin. The client will make both connections to the server, but one of them will be to a random high port, which would almost certainly be blocked by a firewall on the server side
Active FTP is beneficial to the FTP server admin, but detrimental to the client side admin. The FTP server attempts to make connections to random high ports on the client, which would almost certainly be blocked by a firewall on the client side. Passive FTP is beneficial to the client, but detrimental to the FTP server admin. The client will make both connections to the server, but one of them will be to a random high port, which would almost certainly be blocked by a firewall on the server side
A good technical explanation can be found at:
http://www.slacksite.com/other/ftp.html
This is where the snippets above come from.
I've setup ipchains using ShortFork's rules, but I cannot ftp into my site anymore.
I've been reading about passive and active ftp for an hour now. How I set up ipchains to allow me to use ws_ftp in passive mode and hit my site is still a mystery. I can ftp outward from my site, but I cannot ftp IN.
No matter what I try-I get
Connected to 216.12.215.2.
421 Service not available, remote server has closed connection
Anyone care to throw a newbie a bone? Pity help is welcome too!
Shawn
I've been reading about passive and active ftp for an hour now. How I set up ipchains to allow me to use ws_ftp in passive mode and hit my site is still a mystery. I can ftp outward from my site, but I cannot ftp IN.
No matter what I try-I get
Connected to 216.12.215.2.
421 Service not available, remote server has closed connection
Anyone care to throw a newbie a bone? Pity help is welcome too!
Shawn
Shawn,
Even though that ruleset says something about passive transfers, it don't work that way... From what I can see, passive hooks on random ports and guess what.. the script has them all closed
If you set your client to not passive, and to connect on port 21, you should be ok..
Shortness
Even though that ruleset says something about passive transfers, it don't work that way... From what I can see, passive hooks on random ports and guess what.. the script has them all closed
If you set your client to not passive, and to connect on port 21, you should be ok..
Shortness
Negative Ghostrider..the pattern is full
That was one of the first things I did(not setting the passive mode).
I even tried opening port 20(using active), but no luck either.
Still get
ftp 216.12.215.2
Connected to 216.12.215.2
421 Service not available, remote server has closed connection
Ughh-frustrating.
I think maybe I just need sleep. Wonder if I need to set port 21 and 22 to input & output?
If I wasn't being hammered by that IP in China(yes-STILL!) I'd drop the ipchains for a couple minutes and do my site updates.
Shawn
That was one of the first things I did(not setting the passive mode).
I even tried opening port 20(using active), but no luck either.
Still get
ftp 216.12.215.2
Connected to 216.12.215.2
421 Service not available, remote server has closed connection
Ughh-frustrating.
I think maybe I just need sleep. Wonder if I need to set port 21 and 22 to input & output?
If I wasn't being hammered by that IP in China(yes-STILL!) I'd drop the ipchains for a couple minutes and do my site updates.
Shawn
what do you get when you type in
ipchains -L -v -n
?
Nuther option... go get winscp http://winscp.vse.cz/eng/
(ssh powered, similar to ftp)
Since you "own" the box, you could connect via the server admin account, upload the files to the site, chown them to the proper user... or..
open up shell access to that user (you.. right?) in the gui... then connect with winscp upload files.. then if the shell access for that site admin makes you nervous.... turn it back off..
I'm in the process of trying to talk myself into using winscp exclusively.. if I can just figure out how much of a problem I'm giving myself by allowing site level shell access.. then I might do it.. or the slightly more laborous way of doing it as server admin and then chowning..
Anyway, that'll get you running.
Ahh.. stupid question.. FTP is turned on in the cp.. right??
Might also try turing it on and off and saving changes.. dunno, never hurts..
Also.. after the shutdown today.. I found my server being really quirky, just did an orderly shutdown and reboot and things seem to have smoothed out a lot.
ahh.. just one more suggestion.. I seem to see a bit of slowness of the machine lately in resolving back to me.. I added myself to the hosts file in /etc/hosts (ok if you are on a static ip) that seems to speed things up a lot since the server sees you as a local host.
Shortness
ipchains -L -v -n
?
Nuther option... go get winscp http://winscp.vse.cz/eng/
(ssh powered, similar to ftp)
Since you "own" the box, you could connect via the server admin account, upload the files to the site, chown them to the proper user... or..
open up shell access to that user (you.. right?) in the gui... then connect with winscp upload files.. then if the shell access for that site admin makes you nervous.... turn it back off..
I'm in the process of trying to talk myself into using winscp exclusively.. if I can just figure out how much of a problem I'm giving myself by allowing site level shell access.. then I might do it.. or the slightly more laborous way of doing it as server admin and then chowning..
Anyway, that'll get you running.
Ahh.. stupid question.. FTP is turned on in the cp.. right??
Might also try turing it on and off and saving changes.. dunno, never hurts..
Also.. after the shutdown today.. I found my server being really quirky, just did an orderly shutdown and reboot and things seem to have smoothed out a lot.
ahh.. just one more suggestion.. I seem to see a bit of slowness of the machine lately in resolving back to me.. I added myself to the hosts file in /etc/hosts (ok if you are on a static ip) that seems to speed things up a lot since the server sees you as a local host.
Shortness
QUOTE
Originally posted by ShawnK
I've setup ipchains using ShortFork's rules, but I cannot ftp into my site anymore.
Shawn
I've setup ipchains using ShortFork's rules, but I cannot ftp into my site anymore.
Shawn
You realize that Shortfork's rules don't have one for port 20, right?
You should really change the ftp rule to:
ipchains -A input -i eth0 -p tcp --destination-port 20:21 --syn -j ACCEPT -l
...or without the -l if you don't want it logged.
QUOTE
Originally posted by Powerlord
You realize that Shortfork's rules don't have one for port 20, right?
You should really change the ftp rule to:
ipchains -A input -i eth0 -p tcp --destination-port 20:21 --syn -j ACCEPT -l
...or without the -l if you don't want it logged.
You realize that Shortfork's rules don't have one for port 20, right?
You should really change the ftp rule to:
ipchains -A input -i eth0 -p tcp --destination-port 20:21 --syn -j ACCEPT -l
...or without the -l if you don't want it logged.
Got me confused here. Why would we need to connect on port 20?
The error message that Shawn is seeing is not something I see even when messing around with it.
I'm connecting fine on port 21 only with 20 closed tight. In and out.
Now if I try to connect in passive mode, then it tries to go into an entirely different port and we're no joy, turn off passive and we're dialed..
Strangeness!!
port 20 is for ftp data transfer in non-passive mode, but since it's an outgoing connection for the server, you don't need a rule for it (unless you're blocking more than just incoming connections)
QUOTE
Originally posted by ekn
port 20 is for ftp data transfer in non-passive mode, but since it's an outgoing connection for the server, you don't need a rule for it (unless you're blocking more than just incoming connections)
port 20 is for ftp data transfer in non-passive mode, but since it's an outgoing connection for the server, you don't need a rule for it (unless you're blocking more than just incoming connections)
That splains it.. thanks mon..
Shortdazed..
QUOTE
Originally posted by ekn
port 20 is for ftp data transfer in non-passive mode, but since it's an outgoing connection for the server, you don't need a rule for it (unless you're blocking more than just incoming connections)
port 20 is for ftp data transfer in non-passive mode, but since it's an outgoing connection for the server, you don't need a rule for it (unless you're blocking more than just incoming connections)
I didn't take into consideration that it was opened on the server end. (*duhs*) :o
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.