Showing posts with label netadm. Show all posts
Showing posts with label netadm. Show all posts

Sunday, June 29, 2014

Private addresses in IPv6 protocol

It is almost a common wisdom that 172.16.0.0/12, 192.168.0.0/16, and 10.0.0.0/8 are private network addresses that should be used when you don't have assigned address, or you don't intend to connect to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet (at least not directly). With IPv6 being ever more popular, and necessary, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 question is which addresses are used for private networks in that protocol. In this post I'll try to answer that question.

The truth is that in IPv6 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are two types of private addresses, link local and unique local addresses. Link local IPv6 addresses, as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 name suggests, are valid only on a single link. For example, on a single wireless network. You'll recognize those addresses by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir prefix, which is fe80::/10, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y are automatically configured by appending interface's unique ID. IPv4 also has link local address, though it is not so frequently used. Still, maybe you noticed it when your DHCP didn't work and suddenly you had address that starts with 169.254.0.0./16. This was a link local IPv4 address configured. The problem with link local addresses is that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y can not be used in case you try to connect two or more networks. They are only valid on a single network, and packets having those addresses are not routable! So, we need something else.

Unique local addresses (ULA), defined in RFC4193, are closer to IPv4 private addresses. That RFC defines ULA format and how to generate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m. Basically, those are addresses with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 prefix FC00::/7. These addresses are treated as normal, global, addresses, but are only valid inside some restricted area and can not be used on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 global Internet. This is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same as saying that 10.0.0.0/8 addresses can be used within some private networks, but are not allowed on a global Internet. You choose how this conglomerate of networks will be connected, what prefixes used, etc.

There is  difference, though. Namely, it is expected that ULA will be unique in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 world. You might ask why is that important, when those addresses are not allowed on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet anyway. But, that is important. Did it ever happened to you that you had to connect two private IPv4 networks (directly via router, via VPN, etc.), and coincidentally, both used, e.g. 192.168.1.0/24 prefix? Such situations are a pain to debug, and require renumbering or some nasty tricks to make cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m work. So, being unique is an important feature.

So, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 mentioned RFC, actually specifies how to generate ULA with /48 prefix and a high probability of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 prefix being unique. Let's first see cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 exact format of ULA:
| 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID  | Subnet ID |        Interface ID        |
+--------+-+------------+-----------+----------------------------+
First 8 bits have a fixed value 0xFD. As you can see, prefix is 7 bit, but L bit must be set to 1 if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 address is specified according to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 RFC4193. So, first 8 bits are fixed to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 value 0xFD. Note that L bit set to 0 isn't specified, it is something left for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 future. Now, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 main part is Global ID, whose length is 40 bits. That one must be generated in such a way to be unique with high probability. This is done in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following way:
  1. Obtain current time in a 64-bit format as specified in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 NTP specification.
  2. Obtain identifier of a system running this algorithm (EUI-64, MAC, serial number).
  3. Concatenate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous two and hash cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 concatenated result using SHA-1.
  4. Take cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 low order 40 bits as a Global ID.
The prefix obtained can be used now for a site. Subnet ID can be furcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r used for multiple subnets within a site. There are Web based implementations of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 algorithm you can use to eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r get a feeling of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 generated addresses, or to generate prefix for your concrete situation.

Occasionally you'll stumble upon so called site local addresses. Those addresses were defined starting with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 initial IPv6 addressing architecture in RFC1884 and were also defined in subsequent revisions of addressing architecture (RFC2373, RFC3513) but were finally deprecated in RFC3879. Since cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y were defined for so long (8 years) you might stumble upon cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m in some legacy applications. They are recognizable by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir prefix FEC0::/10. You shouldn't use cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m any more, but use ULA instead.

Saturday, August 10, 2013

Getting Libreswan to connect to Cisco ASA 5500

Here are some notes about problems I had while trying to make Libreswan connect to Cisco ASA. Note that I'm using certificate based aucá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ntication in a roadwarrior configuration. The setup is done on Fedora 19.

The procedure, at least in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ory, is quite simple. Edit, /etc/ipsec.conf file, modify /etc/ipsec.d/ipsec.secrets file, import certificates into NSS database and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n start libreswan daemon. Finally, activate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 connection. Well, it turned out that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ory is very far from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 practice. So, here we go.

Preparation steps

First, I used cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following ipsec.conf file when I started to test connection to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ASA:
version 2.0     # conforms to second version of ipsec.conf specification
# basic configuration
config setup
    nat_traversal=yes
    nhelpers=1
    protostack=netkey
    interfaces=%defaultroute

conn VPN
    # Left side is RoadWarrior
    left=%defaultroute
    leftrsasigkey=%cert
    leftcert=SGROS
    leftca=ROOTCA
    leftid=%fromcert
    leftsendcert=always
    # Right side is Cisco
    right=1.1.1.1 # IP address of Cisco VPN
    rightrsasigkey=%cert
    rightcert=CISCO
    rightca=%same
    rightid=%fromcert
    # config
    type=tunnel
    keyingtries=2
    disablearrivalcheck=no
    authby=rsasig
    auth=esp
    keyexchange=ike
    auto=route
    remote_peer_type=cisco
    pfs=no
Note few things about this configuration. First, my client machine (roadwarrior) is a left node, while Cisco is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 right one. Next, I didn't arrive to this configuration immediately, I had to experiment with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 value of interfaces and left statements. The reason was that I'm assigned dynamic NATed address. So, those settings will cause openswan to automatically select appropriate values (interface and IP address) at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 time I'm connecting to VPN. Also, certificate related stuff also took me some time to figure it out.

Into ipsec.secrets file I added cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following line:
: RSA SGROS
this will cause openswan to use RSA key for aucá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ntication. Finally, I had to import certificates and keys into cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 NSS database. Note that NSS database is already precreated in /etc/ipsec.d directory. More specifically, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 database consists of files cert8.db, key3.db and secmod.db. To see imported certificates (if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are any), use cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following command:
# certutil -L -d /etc/ipsec.d/
Certificate Nickname               Trust Attributes
                                   SSL,S/MIME,JAR/XPI
ROOTCA                             CT,C,C
SGROS                              u,u,u
CISCO                              P,P,P
In my case cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are three certificates in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 database. Mine (SGROS), VPN's (CISCO) and CA that signed cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m (ROOTCA). Note that I'm referencing those certificates in ipsec.conf file. If you are configuring this database for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 first time, it will be empty and you'll have to import all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 certificates.

To import CA into your database, use cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following command:
certutil -A -i rootca.pem -n ROOTCA -t "TC,TC,TC" -d /etc/ipsec.d/
Note that I'm assuming you have PEM version of certificate stored in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 current directory (argument to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 -i option). For cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 rest options, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir meaning, please consult man page.

