Today a started apache on CentOS and I'm able to open the test page on same machine as localhost. But I'm unable to open it using another computer. The CentOS server is on a VLAN (using switch) behind a router. I'm able to ping the server from other side using my laptop. But I'm not able to open the test page in my browser. I have another server in same VLAN which I'm able to access from my laptop.
Also here is some entries of iptables -L
Chain INPUT
ACCEPT tcp -- anywhere anywhere tcp:dtp:http
ACCEPT udp -- anywhere anywhere udp:dtp:http
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
I'm not sure what else I need to check.
Security theory tells to first drop the firewall and test (iptables -F). If you can access then it is really a iptables issue, if you are still unable to reach your service, try looking if you got any specific bind: netstat -an | grep "LISTEN " if you see something like:
"tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN "
means that your server is only listening on localhost ip, you should check on specific httpd binds on /etc/httpd/conf/httpd.conf
If you require some more help, keep posting =)
Related
What I want to do is setup two web servers. One will simply deliver normal content to people that request it and one will put minimal strain on the system and strictly deliver an access denied type of message for hackers.
I looked at http://www.cyberciti.biz/faq/linux-port-redirection-with-iptables/ for ideas on how to create this redirection based on a bad IP address and its suggesting:
iptables -t nat -A PREROUTING --src <source address> -p tcp --dport <new server port number> -j REDIRECT --to-port <new server port number>
I then tested that theory by trying the following on a computer without internet but with apache server running on port 80 and nothing on port 81:
iptables -t nat -A PREROUTING --src 127.0.0.1 -p tcp --dport 80 -j REDIRECT --to-port 81
I then typed in 127.0.0.1 in my web browser and received the same apache response as usual. Instead, I expected a browser message that it could not connect to the remote server.
How to I adjust the iptables command to make computers from listed IP in --src redirect from 127.0.0.1 port 80 to 127.0.0.1 port 81?
I understand I can use apache or php and even apache modules and all that for the redirection but I'm trying to use the least system-intensive approach and I want hackers to have the least amount of system resources available to them so that real visitors can enjoy a quality website, however
I want them to be able to see a message because if a real person gets blocked by accident then at least they can understand what's going on from an error message instead of a connection drop.
Packets on the loopback interface (127.0.0.0/8) don't pass through the NAT tables. Try using an external computer for the test.
I have a socket that listen on port 6100 on my development machine, whose lan address is 192.168.1.2
I can access the socket and use it with the address 127.0.0.1:6100, but I can't access it from 192.168.1.2:6100 (I need to access the socket from another client on the Lan)
If I type netstat -an | find "6100" on the command prompt I get:
TCP 127.0.0.1:6100 0.0.0.0:0 LISTENING
So I need to redirect all calls to 192.168.1.2:A_RANDOM_PORT to 127.0.0.1:6100
How can i do that?
I tried with:
netsh interface portproxy add v4tov4 listenport=6200 listenaddress=192.168.1.2 connectport=6100 connectaddress=127.0.0.1
But without luck
I've finally been able to accomplish this task, but only using an external tool.
I downloaded "PassPort port forwarding utility" and set up a redirection from 192.168.1.2 to 127.0.0.1
Unfortunately I haven't been able to do that without an external tool.
You failed to post the code concerned, but you bound your listening socket to 127.0.0.1 instead of 0.0.0.0. Just fix that. No oort forwarding required.
I'm trying to set up a client machine so that only kinit traffic works. So far, my rules look like
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i eth0 -s 192.168.1.130 -p tcp -m tcp --sport kerberos -j ACCEPT
-A INPUT -i eth0 -s 192.168.1.130 -p udp -m udp --sport kerberos -j ACCEPT
-A OUTPUT -i eth0 -d 192.168.1.130 -p tcp -m tcp --dport kerberos -j ACCEPT
-A OUTPUT -i eth0 -d 192.168.1.130 -p udp -m udp --dport kerberos -j ACCEPT
With this as-is, when I run "kinit remuser", I keep getting the error
kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial credentials
If I run
iptables -P INPUT ACCEPT
then "kinit remuser" works as expected. And after that first success, if I run
iptables -P INPUT DROP
it still keeps working.
I've tried using wireshark to see what I'm initially disallowing. It seems arp related, but I can't consistently see that... and I thought iptables wasn't supposed to mess with arp. I'm not seeing anything missing with "arp -n" or "ip -s neigh".
I've got the client and server configured correctly enough to work, but I'm still too new to this stuff to know what other ports I need to allow to get this working. If anyone can give me some tips I'd appreciate it.
UPDATE
Although my adapter claimed to be in promiscuous mode, it wasn't. I ended up running wireshark on the server, and saw no other port numbers needed. To verify that, I updated the rules to include
-A INPUT -s 192.168.1.130 -j ACCEPT
and as the successful kinit wireshark capture suggested, it didn't help. It's only when I open up all INPUTs that it works.
Thanks.
Hector
Kerberos is generally udp by default. I'm not that familiar with IP tables, but while port number on the server is defined the port number on the client is entirely random. So any ip based filter has to allow incoming udp packets with arbitrary client port numbers.
Similarly on the outgoing side, you need to be able to send packets with arbitrary udp ports on the client side. For kinit you only need the kerberos port, but changing passwords, etc, you will also need the kadmin ports.
Having said all that and making my best guess at what the ip tables rules mean, I think that's what you've implemented. However, you also need access to DNS srv records or a working krb5.conf.
http://wiki.unixh4cks.com/index.php/Using_DNS_SRV_records_to_find_Kerberos_realm_servers
It may be that kinit starts working when you allow incoming DNS record lookups. This would also explain why it continues to work after the first connection as it likely the DNS record is cached on the system. Is the server listed in your krb5.conf in your /etc/hosts file? If not that would explain the behaviour.
Thinking about this a bit more, what exactly do you expect to do with this ticket after you get it? The whole point of kerberos is to implement security on an open network by securing the endpoints, not by implementing firewalls.
I got it. And perhaps this only applies to me or anyone else using a HW VPN. An ICMP type 3 packet needed to be received from the gateway for the krb5 transaction to continue. My co-workers who are testing something similar on a work network aren't seeing this issue, so we'll need to figure out what's special in my case and whether it applies to other things.
The hardest part of all this was finding a wired adapter that truly supports promiscuous mode.
So I'm using AWS using EC2 and I'm trying to open up a port for Postgresql. In AWS I already have it open:
TCP
Port (Service) Source Action
0 - 65535 sg-92aadda2 (default) Delete
22 (SSH) 0.0.0.0/0 Delete
80 (HTTP) 0.0.0.0/0 Delete
5432 0.0.0.0/0 Delete
When I do netstat it looks as though the port is listening:
# netstat -an | grep 5432
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN
When I do a localhost nmap I get the following:
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000010s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
5432/tcp open postgresql
And here's where the fun begins. When I do an nmap from an alternative host I get the following:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
5432/tcp closed postgresql
I also looked at my iptables to see if I was missing something, but the iptables look empty (which should mean they aren't really doing much)
$ iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere 127.0.0.0/8 reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:postgresql
ACCEPT icmp -- anywhere anywhere
LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "
DROP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Am I missing something cause I can't seem to figure out how to access the ip. Whenever I try I get the following error:
Is the server running on host "xx.xx.xx.xx" and accepting TCP/IP connections on port 5432?
How do I make it so that I can open up the port so that external servers have access to it? Thanks in advance =) Lemme know if you need any additional data.
EDIT: As asked below, I tested telnetting, and I was able to telnet into the localhost, but when attempting from the outside I get:
$ telnet xx.xx.xx.xx 5432
Trying xx.xx.xx.xx...
telnet: Unable to connect to remote host: Connection refused
Also, I double checked and I was properly able to telnet into ssh:
$ telnet xx.xx.xx.xx 22
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
Edit /etc/postgresql/<version>/main/postgresql.conf and set the listen_addresses to your outgoing interface or all. Restart postgresql: sudo service postgresql restart.
It works for me the last method (thks Julio):
Edit: postgresql.conf
sudo nano /etc/postgresql/9.3/main/postgresql.conf
Enable or add:
listen_addresses = '*'
Restart the database engine:
sudo service postgresql restart
Besides, you can check the file: pg_hba.conf
sudo nano /etc/postgresql/9.3/main/pg_hba.conf
And add your network or host address:
host all all 192.168.1.0/24 md5
If you have edited postgresql.conf and main/pg_hba.conf and still having a problem, please try
sudo ufw allow 5432/tcp
to unblock psql port
In case you are using docker to connect to the host's postgresql you have to use the host's ip which you can obtain by running ip addr show docker0 hope it helps someone.
I'm running memcached, but can't connect. How should I start to debug this? Something appears to be stopping me connecting.
ps -elf | grep memcached
0 S lee 10744 529 0 80 0 - 30529 ep_pol 03:36 pts/22 00:00:00 /usr/bin/memcached -m 512 -p 11211 -u nobody -l 127.0.0.1
(Memcached is definitely running)
But when I try to telnet in, I get a timeout.
telnet 127.0.0.1 11211
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection timed out
Any advice would be appreciated.
Ensure that the local loopback network interface is running. It sounds like you're using a Unix system, so I would recommend running /sbin/ifconfig to see if a section labeled lo with the IP address (labeled as the inet addr) 127.0.0.1 is up and running. If not, run ifdown lo then ifup lo, this should get it going. Read your /etc/hosts file to make sure that localhost or you machine's name is bound to 127.0.0.1. And if your machine is using ipchains or iptables, ensure that those are configured to let traffic pass to 127.0.0.1 from 127.0.0.1.
These things are all fine 99% of the time, but being unable to connect to localhost is indeed odd, so a sanity check is in order.
Make sure you don't have any firewall enabled. In my case I found following entries for iptables:
target prot opt source destination
ACCEPT tcp -- example.com.internal anywhere tcp dpt:11211
ACCEPT udp -- example.com.internal anywhere udp dpt:11211
DROP tcp -- anywhere anywhere tcp dpt:11211
DROP udp -- anywhere anywhere udp dpt:11211
They allow connection only from the example.com.internal and deny from anywhere else, including localhost. To fix that I added specific rule for localhost:
ACCEPT tcp -- localhost anywhere tcp dpt:11211
ACCEPT udp -- localhost anywhere udp dpt:11211