Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Strange iptables log entries |
|---|---|
| Date: | Fri, 11 Feb 2005 13:33:53 -0600 |
Hi,
Not sure if this is a correct forum to post to. Please let me know if
you think that there is a better one.
I am running a web server farm on linux boxes. They are behind a
firewall that I do not administer. In addition I am also trying to
lock the servers themselves with iptables. Almost every day I get 1-2
log entries like the ones below in my logs. They look to me like
normal responses to a SYN to a closed port. The only problem is, I
believe I do not allow anything to connect to these ports in the first
place, so at worst, even if our firewall did allow original SYN
packets to go through, I should have dropped and logged the original
SYN packet instead of response.
The source and destination ports seem to be random high ports,
external IPs are random as well.
Am I right in thinking that these are responses to SYNs? If so, how
did they get through my rules? Any other reason these packets could
have been generated?
Thanks a lot!!
Relevant information:
Log enries:
Feb 10 11:02:48 www7 kernel: FIREWALL_OUT IN= OUT=eth0
SRC=192.168.6.57 DST=216.161.248.225 LEN=40 TOS=0x00 PREC=0x00 TTL=64
ID=18547 DF PROTO=TCP SPT=46388 DPT=37628 WINDOW=6930 RES=0x00 ACK RST
URGP=0
Feb 10 11:11:32 www7 kernel: FIREWALL_OUT IN= OUT=eth0
SRC=192.168.6.57 DST=145.254.250.120 LEN=40 TOS=0x00 PREC=0x00 TTL=64
ID=22239 DF PROTO=TCP SPT=48804 DPT=45819 WINDOW=14600 RES=0x00 ACK
RST URGP=0
My iptables script. I have removed some comments and changed variable
names to protect the innocent :-)
#!/bin/sh
PATH="/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin"
ACTIVE_IFACE="eth0"
INTERNAL_NETS="192.168.0.0/16 10.0.0.0/8"
LOOP="127.0.0.1"
HIGH_PORTS="1024:65535"
DEBIAN_HOSTS="194.109.137.218 208.185.25.35" #need for apt-get
NASDAQ="208.249.116.71" #our servers get quotes from there
OTHER_SERVERS="192.168.3.201"
MS_BOXES="192.168.6.80"
LOCAL_BCAST="192.168.6.255"
# There gotta be a better way..
MY_IP=`ifconfig $ACTIVE_IFACE | sed -e '/^[^ ]\+/N' -e 's|\n||g' | \
grep $ACTIVE_IFACE | sed -e 's|^.*addr:\([^ ]\+\).*$|\1|g'`
Service1=1314
Service2=1316
Service3=1313
Service4=1414
Service1_HOSTS="192.168.3.240"
Service234_HOSTS="192.168.3.244"
# Tweak the conntrack module
modprobe ip_conntrack hashsize=32768
# Flush all the rules from filter table and nat table:
iptables -F
iptables -t nat -F
iptables -X
# We have ip forwarding disabled (see /etc/sysctl.conf)
# but just for a good measure...
iptables -P FORWARD DROP
case "$1" in
start)
# Discard all traffic by default
iptables -P INPUT DROP
iptables -P OUTPUT DROP
# First, allow established connections
iptables -A INPUT -i $ACTIVE_IFACE -d $MY_IP -m state --state
ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $ACTIVE_IFACE -s $MY_IP -m state --state
ESTABLISHED -j ACCEPT
# HTTP(s) traffic
iptables -A INPUT -i $ACTIVE_IFACE -p tcp --sport $HIGH_PORTS -d
$MY_IP --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -i $ACTIVE_IFACE -p tcp --sport $HIGH_PORTS -d
$MY_IP --dport 443 -m state --state NEW -j ACCEPT
# Allow all traffic on loopback interface.
iptables -A INPUT -i lo -s $LOOP -d $LOOP -j ACCEPT
iptables -A OUTPUT -o lo -s $LOOP -d $LOOP -j ACCEPT
#MSSQL and JDBC traffic. FIXME remove JDBC after guys are finished migrating
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS --dport 1150 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS --dport 1433 -m state --state NEW -j ACCEPT
for IP in $Service1_HOSTS; do
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS -d $IP --dport $Service3 -m state --state NEW -j ACCEPT
done
# Allow traffic to stuff
for IP in $Service234_HOSTS; do
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS -d $IP --dport $Service1 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS -d $IP --dport $Service2 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS -d $IP --dport $Service4 -m state --state NEW -j ACCEPT
done
# Allow this box to query NTP servers
iptables -A OUTPUT -o $ACTIVE_IFACE -p udp -s $MY_IP --sport 123
--dport 123 -m state --state NEW -j ACCEPT
# Allow SMPT traffic from this box
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS --dport 25 -m state --state NEW -j ACCEPT
# Allow DNS queries from this box
iptables -A OUTPUT -o $ACTIVE_IFACE -p udp -s $MY_IP --dport 53 -m
state --state NEW -j ACCEPT
#Allow LDAP queries from this box
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS --dport 389 -m state --state NEW -j ACCEPT
# Allow ssh to this box from internal and DMZ networks
for IP in $INTERNAL_NETS; do
iptables -A INPUT -i $ACTIVE_IFACE -p tcp -s $IP --sport $HIGH_PORTS
-d $MY_IP --dport 22 -m state --state NEW -j ACCEPT
done
# Allow pwdgen queries from this box
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS --dport 129 -m state --state NEW -j ACCEPT
# Allow "good" ICMP messages
iptables -A INPUT -i $ACTIVE_IFACE -d $MY_IP -p icmp --icmp-type
destination-unreachable -j ACCEPT
iptables -A INPUT -i $ACTIVE_IFACE -d $MY_IP -p icmp --icmp-type
time-exceeded -j ACCEPT
iptables -A INPUT -i $ACTIVE_IFACE -d $MY_IP -p icmp --icmp-type
parameter-problem -j ACCEPT
for IP in $OTHER_SERVERS; do
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS -d $IP --dport 443 -m state --state NEW -j ACCEPT
done
# Getting quotes
for IP in $NASDAQ; do
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS -d $IP --dport 80 -m state --state NEW -j ACCEPT
done
# Allow apt-get to work
for IP in $DEBIAN_HOSTS; do
iptables -A OUTPUT -o $ACTIVE_IFACE -p tcp -s $MY_IP --sport
$HIGH_PORTS -d $IP --dport 80 -m state --state NEW -j ACCEPT
done
# Logging
iptables -N LOGDROP >/dev/null 2>&1
iptables -F LOGDROP
# Don't care for NETBIOS bcasts from MS boxes
for IP in $MS_BOXES; do
iptables -A LOGDROP -i $ACTIVE_IFACE -p udp -s $IP --sport 137:138
-d $LOCAL_BCAST --dport 137:138 -j DROP
done
iptables -A LOGDROP -o $ACTIVE_IFACE -m limit --limit 15/minute -j LOG
--log-prefix "FIREWALL_OUT "
iptables -A LOGDROP -i $ACTIVE_IFACE -m limit --limit 15/minute -j LOG
--log-prefix "FIREWALL_IN "
# I have seen real eth0 IP talking to loop before. Just in case I need
something.
# FIXME remove this when I am convinced there is nothing going on ...
iptables -A LOGDROP -i lo -m limit --limit 15/minute -j LOG
--log-prefix "LOOP_IN "
iptables -A LOGDROP -o lo -m limit --limit 15/minute -j LOG
--log-prefix "LOOP_OUT "
# INPUT/OUTPUT Policy is good but better be safe than sorry.
iptables -A LOGDROP -j DROP
# Add logging in the end of INPUT, OUTPUT and FPRWARD chains
iptables -A INPUT -j LOGDROP
iptables -A OUTPUT -j LOGDROP
iptables -A FORWARD -j LOGDROP
;;
stop)
# Open everything up....
# We have flushed all tables already
# We probably never need to forward anyway so FORWARD is not here...
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
# If there is a LOGDROP table, delete it...
iptables -F LOGDROP >/dev/null 2>&1
iptables -X LOGDROP >/dev/null 2>&1
;;
restart)
$0 stop
$0 start
;;
*)
echo "Try some sane argument"
;;
esac
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Chinese HTTP ACKs, Peter Kerr |
|---|---|
| Next by Date: | Re: Chinese HTTP ACKs, Kelsey Dawes |
| Previous by Thread: | Re: Chinese HTTP ACKs, Peter Kerr |
| Next by Thread: | RE: Exploit on tcp/4128?, Butterworth, Jim |
| Indexes: | [Date] [Thread] [Top] [All Lists] |