To import your certificate, with a private key, use cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following command:
certutil -A -i certkey.pfx -n SGROS -t "u,u,u" -d /etc/ipsec.d/
Note that this time certificate and private key are stored in PKCS#12 file (named certkey.pfx).

Finally, to import certificate of Cisco ASA, use cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following command:
certutil -A -i rootca.pem -n ROOTCA -t "P,P,P" -d /etc/ipsec.d/
Note that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 command is very similar to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 one used to import ROOTCA, but cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 trust attributes (option -t) are different. Namely, you don't want ASA's certificate to be CA, i.e. to be able to issue new certificates.

Starting and debugging

To start Libreswan daemon, I used cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following command:
ipsec pluto --stderrlog --config /etc/ipsec.conf --nofork
That way I was forcing it not to go to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 background (--nofork) and to log to stderr (--stderrlog). Then in anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r terminal I would trigger VPN establishment using cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following command:
ipsec auto --up VPN
The first problem was that Libreswan said it can not determine which end of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 connection it is, i.e. I was receiving cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following error message.
022 "VPN": We cannot identify ourselves with eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r end of this connection.
That error message took me some time to resolve. I tried everything possible to let Libreswan knows if it is left or right part in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 configuration, which included changing roles several times, changing different parameters and ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r stuff. In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 end, it turned out that that has nothing to do with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 configuration file, namely cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem actually was missing kernel module!? NETKEY wasn't loaded, and libreswan couldn't access IPsec stack within cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 kernel. To be honest, it could be inferred from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 log by nothing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following lines:
No Kernel XFRM/NETKEY interface detected
No Kernel KLIPS interface detected
No Kernel MASTKLIPS interface detected
Using 'no_kernel' interface code on 3.10.4-300.fc19.x86_64
But cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n again, some more informative error message would actually help a lot! In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 end, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following command solved that problem:
modprobe af_key
and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n, in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 logs I saw cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following line:
Using Linux XFRM/NETKEY IPsec interface code on 3.10.4-300.fc19.x86_64
that confirmed NETKEY was now accessible, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 error message about not knowing which end of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 connection it is, disappeared.

Next, I had problem with peer's public key. The error message I received was:
003 "VPN" #1: no RSA public key known for 'C=HR, L=Zagreb, O=Some ORG, CN=Cisco ASA'
Again, I lost a lot of time trying to figure out why it can not access public key even though it is in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 certificate. I also tried to extract public key and write it directly into configuration file. Nothing helped. Then, when I turned on debugging of x509 in ipsec.conf, I found some suspicious messages, like cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following one:
added connection description "VPN"
| processing connection VPN
|   trusted_ca called with a=CN=ROOTCA b=
|   trusted_ca returning with failed
|   trusted_ca called with a=CN=ROOTCA b=\001\200\255\373
|   trusted_ca returning with failed
Note cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 garbage as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 second argument of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 function trusted_ca!? Googling around for something about this didn't reveal anything useful. But cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n, out of desperation I tried removing leftca and rightca parameters from ipsec.conf, and guess what! Everything started to work. Checking again at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 logging output I saw that now b parameter has cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same value as a.

Yet, it still didn't work and after some tinkering I suspected that on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Cisco side XAuth is enabled and required. This I concluded based on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 log output where Libreswan says what it received from Cisco:
"VPN" #1: received Vendor ID payload [Cisco-Unity]
"VPN" #1: received Vendor ID payload [XAUTH]
"VPN" #1: ignoring unknown Vendor ID payload [...]
"VPN" #1: ignoring Vendor ID payload [Cisco VPN 3000 Series]
At first, I thought that Libreswan will support XAuth, but obviously, if it is not configured Libreswan can not use it. Also, looking into manual page it says cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re that Xauth is disabled by default. So, after adding cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following statements into ipsec.conf file:
leftxauthclient=yes
leftxauthusername=sgros
and adding appropriate line into ipsec.secrets file:
@sgros : XAUTH "mypassword"
I managed to get furcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r. Yet, it still didn't work. Looking again in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 log output I realised that something was wrong with client configuration. Also, I got segfaults cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re that I didn't report to upstream for a simple fear that I might send some secret information. But, after adding cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following statements into ipsec.conf segmentation fault was solved:
modecfgpull=yes
leftmodecfgclient=yes
In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 logging output of Libreswan I saw that configuration parameters were properly obtained, i.e.:
"VPN" #1: modecfg: Sending IP request (MODECFG_I1)
"VPN" #1: received mode cfg reply
"VPN" #1: setting client address to 192.168.2.33/32
"VPN" #1: setting ip source address to 192.168.2.33/32
"VPN" #1: Received subnet 192.168.0.0/16, maskbits 16
"VPN" #1: transition from state STATE_MODE_CFG_I1 to state STATE_MAIN_I4
Now, it seemed like everything was connected, but ICMP probes were not going through. Using setkey command I checked that policies and associations are correctly installed into cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 kernel, which cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y were. I quickly realised that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem was that Libreswan didn't assign IP address to my local interface, nor did it assign routes. That was easy to check by just listing interface's IP addresses. To see if this is really problem, I manually assigned address and route:
# ip addr add 192.168.2.33/32 dev wlp3s0
# ip ro add 192.168.0.0/22 src 192.168.2.33 via 192.168.1.1
and after that I was able to reach addresses within a destination network. Note that IP address given as argument to via keyword (in my case 192.168.1.1) isn't important since XFRM will change it anyway. So, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem was why this address isn't added in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 first place.

After some poking around I found that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 script /usr/libexec/ipsec/_updown.netkey is called to setup all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 parameters, and also, looking into that script, I found that it didn't do anything when pluto calls it using up-client parameter! So, no wonder nothing happened. I also found on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet post about that problem. The fix is simple, as shown in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 post I linked, but it messes something with routes. After some furcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r investigation I discovered that when adding locally assigned IP address, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 script messes up netmask. To cut cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 story, I changed cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following line:
-it="ip addr add ${PLUTO_MY_SOURCEIP%/*}/${PLUTO_PEER_CLIENT##*/} dev ${PLUTO_INTERFACE%:*}"
+it="ip addr add ${PLUTO_MY_CLIENT} dev ${PLUTO_INTERFACE%:*}"
and also, I changed cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following lines for IP address removal:
-it="ip addr del ${PLUTO_MY_SOURCEIP%/*}/${PLUTO_PEER_CLIENT##*/} dev ${PLUTO_INTERFACE%:*}"
+it="ip addr del ${PLUTO_MY_CLIENT} dev ${PLUTO_INTERFACE%:*}"
You can get cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 complete patch here.

Some random notes

It might happen that Libreswan suddenly stops working and that you can not access network, i.e. you can only ping you local address, but not local router. In that case try to clear XFRM policy using setkey command:
setkey -FP
you can also check if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is anything with:
setkey -DP

Thursday, March 21, 2013

Detecting hosts that cross connect two networks...

There are different scenarios in which you can have a situation where some of your clients are connected in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same time to two different networks of different trust levels. This is dangerous because effectively cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y can be used as a staging point for potential attackers or malware to "jump" from less trusted network to more trusted one.

For example, suppose that you have protected internal wired LAN, and in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same time you have wireless LAN that is used for guests and allowed unrestricted access to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet, as shown in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 figure below. Someone, from your internal and protected network, might intentionally or accidentally connect to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 wireless network too, and in that case he/she will shortcut cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 two networks. If you thought that you can use MAC addresses to detect such hosts, you can not, for a simple reason that in one network host is connected using wired ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet card with one MAC address, and in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 second network it is connected using WLAN network card with anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r MAC address.

Hypocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365tical situation to illustrate how internal host might shortcut two networks of different trust levels
So, how to detect those hosts that shortcut two networks? Actually, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is an easy and elegant way. Namely, you can send ARP requests on one network for IP addresses on anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r network. ARP module, by default, doesn't know or care for routing tables so that it knows on which interface it should respond with specific addresses. If we look again on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 figure above, this means that you can run cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following command from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 proxy host (cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 host above firewall):
arping -I eth1 10.0.0.250
I assume in that command that eth1 is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 interface connected to AP. What will happen is that broadcast will be sent on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 wireless network and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 client will respond with its wireless MAC address even though that address is not used on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 wireless network.

So, I hope cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 idea is clear now. To detect if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is some host cross connecting two networks I send arp request on a host (i.e. proxy host) for each possible IP address used on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r network (i.e. local protected network in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 figure above).

Note that it is possible to disable such behavior on Linux machines using sysctl variable /proc/sys/net/ipv4/conf/*/arp_filter. You can find more information, for example, here.

nmap games

Now, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r problem. How to scan cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 whole network without manually trying each possible IP address. The first solution is, obviously, to use nmap. Nmap is a great tool for network scanning, but in this case it has a problem, I tried to run it in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following way, but unsuccessfuly:
# nmap -PR -Pn -e eth1 10.0.0.0/24
Starting Nmap 5.51 ( http://nmap.org ) at 2013-03-21 10:07 CET
nexthost: failed to determine route to 10.0.0.0
QUITTING!
Option -PR requires ARP scan, -Pn disables ping scan, and -e eth1 tells nmap to send packets via interface eth1. The problem is that I'm trying to scan network 10.0.0.0/24 on interface eth1 and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is no route in routig tables that tells kernel/nmap that network is really connected on interface eth1. So, nmap refuses to scan those addresses. One solution is to temporarily add that route:
ip route add 10.0.0.0/24 dev eth1
But this isn't an option if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 route already exists in order for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hosts on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 protected network to be able to access proxy, i.e. if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is route similar to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following one:
# ip ro sh
...
10.0.0.0/24 via 172.16.1.1 dev eth0
...
Again, I'm making a lot of assumptions here (network between proxy and firewall, IP addresses and interfaces) but I hope you understand cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 point. The given route is in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 routing tables and removing it isn't an option.

Next try was using -sn switch, i.e. to disable port scan:
# nmap -PR -Pn -sn -e eth1 10.0.0.0/24
Starting Nmap 5.51 ( http://nmap.org ) at 2013-03-21 10:07 CET
Well, now nmap worked, sort of, because it showed all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hosts are up. Using tcpdump I found that it didn't send anything to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network. Reason: it thinks this is remote network, pings are disabled, arp cannot be used, and finally, because of -Pn, assumes all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hosts are up. So, I was again at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 beginning.

Simple arping solution

Until I figure out how to force nmap to send arp probes without worrying  about routing tables here is a simple solution using arping command:
#!/bin/bash

TIMEOUT=4

for i in {1..254}
do
if arping -q -f -w \$TIMEOUT -I eth2 10.0.0.\$i
cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n
echo "10.0.0.$i is up"
fi
done
There are three problems with this solution:
  1. In case your network has netmask ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r than /24 you'll have to change this script, i.e. it is a bit more complicated. How much, depends on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network mask.
  2. The problem with this solution is that it is slow. For example, to scan 254 addresses and with timeout of 4 seconds, it will take about 17 minutes to scan cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 whole address range assuming no address is alive (what is actually desired state on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network).
  3. Finally, timeout value is a bit tricky to determine. Majority of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 responses are really quick, i.e. under a second. But some devices respond slower, i.e. when cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y entered some kind of a sleep state.
Still, it is a satisfactory solution until I find a way to use nmap for that purpose. If you know how, please, leave a comment.

Tuesday, March 12, 2013

Storing arpwatch output into database

arpwatch is very useful tool which logs its output via syslog and also sends mail alerts. Unfortunately, this isn't configurable, i.e. arpwatch, out-of-cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365-box, doesn't support any ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r way of logging.  One approach is to modify arpwatch to be able to log into some SQL database, but this isn't straightforward way, i.e. not an easy one. Namely, arpwatch is written in C, and besides, it's hard to know if this would be accepted by upstream (who ever that migh be).

So, I decided to go with a different approach. I configured arpwatch to log its output into log file and wrote a Python script that executes via cron and transfers all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 data into cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 database. Here is how I did it along with all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 scripts.

Configuring logging

The first step is to configure arpwatch to log its output into a separate file. This isn't possible to do in arpwatch itself, but it is possible to achieve it by configuring syslog, or rsyslog to be more precise. On CentOS 6 rsyslog is used that allows just that. All you have to do is to place a file named (for example) arpwatch.conf in directory /etc/rsyslog.d with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following content:
if $programname == 'arpwatch' cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n /var/log/arpwatch.log
&~
Don't forget to restart rsyslog after that. This will write anything logged by arpwatch binary into /var/log/arpwatch.log file. All cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 different log lines that can appear are documented in arpwatch's manual page so I won't replicate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m here.

Configuring database

In my case I created a single table using cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following SQL statement:
CREATE TABLE arpwatch (
  macaddr char(17) NOT NULL,
  ip_addr int(10) unsigned NOT NULL,
  state varchar(8) NOT NULL,
  timestamp datetime NOT NULL,
  oldmac char(17) DEFAULT NULL
)
I think it's pretty obvious what goes where. Only thing that might be strange is that I'm using INT(10) for IP address. But that is because SNORT also stores IP addresses in such a way so in order to be compatible with it I used it also. Also, what is missing is primary key, but for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 time being I'm not using it.

Script

Here is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 script that should be started from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cron. For example, store it in /usr/local/sbin directory and to start it every 20 minutes add cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following line (as root user) to cron using 'crontab -e' command:
*/20 * * * * /usr/local/sbin/arpwatchlog2sql.py
Note that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 script expects configuration file. Here is a sample configuration file you'll have to modify. The script expects configuration file to be in its current directory, but you can place it into /usr/local/etc and modify cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 line CONFIGFILE in script accordingly.

Log rotation

Finally, you should be certain that logs are properly handled, i.e. rotated along with ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r logs. Since arpwatch is logging via syslog, that means that you have to modify rsyslog's log configuration file, i.e. /etc/logrotate.d/syslog. In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re you'll see that logfiles maintained by rsyslog are enumerated, one per line. Just add arpwatch.log to that list and that should be it.

Friday, June 29, 2012

BIND and network unreachable messages...

Sometimes you'll see messages like cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following ones in your log file (messages are slightly obfuscated to protect innocent :)):
Jun 29 14:32:11 someserver named[1459]: error (network unreachable) resolving 'www.eolprocess.com/A/IN': 2001:503:a83e::2:30#53
Jun 29 14:32:11 someserver named[1459]: error (network unreachable) resolving 'www.eolprocess.com/A/IN': 2001:503:231d::2:30#53
What cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se messages say is that network that contains address 2001:503:231d::2:30 is unreachable. So, what's happening?

The problem is that all modern operating systems support IPv6 out of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 box. The same is for growing number of software packages, among cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m is BIND too. So, operating system configures IPv6 address on interface and application thinks that IPv6 works and configures it. But, IPv6 doesn't work outside of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 local network (cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is no IPv6 capable router) so, IPv6 addresses, unless in local networks, are unreachable.

So, you might ask now: but everything ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rwise works, why is this case special! Well, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem is that some DNS servers, anywhere in hierarchy, support IPv6, but not all. And when our resolver gets IPv6 address in response, it defaults to it and ignores IPv4. It obviously can not reach it so it logs a message and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n tries IPv4. Once again, note that this IPv6 address can pop up anywhere in hierarchy, it isn't necessary to be on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 last DNS server. In this concrete case name server for eolprocess.com doesn't support IPv6, but some name server for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 top level com domain do support it!

To prevent those messages from appearing add option -4 to bind during startup. On CentOS (Fedora/RHEL) add or modify cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 line OPTIONS in /etc/sysconfig/named so that it includes option -4, i.e.
OPTIONS="-4"

Tuesday, June 26, 2012

Setting up reverse DNS server...

In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 post about DNS configuration I skipped reverse DNS configuration. But, it is necessary to have it in some cases, like FreeIPA installation or for mail servers. So, I'm going to explain how to configure reverse DNS server.

While "normal" DNS resolution works by names, from root server down to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 authoritative one for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 name we are looking for, reverse DNS resolution works within special top-level domain (in-addr.arpa). Within this domain, sub-domains are comprised from octets within IP address in reverse order. Now, if your block of IP addresses ends on byte boundary (e.g. /8, /16, /24) cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 setup is relatively simple. Ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rwise, you upstream provider (cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 one that holds larger IP address block) has to point to your domain on a per address base.

Let us bring this to more concrete values. Suppose that our public IP address space is 192.0.2.0/24. Also, suppose that your mail server has public IP address 192.0.2.2. In that case, reverse query is sent for name 2.2.0.192.in-addr.arpa and query type is set to PTR, i.e. we are looking for a name 2 within 2.0.192.in-addr.arpa zone.

So, it's relatively easy to setup reverse DNS. You need to define appropriate zones that include only network part of your IP addresses. In our case we have two zones, but IP addresses used for one of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m depends on who's asking (client from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 local network or client on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet). So, we have three zones in effect:
  1. DMZ, when asked by local clients, is in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network 10.0.0.0/24. This means we have reverse zone 0.0.10.in-addr.arpa for local clients.
  2. DMZ, when asked by internet clients, is in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network 192.0.2.0/24. This means that for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m reverse zone is 2.0.192.in-addr.arpa.
  3. Finally, clients in local network (non-DMZ one) have IP addresses from a block 172.16.1.0/24 and so cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y are placed within reverse zone 1.16.172.in-addr.arpa.
So, within internal view you should add cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following two zone statements:
zone "0.0.10.in-addr.arpa" {
    type master;
    file "example-domain.com.local.rev";
};

zone "1.16.172.in-addr.arpa" {
    type master;
    file "example-domain.local.rev";
};
And within internet view you should add cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following zone statement:
zone "2.0.192.in-addr.arpa" {
   type master;
    file "example-domain.com.rev";
};
Then, you should create cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 three zone files (example-domain.com.local.rev, example-domain.local.rev, and example-domain.com.rev) with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following content:
# cat example-domain.com.local.rev
 $TTL 1D
@    IN    SOA    @ root.example-domain.com. (
            2012062601 ; serial
            1D         ; refresh
            1H         ; retry
            1W         ; expire
            3H )       ; minimum
           NS    ns1.example-domain.com.

1          PTR    ns1.example-domain.com.
# cat example-domain.local.rev
 $TTL 1D
@    IN    SOA    @ root.example-domain.com. (
            2012062601 ; serial
            1D         ; refresh
            1H         ; retry
            1W         ; expire
            3H )       ; minimum
           NS    ns1.example-domain.com.

1          PTR    test.example-domain.local.
# cat example-domain.com.rev
$TTL 1D
@    IN    SOA    @ root.example-domain.com. (
            2012062601 ; serial
            1D         ; refresh
            1H         ; retry
            1W         ; expire
            3H )    ; minimum
           NS    ns1.example-domain.com.

1          PTR    ns1.example-domain.com.
Don't forget to change permissions on those files as explained in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous post. Now, restart BIND and test server:
# nslookup ns1.example-domain.com 127.0.0.1
Server:  127.0.0.1
Address: 127.0.0.1#53

Name:    ns1.example-domain.com
Address: 10.0.0.1
[root@ipa ~]# nslookup 10.0.0.1 127.0.0.1
Server:  127.0.0.1
Address: 127.0.0.1#53

1.0.0.10.in-addr.arpa    name = ns1.example-domain.com.
As it can be seen, DNS server correctly handles request for IP addres 10.0.0.1 and returns ns1.sistemnet.hr. Let's try with a name from LAN:
# nslookup test.example-domain.local 127.0.0.1
Server:  127.0.0.1
Address: 127.0.0.1#53

Name:    ipa.example-domain.local
Address: 192.0.2.1

[root@ipa named]# nslookup 192.0.2.1 127.0.0.1
Server:  127.0.0.1
Address: 127.0.0.1#53

1.2.0.192.in-addr.arpa    name = test.example-domain.local
That one is correct too. So, that's it, you have reverse DNS correctly configured. Testing from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 outside I'm leaving to you as an exercise. ;)

Monday, June 25, 2012

Setting up DNS server...

In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous post I described how to install minimal CentOS distribution with some additional useful tools. In this part I'm going to describe how to install DNS server. This DNS server will exhibit certain behavior depending on where cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 client is, in ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r words we are going to setup split DNS. Note that since DNS server is accessible from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet, it is placed in DMZ network, i.e. 10.0.0.0/24.

Environment and configuration parameters


In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following text we assume network topology from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous post, but we need some additional assumptions and requirements before going furcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r. First, our public domain is example-domain.com and all hosts within DMZ will belong to that zone, i.e. FQDN of mail server will be mail.example-domain.com. But, when some client from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet asks for certain host, e.g. mail.example-domain.com DNS server will return public IP address. On cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r hand, when client from a local network, or even DMZ, asks for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same host private IP address will be returned, i.e. 10.0.0.2. The reason for such behavior is more efficient routing. In ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r words, if client from a local network would receive public IP address, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 traffic would have to be NAT-ed. We'll also assume that we are assigned a public block of IP addresses 192.0.2.0/24.

There will be  also additional domain example-domain.local in which all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hosts from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 local domain will be placed. Additionally, this domain will be visible only from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 local network and DMZ, it will not exist for clients on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet.

To simplify things we are not going to install secondary DNS server nor we are going to install reverse zones. For a test purposes this is OK, but if you are doing anything serious, you should definitely install slave DNS servers (or use someone's service) and configure reverse zones. Also, I completely skipped IPv6 configuration and DNSSEC configuration.

Installation of necessary packages


There are a number of DNS server implementations to choose from. The one shipped with CentOS is BIND. It is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 most popular DNS server, with most features, but, in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 past it had a lot of vulnerabilities. Nevercá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365less, we'll use that one. Maybe sometime in future, I write something about alternatives, too.

So, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 first step, is to install necessary packages:
yum install bind.x86_64 bind-chroot.x86_64 bind-utils.x86_64
Server itself is in bind package, bind-chroot is used to confine server to alternative root filesystem in case it is compromised. Finally, bind-utils contains utilities we need to test server. This is 4.1M of download data, and it takes around 7M after installation. Not much.

Note that it is a good security practice to confine server into alternative root. As I already said, in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 past bind had many vulnerabilities, and in case new one is discovered and exploited, we want to minimize potential damage.

That's all about installation.

Configuration

Next, we need to configure server before starting it. Main configuration file for bind is /etc/named.conf . So, open it with your favorite editor as we are going to make some changes in it. Remember that our domain is called example-domain.com and that we want private addresses to be returned for internal clients, and public ones for external clients. Additionally, we have a local domain example-domain.local. Here is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 content of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 /etc/named.conf file:
acl lnets {
    10.0.0.0/24;
    172.16.1.0/24;
    127.0.0.0/8;
};

options {
  listen-on port 53 { any; };
  directory     "/var/named";
  dump-file     "/var/named/data/cache_dump.db";
  statistics-file "/var/named/data/named_stats.txt";
  memstatistics-file "/var/named/data/named_mem_stats.txt";
  allow-update     { none; };
  recursion no;

  dnssec-enable no;
};

view "internal" {
    match-clients { lnets; };
    recursion yes;

    zone "." IN {
        type hint;
        file "named.ca";
    };

    zone "example-domain.local" {
        type master;
        file "example-domain.local";
    };

    zone "example-domain.com" {
        type master;
        file "example.domain.local";
    };

    include "/etc/named.rfc1912.zones";
};

view "internet" {
    match-clients { any; };
    recursion no;

    zone "example-domain.com" {
        type master;
        file "example-domain.com";
    };
};
Let me now explain what this configuration file actually specifies. In global, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are four blocks, i.e. acl, options, and two view blocks.

acl block (or blocks, because cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re may be more such statements) specifies some symbolic name that will refer to group of addresses.  This is good from maintenance perspective because cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is only one place where something is defined. In our case, we define our local networks, i.e. DMZ and local LAN. There is also loopback address because when some application on DNS server itself asks something, DNS server should treat it as if it is coming from a local network.

Next is an option block. In our case we specify that DNS server should listen (listen-on) port 53 on any IP address (any). In case you want to restrict on which addresses DNS server listens, you can enumerate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m here instead of any keyword. Better yet, create ACL and use symbolic name. In option block we also disabled DNSSEC (dnssec-enable no), disabled updates to server (allow-update no), and disabled recursion (recursion no). Apart from that we defined directories, e.g. for zone files.

Finally, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are two view statements. They define zones depending on where cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 client asking is. If it is on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 local networks, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n first view (i.e. internal) is consulted, and if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 client is anywhere else, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 second view is consulted (i.e. internet). match-clients statement classifies clients, and it is here that we use our ACL lnets. When query arrives, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 source address from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 packet is taken and compared to match-clients. The first one that matches is used. So, it is obvious that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 second view matches anything but since it is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 last one, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n it is a catch-all view. Anyway, for our local clients we allow recursive queries (recursion yes), while we disallow it for a global clients (recursion no). This is a good security practice! Also, note that for internal clients we define example-domain.local zone, which isn't defined for global clients. And, for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same example-domain.com zone, two different files (i.e. databases with names) are used. This reflects cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 fact that we want local clients to get local IP addresses, while global clients should get globally valid IP addresses.

Zone configurations

There are three zones in our case. First one is a global one, used to answer queries to clients on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet. Looking into cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 main configuration file cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 name of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 file containing this zone has to be example-domain.com and it has to be placed in /var/named directory! The content of this file is:
$TTL 1D
@    IN    SOA    @ root.example-domain.com. (
            2012062501    ; serial
            1D            ; refresh
            1H            ; retry
            1W            ; expire
            3H )          ; minimum
           NS    ns1.example-domain.com.

ns1        A    192.0.2.1
There are three records in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 file. The first one defines zone itself, it is called Start of Authority, or SOA. The @ sign is shorthand for zone name and it is taken from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 /etc/named.conf file. Then, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is a continuation that defines name server (NS) for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 zone. It is continuation because cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 first column (where @ sign is) isn't defined so it is taken from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous record. Name server is ns1.example-domain.com. Finally, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is IP address of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 name server (A record). You should keep in mind that any name that doesn't end with dot is appended with a domain name. A lot of errors are caused by that omission. For example, if you wrote ns1.example-domain.com (without ending dot) this would translate into ns1.example-comain.com.example-domain.com. which is obviously wrong. But note that we are counting on this behavior in A records since we only wrote a name, without a domain!

The ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r zone files are similar to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous one and also have to be within /var/named directory. I.e. for local view of example-domain.com. cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 content of zone file is:
$TTL 1D
@    IN    SOA    @ root.example-domain.com. (
            2012062501 ; serial
            1D         ; refresh
            1H         ; retry
            1W         ; expire
            3H )       ; minimum
        NS    ns1.example-domain.com.

ns1        A    10.0.0.2
Note that it is almost identical, except that IP address for name server is now from a private range! Finally, here is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 content of zone that contains names from a local network:
$TTL 1D
@    IN    SOA    @ root.example-domain.local. (
            2012062501 ; serial
            1D         ; refresh
            1H         ; retry
            1W         ; expire
            3H )       ; minimum
        NS    ns1.example-domain.com.

test        A    172.16.1.1
Again, almost cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same. Note that I added one test record with phony IP address. This is so that I can test DNS server if it is correctly resolving IP addresses.

One final thing before starting DNS server! You should change file ownership and SELinux context. To do so, use cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following two commands (run cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m in /var/named directory):
chcon system_u:object_r:named_zone_t:s0 example-domain.*
chown root.named example-domain.*
The first command changes SELinux context, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 second one owner and group of files. So, it is time to start BIND, i.e. DNS, server:
/etc/init.d/named start
If cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re were some error messages, like cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following one:
zone example-domain.com/IN/internal: loading from master file example-domain.com.local failed: permission denied
zone example-domain.com/IN/internal: not loaded due to errors.
Then something is wrong. Look carefully what it says to you as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 error messages are quite self explanatory! In this particular case cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem is that DNS server can not read zone file. If you get that particular error message, check that SELinux context and ownership were changed properly.

Testing


Now, if you get just OK, it doesn't yet mean that everything is OK. You have to query server in order to see if it responds correctly. But, if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re were any errors, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y will be logged in /var/log/messages.

To test DNS server, use nslookup like this:
nslookup 127.0.0.1
Here, I assume you are testing on a DNS server itself. If you are testing on some ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r host cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n you should change address 127.0.0.1 with proper IP address of DNS server (public one in case you ask from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 internet, local one if you are asking from some computer in DMZ or local network). In any case you should receive correct answers. Here are few examples:
# nslookup ns1.example-domain.com 127.0.0.1
Server:        127.0.0.1
Address:    127.0.0.1#53

Name:    ns1.example-domain.com
Address: 10.0.0.2
# nslookup test.example-domain.local 127.0.0.1
Server:        127.0.0.1
Address:    127.0.0.1#53

Name:    test.example-domain.local
Address: 172.16.1.1
As expected, when internal host sends request internal IP address are returned. You should also check that any valid name is properly resolved (recursive queries). For example, you could ask for www.google.hr:
# nslookup www.google.hr 127.0.0.1
Server:        127.0.0.1
Address:    127.0.0.1#53

Non-authoritative answer:
www.google.hr    canonical name = www-cctld.l.google.com.
Name:    www-cctld.l.google.com
Address: 173.194.70.94
Which, in this case, resolves properly.

Now, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is a question how to test if names are properly resolved for clients on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet. The obvious solution is to try from some host on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet and see what's happening. In case you don't have host on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Internet, you can cheat using NAT. ;)

Do cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following. First, add some random IP address to your loopback interface, i.e.:
ip addr add 3.3.3.3/32 dev lo
Then, configure NAT so that any query sent via loopback gets source IP address changed:
iptables -A POSTROUTING -o lo -t nat -p udp --dport 53 -j SNAT --to-source 3.3.3.3
And now, try to send few queries:
# nslookup www.slashdot.org. 127.0.0.1
Server:        127.0.0.1
Address:    127.0.0.1#53

** server can't find www.slashdot.org: REFUSED
That one is OK. Namely, we don't want to resolve third party names for outside clients (remember, recursive is off!). Next test:
# nslookup ns1.example-domain.local. 127.0.0.1
Server:        127.0.0.1
Address:    127.0.0.1#53

** server can't find ns1.example-domain.local: REFUSED
This one doesn't work eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r. Which is what we wanted, i.e. our local domain isn't visible to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 outside world. Finally, this one:
# nslookup ns1.example-domain.com. 127.0.0.1
Server:        127.0.0.1
Address:    127.0.0.1#53

Name:    ns1.example-domain.com
Address: 192.0.2.1
Which sends us correct outside address.

So, all set and done. Don't forget to remove temporary records (i.e. test), iptables rule, lo address, and also don't forget to modify /etc/resolv.conf so that your new server is used by default by local applications.

Sunday, February 12, 2012

Who's listening on an interface...

While I was trying to deduce whecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r arpwatch honors multiple -i options and listens on multiple interfaces I had a problem of detecting on which interface exactly does it listen? To determine that, I started arpwatch in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following way:
arpwatch -i wlan0 -i em1
but that didn't report to me which interface did cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 command bound to. Using -d option (debug) didn't help eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r. So, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 first attempt was looking into files open by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 command. It can be done using lsof command, or by directly looking into aprwatch's proc directory. So, I found out PID (in this particular case that was 23833) of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 command (use ps for that) and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n I went into directory /proc/PID/fd. In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re, I saw cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following content:
# cd /proc/23833/fd
# ls -l
total 0
lrwx------. 1 root root 64 Feb 12 12:32 0 -> socket:[27121497]
lrwx------. 1 root root 64 Feb 12 12:32 1 -> socket:[27121498]
This wasn't so useful! Actually, it tells me that arpwatch closed it's stdin and stdout descriptors and opened only appropriate sockets to get arp frames. lsof command also didn't show anything direct:
# lsof -p 23833 -n
COMMAND    PID USER   FD   TYPE             DEVICE SIZE/OFF     NODE NAME
arpwatch 23833 root  cwd    DIR              253,2     4096   821770 /var/lib/arpwatch
arpwatch 23833 root  rtd    DIR              253,2     4096        2 /
arpwatch 23833 root  txt    REG              253,2    34144  2672471 /usr/sbin/arpwatch
arpwatch 23833 root  mem    REG              253,2   168512  2228280 /lib64/ld-2.14.90.so
arpwatch 23833 root  mem    REG              253,2  2068608  2228301 /lib64/libc-2.14.90.so
arpwatch 23833 root  mem    REG              253,2   235944  2675058 /usr/lib64/libpcap.so.1.1.1
arpwatch 23833 root  mem    REG                0,6          27121497 socket:[27121497] (stat: No such file or directory)
arpwatch 23833 root    0u  pack           27121497      0t0      ALL type=SOCK_RAW
arpwatch 23833 root    1u  unix 0xffff8802e3024ac0      0t0 27121498 socket
But it did show that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is a raw socket in use, but not anything more than that. So, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 next step was to find out how to list all raw sockets? netstat can list all open and listening sockets, so, looking into man page it turns out that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 option --raw or -w is used to show raw sockets, i.e.
# netstat -w
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State   
  
Well, neicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r this was very useful, but by default netstat doesn't show listening sockets so I repeated command adding -l option:
# netstat -w -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State     
raw        0      0 *:icmp                      *:*                         7
So, this is definitely not what I'm looking for. This RAW socket listens for ICMP messages, and arpwatch definitely isn't capturing those. In man page it also says that netstat looks for information about raw sockets from /proc/net/raw file, so I looked into its content:
# cat /proc/net/raw
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops
   1: 00000000:0001 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 47105 2 ffff880308e18340 0
Also not useful! There was inode listed (47105) but how to find out information about particular inode? I looked throughout /proc file system but didn't find anything. I also checked lsof manual but wasn't able to find something useful (though I didn't read manual from start to finish, I just search word inode!).

Then, I remembered that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is a ss command that is specific to Linux, and that is used to provide information about sockets! So, I looked into man page and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re it says that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 option -0 (or -f link) is used to show PACKET sockets, so I tried:
# ss -f link
Netid  State      Recv-Q Send-Q   Local Address:Port       Peer Address:Port
Again nothing, but it quickly occured to me that it doesn't show listening sockets by default, so I tried with -l (and -n to avoid any resolving):
# ss -f link -ln
Netid  State      Recv-Q Send-Q     Local Address:Port       Peer Address:Port
p_raw  UNCONN     0      0                      *:em1                    *    
p_dgr  UNCONN     0      0                [34958]:wlan0                  *
Woohoo, I was on something, finally! I see raw socket bound to em1 interface (note that I started arpwach with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 intention that it listens on wlan0 and em1 interfaces!) Only, I still don't know who is exactly using it. I only see that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r socket is datagram type, meaning network layer, and probably not used by arpwatch. man page for ss again helped, it says to use -p option to find out which process owns a socket, so I tried:
# ss -f link -lnp
Netid  State      Recv-Q Send-Q     Local Address:Port       Peer Address:Port
p_raw  UNCONN     0      0                      *:em1                    *      users:(("arpwatch",23833,0))
p_dgr  UNCONN     0      0                [34958]:wlan0                  *      users:(("wpa_supplicant",1425,9))
Wow!! That was it! I found out that arwatch is listening only to a single interface, and later I confirmed it by looking into cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 source! I also saw that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r socket is used by wpa_supplicant, i.e. for a wireless network management purposes.

One final thing bocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365red me. From where does ss take this information? But it's easy to find out that, use strace! :) So, using strace I found out that ss is using /proc/net/packet file:
# cat /proc/net/packet
sk               RefCnt Type Proto  Iface R Rmem   User   Inode
ffff880308cec000 3      3    0003   2     1 0      0      27121497
ffff880004358800 3      2    888e   7     1 0      0      25292685
Maybe I would get to that earlier if I had looked more closely into available files in /proc/net when /proc/net/raw turned out to be wrong file! But it doesn't matter, this search was fun and educative. :)

Tuesday, January 31, 2012

arpwatch on multiple interfaces

I'm regularly using arpwatch on all servers I install in order to track MAC changes and to notice potential MAC spoofings. But cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem is that on CentOS 6.2 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 startup script shipped with arpwatch (package arpwatch-2.1a15-14.el6.x86_64) doesn't support multiple interfaces. More specifically, I can tell arpwatch on which interface to listen by modifying OPTIONS variable in /etc/sysconfig/arpwatch file and inserting -i option. But, I'm still restricted to a single interface. That is, it is possible to specify multiple -i options, but arpwatch still listens only on a single interface. I checked that in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 source (version 2.1a15), and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 last -i command is in effect, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous one's are ignored.

So, I modified startup script so that it now accepts INTERFACES variable within /etc/syconfig/arpwatch configuration file and starts arpwatch on each specified interface. If this variable isn't defined cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n it behaves as before. For example, to start it on interfaces eth0 and eth1 you should add cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following line in /etc/syconfig/arpwatch:
INTERFACES="eth0 eth1" 
The basic idea behind this change is to start arpwatch tool multiple times, once per each specified interface. Also, to each instance I give different database (arp.dat) so that multiple instances don't overwrite each ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r data.

Note that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 script is a bit rough on edges, i.e. it properly behaves during startup phase, but not on shudown. Also, I embedded fixed path to data files. I'll improve this script in a due course when I find more time, or when it turns out that it's necessary to do so. :)

[20120203] Update: I had a an error in script because of which database files were placed in wrong directory and, as a consequence, arpwatch couldn't write database when it was exiting. Now, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 script is updated and it works, furcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rmore, I tested stoping arpwatch using that script and it also works

Tuesday, January 17, 2012

Interesting problem with OSSEC, active response and mail delivery...

We had a problem that manifested itself in such a way that mail messages didn't come from certain domains, or more specifically from certain mail servers. Furcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rmore, no clue was given in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 mail log to know what went wrong and to make things worse, logs from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 remote mail server were inaccessible to see cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re what actually happened. Finally, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 worse thing was that this happened sporadically. It turned out that this was consequence of a circumstances and a bug with ossec active response. This post explains what happened.

We changed DNS domain several months ago, let me call cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 new domain newdomain.hr, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 old one olddomain.hr. DNS was reconfigured so that it correctly handled requests for a new domain, but we had to leave old domain because of some Web server. The cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 old domain was changed so that when someone asked which is a mail exchanger for olddomain.hr it would receive response: mail.newdomain.hr. Finally, domain olddomain.hr was removed from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 mail server. This was cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 first error, and now I think that it is better eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r to leave old domain on mail server or to not return any response! Actually, if you want to get rid of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 old domain, it is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 best to remove it from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 mail server and that DNS server doesn't return any response for a mail exchanger of a given domain. If you know how mail works, you'll know that by changing MX record for old domain from mail.olddomain.hr to mail.newdomain.hr didn't change anything!

Anyway, that's cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 part concerning mail. Now, about OSSEC. It has a possibility of active response, i.e. to block offending IP addresses for a certain amount of time, 10 minutes by default. One class of offending IP addresses are those that try to deliver mail messages which require mail server to be open relay. Since mail server is properly configured it rejects those messages with a message 'Relay denied'. After mail server rejects  such delivery attempt OSSEC kicks in and blocks offending IP address for 10 minutes.

This, by itself didn't have to be a problem because blocking rules are automatically removed after 10 minutes. But, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is a bug in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 removal script that manifested itself in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 logs like follows (found on agent in /var/ossec/logs/active-responses.log):
Unable to run (iptables returning != 1): 1 - /var/ossec/active-response/bin/firewall-drop.sh delete - 203.83.62.99 1326738019.2370422 3301
For some reason removal of IP address from block list wasn't successful and that basically meant that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 source mail host is blocked indefinitely!

Majority of mail servers that to generate such 'Relay denied' messages are truly spammers and if some of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m were indefinitely blocked that was actually good. But, this particular source mail server that was blocked is very popular one with many users serving many different domains, so now when some ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r user tried to send an email that was legal and had correct address, IPtables blocked access and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 mail couldn't be delivered. There was nothing in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 logs of destination mail server. Also, sending user didn't receive any response message since mail was being temporary put on hold on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 source server.

This particular problem was solved by completely removing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 old domain. Now, source mail servers won't even try to deliver mails for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 old domain and thus OSSEC won't block legitimate servers. Furcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rmore, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 sending users will get notification immediately about non-existent mail address.

Tuesday, December 6, 2011

Problems with resolver library...

I just had a problem that manifested itself in a very strange way. I couldn't open Web page hosted on a local network, while everything else seemingly worked. The behavior was same for Chrome and Firefox. In due course I realized that every application had this problem. On cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r hand, resolving with nslookup worked flawlesly. This was very confusing. To add more to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 confusion, while running tcpdump it was obvious that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re were no DNS requests sent to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network! So, it was obvious that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem was somewhere in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 local resolver. At first, I suspected on nscd that was used as a caching daemon on Fedora, but in Fedora 16 this daemon is not installed. So, how to debug this situation? Quick google query didn't yield anything useful.

Reading manual page of resolv.conf cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is section that says that you can use directive option debug. But trying to do that yielded no output! Neicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re were any results using cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same option but via RES_OPTIONS environment variable. This is strange, and needs additional investigation as why it is so, and more importantly to know how to debug local resolver.

In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 mean time I figured out that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ping command behaves cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same as browser and since ping command is much smaller it is easier to debug it using strace command. So, while running ping via strace I noticed cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following line in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 output:
open("/lib64/libnss_mdns4_minimal.so.2", O_RDONLY|O_CLOEXEC) = 3
which immediately rung a bell that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem could be nsswitch! And indeed, opening it I saw cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following line:
hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname
which basically said that, if mdns4 returns not found dns is not tried. It seems that mdns4 is used whenever cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 domain name ends in .local, which was true in my case. So, I changed that line into:
hosts:      files dns
and everything works as expected.

Since I didn't install explicitly mdns, I decided to remove it. But cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n it became clear that wine (Windows Emulator) depends on it. So, I left it.

Tuesday, November 22, 2011

arping command

arping command is a very useful Linux command. It's purpose is to send ARP request on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 local network and to print received responses. It's a sort like ping command, but it works on layer 2 (data link layer) instead on a network layer like ping. Unlike ping command you have to specify egress interface to this command since ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rwise it doesn't know where to send request, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 command itself is programmed to send it to some predetermined interface, e.g. eth0.

Most frequently, you'll use it like this:
arping -I wlan0 192.168.1.1
which, in this particular case, tells arping command to send requests asking for a link layer address corresponding to IP address 192.168.1.1. Requests should go via wlan0 interface.

Now you may wonder what's so special about this command. Well, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 special part is that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is no way you can block it, unlike ping command. For example, Windows 7 by default blocks protocol packets used by ping command and thus you wont be able to check if host is alive using ping. With arping you can definitely determine if it is alive or not. But cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is a restriction, you can use it only on a local, Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet-like, network! So cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is no way it can be used over cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network, at least not without some heavy tricks. Additional restriction is that you need administrative (root) privileges on a host, unlike ping command that can be run by any user.

SSH TAP tunnels: Using routing instead of bridging...

In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous post about SSH tunneling, I used bridging functionality within Linux kernel in order to connect remote network with local laptop. But it is also possible to use routing in that case. The reason why you would prefer routing, instead of bridging, is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 quantity of traffic that might be flowing from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 remote network to your interface. And because you are probably connected with slower link than available bandwidth on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 local network itself, that could be a real problem. So, routing could help in this case. Note that you are loosing ability to use some protocols, most notably those that use broadcasting since routing code won't route those packets.

The idea is to use routing in combination with proxy ARP. Basically, everything stays cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same except you are not using bridging and you need to setup some basic forwarding features on remote host. So, here we go.

First add an explicit route for your remote host. That way it won't happen that you can not access it because cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 local network on which remote host is will be accessed in a special way:
ip route add remote_host via default_current_router
In case you don't know IP address of your default router (default_current_router) you can find it out using ip route sh command. And for remote_host you need to use IP address with network mask 32!

Now, log in to remote host using cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 usual ssh command that creates tap tunnel (for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 meaning of parameters and what happens see previous post):
ssh -C -w any -o Tunnel=ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet root@remotehost
After logging in, on local host add IP address from remote network that you are assigned when you directly connect on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 remote network. In our example network this is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 address 192.168.0.40/24 (see this previous post).

Now we have one interesting situation which I'm going to describe in some detail.

Start arping command on remote host like this (read this post about arping command):
arping -I tap0 192.168.0.40
Basically, you won't receive response. If you start tcpdump command, you'll notice that ARP requests are arriving, but cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are no responses. The reason why cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are no responses is because your local machine sees unexpected address in request and so ignores it.

You can turn on logging to see that those are really ignored with this command:
echo 1 > /proc/sys/net/ipv4/conf/tap0/log_martians
and now look into log file (/var/log/messages). You'll notice messages similar to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following ones:
Nov 22 14:37:25 w510 kernel: [147552.433215] martian source a.b.c.d from e.f.g.h, on dev tap0
Nov 22 14:37:25 w510 kernel: [147552.433221] ll header: ff:ff:ff:ff:ff:ff:16:90:4a:17:9d:d1:08:06
As you can see, it's called martian address. :)

Now, you can two options. The first one is to turn off filtering and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 second one is to assign IP address to tap0 interface on remote host too. In general I don't suggest that you turn off rp filtering, but since in this case we are turning it off on a special (and restricted) interface I'll go that route, and also to save one IP address. So, on local machine do cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following:
echo 1 > /proc/sys/net/ipv4/conf/tap0/rp_filtering
If you now try arping from local machine to remote machine, trying to reach IP address of remote machine, it won't work! You have to turn off rp filtering on remote machine too. So, execute cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous command cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re also.

One more thing for L2 part to fully work. When local machine asks from some address on local network, via tun0, remote host has to announce itself. For this purpose Proxy ARP is used but it has to be turned on. So, turn it on with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following command:
echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp
If you now try to "arping" any IP address, you'll aways get MAC address of tap0 on remote machine, and that's exactly what we wanted. But, you also need to do that because when machines on remote network search for you, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n remote host has to announce himself and relay/forward everything over cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 tunnel to you.
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
I'm assuming that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 interface name which attaches remote host to local network is named eth0, and I'm also assuming that you didn't create bridge device and attached eth0 to it (as it was described in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 previous post).

Ok, time for L3 part. Everything has to be done on a remote machine. So, on a remote machine, first tell it that 192.168.0.40 is attached to tap0 interface:

ip route add 192.168.0.40/32 dev tap0
Next, allow IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
And that's it. Only what's left is to automate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 whole procedure.

About Me

scientist, consultant, security specialist, networking guy, system administrator, philosopher ;)

Blog Archive